There's a version of the productivity conversation that blames engineers. They're not focused enough, not using the tools, not moving fast enough. It's a comfortable story for leadership because it locates the problem somewhere else.
It's also almost always wrong.
When engineers are slow, the cause is usually a thicket of friction they didn't create and can't fix on their own: a flaky build, a fifteen-minute local setup, an ambiguous ownership boundary, three approvals for a one-line change. Every one of those is the residue of a decision someone above them failed to make.
Friction is a leadership artifact
Think about what it actually takes to ship a change in your organization. Trace the path from idea to production and count the places an engineer waits, retries, or asks permission. Each of those is a tax, and engineers pay it dozens of times a day.
They didn't choose that tax. Someone decided — or failed to decide — that the build pipeline could stay flaky, that the staging environment could stay unreliable, that the approval process could keep growing. The friction is real, but it's not the engineers' doing.
Every hour an engineer fights the toolchain is a decision someone above them failed to make.
Treat developer experience as a product
The organizations that take this seriously do something specific: they fund developer experience as a first-class investment with real ownership, the way they'd fund any product that matters.
That means:
- A team that owns the internal developer platform and treats engineers as its customers.
- A roadmap driven by where engineers actually lose time, not by what's fun to build.
- A budget that reflects the leverage — because a small improvement multiplied across every engineer, every day, is enormous.
This isn't a perk. It's one of the highest-return investments available to an engineering organization, and it's invisible only because nobody bills for the hours it saves.
Measure flow, not activity
The fastest way to ruin a productivity effort is to measure the wrong thing. Count commits or lines and you'll get more commits and lines, and no more value. Worse, you'll teach your best people that the game is gamed.
Measure flow instead:
- How long does a change take from start to production?
- How often can teams deploy with confidence?
- Where, specifically, do engineers report losing time?
Then fix the biggest source of friction, measure again, and repeat. Honest measurement is what separates a real program from a dashboard nobody trusts.
The return
When you remove friction, you don't just get faster delivery. You get engineers who feel respected — who can tell that leadership noticed the daily papercuts and did something about them. That feeling is its own form of leverage. People do their best work when the path to doing it isn't an obstacle course.
Productivity isn't something you demand from engineers. It's something you build for them. And building it is leadership's job.