Shared services transitions are among the most consistently promised simplification programs in the business-case inventory, and among the most reliable producers of organizational complexity once the promised simplification is tallied against what the organization actually operates after the transition stabilizes. The pattern holds across industries, geographies, and functional scopes. The distributed finance teams get consolidated, the distributed HR teams get consolidated, the distributed procurement teams get consolidated, and two to three years later the consolidated organization employs more people in coordination, interface management, and escalation governance than the distributed organization it replaced employed in the functions that were consolidated. The business case delivers on its stated terms, since those terms measured headcount reduction in the consolidated functions rather than net headcount change across the broader organization. The reality diverges from the business case, since the headcount the business case never measured was the headcount the consolidation made necessary.

The shared services business case, in its standard form, rests on a set of assumptions the literature treats as settled: that consolidation produces economies of scale in functional operations, that standardization reduces variance in service quality, that concentration of specialized talent produces expertise the distributed model cannot match, and that technology investment in the consolidated structure produces capability the distributed structure cannot justify. Each assumption describes something real, and each, taken alone, is defensible. The business case that aggregates them treats the consolidation itself as the organizational achievement, on the premise that its operational implications will resolve themselves through the standard operating rhythm of the new structure. That aggregation produces numerical projections whose confidence interval does not reflect the variance the operational resolution actually introduces. The projections model the consolidated organization as the distributed organization with the distributed functions removed, which is not what the consolidated organization operates as, and the gap between the modeled operating state and the realized one is where the coordination growth accumulates.

Hold one transition against the pattern for grounding. It eliminated 340 distributed finance, HR, and procurement roles across a medium-sized enterprise and, within three years, staffed a shared service organization of 410 people: the service center staff plus the relationship managers, service delivery coordinators, escalation governance leads, and interface management roles that did not exist before the consolidation. The organization that was supposed to be simpler now has more people managing coordination than it had people performing the distributed work. Net headcount ran in the opposite direction from the business case, and organizational complexity, measured in coordination layers, authority interfaces, and governance forums, ran decisively up. This is not an unusual outcome. It is a recurring one, visible in enough shared services transitions to count as the structural signature of the model as it is typically implemented.

The explanation is straightforward once stated. Shared services transitions redistribute complexity rather than eliminating it, since the work previously absorbed by distributed teams through local knowledge, physical proximity, and informal coordination moves into a centralized structure that must formalize what was previously tacit. Decision rights that were implicit become contested. Governance that was unnecessary when functions sat close to the business becomes critical when they sit in a separate organization. The coordination burden that seemed absent in the distributed model was present all along, simply absorbed informally by the people doing the work. When those people relocate into a consolidated structure, the burden relocates with them, stripped of the informal mechanisms that made it invisible, and it becomes visible, formalized, and staffed.

What the distributed model produced for free

Three things the distributed model produced at no apparent cost become, in the consolidated model, expensive to replace: local knowledge, informal decision authority, and proximity. Each was a governance input the distributed organization ran on without having to build, maintain, or budget for it. Each becomes, under consolidation, a governance output the centralized organization has to produce through deliberate design or pay for through the coordination demand its absence generates. The three are not independent, and they compound on each other, since the local knowledge supported the informal decisions, the proximity sustained the local knowledge, and the simultaneous removal of all three eliminates an integrated mechanism rather than three separate ones.

Local knowledge matters first, since it carries the operational context the distributed teams used to make their work effective. A business unit finance team that has worked alongside the operations teams for years carries an understanding of the unit’s processes, priorities, seasonal patterns, informal hierarchies, and the specific personalities of the operational managers whose requests it supports. None of this is documented anywhere. Most of it is not explicit knowledge the team members could articulate if asked. Yet it shapes every decision the team makes about how to prioritize requests, how to interpret ambiguous instructions, how to handle exceptions, and how to route information to the right operational manager. When the team consolidates into a shared service center, the people carrying this knowledge consolidate with it, while the relational context that made the knowledge usable does not, since the daily operational contact that kept the context current no longer occurs. Within eighteen months most of that context has decayed, and what replaces local knowledge is process standardization, which handles the routine cases efficiently and generates exceptions everywhere the local knowledge used to handle invisibly.

Informal decision authority is the second thing the consolidation redistributes, and the redistribution is more consequential than the business case recognizes. Distributed teams make countless small decisions daily that never surface as decisions: which requests to prioritize when capacity is constrained, which exceptions to accommodate and which to push back on, how to handle the request that does not fit the standard process, when to break a rule the operational context has made inappropriate. People with enough organizational context made these decisions correctly, and the correctness held since the people making them answered to the operational managers whose work the decisions affected. Consolidation moves the decisions into a governance structure where informal authority no longer applies, since the consolidated team no longer sits inside the accountability chain the distributed team sat inside. The governance structure that replaces informal authority has to be explicit about who decides, on what basis, through what process, with what escalation mechanism when the first-level decision is contested. Decisions once made invisibly now require escalation paths, exception committees, and service level negotiations, each generating coordination work the distributed model never required.

Proximity, the third input the consolidation eliminates, was doing work that is easy to miss until it is gone. Distributed functions sat physically close to the business units they served, and the closeness made coordination frictionless in a way that scaled with the quality of the relationships, since a conversation in a hallway resolved what would otherwise have required an email, then a follow-up email, then a meeting, then an escalation, then a governance forum. Coordinating across distance costs substantially more, since distance introduces interpretation errors, scheduling friction, attention lags, and the translational overhead of turning tacit operational context into explicit communication a distant team can act on. Consolidation creates a boundary where none existed, then builds the relationship management layer to manage across it. The relationship manager role exists to staff a structural gap the consolidation opened, and its cost is the organizational response to a governance problem the consolidation created, a problem the distributed model the consolidation replaced never posed.

The compounding among the three deserves naming directly, since shared services design conversations treat them as separate governance problems to be managed by separate mechanisms, while their simultaneous operation in the distributed model is exactly what made that model work without formal governance. Local knowledge enabled the informal decisions, since the decisions were defensible only to people who carried the operational context behind them. Proximity sustained the local knowledge, since daily contact with the business units kept the context current. Informal authority rested on the trust that the distributed teams’ local knowledge was producing decisions aligned with the operational managers’ priorities. Each of the three held up the other two, and the distributed model’s simplicity was the product of their integration, not of any one of them alone. Consolidation removes all three at once, and the governance design that has to replace them has to address their integration as well as the three individually, which is a design problem most shared services methodologies were never built to handle.

The governance gap at the interface

The interface between a shared service center and the business units it serves is a permanent governance negotiation point, and shared services design conversations rarely treat it as one. They concentrate on process standardization, technology platform selection, service level agreements, and governance forums at the executive level, while the interface itself, where the center’s formal operations meet the business units’ operational needs, gets comparatively little design attention, on the assumption that the service level agreements and executive forums will cover what happens there. They do not. Every exception to the standard process, every priority conflict when capacity is constrained, every service level question that falls between the defined categories, and every operational request that did not exist when the agreement was negotiated produces a decision about who has authority, by what criteria, and through what process. Most of these decisions have to be made faster than the governance forums can convene to make them.

The relationship management layer exists to fill the gap. When governance does not specify who decides about exceptions, the relationship manager decides, or escalates until someone senior enough decides, or pushes the decision back to the business unit while the center keeps running its default process. When priority conflicts arise without a defined arbitration process, the relationship manager negotiates between the center’s capacity constraints and the business unit’s priority claims, or escalates the conflict up both organizational chains until it resolves itself through exhaustion or through an executive intervention neither chain wanted. Each unresolved governance question generates ongoing coordination demand, since the question recurs in slightly altered form the next time a similar exception, conflict, or ambiguity surfaces. The relationship manager handles the demand without resolving the underlying question, since resolving it is not within the relationship manager’s authority. The question persists, generating the next coordination requirement, and the workload grows.

Watch one accrual move through four quarters. A business unit’s month-end close requires the center’s finance team to process a set of accruals that fall outside the standard month-end process, since the unit carries a quarterly reporting obligation the standard service level never anticipated. The first time, the relationship manager negotiates a one-time accommodation between the unit’s finance lead and the center’s delivery manager, which both sides accept as an exception. The exception recurs the next quarter, and the next, and within four quarters the accommodation has become a de facto part of the unit’s service level without ever being formally added to the agreement, and without ever surfacing as a governance question the executive forum would resolve. The relationship manager’s workload absorbs the ongoing coordination the accommodation requires, until the volume of such informal accommodations across the units she covers exceeds her capacity, at which point the center hires another relationship manager to absorb the accumulated commitments. The governance question that would have settled it permanently, whether the service level agreement should cover the quarterly reporting cycle or whether the center should run on exceptions for it, never reaches the forum that would answer it.

The coordination layer expands through exactly this accumulation of unresolved interface governance questions. Organizations do not hire relationship managers they do not need. They hire them since the coordination demand the governance gap generates has exceeded the capacity of the existing coordinators. The new coordinators absorb the demand temporarily, producing the appearance of resolution for a quarter or two, until the demand outgrows their capacity and the next hire becomes necessary. The people are the symptom of a condition that is, at its source, a governance design problem rather than a staffing one. The staffing response treats the symptom without touching the condition, so the condition keeps producing new symptoms at a rate the staffing response cannot keep up with.

What makes the dynamic so durable is that the questions the interface generates are operational, and the forums that could resolve them sit at levels of the organization focused on strategic concerns. The escalations that reach the executive governance forum are the severe ones, the handful of conflicts the relationship managers could not resolve and the business unit and the center could not settle between themselves. The routine governance gaps stay with the coordination layer until they turn severe, and most of them never turn severe enough to reach the executive forum, which means most of them are never resolved at the level of governance design, which means they keep producing coordination demand indefinitely. By the time a question has become severe enough to escalate, the informal management of it has already institutionalized and the role managing it has already become permanent.

Why the coordination layer keeps growing

Organizations respond to the growing coordination burden by adding coordination capability: more relationship managers, more escalation paths, more governance forums, more dedicated roles for managing the interfaces the original transition created. Each addition manages the immediate demand without addressing its structural source. The governance questions stay unresolved, the demand for coordination persists, and the new roles absorb it temporarily, buying the appearance of resolution until the demand grows past their capacity and the next addition becomes necessary. The pattern shows up across transitions of varying size and sector, and the growth curve of the coordination layer is roughly consistent across the sample. Headcount in coordination and interface management roles grows at approximately the rate the governance-gap demand grows, lagging it by about a quarter, which is the interval between a problem becoming unmanageable and a new role being approved.

The layer grows for the same reason the governance gap persists. Resolving questions at the interface requires authority that sits above both the center and the business units, and the forums at that level rarely focus on the operational questions the interface generates, since those questions appear, to the senior leaders who would have to attend, as operational matters that belong at the operational level. They would belong there, under a governance architecture designed to handle them operationally. Under an architecture that did not design for them, they either escalate to inappropriate levels, where they are rejected as too operational, or they get managed by a coordination layer that lacks the authority to resolve them, which means they recur.

Three years after a typical transition, headcount in the coordination layer has usually reached or passed the headcount reduction the business case delivered in the distributed functions, and the business case has been technically delivered in the sense that it eliminated the distributed roles. The coordination roles the structure required offset those eliminations, and the net outcome is not simplification in any meaningful sense. It is a different distribution of the same organizational work, with less proximity to the business units, more formalization, higher coordination cost, and lower adaptability to conditions the original process standardization did not anticipate. The organization ran a program to simplify itself and produced, three years later, a structure more complex than the one it replaced, with a business case delivered on its measured terms and an operating model that was not.

The governance design the methodology skips

The counterintuitive feature of shared services transitions that deliver actual simplification is that they require substantially more governance design than the transitions that produce the coordination growth pattern. This inverts the assumption most shared services conversations begin with. The distributed model ran on minimal formal governance, since proximity, local knowledge, and informal authority supplied the coordination that governance would otherwise have to specify. The consolidated model cannot run on the same substrate, since proximity, local knowledge, and informal authority have all been dispersed, and something has to replace them. The replacement has to be designed, since the centralized organization will not produce it spontaneously the way the distributed organization did. What shared services design conversations skip, or underweight, is exactly the design work required to rebuild the governance substrate the consolidation removed.

That design work runs across several registers, and each needs the rigor usually reserved for the process and technology layers of the implementation. Decision rights at the interface require explicit specification: who decides about exceptions, by what criteria, through what escalation path when the first-level decision is contested, and what authority the center holds when business unit demand exceeds capacity. Every organization has answers to these questions. In most implementations the answers are not designed in advance but discovered through operational friction and settled informally, in ways that become institutional before anyone recognizes that they are becoming institutional. The governance design conversation has to produce the answers at the design stage, since the alternative is settling them under operational pressure in forms the organization will later have to unwind.

One constraint is worth building into the methodology explicitly. For every new coordination mechanism introduced, ask what existing mechanism it replaces. If the relationship manager role is necessary, what informal coordination did it formalize, and what does that formalization retire? If a new escalation forum is required, what governance problem does it resolve that the previous structure could not? The constraint does not prevent coordination roles from existing, since some are genuinely necessary under the consolidated model that the distributed model never required. It requires that their addition reduce governance complexity somewhere else rather than adding to it net, which forces the design conversation to specify both what the new mechanism does and what it retires. Most shared services designs fail this constraint. They add coordination mechanisms without retiring any, and the aggregate effect is the coordination growth pattern.

Interface governance review, run as a standing function separate from the service level reviews shared service centers already conduct, supplies the ongoing diagnostic the design stage cannot fully anticipate. Service level reviews measure delivery performance against agreed service levels. Interface governance reviews identify the questions generating coordination demand and surface them for resolution at the right level before the coordination layer required to manage them becomes permanent. The review asks specific questions. Which exceptions have recurred often enough that they need to be redesigned as standard cases? Which escalations have reached the relationship manager repeatedly since no one above the relationship manager has resolved the underlying question? Which priority conflicts have been managed through informal negotiation since no explicit arbitration mechanism exists? The answers usually sit in the coordination layer’s operational records, which no one reads at the governance-design level, since no one has been told to.

A small team conducts the review, its composition mirroring the interface itself: one representative from the center’s operations leadership, one from the business units’ finance or operations leadership, and one governance specialist whose job is to translate operational-level patterns into governance-design questions the executive forum can act on. The team meets quarterly, reads the coordination layer’s operational records, identifies the recurring patterns that mark unresolved governance questions, and produces a briefing that frames the questions in design terms rather than as operational escalations. The framing is what matters, since the executive forum that would reject an operational escalation as beneath its level will engage a governance-design question as appropriate to it. The review’s output is not a remediation program. It is a set of governance-design decisions that, once made, retire a class of coordination demand the organization was otherwise going to absorb through additional hires.

The investment in governance design pays through headcount that does not need to be hired into the coordination layer over the following two to three years. The savings are hard to attribute cleanly, since they show up as hires that did not happen rather than hires that were cut, which makes the investment difficult to justify against comparable investments whose returns are visible. This recurs across governance investment generally. The return is produced by absences, the absences are counterfactual, and the budgeting conventions most organizations run under do not weigh counterfactual savings against visible costs the way the economics of governance design would require.

Where the simplification actually comes from

The simplification shared services transitions promise is real, and it can be produced. The path to it runs through more deliberate governance architecture, not less, which is the conclusion most shared services conversations are least prepared to reach, since framing the transition as a simplification program works against recognizing that simplification of the apparent kind requires complexity of a different kind underneath it. The distributed model’s informal governance was its strength, since it absorbed coordination work invisibly through mechanisms that needed no explicit design. The centralized model’s formal governance is its requirement, since the mechanisms that absorbed that work invisibly have been dispersed, the coordination work has to land somewhere, and the only mechanism available under consolidation is explicit governance.

Organizations that attempt centralization while keeping the informal governance habits of the distributed model discover the gap through the coordination layer that grows to fill it, quarter over quarter, hire by hire, until the business case the transition was supposed to deliver has been functionally reversed. Leadership usually does not reopen the business case, since reopening it would require admitting that the transition produced the opposite of what it promised, a conversation the organization’s governance is not set up to host. The alternative, designing the interface governance at the outset with the same rigor the process and technology layers receive, produces a materially different outcome, and on any reasonable comparison of implementation effort against three-year operating cost it is the substantially cheaper approach. Most organizations do not take it, since the design work is invisible to the executive forums that approve the transition, and invisible governance design is hard to commission when the visible alternative is hiring more coordinators as the need arises.

The 410 roles managing coordination where 340 once did the work are the organizational expression of governance that was never designed. They are not a failure of the people occupying them, nor of the shared services model as a concept. They are the predictable output of a transition that treated process and technology as the design subjects and governance as the afterthought, and the coordination layer that afterthought generated is the bill the transition pays for having assumed the new structure would produce its governance on its own.