Menu
Close
There is a moment in most transformation diagnostics that I have learned to distrust.
The room has found the problem. It sits in a particular team, or a particular tool, or a particular date that keeps slipping. Everyone can point at it. The relief in the room is real, and it is usually misplaced, because the thing everyone is pointing at is where the problem became visible, and that is almost never where it was made.
I spend a lot of my time telling clients to zoom out. Not as a posture, and not because distance is wise in some general way, but because friction has a habit of surfacing a long way from its source.
The team that misses its dates is rarely the team that created the conditions for missing them. The tool everyone wants to replace is rarely the reason the work is slow. By the time a problem is concrete enough to point at, it has usually travelled some distance from the decision that produced it, and the pointing finger lands on the symptom.
The real leverage in most situations lies in understanding the dynamics, not the detail.
Peter Senge gave this its clearest statement in The Fifth Discipline in 1990. His distinction is between detail complexity, which is many moving parts, and dynamic complexity, which is the situation where cause and effect are not close to each other in time or in space, and where the effects of an intervention are not obvious to the person making it.
His first law reads almost like a warning to consultants: today's problems come from yesterday's solutions. The trouble surfaces here, now, in this team. It was set in motion somewhere else, some time ago, by a choice that looked reasonable when it was made.
What follows from this is a way of reading an organisation in layers. There is the event, the thing that happened, the missed date. Underneath it there is a pattern, the same kind of thing happening repeatedly. Underneath that there is a structure, the set of policies and incentives and reporting lines that keep producing the pattern.
And underneath that there are the beliefs that hold the structure in place. The deeper you go, the harder it becomes to see the connection back to the daily event, which is precisely why most effort stops at the surface. The event is loud and the structure is quiet, so attention goes to the event.
Donella Meadows mapped where this attention is best spent. She ranked the places you can intervene in a system, from the weak to the strong, and put the numbers last. Budgets, headcount, targets, the parameters everyone reaches for first, sit at the bottom of her list.
Her teacher's observation has stayed with me: people are very good at finding the point of leverage in a system, and then pushing it in the wrong direction. The instinct to add a person, add a tool, adjust a target, is the instinct to push the weakest lever as hard as possible.
There is a parable that circulates in this corner of the field, about the Washington/Jefferson Monument that was eroding. The stone was being damaged by the chemicals used to clean it. The cleaning was needed because of birds. The birds came for the insects. The insects swarmed because of when the lights came on at dusk. The fix, in the story, was to change the lighting schedule.
The cause sat several steps away from the damage, owned by a different function than the one that first noticed the stone. The story turns out to be mostly invented, and I have come to like it more for that, because the tidiness of the chain is the seduction.
Real causes are messier than the parable, and the appetite for a clean single thread is itself one of the things to be careful of.
Add up enough local wins and you do not get a global one. Sometimes you get the opposite.
The version of this I see most often in technology work involves a control added in good faith. Delivery feels risky, so a review step is added before anything ships. A board now approves the changes. It’s something we stay mindful of when working on governance structures inside larger projects, like this one (reference case Salesforce transformation program). Thinking about extra measures is easy, but seeing how they potentially slow things down is not.
The intention is quality, and the result, reliably, is that delivery slows, work piles up behind the gate, changes get batched into larger and riskier releases to be worth the wait, and quality does not improve.
Importantly, this is not a hunch. The long-running research programme behind Accelerate, drawing on tens of thousands of responses across the industry, found that approval from an external body sat against every outcome that mattered. Slower lead times. Less frequent deployment. Slower recovery. And no improvement at all in the rate of failed changes. The finding the authors arrived at is worth stating plainly: an external approval body performs worse than having no such approval at all. The friction shows up in the delivery teams, who look slow. It was created by a governance choice made elsewhere, to satisfy a belief about how risk is controlled.
Senge has a name for the deeper pattern. Shifting the burden. A symptom appears, a quick remedy relieves it faster and more cheaply than the fundamental change would, the relief lowers the felt need to make the harder change, and a quiet side effect erodes the capacity to ever make it. The symptom clears, attention moves on, and the underlying condition grows in the space that the relief created.
The same shape appears in incentives. A measure is chosen to track something that matters, the measure becomes the target, and the moment it becomes the target it stops measuring the thing. Wells Fargo set its branches a goal of eight products per household and tied livelihoods to it. The number was met. It was met by opening millions of accounts that customers had not asked for, roughly 3.5 million by the bank's own later accounting. When it surfaced, the first response was to dismiss thousands of the people at the counter, which treated the visible symptom precisely, while the structure that produced their behaviour, the goal and the pressure flowing down to meet it, was the actual author of the outcome. Where the problem showed up and where it was made were separated by the entire height of the organisation.
Teams build systems that look like the way the teams talk to each other.
In 1968 Melvin Conway observed that organisations which design systems are constrained to produce designs that copy their own communication structures. The compression that travels around the industry is blunter. You ship your org chart. A company with separate departments for selling, teaching and supporting builds a product with separate sections for selling, teaching and supporting, organised around its internal divisions rather than around the person trying to use it. The friction looks like a poor experience. It was manufactured by the reporting lines.
This is why a reorganisation is never only an administrative act, though it is routinely treated as one. The way people are grouped is the first draft of what they will build, and if the architecture you want and the organisation you have disagree, the organisation wins. Moving the boxes around moves the communication paths, and the communication paths shape the work. A reorganisation that leaves the real dependencies untouched will relocate the friction rather than remove it, and six months later the same problem will surface wearing a different team's name.
The instinct this argues for is to treat structure as something you design on purpose toward the outcome you want, rather than something you inherit and work around. The deliberate version of the move is to decide what the system needs to look like first, and then to draw the team boundaries, and the budget boundaries, that will produce it. Budget lines belong in this picture as much as reporting lines. When two capabilities sit in separate funding cycles with separate incentives, the late integration between them looks operational, and it is structural.
The most expensive illustration I know is an aircraft. A commercial decision to avoid the cost and delay of pilot retraining travelled downward as a constraint, which pushed the engineers toward classifying a significant change as a minor one. The engineers who built the system that would later fail reported into their business unit rather than to the chief engineer accountable for signing it off, and a relocation of the head office years earlier had already widened the distance between the senior team and the people building the planes. The accountable engineer testified he was unaware of the detail that mattered. The friction was created in the structure and in the boardroom. It surfaced, catastrophically, in two crashes and the lives of 346 people. The distance between where a problem is made and where it appears can be very large.
A caution, because the argument is seductive in the same way the monument parable is. Not every problem is deep. Sometimes the slow team is slow for a reason that lives entirely inside the team, and the local fix is the right fix, applied fast. Some problems are genuinely isolated, and treating them as symptoms of something grand is its own kind of error, the one that never fixes anything because it is always looking past the thing in front of it.
There is also a serious position, held by careful people in the study of complex systems, that the idea of a single root cause is a comfort rather than a fact. What we name as the root is often just the point where we decided to stop looking. Failures in complicated socio-technical systems usually have several contributing conditions, each necessary and none sufficient on its own. I hold this alongside the argument rather than against it. The work is not to find the one true culprit. It is to climb from the event toward the structure that keeps producing it, and to intervene where the leverage actually sits, which is higher up and further back than the symptom suggests.
This is also where a strategy framework we use at Nymark earns its place (learn more about our Discipline: Strategy & Growth).
We structure these choices using Playing to Win, the cascade developed by Roger Martin and A.G. Lafley, and the two questions people treat as afterthoughts are the ones that matter here: what capabilities must be in place, and what management systems are required. Friction that presents as a capability gap (e.g. this team cannot ship fast enough) is often a defect in the management systems, the gate, the incentive, the funding line. The reason these defects persist is that the visible response, the new tool and the new target, operates on the parameters Meadows ranked lowest, while the leverage sits in the structure and the goals that nobody quite owns.
So when I ask a client to zoom out, the request is specific. Not where does it hurt, which the room can always answer, but where was this made, which it usually cannot, at least not yet. The distance between those two questions is most of the work, and something we aim to support through our ongoing strategic consulting.
