Complexity Trap: why More Process Doesn’t Mean Less Risk
There is a particular kind of meeting that happens in organisations around the eighteen-month mark of a scaling phase. Someone — usually a senior leader who has just survived a painful project failure — stands up and says: “We need more rigour. We need more controls. We need a proper process for this.”
The room nods. The instinct is correct. Something went wrong, and structure is the antidote. A working group is formed, a framework is adopted, a new layer of approval is introduced. Six months later, the organisation is slower, decisions are harder to trace, and the underlying risk — the actual source of the failure — is still present. Now it is simply better hidden.
This is the complexity trap. It is not caused by bad intentions or poor thinking. It is caused by a fundamental misdiagnosis: confusing activity with protection, and process with governance.
After more than a decade working across digital transformation programmes, SaaS implementations, and large-scale project portfolios, I have watched this pattern repeat with uncomfortable consistency. The organisations that scale well are not the ones with the most comprehensive process libraries. They are the ones that understand precisely what their processes are actually protecting against — and what those same processes are silently doing to their velocity, their culture, and their ability to make clear decisions under pressure.
The Anatomy of a Complexity Trap
A complexity trap does not arrive fully formed. It accumulates. Each individual addition — a new sign-off requirement, an additional status report, a mandatory pre-meeting before the actual meeting — seems entirely reasonable in isolation. The problem is systemic, not symptomatic.
What tends to happen is this: a process layer is introduced in response to a specific failure. That layer reduces the likelihood of that particular failure recurring. But it also introduces friction. To manage that friction, another layer is added — a coordination mechanism, a tracking tool, a governance committee. That layer creates its own ambiguity about ownership. To resolve the ambiguity, escalation paths are formalised. Those escalation paths slow decision cycles. To compensate, informal workarounds emerge. Those workarounds bypass the original control entirely.
By the end of this sequence, the organisation has more process than before the failure, less clarity about who actually decides anything, and the original risk is now being managed through an informal channel that exists precisely because the formal one became unworkable.
This is not dysfunction in the traditional sense. Every step felt rational. The complexity was built by competent people trying to do the right thing.
Why Risk Doesn’t Reduce Linearly With Process
The intuitive model is linear: more controls, less risk. The reality is far more like an inverted U. Up to a certain point, adding structure genuinely reduces exposure. Beyond that point, you begin generating a different category of risk — one that is harder to see and considerably harder to address.
The risks that emerge from over-engineered process are not the same as the risks you were originally managing. They include:
Decision latency. When every significant choice requires multiple approvals, decisions slow down. In fast-moving environments, slow decisions are not neutral — they are themselves a form of risk. Markets move. Technical dependencies shift. Vendor windows close. A decision made correctly but six weeks too late can be more damaging than a faster decision that was seventy percent right.
Accountability diffusion. Complex approval structures distribute ownership to the point where it becomes genuinely unclear who is responsible for an outcome. When five stakeholders have signed off on a decision, none of them feel fully accountable for what follows. This is not a cultural failure — it is a structural one. The process itself created the conditions for accountability to dissolve.
Risk concealment. Perhaps the most insidious effect. When teams know that surfacing a risk will trigger a complex governance response — escalations, additional reporting cycles, potential project pauses — they develop a rational incentive to manage risks quietly rather than flagging them. The formal risk register looks clean. The actual risk landscape is obscured. The first indication of a problem becomes the problem itself, rather than a signal that could have been acted upon earlier.
Cognitive overhead as a bottleneck. Every process layer requires mental bandwidth to navigate. In senior teams working across multiple programmes simultaneously, this overhead is not trivial. Time spent managing the governance apparatus is time not spent making substantive decisions. Eventually, good people begin to optimise for process compliance rather than outcome quality — not because they have given up, but because the system rewards the former.
The Framework: Distinguishing Governance From Administration
The practical challenge is that most organisations cannot easily distinguish between governance that genuinely manages risk and administration that merely generates the appearance of control. Both look similar from the outside. Both involve meetings, documents, and approvals.
The distinction I have found most useful across large-scale programmes comes down to a single question: does this process change what people do, or does it change what people record?
Genuine governance shapes behaviour. It creates clarity about who decides, what information is required to decide, and what happens when a decision turns out to be wrong. It creates feedback loops. It surfaces information that would otherwise stay buried. It makes accountability legible.
Administration, by contrast, shapes documentation. It ensures that the right forms are completed, the right meetings are attended, the right sign-offs are obtained. It creates the paper trail that demonstrates compliance with the process. But it does not fundamentally alter how decisions are made or how risks are identified.
This distinction points toward a working framework I use when auditing governance structures in scaling organisations:
The Purpose Test. For each governance mechanism — every approval gate, every status report, every committee — ask: what specific risk does this exist to manage, and how does it change behaviour in response to that risk? If the answer is unclear, or if the mechanism has drifted from its original purpose over time, that is a strong signal that you are looking at administrative overhead rather than effective governance.
The Decision Owner Test. For every category of significant decision in your programme portfolio, there should be a single identifiable person who is accountable for that decision — not a committee, not a quorum, not a working group. Committees can advise, consult, and challenge. But accountability must be individual. If you cannot name that person, your governance structure has already failed the most basic test.
The Information Flow Test. Governance exists to move relevant information to decision-makers at the right time. Map the actual flow of information in your organisation: what reaches the people who need it, when, and in what form? Where does information get filtered, delayed, or repackaged? The bottlenecks in your information flow are often more revealing than the formal governance charts.
The Worst-Case Visibility Test. The real measure of a governance structure is not how it performs when everything is on track — it is how it performs when something goes seriously wrong. Ask yourself: if a major risk emerged today, how quickly would it reach the person who needs to act on it? What would prevent it from being flagged? If the honest answer involves workarounds, informal channels, or a reluctance to trigger formal escalation, your governance structure is creating concealment risk.
Implementation Risks and Trade-offs
Applying this framework requires navigating some genuine tensions. Simplifying governance feels, to many senior stakeholders, like loosening control. That perception is a real implementation risk in its own right.
The conversation with a board or a senior leadership team about reducing process overhead is not straightforward. The language of “removing controls” triggers legitimate concern — particularly in regulated industries, publicly funded programmes, or organisations that have recently experienced a high-visibility failure. The argument needs to be reframed: the goal is not fewer controls, but more *effective* controls, and the evidence that a control is effective is that it changes what people do, not just what they document.
There is also a meaningful trade-off between standardisation and adaptability. Organisations operating across multiple projects simultaneously often standardise governance frameworks for efficiency — one approval structure, one reporting cadence, one escalation path. This works reasonably well for programmes of similar scale and risk profile. It works poorly when applied uniformly across a portfolio of genuinely different projects. A large ERP implementation has different governance needs than a rapid UX iteration cycle. Forcing both through the same framework is not consistency — it is the wrong kind of efficiency.
The calibration question is not whether to standardise, but what to standardise. The core logic of governance — who decides, what information is needed, how risk surfaces — can and should be consistent. The specific mechanisms through which that logic is implemented should be proportionate to the programme’s actual risk profile, velocity, and stakeholder complexity.
A third tension worth acknowledging: simplifying governance in an organisation that has developed workaround cultures is harder than it sounds. If teams have spent months or years navigating around formal process, those workarounds have become load-bearing. They are how actual decisions get made. Removing the formal overhead without addressing the informal structures that have replaced it can create genuine confusion about how to proceed. The governance redesign needs to be accompanied by deliberate clarity about the new decision logic — not just removed and replaced with an expectation that people will figure it out.
What Effective Governance Actually Looks Like
The organisations I have seen manage complexity well share a few consistent characteristics that are worth naming explicitly.
They treat governance as a design problem, not a compliance problem. They ask what behaviour they need to produce, and they design the lightest possible structure that reliably produces that behaviour. They revisit that design regularly — not because process is inherently bad, but because context changes and governance structures that were appropriate at one stage of growth often become obstacles at the next.
They maintain a hard distinction between programme-level governance (portfolio oversight, strategic alignment, resource allocation) and project-level execution (daily decision-making, risk surfacing, delivery management). Conflating these two levels is one of the most common sources of the complexity traps described above. Senior leadership gets involved in decisions that should be made closer to execution; execution teams wait for approvals that slow momentum without adding meaningful oversight.
They invest in information architecture rather than approval architecture. The most effective governance interventions I have seen have not been new committees or additional sign-off requirements. They have been improvements in how information reaches decision-makers — better dashboards, clearer risk registers, more honest programme reporting. The instinct to add governance is often, at root, a response to information anxiety: senior leaders do not feel they have enough visibility, so they add mechanisms to generate more reporting. The better response is to make existing information more reliable and more accessible.
And they hold the accountability question with genuine rigour. Named owners. Clear mandates. Explicit authority to make decisions without escalating for every edge case. This is uncomfortable for many organisational cultures — it means that specific people are visibly accountable when things go wrong. But it is also what makes organisations capable of learning rather than just surviving.
The Strategic Reflection
The deeper issue underneath the complexity trap is a particular relationship with uncertainty. Process proliferation is, in many cases, an attempt to reduce the felt experience of risk by increasing the felt experience of control. More approvals feel safer. More documentation feels more rigorous. More committee involvement feels more thorough.
But risk is not reduced by documentation. It is reduced by better decisions, made by people with the right information, who have clear authority to act on what they know, and who surface problems early because the system rewards honesty rather than punishing it.
The measure of a governance structure is not its comprehensiveness. It is whether the people inside it make better decisions than they would without it — and whether the people most likely to see a problem first feel genuinely equipped to flag it.
If your process is doing that, it is worth every layer. If it is not, the question is not whether to simplify. The question is how quickly you can begin.