Chapter 10: Centralize vs. Distribute
Every organizational design contains a recurring decision: should this capability, function, or system sit at the center — owned and operated by a shared team — or at the edges — owned and operated by the teams that depend on it? Centralize for consistency, standards, and scale. Distribute for speed, autonomy, and proximity to the work.
In a traditional organization, this decision is applied primarily to human functions. Should data engineering be a central team or embedded in product teams? Should security sit in a shared service or be distributed across engineering groups? Should platform infrastructure be owned centrally or built locally by each team? These are real design questions with real tradeoffs, and the frameworks for thinking through them are reasonably well developed.
In a hybrid organization, the decision becomes more complex — not because the underlying tradeoffs change, but because there are now two distinct layers to make the decision about: the human layer and the system layer. And these two layers do not always move together. A well-designed hybrid organization can centralize systems while distributing human teams. It can have distributed product teams all drawing from centralized governance infrastructure. It can push execution to the edge while holding standards at the center. Getting the decision right requires understanding what belongs at each layer — and recognizing that conflating the two produces the most common structural mistakes in hybrid organizational design.
THE CORE IDEA
In a hybrid organization, the centralize vs. distribute decision operates on two independent axes.
The centralize vs. distribute decision is not about where work happens. It is about where control resides and where execution is owned.
The human axis — where human teams, capabilities, and decision-making authority sit — follows the traditional logic with some adaptation for hybrid execution. Centralize where consistency, standards, and cross-team governance are the primary value. Distribute where speed, context, and proximity to the execution surface are the primary value. On the human axis, the tradeoff is speed vs. consistency.
The system axis — where systems, automations, AI agents, and platform infrastructure sit — follows a different logic entirely. On the system axis, the question is not proximity or autonomy. It is composability vs. fragmentation. Does this system create more value as shared infrastructure that every team builds on, or as a locally owned component that a specific team governs for its own execution surface?
The critical insight is that these two axes are independent. Decentralizing the human axis — giving product teams full ownership and autonomy — does not require decentralizing the system axis. A product team can own its outcomes, make its own delivery decisions, and govern its own execution surface while still drawing from shared platform infrastructure, shared governance tooling, and shared observability systems at the center.
The framework for the centralize vs. distribute decision in a hybrid organization is therefore not a single call. It is a structured set of calls, made separately for each axis, and deliberately combined.
THE FRAMEWORK
Four categories of organizational capability require explicit positioning on the centralize vs. distribute spectrum. Each category represents a default position — not a rule. The design act is deciding when to override the default, and why. Misalignment at scale rarely comes from a single wrong decision — it comes from inconsistent positioning across these categories.
Figure: Default positioning on the centralize vs. distribute spectrum
Color encodes positioning meaning: teal = default centralized, gray = contextual, coral = default distributed.
Platform infrastructure — default: centralized. The arguments for centralizing platform infrastructure are the same arguments made in Chapter 9: composability, governance consistency, and the platform's role as control architecture. When every team builds its own deployment pipeline, its own observability stack, its own data infrastructure, the execution surface fragments and governance becomes impossible to enforce. Centralized platform infrastructure is what makes governance real rather than aspirational.
The condition under which this default should be overridden is genuine domain incompatibility — when a specific team's execution requirements are so different from the rest of the organization that shared infrastructure creates more friction than it eliminates. A team running real-time machine learning inference at millisecond latency may need infrastructure that is structurally incompatible with the platform serving the rest of the organization. In that case, a satellite platform owned by the team — governed by the same standards as the central platform but operated independently — is the correct design. The override requires explicit justification and explicit governance, not just a preference for local control.
Governance standards — default: centralized. Governance standards — the rules that determine what execution modes are appropriate for what work, how automation is reviewed before deployment, how AI agents are monitored, how ownership is assigned and maintained — must be centralized. Not because central teams are better at governance than distributed teams, but because governance only creates value when it is consistent. A governance standard that applies to some teams and not others is not a standard. It is a suggestion.
Centralized governance standards do not mean centralized governance enforcement teams. The automation capability group owns and maintains the standards. Individual teams apply them to their own execution surfaces. The standard is centralized. The application is distributed. The condition under which this default should be overridden is essentially never. Distributed governance standards produce exactly the fragmentation and accountability diffusion that the ownership model in Chapter 3 was designed to prevent.
Execution ownership — default: distributed. Teams own the execution surfaces they govern. Product teams own their product execution surfaces. Platform teams own their platform infrastructure. Execution pods own their bounded problem space until dissolution. This distribution of ownership is what makes accountability clear, what makes escalation paths traceable, and what makes the governance capacity model in Chapter 8 operational.
Centralized execution ownership — where a shared team owns and operates significant execution surfaces on behalf of product teams — produces the service trap described in Chapter 9. It creates a bottleneck, obscures accountability, and prevents product teams from developing the governance capability their execution surfaces require. The condition under which this default should be overridden is genuine scarcity of specialized capability. This is a transitional state, not a permanent design.
Data and analytics infrastructure — default: contextual. Data and analytics sit at the intersection of the two axes in a way that makes a universal default less useful. The data infrastructure layer — pipelines, storage, processing — benefits from centralization for the same reasons as platform infrastructure. But the analytics and insight layer — the models, the analyses, the decision support systems — often benefit from distribution, because proximity to the domain produces better outcomes than centralization in a shared team. Centralizing insight creation disconnects decisions from accountability.
The right framework for data and analytics is therefore layered. Centralize the infrastructure that data depends on. Distribute the ownership of the insights and models that sit on top of that infrastructure. A centralized data platform serves the entire organization. The fraud model that runs on that platform is owned by the fraud team. The personalization engine that draws from it is owned by the product team. The infrastructure is shared. The execution surfaces are not.
WHAT THIS LOOKS LIKE
A technology company operating a consumer platform is redesigning its organizational structure after a period of rapid growth. It has accumulated twelve product teams, a data engineering group, a platform team, and a recently formed AI capability function. The question the CTO is working through is: what should be centralized, and what should be distributed?
The platform infrastructure is correctly centralized — the platform team owns the deployment systems, observability stack, and shared services that product teams build on. Two product teams have built local infrastructure workarounds because the platform was not keeping pace with their requirements. The CTO identifies these as service trap symptoms: the platform was being run as a service, not as a structural foundation. The correction is to shift the platform roadmap from product team requests to execution model requirements — not to distribute the infrastructure.
The governance standards are partially centralized. The AI capability function has defined standards for AI agent deployment and model governance, but they apply only to teams that have adopted AI capabilities so far. Seven of the twelve product teams have begun adopting AI tooling without reference to those standards. The CTO identifies this as a governance fragmentation problem — not a distribution problem. The correction is to extend the governance standards to cover all teams.
The execution ownership is distributed — each product team owns its execution surface. Two exceptions exist: the data engineering team is operating as an execution owner for three product teams. The CTO treats this as a transitional state and puts a twelve-month target on capability transfer to each product team.
The data and analytics infrastructure is layered correctly in some areas and incorrectly in others. The core data platform is centralized and well-governed. But the fraud model and the personalization engine are both owned by the central data science team. The CTO initiates a transfer of execution ownership for both, keeping the infrastructure centralized but distributing the model ownership to the teams whose outcomes depend on those models.
The resulting design is not fully centralized or fully distributed. It is precisely positioned: infrastructure and standards at the center, execution ownership and delivery at the edge.
CENTRALIZE VS. DISTRIBUTE ACROSS THE GROWTH CURVE
The framework describes the correct positioning for a mature hybrid organization. It does not describe a prerequisite structure that must be fully in place before the framework applies. In a growing organization, the four categories will frequently overlap — carried by the same small teams, governed by the same individuals. That is expected.
The engineer counts that follow are directional, not deterministic. The signal is structural pressure — not the number itself.
Early stage — positioning exists as accountability, not structure
Under roughly thirty engineers, a single team carries all four categories simultaneously. The framework cannot be structurally instantiated — there are not enough people to create separate functions. But the positioning logic should still be applied explicitly within the team. One engineer owns platform infrastructure and is accountable for its fitness. One person owns automation standards and reviews new automation before it deploys. At this stage, the most important positioning discipline is preventing governance standards from distributing by accident. Name a single person accountable for governance standards, even if that person is also writing product code.
Growth stage — the first separations
Between roughly thirty and one hundred engineers, the first natural separation is platform infrastructure from product delivery. The signal: when platform infrastructure is competing with product delivery for the same engineers' attention, the separation has become structurally necessary. Governance standards often drift toward distribution at this stage — not by decision, but by growth. New teams form, each adopting their own tooling and governance conventions. The correction is to treat governance standard centralization as a structural act: assign the automation capability group accountability before the distribution has gone too far to reverse cleanly.
Scale stage — all four categories become distinct functions
Above roughly one hundred engineers, all four categories require distinct structural representation. The costs of misalignment at scale become visible and compounding. The signals that each separation has become structurally necessary: product teams spending significant engineering capacity on local infrastructure that should be platform capability; the execution surface containing automation and AI agents under inconsistent governance models; a central data or AI team that has become the primary execution owner for multiple product domains; product teams unable to explain the behavior of systems executing on their behalf.
Each separation is a structural response to a positioning failure that has become costly enough to force correction. The earlier the positioning logic is applied — as accountability if not as structure — the less disruptive the eventual structural correction will be.
THE FAILURE MODE
The failure mode specific to the centralize vs. distribute decision is not choosing wrong on a single call. It is applying the decision inconsistently — centralizing and distributing by default or by political pressure rather than by structural logic.
The most common pattern is simultaneous over-centralization and under-centralization. The organization centralizes the wrong things — execution ownership, data science output, AI development — creating bottlenecks, reducing team autonomy, and producing service traps at scale. And it distributes the wrong things — governance standards, platform infrastructure, observability tooling — creating fragmentation, inconsistent quality, and ungovernable execution surfaces.
The result is an organization that has the disadvantages of both models and the advantages of neither. Teams cannot move fast because execution ownership is centralized. The organization cannot govern because standards and infrastructure are fragmented.
The second failure mode is deferral. The centralize vs. distribute decision is hard to make politically. The path of least resistance is to defer the decision, allow the current state to persist, and manage the consequences operationally. Deferral always costs more than the decision it avoids. The fragmentation compounds. The bottlenecks deepen. The governance gaps widen.
THE STRUCTURAL CORRECTION
Making the centralize vs. distribute decision well requires applying the framework explicitly to each category of organizational capability — not making a single organizational call that treats all capabilities the same way. The cost of not making the decision explicitly is that the organization makes it implicitly — and inconsistently.
A structured audit of each capability against the four-category framework — its current positioning, whether that positioning is explicit or drifted, and whether it is producing the symptoms of misalignment — is the practical instrument for making these decisions. Appendix B provides an interactive version of this audit, with scoring and a prioritized correction output designed to be used directly in a leadership conversation.
The audit is not a one-time exercise. As the organization grows and the execution model evolves, capabilities that were correctly distributed may need to be centralized, and capabilities that were correctly centralized may need to be distributed. The framework is a recurring decision instrument, not a one-time design choice.