Centralization vs Decentralization: Why Recentralizing Teams Fixes the Wrong Problem

Centralization vs decentralization fails when leaders treat structure as the variable that matters. The real deciding factors are coupling, whether one team decision can break another work, and expertise depth, how much judgement is required to make safe local decisions. Distributing tightly coupled work that needs deep expertise turns skilled teams into bottlenecks.

1. Two arguments that sound contradictory and are not

Most organisations end up holding two opposite opinions about centralisation at the same time, often within a few weeks of each other.

1.1 The case for pulling a function back together

Somewhere, a function that used to sit centrally has been pushed out into the business units it supports, and it is not going well, with standards drifting inconsistent and nobody upstream holding real visibility into decisions before they are made. A capable team ends up rejecting work late, and starts to feel like a checkpoint rather than a contributor. The obvious lesson is that decentralisation was a mistake and the function needs to come back together.

1.2 The case for pushing a function back out

Somewhere else in the same organisation, the opposite move is causing the opposite complaint. A function that used to sit close to the teams it served has been pulled into a central group, often attached to a department that has little direct stake in the actual craft, and nothing gets faster or more consistent as a result. Teams simply spend more time restating decisions that were already reasonable to a committee that adds a signature but not much judgement. The obvious lesson here is that centralisation was a mistake and the function needs to be handed back.

1.3 Why both lessons miss the point

Both lessons get drawn constantly, often by the same leadership team looking at two different functions, and both conclusions treat centralisation itself as the variable that matters. It is not. What actually determines whether a function should sit centrally or be distributed has almost nothing to do with a general preference for one structure over the other, and almost everything to do with two properties of the work itself.

2. The question underneath the question

Before reaching for either structural fix, it is worth asking a blunter question first.

2.1 Loss of visibility can look exactly like loss of quality

Is the problem being described a real quality problem at all, or simply the discomfort of a group that used to be involved in decisions and no longer is? Loss of visibility and loss of quality feel identical from the inside, and almost nobody experiencing the first one describes it to you as the first one. It nearly always arrives dressed as the second, because a quality concern is a legitimate reason to ask for authority back, while a feeling of exclusion is not. A team that has stopped being asked for its opinion will often start asking, with growing frustration, who approved this and why, and that question gets heard as evidence that something has gone wrong. Frequently nothing has gone wrong at all. The work has simply started happening without a group that is no longer strictly necessary to it, and that is a much harder thing to sit with than an actual quality failure, because there is no fix for it that does not involve accepting a smaller role.

2.2 Both misdiagnoses are expensive

The honest cases genuinely do exist alongside the manufactured ones, and mistaking one for the other in either direction is expensive. Recentralising to fix a problem that was really just lost visibility restores comfort for one group while quietly destroying the responsiveness that justified the original change. Refusing to recentralise a function that has a genuine, measurable quality problem, out of a general belief that federation is always healthier, leaves real damage in place because nobody wants to be the one arguing for control.

3. The two variables that actually decide it

Once the diagnosis is honest, two properties of the work determine which structure will actually hold up over time, and most disagreements about this happen because two people are each picturing a different one of these two variables without realising it. Neither variable is a new idea. Both have solid grounding in organisational and economic research, which is worth knowing because it means the answer does not have to be argued from first principles inside every single reorganisation.

3.1 Coupling

The first is coupling, and the clearest articulation of why it matters comes from software organisation design rather than general management theory. Conway’s law observes that the structure of what gets built ends up mirroring the structure of the teams that build it, because communication patterns between teams become the boundaries in the system itself. Matthew Skelton and Manuel Pais built on this in their book Team Topologies, arguing that a shared, tightly coupled system needs deliberate team boundaries and interaction modes to avoid the coupling turning into chaos, while also warning that spreading a team too thin across unrelated concerns overloads what they call its cognitive load, the amount a group can reasonably be expected to hold in its head at once Team Topologies focuses on cognitive load management, clear team responsibilities, and explicit collaboration modes, and restricts unnecessary communication between teams because many to many communication prevents modularity and creates monolithic, highly coupled systems. Some functions produce a single shared artifact that many teams touch at once, where one team’s local decision can quietly break something for everyone else working on the same thing. Other functions produce separate deliverables that only need a common language between them, where one team’s choice has no mechanical effect on another team’s output.

3.2 Why coupling is really an economic question

This is really the same question economists ask about firms themselves. Ronald Coase’s foundational answer to why firms exist at all was that coordinating certain activities inside a single organisation is cheaper than coordinating them through arm’s length agreements between separate parties, and a firm keeps expanding its boundary until the internal cost of managing one more activity centrally exceeds the cost of leaving it outside a firm tends to expand until the cost of organising an extra transaction within the firm becomes equal to the cost of carrying out that same transaction on the open market. Oliver Williamson later extended this by pointing out that the calculation shifts once an activity requires investments or knowledge that only make sense in that specific relationship, since that kind of specificity raises the cost of coordinating at arm’s length and makes tighter integration worth the overhead bounded rationality, opportunism, and asset specificity all push organisational form toward tighter integration when they are present. Coupling and expertise depth are, in effect, the organisational design version of asset specificity.

3.3 Expertise depth

The second variable is how deep the expertise has to be before someone can make a safe local decision without support. Some domains take years to build real judgement in, and that judgement does not transfer quickly just because someone was moved onto a team that now owns the decision. Other domains can be captured reasonably well in a system, a set of principles, or a well built set of guardrails, and once those exist and are properly maintained, a competent practitioner can apply them locally without years of specific experience behind them.

Distributing a function that is tightly coupled and demands deep expertise tends to fail badly, because the coupling does not disappear just because ownership moved. Somebody still has to protect the shared thing from conflicting decisions, and if that responsibility was not deliberately kept somewhere, it gets picked up informally by whoever is left holding the consequences, usually far too late in the process to do anything but reject work that has already been built. That is exactly how a genuinely skilled team turns into a bottleneck that only stops bad decisions rather than shaping good ones early.

Centralising a function that is loosely coupled and does not require years of specific depth tends to fail for the opposite reason. Authority moves to a group that gained a reporting line without gaining the expertise required to actually improve the decisions in front of it, and what should have been a standard becomes a toll booth instead.

3.4 Three examples that make it concrete

Nobody would seriously propose centralising all code development, forcing every team that needs a piece of software built to route the request through one team that writes every line on their behalf. The work is genuinely distributable, the expertise required to write most application code competently is widely held, and forcing it through a single team would simply recreate the queue that decentralisation exists to remove.

A single core banking database sits at the opposite end of the same scale, and almost nobody would argue for handing schema decisions on it out to whichever team happens to want a change that week. The database is tightly coupled by its very nature, since one team’s careless decision becomes every other team’s outage, and it does not know or care what the organisation chart looks like. Point a bad workload at it and it degrades performance for the careful teams exactly as much as for the careless one, because a shared system enforces coupling whether or not the organisation has bothered to design for it.

Design work sits in a different place again, and for a different reason than either code or a database. It is not tightly coupled in the way a shared database is, but it is genuinely deep, since good design decisions depend on product knowledge, user context, and an intimate, iterative relationship with the problem that cannot be captured fully in a document and handed across a wall. A design specification thrown at a delivery team as a one way instruction tends to produce poor outcomes, not because anyone failed to follow it properly, but because the real value in design work is not the sign off at the end. It is the learning that happens while the thing is still being shaped. This is why the standards and the shared libraries belong centrally while the actual work does not. The standard is portable. The judgement is not.

4. Separating governance from containment

Underneath both variables sits a distinction that most organisations never quite make explicit, and it is the one that resolves the apparent contradiction between the two arguments.

4.1 Two different questions

Governance is the ability to define and enforce a standard. Containment is the act of physically owning the people and the budget who do the work. For most of organisational history these were bundled together by necessity, because there was no practical way to guarantee a standard without gathering everyone who touched it into one team under one accountable leader. That history is why every one of these debates still defaults to an all or nothing choice, even though the two questions genuinely do not require the same answer.

4.2 A live example, not a theoretical compromise

Data architecture has already had to solve exactly this problem at scale. Zhamak Dehghani’s data mesh model deliberately separates domain teams that own and build their own data products from a single federated governance function that sets and enforces the standards those products must meet, precisely because a fully centralised data team became a bottleneck at scale while a fully decentralised one produced silos and inconsistency a federated computational governance model is a decision making model led by the federation of domain data product owners and data platform product owners, with autonomy and domain local decision making power, while creating and adhering to a set of global rules. The goal of that governance layer is explicitly not to take the work back in house. It exists to create a data ecosystem with adherence to organisational rules and industry regulations while leaving domain teams responsible for building the thing itself.

4.3 The rule that follows from it

It is entirely possible to have one accountable owner for a standard without that owner directly employing everyone who touches the related work, in the same way it is possible to require every team to comply with a shared set of practices without requiring every practitioner to sit in the same room. Where coupling and expertise depth are both genuinely high, keep governance and enough containment together, and give that centre real authority early in the process rather than only a chance to reject finished work. Where neither is high, federate the doing and keep only the standard centralised, making sure whoever holds that standard has actually earned the authority they were given.

4.4 What getting this right actually removes

It is worth being explicit about what the whole exercise is for, because the framework can otherwise sound like an argument about org charts for their own sake. The actual goal is to reduce brokerage, the unnecessary go betweens who exist only because nobody can agree who is allowed to talk to whom directly. It is to remove misdirection, the pattern where work gets routed to whoever currently holds the reporting line rather than to whoever can actually improve it. It is to stop alignment happening over the heads of the people doing the work, where decisions are settled between leaders in a room the practitioners never enter and then handed down as a fact rather than a conversation. It is to cut the round trips between teams that exist purely to satisfy a structure rather than to improve the outcome, each one adding delay without adding judgement. It is to remove the power struggles that flare up whenever ownership is ambiguous, because ambiguity over who decides is what turns a working relationship into a turf contest. And it is to remove the heckling from the sidelines, the pattern where a group with no real stake in a decision gets to publicly second guess it without ever being accountable for the outcome. None of those six things are structural problems in the abstract. They are what happens, specifically and predictably, whenever governance and containment are either wrongly bundled together or wrongly pulled apart.

5. When loss of control feels like loss of quality

It is worth staying with the psychological side of this a little longer, because it explains why the same argument keeps recurring in organisations that have every reason to know better by now.

5.1 The leader who kept fifteen people

Picture a leader who once had a hundred people reporting to them, all of whom then moved out into product teams. Those teams become faster, their output improves, and the business units they now sit inside are visibly happier with them. By every measure the organisation cares about, decentralisation worked.

But that same leader now has fifteen people, a calendar that looks completely different, and far fewer decisions passing across their desk. They increasingly hear about important things after they have already happened rather than while they are being decided, and the expertise they spent years building is no longer something people default to asking for.

From the organisation’s perspective, this is a success story. From that leader’s perspective, something real has been taken away, regardless of how well the new arrangement is actually working. Recentralisation, in cases like this, is not really a response to a quality problem at all. It is a rational response to an identity problem that has learned to describe itself using the language of governance, because a quality concern is something an organisation will listen to and a feeling of diminished relevance is not.

5.2 What the research says about staying connected

Amy Edmondson’s work on psychological safety established that people take the interpersonal risks that learning and good performance require, admitting uncertainty, asking questions, challenging a decision, only when they believe it is safe to do so, and a leader who has just lost the standing they built their safety around is in exactly the wrong position to feel that safety themselves.

A 2025 meta analysis of more than thirty years of research on team boundary management, covering 85 studies and almost 11,000 teams, found a clear positive relationship between how a team manages its boundaries and how well it performs, but with an important qualification. The benefit came specifically from teams that stayed engaged in coordination, information search, and relationship building across their boundary rather than teams that policed or restricted it the performance benefits of boundary management are more pronounced when boundary management activity is directed outward across the boundary through coordination, representation, or information search, rather than through activity that restricts the boundary. Removing organisational containment does not have to mean removing organisational connection.

5.3 A sharper version, under higher stakes

General Stanley McChrystal’s account of restructuring a large military task force offers a sharper version of the same finding under much higher stakes. His command was too slow and too hierarchical to keep pace with a decentralised enemy, and his fix was to build shared consciousness, a genuinely transparent flow of information and context across the whole organisation, paired with empowered execution, pushing actual decision authority down to whoever was closest to the problem.

The result surprised his own team as much as anyone, since even as speed increased and authority moved further down the organisation, the quality of decisions actually went up, producing something closer to a ninety percent solution delivered immediately rather than a better solution delivered too late to matter. What he centralised was context and standards. What he decentralised was execution, which maps almost exactly onto the governance and containment split running through this whole argument.

5.4 Why AI raises the stakes

Hierarchy historically solved several problems at once, because expertise was scarce, information moved slowly, and coordinating specialised work was expensive, which made controlling people one of the most reliable ways to control capability. AI is quietly dismantling that bundle, since a small team can increasingly write its own code, analyse its own data, draft its own documentation, and prototype its own interface without waiting on five separate specialist functions.

Capability is leaking out from underneath the organisation chart faster than most leaders’ instincts have had time to adjust, and the very human response to capability escaping a chart is to try to redraw the chart around it. AI is shrinking the cost of decentralised capability considerably faster than most organisations are shrinking their psychological dependence on centralised control, and that gap is precisely where the pressure to recentralise is coming from.

6. The fence you actually need

None of this is an argument against structure or against standards, in either direction. Every ecosystem still needs rules, and removing an internal boundary never means removing responsibility for the whole. A shared standard, kept centrally, is a fence worth keeping. A single accountable owner for genuine risk and quality is a fence worth keeping. What is not required, in most cases, is the fence that pulls a function back into one department purely because a group that used to control it is uncomfortable with how little it now sees.

7. The short version

Six sentences, if this is all you keep.

Structure should follow the work, not the org chart’s comfort with who used to be in the room.

Loss of visibility and loss of quality feel identical from the inside, and only one of them is a reason to recentralise.

Coupling plus deep expertise means keep it together. Loose coupling plus distributable expertise means let it go.

Governance is not containment. You can own the standard without owning every person who applies it.

A leader losing headcount is not the same as an organisation losing quality, however it gets described.

AI is shrinking the cost of decentralised capability faster than most leaders are shrinking their need to control it, and that gap is where every one of these arguments is really coming from.