There is a meeting that happens in every company. Someone asks why the team is not shipping faster. Someone suggests hiring more people. Almost nobody asks the cheaper question first: what is slowing down the people we already have?
I want to talk about developer experience, DevEx for short. Not the marketing version of it, with beanbags and free snacks. The real version. How long does a build take. How often do tests fail for no reason. How many days does a new hire wait before they can run the app locally. How many approvals does a one line change need.
These sound like small annoyances. They are not. They are payroll burned.
The math is brutal and nobody runs it
Take a simple example. A build takes 25 minutes. A developer triggers it maybe 8 times per day. Even if they multitask during part of it, the context switching alone eats real focus time. Multiply by 40 developers, by 230 working days, by what a developer hour costs your company. The number that comes out is usually bigger than the salary of the platform engineer who could fix the build. The fix pays for itself, and then keeps paying every year.
Flaky tests are even worse, because they do double damage. First, the rerun time. Second, the trust damage. When tests fail randomly, people stop believing them. They start clicking rerun without reading the failure. Then one day the failure is real, and it sails into production wearing a flaky test costume. Now you have an incident on top of the wasted time.
I learned to see this clearly back when I ran my company in Brazil. With a tiny team, every wasted hour was visible. There was no slack to hide it. A slow deployment process did not feel like an abstraction, it felt like staying at the office until 11 pm. Big companies have the same waste, just spread thin enough that no single person feels responsible for it.
SPACE, or how to measure without being stupid about it
In 2021, Nicole Forsgren and other researchers published the SPACE framework. I like it because it pushes back on the dumbest idea in our industry, measuring developers by lines of code or ticket counts. SPACE says productivity has five dimensions: Satisfaction, Performance, Activity, Communication, and Efficiency of flow. The point is not to track all five perfectly. The point is that any single number lies to you.
The same researchers were behind the Accelerate book and the DORA metrics: deployment frequency, lead time for changes, change failure rate, and time to restore. These four are the closest thing we have to an honest scoreboard for a delivery team. Notice what they measure. Not effort. Not busyness. Flow. How fast does an idea become safe running software.
Here is the part leaders miss. Those metrics are mostly determined by the environment, not by individual talent. You can hire brilliant people and put them in a system with a 3 day code review queue, a manual deployment ritual, and a staging environment that is broken every other week. Their metrics will look mediocre. The system ate their talent. Martin Fowler has years of writing about this, the design of the delivery system is itself an engineering problem, and probably the highest leverage one.
Retention is where the real money is
Now the part that finance people should care about most. Replacing a developer is shockingly expensive. Recruiting takes months. Then the new person needs more months to learn the domain, the codebase, the tribal knowledge that lives in nobody’s documentation. Industry estimates usually land between 6 and 12 months of salary in total cost, and for senior people who carry deep system knowledge, I think that is optimistic.
And why do developers leave? Money matters, sure. But in every exit conversation I have witnessed over the years, frustration with the daily work shows up more than salary. Nobody writes “the compensation was fine but I spent half my life fighting the CI pipeline” in the official survey. They say “looking for new challenges.” The flaky tests do not appear in the exit interview. They appear in the resignation date.
So bad DevEx hits you twice. The people who stay produce less than they could. The people who leave take expensive knowledge with them, and you pay again to rebuild it.
What I actually push for
I am a Senior developer, not a magician, so my tool is mostly persuasion with numbers. A few things that work:
- Measure the boring stuff. Build time, test flake rate, time from commit to production, onboarding time to first merged PR. You cannot argue about what you do not measure.
- Translate to money before presenting. “The build is slow” gets a shrug. “We burn around 30 hours of engineering time per week waiting” gets a meeting.
- Fix the top one thing per quarter. Not a giant DevEx initiative with a steering committee. One painful thing, fixed properly, every quarter. Compound interest does the rest.
- Ask new hires what shocked them in week two, before they get used to the pain. Fresh eyes are a free audit, and they expire fast.
The title of this post says happy devs ship more, and I want to be precise about what happy means here. Not pampered. Not entertained. Happy in the craftsman sense, able to do good work without the tools fighting back. That kind of happiness is not a perk. It is throughput, retention, and quality, all wearing one face.
The cheapest team upgrade is usually not a new hire. It is removing the things that waste the team you already pay for.
Pax et bonum.