Approval Flows Through the Side Door: Mapping the Real Power Structure Before Your Transformation Begins

Every large American enterprise has two org charts. One is published on the intranet, complete with headshots and reporting lines. The other lives in hallway conversations, conference room dynamics, and the quiet arithmetic of who has been in the building long enough to know where the bodies are buried.

When a digital transformation stalls — and most do, at least temporarily — the post-mortem usually points to scope creep, vendor missteps, or budget overruns. Rarely does anyone name the actual culprit: the initiative was designed around the formal hierarchy while the real decisions were being made elsewhere.

The Three People Who Weren't in the Kickoff

Consider a familiar pattern. A Fortune 1000 manufacturer greenlights a multi-year ERP modernization. The CIO sponsors it, the CFO funds it, and the steering committee includes every relevant vice president. On paper, governance is airtight.

Then the delays begin. Purchase orders sit in queue. Data mappings stall. Requirements reviews get rescheduled for the third time. What the steering committee doesn't see is that the approvals actually route through a deputy controller who has managed the month-end close for fifteen years and trusts no system she didn't build. Or that the only person who understands the custom interfaces written in 2009 is a database administrator who has already accepted a retirement date.

These figures — the unofficial approver, the institutional gatekeeper, the departing knowledge holder — hold more practical power over the transformation than most of the people on the steering committee. And none of them were consulted before the program charter was signed.

Why Informal Authority Outranks Formal Authority

Formal authority grants permission. Informal authority grants cooperation. A transformation needs both, but enterprises routinely secure only the first.

Informal power accumulates through three channels. The first is process ownership: the person who has run a workflow long enough that the workflow now runs through them, regardless of what the title says. The second is institutional memory: the individual everyone consults before making a decision, because they remember the last three times the organization tried something similar. The third is risk aversion at the top of a function — an executive who never formally blocks anything but whose silence departments have learned to treat as a veto.

None of this is pathological. It is simply how large organizations absorb complexity. The mistake is treating it as invisible rather than mappable.

A Framework for Mapping Real Decision-Makers

Before any major initiative kicks off, we recommend a structured exercise that takes roughly two weeks and requires no external consultants. It has four steps.

Step one: trace the last five decisions. Pick five recent decisions comparable in scale to the transformation — a prior system replacement, a major reorganization, an acquisition integration. For each, document who initiated it, who reviewed it, who could have killed it, and who was consulted after the fact. Patterns emerge quickly. The same two or three names will surface repeatedly, and they will not all be titles.

Step two: follow the approval trail, not the approval matrix. Pull twelve months of purchase orders, change requests, and sign-offs related to the systems in scope. The formal delegation-of-authority matrix says who is permitted to approve. The actual trail shows who is asked to approve. Where the two diverge, you have found informal authority.

Step three: interview for the veto. Ask a cross-section of managers a single question: "If this initiative were going to quietly fail, who would you expect to hear about it first?" The answers converge on the people whose resistance matters — which is precisely the population most engagement plans ignore.

Step four: plan for the departure calendar. Cross-reference the mapping against HR's retirement eligibility data and attrition risk. In many US industrial and public-sector organizations, the employees with the deepest system knowledge are within eighteen months of retirement. If the transformation depends on them, the knowledge transfer plan is not an HR courtesy — it is a critical-path workstream.

A Diagnostic Checklist for Your Next Initiative

Run the following before your next program kickoff. If you cannot answer all seven questions with a specific name and evidence, your governance model is incomplete.

• Whose signature appears on approvals even when the matrix says someone else's should?
• Which employees do peers consult before raising a proposal to leadership?
• Who has sole administrative access to the systems being replaced, and when do they plan to leave?
• Which executives have blocked or slowed a comparable initiative in the past five years, and what triggered it?
• Where do informal working groups meet that no steering committee charter created?
• Which functions have quietly opted out of discovery interviews so far?
• If the program lost its executive sponsor tomorrow, who would inherit the political weight?

Governance Should Describe Reality, Not Aspiration

None of this argues for rewarding informal power structures or letting shadow hierarchies ossify. It argues for honesty in program design. A steering committee that reflects the published org chart but not the operating one will spend its meetings surprised — and enterprises pay dearly for surprise.

The most effective transformation leaders we work with treat the informal map as a first-class governance artifact, updated quarterly alongside the risk register. They engage the deputy controller in month one, not month nine. They build the retiring administrator into the plan as a named knowledge-transfer owner rather than discovering her importance during a cutover crisis.

The org chart tells you who reports to whom. The transformation succeeds when you also know who listens to whom. Map both before the ink dries — because the second chart is the one that decides whether your program ships or stalls.