How to Improve Developer Productivity: It’s a Leadership Problem, Not a Tooling One

Search “how to improve developer productivity” and the first page of Google is almost all the same thing: a software company selling you a dashboard. Measure your deployment frequency. Track your cycle time. Buy the tool, watch the metrics, and productivity follows.

I ran engineering for years believing some version of that. I chased the numbers I could see and assumed a busy team was a productive one. Every dashboard was green and I still couldn’t tell you if we were building anything that mattered.

Here’s what I eventually figured out.

You can buy every tool on that first page of Google and still have a slow team, because the thing slowing it down sits upstream of any dashboard.

That thing is leadership. Most of the time, the biggest drag on a team’s output has nothing to do with the editor they code in or some metric you forgot to track. It comes from an unclear goal, a shifting set of priorities, and a team that doesn’t really know why it’s building what it’s building. I’ve run engineering at three companies and built a team of more than 350 people at Full Scale, and the pattern holds everywhere. Fix the leadership and the productivity shows up. Skip it, and no tool saves you.

This is a guide for the people who own that outcome: chief technology officers (CTOs), VPs and directors of engineering, engineering managers, and technical founders, not the individual developer hunting for personal workflow hacks. The levers that actually move a whole team are different ones, and almost nobody writes about them.

Why most advice on how to improve developer productivity misses

Look at who writes the top-ranking articles on this topic and you’ll mostly find engineering-metrics companies. They sell dashboards, so naturally they tell you the answer is a dashboard. I don’t think that’s a conspiracy. It’s just incentives at work, because when you sell measurement tools, every problem starts to look like a measurement problem.

The trouble is that measuring something doesn’t improve it. A scale doesn’t make you lose weight. You can instrument your team six ways and still ship slowly, because the numbers describe the symptom and leave the cause alone. If you do put numbers on a dashboard, pick the few software development metrics that actually predict performance instead of the ones that just look busy.

The people who built the leading productivity frameworks already admit this. The DevEx (developer experience) model, written by the same researchers behind the well-known DORA (DevOps Research and Assessment) and SPACE frameworks, says the real drivers of productivity are feedback loops, cognitive load, and flow state. Read that list again. Every one of those is a condition leadership creates or destroys: how fast a developer hears whether their work was right, how much junk they have to carry in their head, whether they get a clear stretch of focus to think. You can’t buy any of that in a box.

There’s also a fight in the industry that tells you how contested this is. When McKinsey published a piece arguing you can measure developer productivity like a factory line, Kent Beck and Gergely Orosz tore it apart, warning the approach measures activity instead of outcomes and would do more harm than good. The loudest voices in software already rejected the premise the rest of the SERP is built on.

To be clear, measuring matters. You should track delivery, and you should know which metrics are honest and which ones get gamed. I just don’t want to re-fight that battle here, because we wrote a whole post on why most teams measure software engineering productivity wrong. This post is about the cause behind the numbers, not the scoreboard.

Developer productivity is a leadership problem, not a tooling one

For most of my career, when a team was slow, I looked everywhere except the obvious place. I’d reach for better tools, more process, or a new project management board, when the honest answer was usually closer to home.

At Stackify, my COO Craig sat me down and told me I was the bottleneck. He handed me a copy of Rocket Fuel by Gino Wickman and explained the difference between a visionary and an integrator. I was so busy being in the middle of everything that the team couldn’t move without me. I was the ceiling on what they could do, and I had no idea.

That’s the part the dashboard never shows you.

Leadership maturity is the cap on product maturity.

A team can’t think more clearly than its leader communicates. It can’t move faster than its priorities are stable. When output is low, the reflex is to push the developers harder. The more useful question is whether the people setting direction gave them anything clear to run at.

Laura Tacho, the CTO of the developer-productivity company DX, put a number on it on our Product Driven podcast. Her research across hundreds of companies found developers lose about 20% of their week to inefficiency, bad process, and poor tooling. As she put it, most of that “is really organizational friction,” the cost of everything the rest of the company does around the engineers. That waste doesn’t come from developers slacking. It piles up around them, and clearing it is a leadership job.

There’s a worse version of slow that no metric catches.

The most expensive thing a fast team can do is build the wrong thing.

You can ship quickly, hit every deadline, and still waste a year. Pendo found that 80% of software features are rarely or never used. The Project Management Institute (PMI) found that 47% of projects that miss their goals do so because of poor requirements management. A team can be busy, efficient, and well-tooled while it sprints toward something nobody needed. Speeding that up only makes the waste bigger. Productivity that points the wrong direction is just expensive motion.

The Product Driven model: five levers that move developer productivity

If the bottleneck is leadership, then improving developer productivity is mostly about leading better. I wrote a whole book on how, called Product Driven, and the model in it comes down to five things engineering leaders are responsible for. Each one is a lever on how much a team actually gets done. It is also why I am skeptical of hiring a so-called 10x developer to fix things, since most of the gap comes from the environment a team works in, not the individual. The same logic drives how to build a team of 10x engineers: set the conditions and the output follows.

Vision: a team that sees the why moves faster

Engineers waste enormous energy when they don’t understand the goal. They build defensively, ask for permission, and second-guess decisions that should be easy. Give them the reason behind the work and they stop waiting. The faster a team understands why something matters, the faster it can move together without checking in at every fork. Good vision shows up in the decisions people make when you’re not in the room, long after the kickoff meeting is over.

Focus: protect the team from the wrong kind of urgency

A slow team is usually a scattered one. Every new “urgent” request from a stakeholder pulls someone off the thing that actually matters, and a developer who switches context five times a day never gets into the deep work where real progress happens. Focus is a leadership job. It means saying no to the wrong things and shielding the team from churn so the people doing the work can stay on it long enough to finish. Protecting that focus is one of the challenges every CTO runs into as the team grows.

Clarity: unclear work is a tax you pay in rework

A team needs three kinds of clarity, and missing any one of them slows everything down. There’s product clarity (what we’re building and for whom), scope clarity (what’s in and what’s out), and technical clarity (how it fits the system). When any of those is fuzzy, engineers fill the gaps with guesses, and half of those guesses are wrong. Wrong guesses get built, then ripped out and rebuilt, which is how unclear work turns into technical debt you pay down for months. It’s the same poor requirements management that sinks so many projects. Clarity isn’t a kickoff doc you write once. It’s a daily habit of giving people just enough context to decide well on their own.

Ownership: owners outproduce order-takers

This is the big one.

Engineers who think like owners outperform the ones who wait for tickets.

When I started VinSolutions, I didn’t write tickets for myself or wait on a product manager. I’d talk to a customer in the morning and ship a fix that afternoon. That’s the productivity ceiling of a single engaged owner, and it’s enormous. The job of an engineering leader is to build that same ownership across a whole team, so people care about the outcome and not just the task. A team that owns the problem makes better decisions, because they’re solving for the customer instead of clearing a queue. The most productive thing I ever did as a leader was stop trying to carry the work myself and start making other people more capable of carrying it. That’s also how you keep a team motivated instead of grinding it down.

Courage: safety to push back saves you from building junk

A team that’s afraid to speak up will build whatever you tell them, including the wrong thing. Psychological safety is what lets an engineer say “this requirement doesn’t make sense” before the sprint instead of after. That single conversation can save weeks. You build that kind of courage by rewarding the truth instead of punishing it, so the person who spots the problem feels safe enough to actually say so.

Drive real urgency, the lever nobody on that first page mentions

Here’s the one that almost no productivity article will tell you, and it’s near the top of my own list.

Drive a real sense of urgency.

Work expands to fill the time you give it. Parkinson’s Law named this back in 1955, and it still holds. If you hand a team a vague timeline, the work stretches to match it. Give people a real deadline and the same work gets done in a fraction of the time, because a deadline forces the small decisions that open-ended work lets people avoid.

My favorite way to do this doesn’t involve imposing a date from above. I ask the engineer how long they think it’ll take. Then I hold their feet to the fire on their own number. The estimate is theirs, so the commitment is theirs, and most people will move heaven and earth to hit a deadline they set themselves. You get the urgency without the resentment that comes from a date handed down by someone who isn’t doing the work.

There’s a real tension here, and it’s worth naming. The Focus lever above is about protecting the team from urgency, and now I’m telling you to create it. The difference is the kind of urgency. Bad urgency is manufactured panic: a stakeholder’s last-minute request, a fire drill that scatters everyone, pressure for its own sake. Good urgency is a real, owned deadline on the right work. One destroys focus. The other concentrates it.

The guardrail matters as much as the lever.

You can absolutely push too hard. A constant state of emergency doesn’t make a team faster, it burns people out and your best engineers leave, which is the most expensive productivity loss there is. Urgency is a dial, not a hammer. The goal is a team that feels a healthy push toward a finish line, not one that’s sprinting toward burnout every single week.

AI won’t fix an unproductive team

Every competitor post now has an AI section that says the same thing: adopt the tools and watch productivity climb. The data tells a more honest story.

In an early-2025 study, METR found that AI tools made experienced developers about 19% slower on real tasks in code they knew well, even though those same developers believed AI had sped them up by 20%. It was a small study of seasoned engineers working in familiar code, so I wouldn’t lean too hard on the exact figure. The part that sticks is the perception gap. People felt faster while they were actually moving slower.

It gets more pointed at the team level. The 2024 DORA report found that as AI adoption went up, delivery throughput and stability went down, even though most developers reported feeling more productive. On the 2025 Stack Overflow survey, 84% of developers use or plan to use AI, but close to half don’t trust the accuracy of what it produces, and the top frustration (66%) is AI solutions that are “almost right, but not quite.” Almost right is exactly the kind of bug that’s expensive to find.

The clearest summary comes from DORA’s 2025 report.

AI amplifies what’s already there.

On a well-led team with clear goals and strong ownership, AI is a force multiplier. On a chaotic team that doesn’t know what it’s building, AI just helps it build the wrong thing faster. The tool magnifies your leadership, good or bad. At Google Cloud Next in 2026, Sundar Pichai said about 75% of Google’s new code is now AI-generated. Even there, a human engineer still owns the judgment on what actually ships. If you want the longer version of this, we wrote it up in how AI is really affecting developer teams. That’s why engineering leadership is really a force-multiplier job: the job is making everyone else more productive.

More developers won’t fix it either, especially cheap ones

When output lags, the other reflex is to add people. If five developers ship slowly, ten will ship faster, right?

Usually not. Adding bodies to a team with unclear goals and weak ownership just multiplies the confusion. Now you have twice as many people building the wrong thing, and a leader who’s even more stretched than before. More headcount on a broken system gives you a bigger broken system. Fred Brooks made this point back in 1975: adding people to a late software project tends to make it later.

The version of this that fails hardest is hiring on price alone. I call it cheapshoring: going offshore purely to get the cheapest possible developer, with no thought to how the team is led or whether anyone owns the outcome. You end up with cheap bodies and the same leadership gap you started with, plus a time zone in between. Cost is a fine reason to hire offshore. It just can’t be the only one.

The model that actually raises a team’s output is the opposite of throwing cheap bodies at it. Bring on senior engineers who join your team, your standups, and your process, and who own the work like employees instead of taking orders like a project shop. That’s staff augmentation done right. When AMC Theatres added Full Scale developers in the Philippines, the engineers worked as full members of the AMC team rather than an outside vendor. As their leader Derrick Leggett put it, “It’s a fully integrated team. It’s just some of the people happen to be living in the Philippines.” That’s also why we keep 93% of our developers year over year. People who own their work and feel like part of a real team don’t leave, and a team that stays together is far more productive than one that turns over every nine months. Infrastructure roles follow the same pattern. When you hire DevOps engineers from the Philippines through Full Scale, they join your standups, own your pipeline, and stay the same way your product engineers do.

How to improve developer productivity, starting Monday

If you want concrete ways to improve developer productivity this week, here’s the list. Notice that none of them are tools.

• Make sure every engineer can explain why the current work matters. If they can’t, that’s your vision gap to close.
• Cut the number of things in flight. Protect at least one long block of focus time a day from meetings and “quick” interruptions.
• Tighten clarity before the sprint, not during it. Spell out what’s in scope, what’s out, and how it fits the system.
• Push decisions and ownership down. Let engineers shape the work, not just execute it, and hold them to outcomes instead of tasks.
• Ask people for their own estimates, then hold them to a real deadline. Drive urgency without manufacturing panic.
• Watch for burnout as closely as you watch velocity. The dial only works if you don’t break the team.
• Treat AI and new tools as a multiplier on the above, not a substitute for it.

Every one of those is a leadership move, and that’s the whole point. Each will do more to increase developer productivity than any dashboard you could buy, because they fix the thing sitting upstream of the tools. If you’re a CTO weighing where to spend your energy this quarter, these are the challenges worth your time.

Improve your team’s productivity with engineers who own the work

The fastest way to raise your team’s output is rarely another tool. It comes down to clearer leadership and people who own what they build. If you want senior engineers who join your team and treat your goals like their own, let’s talk about how Full Scale can help.