A product team splits its work across two cities on opposite sides of the Atlantic. Revenue is growing. The roadmap is full. Delivery is slowing anyway. The CTO’s answer is six more engineers.

It sounds rational until you look at where the time is already going. A mixed-methods study of global software engineering teams found employees spent an average of 7 hours 45 minutes a week in scheduled meetings and another 8 hours 54 minutes in unscheduled ones, 16 hours 36 minutes of meetings a week overall.

The company may not lack people. The people it already has may be spending too much of the week coordinating one another.

— Anderson Oz’

From the Operator’s Desk

Case in Point

What leadership believed: More work on the roadmap means more people are needed to ship it.

What broke: More contributors created more dependencies. Senior staff became approval bottlenecks. Rework spread across teams. Distributed teams lost the speed of informal, in-person communication. Low-output contributors consumed management capacity disproportionate to what they shipped.

The reality: Microsoft surveyed 775 software engineers on how coordination actually happens. The most common coordination objects were schedules and features, not code or interfaces, and direct communication, not more process, was what made cross-team interaction work.

The lesson: Before approving headcount, measure how much of the existing team’s capacity is already being spent coordinating the work.

The Evidence Stack

• 775 Microsoft engineers: Surveyed on coordination across large engineering teams; the most common coordination objects were schedules and features rather than code, and personal contact improved cross-team interaction more than added process did (Microsoft Research).
• 16h 36m a week: Average time global software engineering employees spent in meetings, 7h 45m scheduled, 8h 54m unscheduled, with distributed teams running significantly larger than co-located ones (Journal of Systems and Software, Stray & Moe, 2020).
• 46 publications, 2001–2013: A systematic literature review found geographical dispersion tends to hurt both team performance and software quality, while temporal dispersion (time-zone spread) tends to hurt software quality specifically (Information and Software Technology, Nguyen-Duc et al., 2015).
• 300-person team, three sites: A Microsoft engineering group in Redmond, coordinating with dependent teams in Redmond, Boston and Hyderabad, found coordination was most impacted by communication, capacity and cooperation gaps, worsened by time-zone and cultural differences (Microsoft Research).

Companies measure the capacity they add. They rarely measure the coordination they create.

Flagship Insight: The Coordination Debt Mechanism

Headcount becomes a trap when a company adds people faster than it improves the system those people have to operate inside.

Every Hire Adds a Dependency A new engineer needs context, reviews, decisions, access and integration, meaning one hire can create more work for everyone around them before it creates output. The schedules-and-features finding above shows the harder problem is usually aligning work, not producing it.

Geography Makes the Tax Harder to See A team split across time zones gets access to two talent markets, and a system where a five-minute clarification can become a one-day delay. The 46-publication review found this cost is structural: dispersion changes team performance and software quality on its own.

Weak Contributors Create System-Wide Costs A low-output hire doesn’t just produce less. Someone has to review, correct, explain and rework what they ship, which makes talent density an operating metric, not an HR one. Hiring around a bottleneck usually just adds people waiting on it.

What’s Actually Working

Audit before hiring: Compare headcount against output, cycle time and rework over the last two quarters. If headcount rose while output stayed flat, the problem isn’t capacity.

Find the human bottlenecks: Identify whoever’s approval or review regularly blocks others. Six more hires don’t remove a bottleneck, they create six more people waiting on it.

Separate talent from architecture: For every stalled team, classify the real constraint, capability, ownership, dependency, or architecture, and fix that, not the headcount.

Steal This: The Headcount Audit

1. Map output: Rank contributors against measurable delivery outcomes.
2. Map dependency: Identify every decision, review or approval that requires another person.
3. Map rework: Count work repeated because of poor requirements, quality or ownership.
4. Run the hiring freeze test: Ask what you’d redesign if hiring were impossible for six months. The answer usually reveals what the headcount request was hiding.

Field Intelligence

Signal

• Tracking output per contributor alongside team size.
• Asking what specific constraint new headcount is meant to remove.
• Making ownership explicit across distributed teams.
• Tracking rework and decision latency, not just sprint velocity.

Noise

• “We need more hands.”
• “Everyone is already busy.”
• “The roadmap is bigger, so headcount must grow.”
• Blaming the remote team for a coordination design problem.

Bottom Line

Summary: Headcount adds capacity, but it also adds coordination, and the second cost is rarely measured.

Reality: Operators who ask whether the constraint is people, architecture, ownership or dependency protect their margin; everyone else treats declining velocity as proof the team needs to get bigger.

Hard Truth: If adding people keeps failing to raise output, the company doesn’t have a headcount problem. It has a coordination problem wearing a headcount costume.

The data doesn’t lie. The headcount does.

Keep digging. Till next time, this is DUG Weekly!

Forward this to the founder, CTO or CFO debating another hiring round, the next productivity gain may come from removing coordination, not adding capacity.