Why Your 40-Engineer Team Is Shipping Like 25

Steve Taplin is CEO & founder of Sonatafy Technology, a software consulting & engineering firm focused on delivery, quality & accountability

Most software engineering leaders think they have a talent problem. After interviewing more than 180 CTOs on my podcast and working with dozens of scaling software organizations, I have come to believe something different. They have a coordination problem. And it is costing them far more than they realize.

I call it the coordination tax. It is the invisible overhead that accumulates whenever a new engineer is added to a team beyond a certain inflection point. The math is unforgiving. Each additional engineer introduces roughly 15% to 25% of coordination overhead while delivering only 5% to 10% of net output gain. Somewhere between engineer 15 and engineer 25, the curve inverts. You are paying for more headcount and receiving less throughput.

Nobody puts this on the P&L, but it is there.

The Hidden Math On A 30-Person Team

Consider a typical growth-stage software organization with 30 engineers. Fully loaded, that team represents somewhere between $6 million to $9 million in annual cost. If even 15% to 20% of that capacity is being absorbed by coordination overhead (meetings that exist to align people who should not need to be aligned, handoffs between teams that should own the work end to end, context switching caused by fuzzy decision authority), you are looking at $900,000 to $1.5 million per year in waste. Per year. Every year.

And the number grows, not shrinks, as you hire.

This is the part most leaders miss. Adding engineers does not dilute the coordination tax. It compounds it. The communication overhead of a team scales quadratically, not linearly, because each new person must synchronize with everyone already there. You do not feel this with 10 engineers. You start to feel it at 25. By 50, it has quietly become the largest single line item in your engineering budget, and it does not appear anywhere in your financial reporting.

Why Leaders Misdiagnose It

When delivery slows, most CTOs reach for one of three explanations: 1)The engineers are not senior enough; 2) the tooling is not good enough; or 3) the process is not rigorous enough.

So they hire more senior engineers. They buy more tools. They add more process. And the problem gets worse.

The reason is that none of those three things is the actual constraint. The actual constraint is that the work requires too many people to agree before anything can move. Every decision touches three teams. Every PR touches two codebases. Every road map commitment depends on four dependencies that nobody owns. You do not have a talent shortage. You have an authority shortage.

I have watched organizations triple their engineering headcount over 18 months and ship measurably less software at the end than they did at the start. The engineers were not worse. The coordination burden was heavier.

Three Places The Tax Shows Up

In my conversations with engineering leaders, the coordination tax tends to hide in the same three places.

The first is the weekly calendar. If your senior engineers spend 40% or more of their time in synchronous meetings, that is not a collaboration pattern. That is a symptom of too many decisions requiring group consent. Strong organizations push decisions down to the person closest to the work and accept the occasional wrong call as the price of speed.

The second is the PR review queue. When pull requests sit open for days waiting for review from people outside the contributing team, you are paying the tax. The fix is not faster reviewers; it is fewer cross-team dependencies in the code itself. Architectural choices create or eliminate coordination overhead long before a PR is ever opened.

The third is the backlog. Backlogs that grow faster than teams can burn them down are rarely a prioritization problem. They are an ownership problem. Work sits in the backlog because no single team has the authority to finish it without involving three others. In the engagements I have seen succeed, clients have cut backlogs by as much as 45% after redesigning ownership, not priorities.

The Structural Fix

The instinct when you finally see the tax is to fix it with process. Add a RACI. Tighten the standup. Institute an architecture review board. This rarely works because the coordination tax is created by structure, not behavior. A process layered on top of a bad structure makes the tax heavier, not lighter.

The real fix is to redesign the work so that a single team, with clear decision authority, can own an outcome end to end. That often means fewer, smaller teams with broader scope rather than more, larger teams with narrower scope. It means treating coordination as a cost to be minimized rather than a virtue to be celebrated. And it means giving one human the authority to make the call when the work stalls rather than waiting for a consensus that will never come.

The Choice In Front Of You

If your organization has 25 to 200 engineers and delivery has gotten harder as you have scaled, you are almost certainly paying this tax. The question is whether you keep hiring through it or fix it first.

Hiring through it is the default. It is also the more expensive path, because every new engineer you add makes the tax heavier for everyone already on the team. Fixing it first is harder to sell internally because it requires redesigning teams rather than adding to them. But the math is clear. A 30-engineer team that recovers even half of its coordination overhead ships like a 40-engineer team, at a 30-engineer cost.

That is not a talent win. That is a structural win. And it is available to anyone willing to stop asking how many more engineers they need and start asking why the ones they already have cannot get the work done.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?