The Problem With Designing for Stability
The standard approach to operating model design assumes a relatively stable environment. You analyze the strategy, map the work, design the structure that best executes the strategy, and implement it. The model is then tuned over time as you learn more about what works. The underlying assumption is that the environment — the strategy, the technology, the market, the competitive landscape — will be sufficiently stable that the model you designed will remain valid long enough to deliver its intended value.
That assumption held reasonably well for much of the twentieth century. It holds less well now, and for some organizations it has never held at all.
I have spent nineteen years working with organizations across ten countries. A significant portion of that work has been with organizations that are not simply adapting to change — they are operating in environments of continuous structural change: mergers and acquisitions that restructure the competitive field every two to three years, technology platforms that shift the economics of delivery faster than the organization can absorb, regulatory environments that impose new obligations on quarterly timescales, and growth trajectories that mean the organization is effectively rebuilding itself every eighteen months.
For these organizations, the standard approach to operating model design produces a model that is obsolete before it is fully implemented. The design is completed, the implementation begins, and by the time the new model is operational, the strategic context that justified the design has shifted enough that the model needs to be redesigned. The organization ends up restructuring continuously without ever achieving the stability that the restructuring was meant to produce.
The alternative is not to design a model optimized for the current environment and then restart the design every time the environment changes. The alternative is to design for absorbing change — to build operating models that remain functional across a wider range of environmental conditions without requiring constant structural reconstruction.
Modular Architecture: Designing Clean Interfaces
The first principle of change-ready operating model design is modularity. Organizational units should be designed with clean interfaces between them — explicit definitions of what inputs they receive, what outputs they produce, and what decisions they make autonomously versus through coordination with adjacent units.
Modularity is a well-established concept in software architecture. Its application to organizational design is less systematic, but the logic is the same: a modular system can be reconfigured — units added, removed, or replaced — without requiring the entire system to be redesigned. A non-modular system requires touching everything when you change anything.
In organizational terms, a unit with a clean interface is one where the boundary conditions are documented and stable. If the unit''s internal processes change — new technology, different staffing model, different delivery approach — the change is contained within the unit because the external interface is unchanged. Adjacent units continue to receive the same outputs and provide the same inputs.
The practical test for whether your operating model has clean interfaces is this: if you replaced the team running a given function with a completely different team, how long would it take that new team to understand what they are supposed to deliver to whom, and what they need from others? If the answer is months, the interface is not clean — the function''s integration with the rest of the organization exists in the heads of the people currently running it, not in documented structure.
In a large HPE program I directed, one of the early structural decisions was to design the project delivery units as modular components with explicit handoff contracts. Each unit had a one-page specification describing its inputs, outputs, decision authority, and escalation path. When we brought on new delivery partners at months four and seven — additions driven by scope growth, not by anything we had planned for — those partners were able to integrate within weeks rather than months. The interface documentation meant that integration was a process of alignment to documented standards, not a process of learning how the organization informally operated.
Contrast this with a program I inherited mid-execution at a different client. The program had been running for eighteen months under a structure where integration between delivery units happened through informal coordination between individual project managers. When two of those project managers left in the same month, the integration collapsed. The dependencies between units existed only in the personal networks of the people who had been managing them. Rebuilding that coordination took four months and produced a formally documented interface structure that should have existed from the beginning.
Governance by Principle, Not by Rule
The second principle is the governance design choice that most organizations get wrong: the distinction between rule-based governance and principle-based governance.
Rule-based governance defines specific procedures, approval thresholds, and process steps. It is precise, auditable, and comprehensible. It is also brittle: when the environment changes in ways that the rules did not anticipate, the rules either produce wrong answers or require exception processes that gradually displace the formal system.
Principle-based governance defines the objectives that governance is meant to achieve and the values that should guide decisions within those objectives. It is flexible — principles apply across a wider range of contexts than specific rules — but it requires judgment to apply and is harder to audit for compliance.
The right design is neither purely rule-based nor purely principle-based. It is layered: principles at the top, rules operationalizing those principles for standard situations, and explicit exception processes for situations the rules do not cover. The critical discipline is making sure that when exceptions become standard practice, the rules are updated — not left as dormant policy while informal practice diverges.
In a contact center operation I built at Full Potential Solutions, the quality governance framework went through three major redesigns in eighteen months as the client portfolio evolved. Each redesign had to touch hundreds of specific quality rules because the original framework had been built around the specific metrics of the first client. When new clients arrived with different metrics and different quality definitions, the rules did not transfer.
The fourth version of the framework was designed on principles. The principle layer defined what "quality" meant across the portfolio: accuracy of information, resolution within committed timeframes, client-defined outcome criteria, and compliance with applicable regulatory requirements. The rule layer specified how those principles translated to specific metrics for each client. When new clients arrived, the rule layer was extended — new specifications were added — without touching the principle layer that applied consistently across the portfolio. The governance overhead for onboarding a new client dropped significantly because the foundational framework was already in place and the extension was incremental.
Explicit Change Absorption Capacity
The third principle is the one most consistently absent from operating model designs: intentional slack. Change-ready operating models are designed with explicit capacity to absorb disruption without cascading failure.
This runs counter to the efficiency logic that dominates most operating model design. Optimization means removing waste and maximizing utilization. A team operating at 90 percent capacity is more efficient than one operating at 70 percent. In a stable environment, this is correct. In an environment of continuous change, a team operating at 90 percent capacity has no room to absorb unexpected demands — a new regulatory requirement, a delivery failure that requires remediation effort, a strategic shift that redirects resources — without displacing something else.
The cascading failure pattern in over-optimized operating models is predictable: a disruption hits one team, that team is already at capacity, some of its work is dropped or delayed, the delay hits adjacent teams that were depending on that work, those teams now have gaps they cannot fill because they are also at capacity, and the disruption propagates across the model.
Change absorption capacity does not mean waste. It means intentional design of where the slack lives, what size of disruption it is designed to absorb, and what the escalation path is when disruptions exceed the designed absorption capacity.
In the venture portfolio I manage, the governance model for each venture includes an explicit capacity allocation for "absorb and respond" — work that was not planned but that must be handled when it arrives. The allocation varies by venture stage: early-stage ventures carry more of it because the uncertainty is higher. Mature ventures carry less. The key discipline is that this allocation is explicit, reviewed regularly, and adjusted when the actual pattern of disruptions changes.
The ventures that have experienced structural crises in the past three years have uniformly had this allocation crowded out by growth pressure. When everything is a priority and every resource is committed, the first thing that gets cut is the unallocated capacity — because it appears to be doing nothing. It is doing something. It is carrying the organization''s ability to respond to the unexpected. When that capacity is gone, the organization cannot respond to disruption without cannibalizing something that was already committed.
Documented Decision Authority
The fourth principle is the most operationally specific: decision authority must be explicitly documented and maintained as a first-class governance artifact.
An operating model that does not document who decides what, under what conditions, with what escalation path, is not a complete operating model. It is an organizational chart with implied authority. Implied authority works when the people who carry it are stable and when the situations they face are familiar. It fails when people leave, when the organization grows, or when the situations are novel enough that the informal consensus about who decides does not apply.
The documentation of decision authority is not a RACI chart. RACI charts document who does what. Decision authority documentation answers a different question: in a situation of conflict or ambiguity about a decision of type X, who has the authority to make the call, what information are they expected to have consulted, and when does the situation require escalation to a higher authority?
At a practical level, this means documenting four things for each significant decision type: who decides (not a person — a role), what constitutes a decision of this type (scope boundaries), what inputs the decision-maker is expected to have considered, and what escalation triggers apply. This documentation is not long. For most decision types, it fits on half a page. The value is not in its length — it is in the fact that it exists and can be consulted when the normal informal channels are not available.
When I rebuilt the operating model for a consistently underperforming office in the Australian network, the first three weeks were spent exclusively on decision authority documentation. We did not change any process, any reporting structure, or any personnel. We documented who decided what. By the end of the three weeks, three previously unresolvable inter-team conflicts had resolved because it became clear that one team had been making decisions that were not theirs to make, and the team that should have been making them had been deferring because the authority was ambiguous.
Decision authority documentation does not eliminate conflict. It changes the nature of conflict from "who is right?" to "who decides?" — which is a much faster question to resolve.
Operational Evidence
The pattern I have described — continuous change producing operating model obsolescence — was most acute in the US startup I worked with over an extended engagement. The company was scaling rapidly: from $8,000 to $10,000 per month in revenue when I first engaged with their operational structure, to over $500,000 per month within the engagement window. That is a 6,150 percent revenue scaling across a period during which the operating model was entirely rebuilt three times.
The first operating model was designed for a team of four. It worked. The second was designed for a team of fifteen. It worked, briefly. The third was designed for a team of forty. It held.
The difference between the first two redesigns and the third was modularity. The first two models were integrated — processes that worked across the whole organization, authority structures that depended on everyone knowing everyone, delivery approaches that relied on informal coordination. Each worked at the scale it was designed for and failed when the organization grew past it.
The third model was designed modularly from the beginning, with explicit interfaces between the acquisition function, the delivery function, and the operations function. Each function could scale internally without requiring the others to change. Decision authority was documented at each level. Governance was principle-based with rules that could be extended as new situations arose.
The organization continued to grow after my engagement was complete. The operating model did not require a fourth redesign at the same pace because it had been designed to absorb scale rather than to optimize for a specific scale point.
A second data point: in the multi-venture portfolio I manage, the ventures that have held their structure through the most disruption have been the ones where governance was principle-based. The ventures with detailed rule-based governance have required the most intervention when market conditions changed — because the rules were written for conditions that no longer existed, and updating a hundred specific rules is slower and more error-prone than applying principles to a new situation.
Where This Does Not Apply
The four principles described here are not universally appropriate. They carry costs that are not worth paying in every context.
Modular architecture requires more explicit coordination than integrated approaches. When the organization is small, the coordination overhead of maintaining clean interfaces exceeds the benefit. A team of five does not need documented handoff contracts — the people are in the same room and can resolve integration questions in real time. Modular design is appropriate when the scale or complexity of the organization means that implicit coordination is no longer reliable.
Principle-based governance requires judgment. It places higher demands on the people applying the governance because they must understand the intent behind the principles, not just follow specific rules. Organizations with less experienced teams, or with regulatory environments that demand specific procedural compliance, may not have the capacity to operate effectively under a pure principle-based model.
Explicit change absorption capacity runs counter to short-term efficiency metrics. It will look like waste to anyone who is measuring utilization without understanding the function of the unallocated capacity. Organizations under severe short-term financial pressure may not be able to maintain explicit slack regardless of its structural value.
Decision authority documentation requires maintenance. As the organization evolves, decision types change, and the documentation must be updated to reflect the current state. An organization that documents decision authority once and treats it as permanently valid will find that the documentation drifts from reality over time, eventually producing the same confusion as no documentation at all.
The Principle
Operating models are not designed once and deployed permanently. They are living structures that either adapt as the organization''s environment changes or become obstacles to adaptation. The choice in operating model design is not between stability and flexibility — it is about where the flexibility lives. A model designed for a specific steady state will require complete redesign when the state changes. A model designed for change absorption can accommodate a wider range of states without structural reconstruction.
The four principles — modularity, principle-based governance, explicit change absorption capacity, and documented decision authority — do not produce a model that is optimized for any single context. They produce a model that remains functional across more contexts. For organizations in environments of continuous change, that is the right objective. Optimization for the present state is expensive to achieve and immediately begins to depreciate. Adaptability compounds.