Monday Myth: Adding People Speeds Things Up

When delivery slows down, companies hire. They add engineers, product managers, and coordination roles with the expectation that more hands will translate into more output.

A few months later, nothing improves. Deadlines slip, dependencies multiply, meetings expand, and energy drops. What looks like a capacity problem reveals itself as a systems problem.

1. The Intuition That Fails

The belief that adding people accelerates delivery feels intuitive. More hands, more output. This is raw output thinking. It ignores outcomes, flow, and system behaviour.

Software delivery does not behave as a linear system. It behaves as a network under load. Every new person adds capacity, and also interfaces. More interfaces create more communication paths. More paths increase alignment overhead. More overhead introduces latency. At some point, coordination dominates execution.

This is not new. In The Mythical Man-Month, Fred Brooks made it explicit: adding manpower to a late software project makes it later. Not because people lack skill, but because each addition increases interactions, turning the system into an NP-complete problem where coordination grows combinatorially and cannot be absorbed fast enough.

2. What Actually Happens in the Field

This pattern shows up everywhere. A team struggles with delivery and leadership decides to "reinforce". Two engineers join, a delivery manager appears, and a product owner steps in to “clarify”. Within weeks, meetings multiply, tickets proliferate, and rework increases. Delivery slows further, not because people fail, but because friction increases across interfaces that were never designed to scale.

A similar pattern appears with platform teams. A company creates a platform to accelerate product squads and it works at first. Demand grows, and instead of improving interfaces, more people join the platform team. The outcome shifts: the platform becomes a bottleneck, queues grow, prioritisation turns political, and autonomy disappears. What was meant to reduce friction becomes the main source of it.

3. Complexity, Not Capacity

Software organisations operate closer to NP-complete systems than predictable pipelines. Brute force does not work. Throwing people at the problem does not scale. Each addition increases interaction complexity, decision latency, and cognitive load. These factors grow faster than capacity, which is why a second-order perspective becomes necessary.. Not components, but interactions.

Like second quantisation in physics, system behaviour emerges from interactions rather than individual elements. Without control over interactions, the system becomes unpredictable.

You are not scaling capacity. You are scaling interactions.

4. What Good Looks Like (Real-World Signals)

A few organisations have internalised this.

Toyota did not scale production by adding people blindly. It designed flow: constrained work-in-progress, clear signals (andon), and immediate feedback loops. Capacity followed coherence, not the other way around.

Amazon institutionalised small, autonomous teams (the “two-pizza” rule). The constraint was not headcount, but interface surface. Teams owned outcomes end-to-end, which reduced coordination overhead and preserved speed as they scaled.

Spotify’s early model pushed for aligned autonomy: squads with clear missions, shared language, and lightweight interfaces. Where it worked, it reduced dependency drag and allowed local optimisation without breaking global coherence.

The common pattern remains the same: limit interfaces, clarify ownership, and let signals flow.

Scale the system first. Then scale the people.

5. Friction as the Leading Indicator

Friction does not appear on org charts and does not show in headcount, yet it defines delivery. It shows up in outcomes: KPI drift, OKR deviation, and the widening gap between expected and actual results. It also appears in daily work such as waiting between teams, rework from misalignment, endless clarification loops, and decision bottlenecks.

Adding people without removing friction adds weight to an already strained system. The result is not acceleration, but instability that compounds over time.

6. Where the Pressure Comes From

This push rarely originates in engineering. It comes from stakeholders outside the delivery system, people who do not experience constraints directly, do not understand flow dynamics, and treat capacity as interchangeable resources. This erodes purpose and dehumanises software engineering by reducing people to fungible inputs rather than accountable contributors to outcomes. The logic appears simple, too simple: more demand requires more people.

In complex systems, that logic fails.

It also exposes weak prioritisation. When everything becomes a priority, nothing is. Without a clear outcome hierarchy, organisations revert to output thinking: more features, more parallel work, more people. The system turns into a feature factory. Outcome focus disappears, economic efficiency degrades, and the ratio between revenue and investment collapses.

From a systems perspective, the stock depletes. Work in progress grows faster than completion, quality declines, and rework expands. The system consumes its own capacity instead of producing value. People are not units of production. They are active contributors in a system that must remain coherent. Without structure, each addition increases inconsistency rather than throughput.

7. The Only Scalable Alternative

Scaling requires coherence. Without it, organisations rely on guesswork, and at scale, guesswork produces entropy. A coherent system behaves differently: customer signals flow through the organisation and return as value. Everyone aligns on the same languag, like a North Star Metric to define success, OKRs to translate intent, KPIs to reflect business signals, and SLOs to guarantee reliability.

Each actor understands their contribution and each team knows where it can influence outcomes. This creates a living system that adapts: engineers can engage earlier in pre-sales when needed, marketing can influence KPIs and even SLOs alongside engineering to shape customer signals, and feedback loops tighten across functions. This is not overhead. It is friction removal that protects flow.

8. Scaling Without Collapse : Back to Agile

Scaling is not about adding people, but about preserving flow while increasing capacity. That requires discipline: stable interfaces, limited dependencies, and clear decision ownership. Only then can additional people integrate without degrading the system.

This was the original intent of Agile. Not rituals or ceremonies, but flow: small autonomous teams, clear ownership, fast feedback loops, and minimal coordination overhead. In other words, systems designed to scale without collapsing under their own complexity. A living system.

9. Remember

When delivery slows down, resist the instinct to hire. Ask instead where friction accumulates, and remove it first. Otherwise, additional people will amplify the problem, making it bigger, more expensive, and harder to untangle.

This is how organisations end up spending more to deliver less, while believing they are scaling.

You do not fix a slow system by adding people. You fix it by removing what slows it down.