The Frictionless Seven-Step DevX Program
A start-anywhere playbook to stand up a developer-experience initiative
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 7
- Confidence
- 95%
A seven-step process for launching and running a developer-experience improvement program, designed so you can enter at whichever step matches your situation. It sequences from listening, to a quick win, to data, to strategy, to selling that strategy, to driving change at your scope, to proving value and looping back. Use it to remove friction along the value stream in an AI-accelerated org.
Origin
This is the backbone of Forsgren's forthcoming book Frictionless, co-authored with Abi Noda of DX (recently acquired by Atlassian). It synthesizes interviews with hundreds of engineering leaders, CTOs, and devs to validate the 'smells' the steps address.
Core principles
- 01You can jump into whichever step matches where you are right now
- 02Get a visible quick win before asking for data or budget
- 03Deciding strategy comes AFTER you have data, not before
- 04Driving change differs by scope — grassroots (local), top-down (global), or hybrid (middle)
How to run it
- 1
Start the journey
Run a listening tour, synthesize what you learn, and visualize the current workflow and tools to understand the present state.
Pro tip If you're kicking off a new team or initiative, you should definitely start here.
- 2
Get a quick win
Start small, pick the right project, deliver a visible improvement, and share it out to build momentum.
Pro tip A small local win could be as simple as cleaning up a flaky test suite that any team can do.
- 3
Use data to optimize the work
Establish a data foundation, find existing data, start collecting new data, and use surveys for fast insight.
Pro tip Surveys give a quick landscape view when you lack instrumentation.
- 4
Decide strategy and priority
With data in hand, evaluate the remaining broken things and choose what to do next using evaluation frameworks.
- 5
Sell your strategy
Convince stakeholders: gather feedback and articulate why this is the right strategy right now.
- 6
Drive change at your scale
Use grassroots tactics if you have local scope, top-down levers if you have global scope, and blend both if you're in the middle.
- 7
Evaluate progress and show value
Measure impact, demonstrate value, then loop back to the earlier steps.
Pro tip Improvements tend to follow a J-curve — quick wins, then a dip as low-hanging fruit runs out, then compounding gains once you build telemetry and infrastructure.
In the wild
A company had a dreaded process on an old mainframe: someone printed a document, walked it down three or four flights for approval, then walked it back up. Everyone assumed the whole system needed replatforming, so nobody touched it. The actual fix was to change the process to send an email — no replatform, no redesign.
→ A hated, slow process was fixed with a lightweight process change instead of a major engineering project.
Common mistakes
Running it as an isolated side project
If the effort feels like just another internal project that won't matter or get celebrated, momentum dies — leaders must provide structure, communicate priorities, and celebrate wins.
Making simple up-front mistakes
Even smart teams new to the space make early errors that force a restart later — starting at step one avoids this.
Is it for you?
Best for
Technology leaders and PMs kicking off or joining a developer-experience improvement program
Not ideal for
Individual contributors with no mandate or scope to change processes or tooling
From the transcript
“Step one is to start the journey”
“step two is to get a quick win”
“step three is using data to optimize the work”
“step four then is to decide strategy and priority”
“Step five is to sell your strategy”
“step six is to drive change at your scale”
“step seven is to evaluate your progress and show value”
From the episode
How to measure AI developer productivity in 2025
Nicole Forsgren