Most organisations do not have a strategy problem. They have an execution problem disguised as coordination.
The strategy is often clear enough. The technology is usually viable. The people are capable. The funding exists. There is executive sponsorship, a programme structure and more than enough governance to reassure everyone that something serious is happening. Then the work begins to move across organisational boundaries, and what looked straightforward starts to slow down.
Product needs architecture. Architecture needs security. Security needs infrastructure. Infrastructure needs procurement. Procurement needs legal. Delivery needs someone to make a decision. Operations needs to know what exactly it is being asked to support. None of these interactions is unreasonable in isolation, and that is precisely why the problem is so persistent. Every function can be doing its job correctly while the organisation as a whole becomes slower, more expensive and less capable of delivering anything consequential.
The friction lives in the gaps between competent teams.
Local optimisation creates organisational drag
Most large organisations are designed around specialist functions, and there is a perfectly sensible reason for that. Security teams should think deeply about security. Engineers should optimise for engineering quality. Finance should protect capital. Procurement should control commercial exposure. Operations should protect stability. Architecture should improve coherence and reduce unnecessary variation.
The problem begins when each function is optimised independently and measured primarily against its own objectives. Security reduces risk by adding controls. Operations reduces instability by limiting change. Procurement improves commercial discipline by adding process. Architecture improves consistency by introducing standards and review. Finance protects spend through approval gates. Every one of these behaviours may be rational within the boundaries of the function, but collectively they can make progress painfully difficult.
This is one of the more frustrating characteristics of transformation work. The organisation does not need to contain a villain, an incompetent team or an obviously broken process for delivery to grind to a halt. Quite often, everyone is behaving exactly as their incentives encourage them to behave. The result is a system in which local success produces organisational drag.
That is why transformation so often feels harder than the underlying technology would suggest. The real complexity is not always technical. It is the cumulative cost of moving an idea through an organisation that has evolved into a sequence of checkpoints rather than a system for producing outcomes.
Then someone suggests a RACI
At some point, somebody will decide that the real problem is insufficient clarity of responsibility. This is when the RACI appears.
A spreadsheet is created. Across the top are stakeholders. Down the side are activities, decisions and artefacts. Every cell is populated with an R, A, C or I until the organisation has produced a highly detailed representation of who is theoretically involved in everything.
The attraction is obvious. RACIs create the appearance of precision. They make responsibility look manageable because it has been reduced to a taxonomy and distributed neatly across a grid. The problem is that most serious delivery failures are not caused by uncertainty about whether somebody is Consulted or Informed. They are caused by uncertainty about authority.
Who can decide? Who owns the outcome? Who can accept the risk? Who can spend the money? Who can stop the work? Who is accountable when several functions disagree and the answer is no longer obvious?
A RACI often answers those questions badly, if at all. Worse, it can conceal the underlying problem by documenting complexity rather than removing it. If twelve people are involved in a decision, carefully describing the role of all twelve does not necessarily make the decision clearer. It may simply formalise twelve opportunities for delay.
There is something wonderfully corporate about this. When an organisation cannot work out who has authority, it responds by creating a document proving that everyone is involved.
Accountability weakens as it is distributed
Responsibility becomes less effective as it is spread across too many organisational boundaries. This is not because people are unwilling to take ownership. It is because people naturally optimise for the risks and incentives they personally carry.
Security sees security risk. Finance sees financial risk. Operations sees service risk. Legal sees legal exposure. Engineering sees delivery risk. Architecture sees structural and technical risk. All of those perspectives matter and any serious organisation needs them.
What none of those functions can do independently is decide what balance of those risks the organisation should accept in pursuit of an outcome. That is a leadership responsibility. Somebody must be able to look across the whole system and decide that one risk matters more than another, that a delay is more dangerous than a technical compromise, or that a commercial opportunity justifies moving faster than the standard process would normally allow.
That judgement cannot be replaced by stakeholder management. It cannot be outsourced to governance, and it certainly cannot be manufactured by adding another column to a spreadsheet.
Handoffs destroy context
There is another cost to handoffs that is less visible but often more damaging. Every time work moves between teams, context gets compressed.
The business problem becomes a requirement. The requirement becomes an architecture. The architecture becomes a security review. The security review becomes a set of controls. The controls become delivery tasks. The delivery tasks become operational procedures.
At each step, the representation becomes more specific but often less connected to the original purpose. The teams involved are not doing anything wrong. They are translating the problem into the language and responsibilities of their function. The trouble is that each translation strips away a little context.
Eventually the organisation can find itself arguing passionately about whether a particular control, standard or approval has been satisfied while the original business objective has become strangely distant. The process has become more visible than the outcome it was supposed to enable.
This is how organisations end up implementing technically correct solutions to increasingly irrelevant problems. Nobody consciously chooses this result. It emerges gradually as the work passes through a series of rational, well-intentioned handoffs.
The transformation has not failed dramatically. It has simply been processed to death.
The usual response makes things worse
When leaders notice that delivery is slow, the instinctive response is usually to increase control. More reporting is introduced. Governance forums multiply. Programme management expands. Steering committees become more frequent. Escalation paths are formalised. New checkpoints are added to ensure that work does not get stuck.
The intention is reasonable. The effect is often the opposite of what was intended.
Every additional governance mechanism creates another interaction between teams. Every interaction creates another potential queue. Every queue introduces waiting time, and waiting time is one of the least measured sources of cost in large organisations. A piece of work may take two days to complete but spend three weeks waiting for permission to begin.
Because that delay looks like poor execution, organisations frequently respond with even more oversight. This creates a particularly destructive loop in which the machinery designed to improve delivery steadily consumes more of the organisation's capacity to deliver.
There is a point at which governance stops reducing risk and starts generating it.
Measure the journey, not just the teams
Leaders tend to ask whether individual functions are performing well. They want to know whether security is effective, whether engineering is productive, whether operations is stable and whether procurement is controlling spend. Those questions matter, but they do not tell you whether the organisation can move.
A more useful question is how much organisational energy it takes for an important decision to travel from intention to execution.
How many teams touch it? How many approvals does it require? How many times is the same context explained again? How often does work stop because nobody has clear authority? How many decisions are escalated because delegation is ambiguous? How much time is spent waiting rather than doing?
Those questions expose something that functional metrics often hide. An organisation can have excellent teams, strong leaders and green dashboards while still being structurally incapable of moving quickly.
Transformation is not the sum of functional performance. It is the ability of the whole organisation to act coherently.
Reduce the distance between decision and consequence
The answer is not to remove specialist functions or abandon governance. Controls exist for good reasons, and expertise matters. The answer is to design the organisation so that decisions remain connected to outcomes.
That means giving people genuine authority over clearly defined outcomes rather than asking them to coordinate endlessly across functional boundaries. It means making risk acceptance explicit rather than forcing every function to defend its own interests until consensus somehow emerges. It means bringing specialist teams into the work early enough that their expertise shapes the solution rather than appearing later as an approval barrier.
It also means being willing to remove decisions that should no longer exist. Many organisations carry approval mechanisms long after the risk that created them has disappeared. Others escalate decisions because nobody has bothered to redefine authority as the organisation has grown. The resulting complexity becomes normal simply because it has been there for years.
And when accountability appears to require thirty-seven rows of a RACI matrix, it is worth considering the uncomfortable possibility that the problem is not the matrix. The matrix is merely documenting the mess.
High-performing organisations are not necessarily those with the strongest individual functions. They are the ones where responsibility survives the journey between them, where context remains attached to decisions and where authority is clear enough that progress does not depend on navigating an ever-expanding network of stakeholders.
Strategy rarely dies in the boardroom. More often, it dies somewhere between teams, waiting for somebody who is apparently Responsible, Accountable, Consulted or Informed to make a fucking decision.