How Every Decision Worth Making Travels The Organisation
Large organisations are complex by necessity. The scale of what they operate, the breadth of what they deliver, and the number of people required to do it means that structure is not optional — it is the mechanism through which complexity is managed.
Most large organisations settle into some version of a matrix. Horizontal technology functions — platforms, APIs, data, channels — sitting alongside vertical business or product teams responsible for specific features, capabilities, or customer journeys. Some organise primarily around products, with engineering and architecture embedded within each product line. Others organise around customer segments, with technology functions wrapped around the segment rather than the capability. The permutations vary. Each layer has its own leadership, its own priorities, and its own definition of success.
Within that matrix, architecture doesn’t sit in one place. It is embedded across layers and functions — enterprise architecture setting direction and guardrails at the top, and architecture teams within each horizontal and vertical operating to their own strategies, their own roadmaps, and their own north stars. The enterprise layer exists to provide coherence. The embedded layers exist to deliver. In theory, these two things are complementary. In practice, the relationship between them is where some of the most consequential — and most exhausting — dynamics in large organisations play out.
This edition is about decisions. Specifically, about what happens to them.
The decision itself is rarely the problem.
In most large organisations, the people closest to the work arrive at a view relatively quickly. They understand the context, they have assessed the options, and they have a recommendation. That part — the actual thinking — might take days or a couple of weeks. It is the right amount of time for a decision of that complexity.
What follows is where the time goes.
Every decision of consequence in a matrix organisation has to travel. It moves through layers of review, approval, and governance — each layer applying its own lens, its own priorities, and its own definition of what good looks like. The enterprise architecture function applies an enterprise lens. Engineering applies a delivery lens. The business applies a commercial lens. Each perspective is legitimate. None of them are fully aligned. And the decision sits in the middle, accumulating commentary, attracting opinions, and waiting for a state of alignment that the structure of the organisation makes genuinely difficult to reach.
What should take two weeks routinely takes six. Sometimes longer. Not because the decision was wrong. Not because the process was corrupt. But because the matrix that exists to manage complexity creates a complexity of its own — and decisions are where that complexity becomes most visible.
There is usually a RACI model. Accountabilities are defined. Responsibilities are documented. In theory, the model exists precisely to prevent this — to ensure the right people make the right decisions and the right people support rather than obstruct. In practice, the model and the reality diverge. The formal accountability structure describes how decisions should be made. The actual mechanism through which decisions get made is something different entirely.
Consider a technology choice. A team needs a workflow orchestration tool. The architecture function assesses the options, applies the relevant technical criteria, and arrives at a recommendation. The recommended tool has already been proven within the organisation — not as an experiment, not as a pilot, but in production, for an identical use case, in a different area of the business. The risk has already been retired. The recommendation is not speculative.
What follows is not a rubber stamp.
The enterprise architecture function is balancing tool choices across multiple teams and multiple programmes. Their lens is enterprise-wide standardisation — reducing the number of tools the organisation supports, managing licensing costs, and maintaining a coherent technology landscape. A legitimate lens. But a different one. And in this case, it introduces competing options into a conversation that the team closest to the work considered closed.
Engineering has a view too. The recommended tool is, in their assessment, overengineered for the use case. This is also a legitimate concern — but it is a delivery concern, not an architectural one. It is a question of resourcing, training, and implementation approach. It is not a reason to reopen the technology decision. The RACI model, had it been followed, would have kept these two conversations separate. The architecture team makes the technology decision. Engineering organises to deliver it. The enterprise function governs and supports. Each lane is defined. Each lane has a purpose.
Instead, the lanes blur. The technology decision becomes a negotiation between three functions with three different lenses, none of which are wrong, none of which are fully aligned. Weeks pass. Documentation is produced. Reviews are scheduled. Alignment is sought and partially reached and then partially lost again. The enterprise function continues to carry a preference for a different tool. Engineering continues to question the recommendation. The architecture team continued to defend a decision it had made — correctly — weeks earlier.
Ten to twelve weeks after the analysis was complete, an engineering proof of concept was finally underway. The decision had nominally been made. The noise eventually stopped. But the time lost in the alignment process — time that could have gone into delivery — was gone. And the proof of concept that should have started in week three started in week eleven.
The tool was never the problem. The structure around the decision was.
The second example is more nuanced. And in some ways more instructive.
A business critical legacy estate. Years of accumulated complexity — an architecture that has received only regulatory funding and reactionary investment for the better part of two decades. Not neglect exactly, but a consistent prioritisation of the immediate over the foundational. The estate has served its purpose. But legacy and market forces are now catching up, and the case for transformation is no longer optional. The strategy is clear: create domains that encapsulate the business logic, master the data, and rationalise the complexity into something that can be owned, evolved, and delivered against with clarity.
The domain boundaries need to be agreed. The capabilities that sit within each domain need to be defined. This is foundational work — get it wrong and everything built on top of it inherits the misalignment.
The team closest to the work has a view. The capabilities are understood well enough to begin. The boundaries are drawn carefully enough to avoid overstepping into adjacent domains owned by other teams. The thinking is sound.
And then the conversation opens up.
This is where something discussed in a previous edition of this newsletter becomes directly relevant. Architectural language is accessible. Domains, capabilities, bounded contexts — the vocabulary of modern architecture is intentionally plain enough to invite broad participation. That accessibility is by design. It is meant to make architecture collaborative, to bring business and technology closer together, to ensure that what gets built reflects what the organisation actually needs.
But accessibility has a shadow side. When everyone can engage with the language, everyone feels qualified to have a view. And in a matrix organisation, everyone does. Product teams have a view on what the domain should contain. Business stakeholders have a view on where the capability boundaries should sit. Other architecture functions have a view on what should be built and where. The enterprise function has a principle — one capability, one place, available for all to consume — and applies it with a consistency that does not account for the business process and journey level nuance that makes the principle, in this specific context, too blunt to be useful.
The principle is not wrong. Building the same capability twice is wasteful. Fragmentation creates its own complexity. An enterprise function holding that line is doing exactly what an enterprise function should do. The problem is not the principle. The problem is the rigidity of its application — a black and white rule imposed on a situation that has genuine shades of grey, and a governance function that is not distinguishing between the spirit of the guardrail and a literal interpretation of it.
Six months pass. One domain. The capabilities for that domain are eventually agreed — not because the governance model resolved the tension, but because the weight of time and negotiation and exhausted alternatives finally produced a temporary state of alignment.
These domain conversations do not close quickly. The pattern, once established, tends to repeat — each new domain boundary triggering the same cycle of competing views, accessibility of language inviting broader participation than the decision requires, and a governance function applying principles at a level of abstraction that does not account for the nuance on the ground. Weeks become months. And while the conversations continue, the transformation waits. The legacy persists. The market forces that made the case for change do not pause while the organisation works through its alignment process. The business feels it. And eventually, so does the customer.
There is almost always a RACI model.
Accountability is defined. Responsibilities are documented. Decision rights are assigned — at least on paper. The model exists precisely to prevent what the two examples above describe. It exists to ensure the right people make the right decisions, and the right people support rather than obstruct. In theory, it is the mechanism that keeps the matrix functional.
In practice, the model and the reality diverge in ways that are rarely acknowledged openly.
The formal accountability structure describes how decisions should be made. It does not describe how they actually get made. What actually terminates the loop — in both examples above, and in countless variations of the same pattern across large organisations — is not the model. It is organisational weight. A senior leader steps in. Two senior leaders negotiate an outcome between themselves. The decision that could not find resolution through the formal process finds it through the informal hierarchy.
Calling that a model would be generous. It is an escalation mechanism. And there is an important distinction between the two. A model is a designed, repeatable process that produces consistent outcomes. An escalation mechanism is what organisations resort to when the designed process has failed. The fact that it works — that senior leader intervention does eventually unblock delivery — does not make it a model. It makes it a coping mechanism dressed as one.
What makes this particularly costly is not the escalation itself. It is everything that precedes it. The weeks of alignment loops. The documentation produced and reviewed and challenged. The meetings scheduled and rescheduled. The energy spent defending decisions already made. All of the avenues that have to be exhausted before the organisation accepts that the formal process has run its course and a different mechanism is needed.
Exhausting all avenues is in itself exhausting. And the time lost in that exhaustion does not come back.
The delivery that was waiting on the decision continues to wait. The teams that could have been building continue to be held in a state of readiness that slowly erodes into frustration. The business case that justified the investment continues to accrue carrying costs that nobody budgeted for. And the business waits and the customer waits and transformation waits.
Which brings us to the question that sits underneath both of these examples. And underneath every variation of this pattern that plays out across large organisations every day.
Do large organisations ever truly solve for this?
The structures exist. The frameworks exist. The governance models, the RACI matrices, the enterprise architecture functions, the decision rights — all of it exists. And yet the two examples above are not unusual. They are not edge cases or failure modes. They are the normal operating rhythm of large organisations trying to make decisions in a matrix that was designed to manage complexity but produces a complexity of its own.
The obvious answer is that the RACI model should be followed. Roles and responsibilities exist for a reason. The people accountable for a decision should make it. The people responsible for supporting it should support rather than obstruct. The people who need to be consulted should be consulted — and then the decision should move. That answer is not wrong.
But it raises a question of its own. Enforcing the RACI model means constraining who gets to influence a decision. And in a matrix organisation, some of the most valuable perspectives come from exactly the people the model would constrain. The engineering concern about over-engineering is legitimate. The enterprise principle about building capabilities once is legitimate. The question is not whether those perspectives have merit. The question is whether the mechanism through which they are expressed — an open-ended alignment loop with no clear termination point — is the right one.
Tightening the model might produce faster decisions. It might also produce narrower ones. And whether that tradeoff is worth making is not a question with a clean answer.
What is harder to accept is the alternative — that the organisation is not conscious of the cost at all. That the loops and the alignment cycles and the escalations are simply how things work, unremarked upon and unexamined, while the business waits and the customer waits and transformation waits.
The question worth asking is whether large organisations are organised to get things done. Or whether they are organised to manage the complexity of their own organisation. And whether, at some point, those two things became mutually exclusive.
