There is a pattern I have seen repeatedly across IT organizations, regardless of industry, size, or maturity.

When an IT department has several chronically deficient teams, the rest of the organization inevitably absorbs the cost. High-performing teams spend a disproportionate amount of time firefighting, compensating for failures elsewhere, and stabilizing production. Over time, those same teams are asked to justify more headcount. Not because they are inefficient, but because maintaining reliability while absorbing the fallout from five or six struggling teams becomes nearly impossible.

What looks like excess capacity is often hidden fragility.

Recently, while discussing headcount planning with a colleague of mine Rocco Brittingham, he articulated a version of this pattern that immediately resonated with me. Fixing the entire IT system usually feels too hard, too slow, or too politically complex. In that environment, the only viable coping mechanism for high-performing teams is to buffer themselves by requesting and fighting for more resources.

From the outside, this looks like headcount inflation.
From the inside, it is self-preservation.

When Structure Makes the Problem Worse

This dynamic is often exacerbated by how work is structured inside IT.

Many organizations rely on tightly coupled, relay-style team models where work must pass through multiple groups just to design, build, deploy, and operate a single system. Each handoff introduces delay, misalignment, and risk. Accountability becomes fragmented. When something breaks, no single team fully owns the outcome.

Even strong teams struggle in this environment. They spend as much time coordinating, waiting, and compensating for upstream and downstream gaps as they do delivering value. Production incidents multiply, learning slows, and meaningful improvement becomes difficult.

The system quietly trains people to optimize locally rather than globally.

End-to-End Ownership Changes Behavior

Smaller teams with clear end-to-end ownership tend to behave very differently.

Teams that build, run, and maintain their systems develop stronger judgment and tighter feedback loops. They experience the consequences of their design decisions directly. Reliability, operability, and maintainability stop being abstract concerns and become daily realities.

This is not about heroics or burnout. It is about incentives. When ownership is clear, learning accelerates and quality improves because responsibility is real.

Centralization is often chosen in the name of control, consistency, or efficiency. In practice, it frequently creates bottlenecks. Work queues grow. Decisions stall. Standards enforced through gatekeeping rather than enablement slow the entire system and push teams to work around constraints instead of improving them.

In contrast, many small, decentralized teams with shared standards consistently outperform large, centralized structures. Autonomy with guardrails scales better than coordination through dependency. Resilience emerges when teams are designed to own outcomes, not pass work along.

This Is Not a Capacity Problem

At its core, this is rarely a capacity problem. It is a systems problem.

Hiring well matters. Hiring systems thinkers matters even more. Engineers should be expected to continuously improve their skills, not just maintain what they already know. At the same time, leaders must create the conditions for that improvement by protecting time for learning, modernization, and reflection.

When fundamentals are weak, headcount becomes the default solution. When fundamentals are strong, headcount discussions become clearer, calmer, and more honest.

If we invest in better team design, clearer ownership, and continuous skill development, fewer teams become chronic risk factors. Strong teams stop fighting each other for survival. IT organizations become smaller, healthier, and more effective, not larger and more fragile.

Efficiency does not come from adding people.

It comes from building resilient systems and developing capable engineers.