I see this pattern in almost every client engagement I take on. A team has paid top of the market for senior engineers, the people on the team are genuinely good, and yet feature delivery is two or three times slower than those engineers would tell you they could ship if they were allowed to. The cause is almost never the engineers. It is the conditions they are working in.
The shorthand I use for this is that an engineer’s true cost to the business is not their salary. It is the salary plus the work they are not doing because the conditions are stopping them. A six-figure engineer producing four hours of focused work per week (a number I have seen often enough that it does not surprise me any more) is costing the business several multiples of their compensation in opportunity.
The arithmetic of squandered capacity
The maths aren’t subtle. If you employ ten engineers at £100,000 each, you spend £1m a year on engineering salaries. That’s the line item your finance director cares about. What does not appear on the line item is the value of what those ten engineers are not building because they are spending two-thirds of their time fighting their environment.
The split varies between organisations, but a working number for SME engineering teams I have worked with looks something like this. Out of a notional 35 working hours a week, around eight are spent in meetings that did not need to happen, four are spent waiting for builds and tests that should not take that long, three are spent on environment setup that should have been automated, and another three or four are lost to context-switching between tools that do not talk to each other. What is left, on a good week, is ten or twelve hours of focused engineering. On a bad week, closer to five.
That ratio is what I mean by “operating at 20% capacity.” It is not about effort. It is about what the environment allows them to do with the time you are paying for.
Three-quarters of your engineering budget is not buying you engineering. It is buying you a tax on your engineers’ time that they would happily give back to you if you let them.
What this looks like in the building
I will not put fictional people on the page. Instead, here are the three patterns I see most often when I sit with engineering teams during the early phase of a consulting engagement.
The first is environment friction. The build pipeline that takes ninety minutes. The local development environment that needs to be rebuilt every time someone touches a config file. The deployment process that requires a developer to follow seventeen manual steps in the right order or end up with a broken environment. None of these are visible to leadership because the developers shoulder the cost.
The second is tool sprawl. Tickets in one place, documentation in another, code review in a third, build status in a fourth, deployment status in a fifth, and an internal Wiki that nobody trusts because half the pages are out of date. Every action that should be one click is three or four. Multiply that across thirty actions in a day and the friction becomes the job.
The third is meeting culture that has lost track of what meetings are for. The kickoff before the planning before the planning. The standup that became a status report. The architectural review that runs ninety minutes because nobody knows who decides. Most engineering teams I have worked with would get more done with half the meetings and clearer decision rights. (I wrote about that pattern at length in the too-many-waiters series.)
If you recognise more than one of those in your own team, you are not the exception. That is what most engineering teams look like.
How the gap widens over time
The compounding works in both directions. A competitor with a healthier engineering environment ships a feature every two weeks while your team ships one a month. Over a year that’s twenty-six versus twelve. Over two years they have a product that is qualitatively different from yours, not because their engineers are better than yours, but because their engineers are being allowed to do their jobs.
That delta also affects the recruiting market. Strong engineers talk to each other. The story about your build pipeline gets out. The team that should have been your top hire takes the other offer.
What to do this week
The pattern I have seen work, repeatedly, looks like this.
Survey your engineers anonymously about where their time goes. Ask three questions and resist the temptation to add more. How many hours of focused engineering work did you do this week? What was the single biggest waste of your time? What would you fix this week if you had the authority?
The answers will surprise you. They are usually directionally consistent with the patterns above, which means there is a small number of things to fix and the engineers already know what they are.
Pick the one with the highest leverage and the lowest cost to address. For most teams that is meeting reduction; for some it is the build pipeline; for a few it is tooling fragmentation. Whichever it is, ship the fix in a two-week window and tell the team you did it because of their survey responses. That alone changes how the team behaves on the next survey, because they now know it counts.
Then do it again with the next item. The maths work in your favour as well as against you. Teams that systematically remove friction become quietly faster; the difference is visible inside a quarter.
Your move
I run engagements that do exactly this work, in the form of a workshop and follow-on retainer. The workshop is a day. The brief is to audit the current state of your engineering environment with a live engineering survey and produce a costed roadmap of the things worth fixing first. It typically finds an order of magnitude more wasted weekly capacity than the cost of the engagement.
If that conversation sounds useful, let’s talk.