Most technology restructures fail. Not because the people are wrong, but because the restructure changes the org chart without changing the operating model. People move. Reporting lines change. New names appear on new boxes. But the way work actually flows — the constraints, the bottlenecks, the decision rights — remains unchanged. Within six to twelve months, the same coordination overhead returns. The same complaints surface. And a new restructure is proposed.
This is not a failure of execution. It is a failure of diagnosis. The organisation treated a structural problem as a personnel problem, and the structural problem — predictably, inevitably — reasserted itself.
The org chart is not the operating model
This distinction is fundamental, and it is almost universally overlooked. The org chart shows who reports to whom. It is a hierarchy of authority — a map of management relationships. It tells you where people sit in the formal structure. It says nothing about how work is done.
The operating model is entirely different. It describes how work flows through the organisation. How decisions are made, and by whom. How accountability is distributed — not on paper, but in practice. How outcomes are measured and how those measurements drive behaviour. The operating model is the invisible architecture that determines whether the organisation can actually deliver what it promises.
Most restructures redesign the org chart. Almost none redesign the operating model. This is why restructures feel productive but deliver nothing. The visible structure changes. People see new team names, new leadership assignments, new diagrams on the intranet. It looks like progress. But the invisible structure — the one that actually governs how work gets done — remains untouched. The same approval processes survive. The same governance forums persist. The same unclear accountabilities continue to slow everything down.
Changing the org chart without changing the operating model is like repainting the walls of a building with a broken foundation. The building looks different. It is still sinking.
Why the bottlenecks reappear
When you move people without redesigning work flow, the bottlenecks follow. They do not disappear — they relocate. The queue that existed before the restructure forms again, in a different part of the organisation, within weeks. The same structural constraints produce the same structural outcomes, regardless of where the people sit.
Consider the patterns that recur across almost every failed restructure:
- Shared services that create queues. The organisation centralises infrastructure, security review, or architecture governance into a shared function. The intent is consistency and efficiency. The result is a bottleneck. Every team now depends on the same small group for approvals, reviews, or provisioning. The queue grows. Delivery slows. A restructure moves the shared service under a different leader or splits it across business units — but the approval process, the governance model, and the capacity constraints remain identical. The queue simply reforms under new management.
- Approval chains that survive restructures. Architecture review boards, change advisory boards, security sign-off processes — these governance structures are rarely touched during a restructure. They persist because they are embedded in policy, not in the org chart. Moving people into new teams does nothing to address the fact that a single architecture review board is the gating function for every major change. The restructure changes who sits in the meeting. It does not change the meeting.
- Coordination layers that reform. Restructures often eliminate coordination roles — programme managers, integration leads, cross-functional liaisons. Within months, these roles reappear, sometimes with different titles. They reappear because the underlying need for coordination has not been addressed. The operating model still requires teams to synchronise across boundaries. Remove the coordinators without removing the need for coordination, and the organisation will reinvent them.
- Accountability that remains diffused. Before the restructure, nobody was clearly accountable for end-to-end outcomes. After the restructure, nobody is clearly accountable for end-to-end outcomes — just in a different configuration. The restructure moved boxes. It did not assign ownership.
Each of these is a symptom of the same root cause: the restructure addressed the visible structure and left the invisible one intact.
The coordination overhead trap
Here is the cruel irony of most restructures: they create more coordination overhead, not less. The restructure was supposed to reduce friction. Instead, it created new friction in different places.
New teams need new interfaces. When you split a function into two, you create a boundary that did not exist before — and boundaries require coordination. New reporting lines create new alignment meetings. The leaders of the new structure need to synchronise with each other, with their stakeholders, and with the teams they inherited. Matrix structures, introduced to provide both functional depth and business alignment, multiply this overhead exponentially. Every person with two reporting lines is a coordination problem waiting to surface.
A restructure that increases the number of organisational boundaries without reducing the need to coordinate across them has not simplified the organisation. It has made it more expensive to operate.
The mathematics are unforgiving. Coordination overhead scales with the number of dependencies between teams. A restructure that creates more teams, more boundaries, or more reporting relationships without eliminating dependencies will always increase overhead. The organisation will feel busier. It will deliver less. And within a year, someone will propose another restructure to fix the problems created by the last one.
What a restructure should actually address
If the org chart is the wrong starting point, what is the right one? The operating model. Specifically, a restructure should begin by answering a set of questions that most organisations never ask:
- How do decisions flow? Where are decisions made quickly and well? Where do they stall? Where are they made by default — by whoever happens to be available — rather than by design?
- Where does work queue? Where are the structural bottlenecks? Which teams or functions are capacity-constrained in ways that affect the entire organisation? What creates wait time?
- Where is accountability diffused? Which outcomes have no clear owner? Where do multiple teams share responsibility in ways that mean nobody is truly responsible?
- What governance structures are creating delay? Which review boards, approval processes, and sign-off requirements add value, and which exist because they have always existed? What would happen if they were removed?
- What metrics are driving the wrong behaviour? Are teams optimising for utilisation rather than throughput? For activity rather than outcomes? For local efficiency rather than system-wide flow?
A restructure that does not answer these questions is a personnel exercise, not an operating model reform. It will produce new org charts, new announcements, and new team names. It will not produce different outcomes. The structural constraints will remain, and the organisation will continue to perform exactly as its operating model dictates — regardless of what the org chart says.
The alternative: structural diagnosis before structural change
The discipline required is straightforward but rarely practised: diagnose the system before redesigning it. Before moving anyone, before announcing anything, before drawing a single new org chart — understand why the current structure is producing the outcomes it produces.
Map the constraints. Identify where work queues and why. Trace decision flows and find where they stall. Determine where accountability is unclear — not on the RACI chart, but in reality. Understand which governance structures create value by managing genuine risk, and which create delay by managing organisational anxiety.
Then design the operating model first. Define how decisions should flow. Clarify where accountability should sit. Determine which governance structures are necessary and which should be retired. Establish the metrics that will drive the right behaviour. Design the interfaces between teams — not just the teams themselves.
Let the org structure follow from the operating model, not the other way around. When the operating model is clear, the org structure often becomes obvious. The teams, the reporting lines, the leadership assignments — they fall out naturally from a well-designed model. When the operating model is unclear, any org structure will fail, because no arrangement of people can compensate for a system that does not work.
This approach takes longer. It requires more intellectual honesty. It surfaces uncomfortable truths about why the organisation performs the way it does — truths that are often more about leadership decisions and governance design than about the people on the ground. But it produces restructures that work. Once.
The bottom line
The most expensive restructure is the one that has to be done twice. And most organisations are on their second or third. Each iteration costs millions — in direct spend, in lost productivity during the transition, in the attrition of people who are tired of being reorganised without anything changing. Each iteration erodes trust in leadership's ability to solve the problem.
The problem was never the people. It was the model they were operating inside. Change the model, and the people will deliver. Change the org chart without changing the model, and twelve months from now, the same conversation will be happening in the same boardroom — with a new set of boxes on a new slide, and the same structural constraints producing the same disappointing outcomes.