Centralization Is Contention: The Hidden Tax on Your Engineering Velocity

There’s a file in one of our monoliths that I’ve come to think of as the merge conflict generator. It’s 4,000 lines of IoC registrations — every AddSingleton, AddTransient, and AddScoped call in the entire system, lovingly crammed into a single class. Every developer touching dependency injection hits this file. Every feature, no matter how unrelated, eventually requires a change here.

The result? Constant merge conflicts. Not because developers are working on the same feature — they aren’t. They’re working on completely unrelated features that happen to need a new service registered. The file has become a serialization point, a queue that every change must pass through single-file.

You’ve probably got one of these files too. Maybe it’s a god-class that accumulates responsibilities like a hoarder collects newspapers. Maybe it’s a configuration file that everyone touches. Maybe it’s that one service endpoint that’s become the de facto integration point for the entire platform.

Here’s the uncomfortable truth: that file is a microcosm of a much larger problem. And if you look carefully, you’ll find the same pattern at every level of your organization — in your code, your systems, and your team structures.

The Math That Should Keep You Up at Night

The economist Thomas Sowell once observed, “The first lesson of economics is scarcity: there is never enough of anything to fully satisfy all those who want it.” He was talking about markets, but he might as well have been describing your central platform team’s backlog.

Centralization creates queues. This isn’t opinion — it’s queueing theory, and the math is brutal.

When you centralize ownership of anything — a file, a service, a team’s responsibilities — you create a single server that everyone must queue for. As your organization grows, the arrival rate of requests increases. More teams, more features, more demands on that central resource.

But here’s the counterintuitive insight from LeSS (Large Scale Scrum) that most organizations miss: as utilization goes up in a system with high variability, average cycle time gets worse, not better. At 50% utilization, your cycle time might be five times your service time. Push toward 100% utilization — as central teams inevitably do when demand exceeds capacity — and wait times don’t just increase linearly. They explode.

Central teams are always highly utilized because they’re a shared resource that everyone depends on. Organizations try to “maximize efficiency” by keeping them busy. And knowledge work has inherently high variability — requests aren’t uniform widgets coming off an assembly line.

This is a mathematical inevitability, not a management failure. The only escape is to eliminate the queue by distributing ownership.

Little’s Law makes this even clearer: the average number of items in your system equals the arrival rate times the average wait time. If your arrival rate exceeds your service rate — which it will, given enough teams depending on a central resource — your queue grows unbounded. Forever.

The Same Pattern at Every Scale

Kent Beck, in Extreme Programming Explained, describes a principle called self-similarity: “Try copying the structure of one solution into a new context, even at different scales.” The principle works both ways — if a pattern solves a problem at one level, try it at others. And if you see a problem at one level, look for it everywhere else.

Centralization creating contention is a self-similar problem. It manifests at every level of abstraction, and recognizing it at one scale helps you find it at all the others.

At the code level, central files and classes become merge conflict hotspots. That 4,000-line IoC file? Every developer queues to modify it, even when their changes are completely independent.

At the system level, central services become API bottlenecks. That authentication service that owns permissions for every consuming system? Every feature change that touches authorization queues for the auth team’s attention.

At the organizational level, central teams become approval queues. That platform team that reviews every infrastructure change? Every product team waits in line for their turn.

This isn’t coincidence. It’s the same underlying dynamic: when multiple independent actors need to modify a shared resource, you get contention. The resource might be a file, an API, or a team’s backlog — the math is identical.

The insight here is that organizations that centralize teams often have codebases with centralized god-files. Systems designed by centralized teams tend to have centralized choke points. This is Conway’s Law operating fractally — the communication structure shapes the architecture at every level of zoom.

The Authentication Trap

Let me give you a concrete example we wrestled with. Imagine an authentication API that gives you a JWT with claims about who you are. So far, so good — that’s exactly what an auth service should do.

But then the auth service also maintains permissions for every system that consumes those claims. Want to add a new permission for your feature? Submit a PR to the auth system. Or worse — log into some back-office tool and manually configure it, completely decoupled from your actual feature deployment.

The problems compound quickly. The auth team needs intimate knowledge of every consuming system. Every new feature requires either a PR to auth or a manual configuration step. The permission change is decoupled from the actual feature change — your unit of work is no longer atomic.

And critically, you’ve created a queue. The auth team becomes a bottleneck. Every team building anything that touches authorization waits their turn.

The basketball coach Phil Jackson once said, “The strength of the team is each individual member. The strength of each member is the team.” He was talking about the Bulls, but he could have been describing microservices. The distributed model inverts the ownership: the auth API authenticates (identity and claims), but each system interprets what those claims mean for their domain.

“User X is a manager” is the auth service’s job. “User X can approve purchase orders in this system” is the consuming service’s job.

Now your feature PR includes its own authorization rules. The unit of change is atomic — code, tests, config, permissions, all deployed together. No queue. No waiting for a central team. No drift between what you deployed and what permissions exist.

The Monolith Team Problem

Here’s where it gets organizational. We talk a lot about breaking up monolithic codebases, but we often forget to break up the monolithic teams that built them.

You decompose the code into microservices. You set up independent deploy pipelines. Each service can move at its own pace. But then you leave a “vertical” central team owning the platform, while “horizontal” product teams merely contribute, waiting for reviews and approvals.

Congratulations — you’ve distributed the code and centralized the contention.

The transformation that actually works is to decompose the central team alongside the monolith. Distribute ownership to the teams working in each business domain. In Team Topologies terms, you’re converting a bottleneck into a set of stream-aligned teams — teams that own their slice end-to-end, from design through deployment, with no hand-offs required.

This is uncomfortable. Central teams often exist because that’s where the expertise lives. But hoarding expertise creates dependency. Spreading expertise creates capability.

The Red Flag Heuristic

When you encounter centralization at any scale, treat it as a smell. It may be justified — but it requires justification. The default should be distributed ownership, with centralization as the exception requiring defense.

Ask these questions intensely:

Does this create a queue? If multiple teams wait on one team (or one file, or one service), you have contention. Count the items in the queue. If it’s growing, you have a scaling problem.

Does this couple unrelated changes? If feature work requires changes in central systems, you’ve created unnecessary coupling. The IoC file that causes merge conflicts between unrelated features is exhibit A.

Can we distribute this? What would it take to give teams ownership of their slice? Often the answer is “a library they call” rather than “a team they wait for.”

What’s the scaling behavior? Does adding teams make this worse? If your central platform team’s backlog grows faster than you can hire for it, you’ve discovered a scaling ceiling.

When Centralization Actually Makes Sense

I’m not arguing that everything should be distributed. Some things genuinely need a single source of truth.

Identity and authentication — who you are, not what you can do — needs centralization. There should be one place that says “this JWT belongs to user X.”

Observability platforms — centralized logging, metrics, tracing — make sense, but they should be consumed self-service, not gatekept. The difference between a platform that enables and a platform that blocks.

Compliance and audit tooling — where regulation genuinely requires uniform enforcement. Sometimes the law says you need a central view.

Early-stage startups — where distributed overhead exceeds benefit. But be ready to evolve. The structure that works for 10 engineers becomes a bottleneck at 50.

The key distinction is between platform-as-a-service and platform-as-a-gatekeeper. The former enables autonomy. The latter creates queues.

What’s not a good reason for centralization? “Consistency” — achieve through standards, libraries, and tooling, not central ownership. “Expertise lives in one team” — spread the knowledge, don’t hoard it. “It’s always been this way” — legacy isn’t justification.

The Bottom Line

The management theorist Peter Drucker noted, “What gets measured gets managed.” But the corollary is equally important: what doesn’t get measured gets ignored. Queue length in central teams. Wait time for PR reviews on platform code. The gap between “feature complete” and “actually shipped.”

Centralization’s costs are diffuse and long-term. The benefits — expertise concentration, consistency, control — are visible and immediate. This asymmetry is why organizations default to centralization and why they keep discovering the same bottlenecks.

The fix isn’t more process. It’s recognizing the pattern: centralization creates contention. At the code level, at the system level, at the organizational level. Same math, different scales.

Look at your 4,000-line god-file and ask: where else in the organization does this pattern exist? Your architecture is telling you something about your org chart, and your org chart is telling you something about your architecture. Conway’s Law isn’t just descriptive — it’s predictive.

The next time someone proposes centralizing ownership of something, ask them to model the queue. How many teams will depend on this? What’s the arrival rate of requests? What happens when utilization hits 80%? 90%?

Then watch them struggle to justify the math.

Now, if you’ll excuse me, I need to go review a PR. It touches that IoC file, and there are twenty other developers waiting behind me. We’ve been meaning to break it up for two years. But hey, at least our org chart looks clean.