Perspective

Most engineering teams are not as productive as leadership thinks

Engineering delivery

One of the most consistent findings when I assess an organization is the gap between what an engineering team appears to deliver and what it is actually capable of delivering. Leadership usually reads the team as at or near capacity. The team usually feels it is being asked for too much with too little. Both are right, in different ways, and the gap between them is where the real problem lives.

The causes are rarely effort. They are unclear priorities that send people in three directions, constant context switching, thin tooling, and technical debt that taxes every sprint before any new work begins. The honest complication is that engineering output is genuinely hard to measure, which is why the gap goes unexamined for so long. As the Stack Overflow team has written, a developer's real contribution is not something an outside observer can read off a count of commits or lines, because the work is interdependent. The engineer who quietly unblocks everyone else, or who keeps the codebase clean enough for the rest of the team to move fast, produces enormous value that never shows up in an individual metric. So leadership measures the visible activity, draws the wrong conclusion about capacity, and the gap persists.

Closing it does not start with a productivity dashboard. It starts with understanding where the time actually goes. When I look at a team that feels stuck, I trace a few real weeks: how much went to planned work, how much to interruptions, rework, and waiting on decisions. That picture almost always points at the constraint, and it is rarely that people are not working hard enough. It is usually that the system around them is making good work expensive.