The Operating Model Nobody Drew: Why Informal Structures Decide Transformation Outcomes

Every organization operates through two structures simultaneously. The first is the formal operating model: the organization chart, the documented processes, the governance frameworks, the role descriptions, and the decision rights that appear in policy documents and transformation blueprints. The second is the informal operating model: the actual network of relationships, trusted advisors, informal approvals, workarounds, and unwritten rules through which work actually gets done.

Transformation programs redesign the first. They consistently underestimate the second. The formal redesign produces a new operating model that is logically coherent and strategically aligned. The informal network continues to operate largely as before, routing decisions through trusted relationships that predate the redesign, maintaining workarounds that were built around limitations that the formal change was supposed to eliminate, and preserving influence patterns that the new reporting structure formally reassigned but practically did not.

Scrum.org's February 2026 analysis of organizational network dynamics puts a number on the consequence: 30 percent productivity loss as employees navigate the gap between formal authority and actual influence. That gap is not random. Organizations develop informal structures because formal hierarchies cannot adapt fast enough to operational reality. When formal structures have built-in limitations, informal structures fill the gap. The informal structure is not dysfunction. It is the organization's actual operating system, built through years of practical adaptation to the limitations of the formal one.

The implication for business architecture is direct: designing a new operating model without first understanding the informal one produces a design that addresses the documented version of how the organization works rather than the actual version. The transformation will meet resistance that looks like change management failure but is actually operating model design failure: the new formal structure conflicts with the informal one, and the informal one wins because it is the one employees trust, have invested in, and have built their working relationships around.

What the Informal Operating Model Actually Contains

The informal operating model has four components that are distinct from the formal structure and that each affect transformation outcomes in specific ways.

The Informal Decision Network

Most consequential decisions in organizations are not made in the meetings where they are formally announced. They are made in the conversations that precede those meetings, through the informal consultation process where decision-makers seek input from advisors they trust, often across formal organizational boundaries, before committing to a position that will then be presented as the formal recommendation.

The people who are influential in this informal consultation network are not always the same people who are formally accountable for the decisions. A senior technical architect three levels below the CIO may be consulted by every major vendor evaluation team because of their technical credibility, even though they have no formal role in vendor selection. A long-tenured director with no direct reports may effectively veto operational changes because the COO's trust in their operational judgment means nothing happens without their informal endorsement.

Transformation programs that reorganize formal accountability without mapping the informal consultation network will redistribute formal authority while leaving informal influence largely intact. The new structure may give formal decision rights to a team that lacks the credibility and relationships to exercise them effectively, while the people who actually shape decisions continue to do so through informal channels that the new structure did not account for.

The Trust Network

Organizations route high-stakes work through trusted relationships rather than formal structures when the formal structures are unreliable, slow, or have failed in the past. A team that needs a fast turnaround on a legal review does not always go through the formal legal intake process if they know from experience that it takes three weeks. They call the lawyer they worked with on the last project, who will turn it around in three days as a favour. A business unit that needs IT support for an urgent system issue does not always log a ticket. They call the IT contact who helped them last time.

These trust-based shortcuts are the informal operating model in its most visible form. They are also the operating model component that is most disrupted by reorganizations, because reorganizations break the working relationships that the trust network is built on. When the lawyer who handled the fast-turnaround reviews moves to a different team, the business unit that relied on that relationship loses a capability that does not appear in any capability map. When the IT contact who handled the urgent issues moves to a different account, the business unit discovers that the new formal process is slower and less reliable than the informal one they had relied on.

The McKinsey research on transformation success rates, consistently finding that 70 percent of transformations underperform against their objectives, reflects in part the disruption of informal operating models that transformation programs do not map before they reorganize. The formal capability may be preserved or improved by the new structure. The informal capability, built through relationship and trust rather than process design, is lost.

The Workaround Layer

Every organization has a layer of undocumented workarounds that compensate for limitations in formal systems and processes. The finance analyst who downloads the data to Excel because the BI system cannot produce the specific cut they need, then manually combines it with data from three other systems that are not integrated. The procurement officer who knows which vendor will accept a modified contract template and which will not, saving weeks of negotiation on every engagement. The customer service agent who knows the system limitation that causes a specific error and has developed a manual sequence that avoids triggering it.

These workarounds represent accumulated operational knowledge about where the formal systems fail and how to compensate. They are invisible to the operating model documentation because they are not documented anywhere. They exist in the knowledge and practice of specific individuals whose tenure in the organization provided the repeated experience through which the workaround was discovered and refined.

Transformation programs that replace the formal systems these workarounds compensate for consistently discover the workarounds only after the new system goes live. The new system eliminates the formal limitation the workaround addressed, but introduces new limitations that the workaround population had not anticipated. The people who knew the old workarounds are now in the position of re-learning how to compensate for a new set of system limitations, while the operational continuity the workarounds provided is temporarily lost.

Mapping the workaround layer before transformation is not an argument against changing the systems that generate the workarounds. It is an argument for understanding what the workarounds are compensating for, so that the new system can address those needs directly rather than creating the conditions for a new set of compensating workarounds.

The Informal Governance Layer

Formal governance frameworks define who has authority to approve what, through what process, with what documentation. Informal governance operates alongside the formal layer through the personal relationships, political dynamics, and unwritten precedents that shape which formal approvals are actually required, which can be obtained through informal channels, and which approvals are nominal because the real decision was made before the formal process began.

The most consequential informal governance in most large organizations is at the boundary between functions: the informal agreements between the IT function and the finance function about which IT decisions require finance approval, the informal understanding between the legal team and the business units about which contracts require legal review before they are signed versus which can be sent to legal after the fact, and the informal norms about which risk exceptions require escalation versus which are handled at lower levels based on trust rather than documented criteria.

These informal governance agreements are often more operationally important than the formal governance frameworks, because they determine the actual speed and friction of decision-making in daily operations. A transformation that redesigns the formal governance framework without understanding and redesigning the informal governance layer will produce a formal governance process that nobody follows precisely, because the informal governance layer continues to operate based on relationships and precedents that predate the formal redesign.

How to Make the Informal Visible Before Redesigning the Formal

Making the informal operating model visible is organizational network analysis applied to transformation design. It does not require sophisticated social network mapping software, though that tooling is available and useful for large organizations. It requires structured conversations with the people who know how the organization actually works, conducted before the operating model design work begins rather than after.

The diagnostic conversations have a specific structure. Rather than asking people to describe the formal process, ask them to describe what actually happens: who do they call when they need a fast answer, which formal processes do they use versus route around, which decisions require sign-off from someone who is not formally accountable, and which capabilities would be lost if specific individuals left the organization. The answers to these questions produce a picture of the informal operating model that no organization chart or process document contains.

The capability maturity assessment methodology described in this series provides the framework for this diagnostic. The four-dimension assessment, people, process, technology, and information, captures the formal dimension of how a capability is performed. The diagnostic conversations that precede the assessment reveal the informal dimension: which people are actually performing the capability versus who is formally accountable for it, which processes are actually followed versus documented, and which information flows are real versus prescribed.

The output of this diagnostic is a current-state operating model that includes both the formal structure and the informal overlay. That dual view is the design input that produces operating model designs that work in practice rather than on paper. The new formal structure is designed to preserve the informal capabilities that are producing genuine value, to provide formal support for the informal relationships that are doing critical work without formal recognition, and to eliminate the informal workarounds that compensate for formal system limitations by addressing those limitations in the new design rather than assuming they will disappear when the structure changes.

What This Means for Transformation Design

The operating model design process that accounts for informal structures has a different sequence from the one that does not. It begins with the informal diagnostic rather than the formal current-state documentation, because the informal diagnostic reveals what the formal documentation obscures. It incorporates the informal network's key nodes, the people whose informal influence is critical to how work gets done, into the design process rather than treating them as stakeholders to be communicated to after the design is complete. And it tests the proposed formal design against the informal network before implementation, identifying where the new structure conflicts with established informal relationships in ways that will generate resistance, workarounds, or capability loss.

The operating model design post in this series describes the formal methodology. The informal layer described here is what that methodology misses when it is applied without the diagnostic work that makes the informal visible. Together they produce a transformation design that is grounded in how the organization actually operates rather than how it is documented to operate, which is the difference between a transformation that changes how work gets done and one that changes what the org chart says while work continues as before.

Talk to Us

ClarityArc's business architecture practice designs operating models that account for both formal structure and informal dynamics, using diagnostic conversations and organizational network analysis to ensure the redesign addresses how the organization actually works rather than how it is documented to work. If your transformation is meeting resistance that looks like change management failure, the root cause is often operating model design, and we are ready to help you diagnose it.

Get in Touch
Previous
Previous

The Data Strategy for Organizations That Have Tried Before

Next
Next

The FinOps Reckoning: Why Canadian Cloud Spend Is Getting Away From You and What to Do