Part I The mistake we keep making
Most problems are already diagnosed
Most delivery problems have already been diagnosed. Usually more than once, by people who were not wrong.
If you lead delivery in an organisation of any size, you have probably sat through some version of this. Delivery is slow, or unpredictable, or both. Someone commissions a review. The review comes back and says the teams need clearer priorities, or better collaboration, or more ownership, or a tighter process. You act on it. You bring in the framework. You run the workshops. You restructure the squads. For a quarter, maybe two, something feels different. Then it settles back to exactly where it was.
This happens often enough that it deserves a real explanation, and the usual one is wrong. The usual explanation is that the change did not go deep enough, or that the people did not commit to it, or that the culture resisted. So the next intervention is larger and more insistent than the last. It also fails, and for the same reason the previous one did.
The reason is this. The diagnosis described a symptom, and the intervention treated it as the cause.
That sentence is the whole argument of this paper. Everything that follows is detail, evidence, and what to do about it.
I want to be careful about who this is aimed at. If your delivery problem really is a capability gap, or a genuinely toxic individual, or a market that moved underneath you, then this paper is not about your situation, and you should act on what you already know. This paper is about the more common and more frustrating case: the organisation that is full of capable, well intentioned people, that has done the sensible things, that has been advised more than once, and that still cannot make delivery hold. That organisation does not have a people problem. It has a structure problem wearing a people problem as a disguise. The disguise is the reason the sensible things did not work.
The level error
Delivery behaviour shows up at the team level. That is where you can see it. A team misses a date, ships the wrong thing, goes quiet about a problem until it is too large to hide, burns out, argues, waits. Because that is where the behaviour is visible, it is also where we instinctively look for the cause. The team missed the date, so the team has a planning problem. The team went quiet, so the team has a safety problem or a maturity problem.
Sometimes that is correct. More often it is a level error. The behaviour is at the team level and the cause is one or two levels above it, in how the organisation has arranged authority, priority, information and load. The team is not generating the behaviour. The team is the place where a structural condition becomes visible. It is the smoke, not the fire, and we keep sending the fire brigade to the smoke.
Consider a team that escalates almost every non routine decision and then waits. You can read that as passivity, and you can send the team on a course about decision making and ownership. Or you can ask a different question: what actually happens to this team when it decides something on its own. If the honest answer is that decisions made at team level are routinely overturned, second guessed, or quietly held against the team when they go wrong, then the team is not passive. It is behaving rationally inside a structure that has taught it that deciding is more dangerous than waiting. No amount of ownership training survives contact with that structure, because the training addresses the team and the cause sits in the authority design above the team.
The level error is seductive because it is almost always accompanied by a true observation. The team really did go quiet. The reports really were optimistic. The dates really did slip. None of that is imagined. The mistake is not in seeing the behaviour. The mistake is in assuming that the behaviour is its own cause. A thermometer reading of forty degrees is not lying. It is simply not the same thing as the broken cooling system that produced it.
I have watched this exact mistake repeat across very different organisations, in different industries, at very different levels of process maturity. The constant is not the sector and it is not the toolset. The constant is the level error, and the thing that makes it expensive is that every intervention built on top of it inherits the mistake and amplifies it.
Why the usual instruments cannot see it
The dominant way organisations try to understand themselves is the survey. Engagement surveys, pulse surveys, culture assessments, health indices. They are useful for what they are, and what they are is a measure of how people feel about their conditions. Are you satisfied. Do you feel safe. Do you feel the strategy is clear. Do you have what you need to do your job.
Feelings are real and they matter. But a feeling is a downstream signal. It tells you that something is wrong. It does not tell you what, and, crucially, it cannot distinguish between two situations that produce the same feeling for entirely different reasons.
Take a low score on a question about clarity of priorities. Two teams can answer that question identically. In the first team, leadership genuinely has not communicated the priorities, and the fix is communication. In the second team, leadership has communicated the priorities clearly and repeatedly, but the structural mechanism that is supposed to turn those priorities into what the team actually works on does not exist, so the stated priority and the real one drift apart again every single cycle. Both teams feel the same way. The survey records the same dissatisfaction in both. Yet the interventions required are not merely different, they are almost unrelated. The first team needs a message. The second needs a mechanism. Run the same playbook for both and you will fix one while quietly entrenching the other, and the entrenched one will come back next year wearing a slightly different complaint.
This is the structural limit of any instrument built on sentiment. It measures the temperature. It cannot tell you why the room is hot. And because the readout is emotional, it pulls leadership towards emotional and cultural responses, which is to say towards working on the people, when the cause is very often sitting in the architecture the people are operating inside. The instrument does not just miss the cause. It points you confidently in the wrong direction, because it hands you a list of feelings, and feelings invite reassurance, recognition, and culture work rather than structural redesign.
There is a second, quieter problem. People are increasingly tired of being asked how they feel, and they have learned which answers are safe to give and which are not. The more often you ask, the more the signal degrades, because the act of asking has itself become part of the system being measured. A team that has learned that candour brings scrutiny will not become candid on a form. None of this is a reason to stop caring how people feel. It is a reason to stop treating how they feel as a diagnosis. The feeling is the start of the investigation, not the end of it.
Sentiment tells you a problem exists. Structure tells you what to change. Only one of those is actionable.
Part II The six structural conditions
When I say a delivery problem is structural, I mean something precise, not a vague gesture at the system. I mean that the problem is produced by how a small number of specific conditions are configured, and that those conditions can be observed through behaviour rather than inferred from opinion.
There are six of them. Each one answers a single question about how the delivery system is built. Each has a recognisable signature when it is healthy, and a different, equally recognisable signature when it is failing. And each fails in a way that no other condition would explain. That is the entire point of separating them. If you can locate which condition is failing, you can stop guessing at the cause, and you can stop applying the one intervention you happen to be good at to every problem you meet.
A note before the six. None of these conditions is about how hard people work or how much they care. Every one of them is about how the work is arranged around the people. You can take a group of genuinely excellent people and place them inside a structure that guarantees poor delivery, and they will deliver poorly while remaining excellent. This is the single most important thing to hold onto while reading what follows. The conditions describe the building, not the tenants.
1. Decision Authority
Is authority held at the level where the relevant information lives?
This condition is about the design of decision rights, and one thing only: whether the people who hold the authority to decide are the same people who hold the information needed to decide well. It is not about how confident a team feels, and it is not about what gets prioritised. It is about where, structurally, a decision is allowed to be made.
When this is healthy, teams resolve the trade offs that belong to them without waiting, and escalation is reserved for decisions that genuinely need authority or information the team does not have. Leaders operate at the boundary of their mandate rather than inside the team. When a decision turns out to be wrong, it gets corrected at the level where it was made, which means the organisation learns at that level too.
When it is failing, teams wait for sign off on decisions that sit squarely inside their own remit. The same kinds of decision are escalated again and again, and nobody ever clarifies the boundary, so the escalation never stops. People who were nowhere near the work make the call on it, using less information than the team had. The cost compounds quietly. Every non routine situation becomes an escalation, escalation becomes the default, and the organisation begins to read the resulting passivity as a capability problem in the teams.
The misdiagnosis. Misplaced authority is almost always read as weak teams, low ownership, or a maturity gap. It is an authority problem wearing a capability costume. The standard response is to train the teams to be bolder and to take more ownership, which does nothing, because the structure still punishes boldness the moment it is exercised. Worse, it adds insult: the people behaving rationally inside a constraint are now told the problem is their attitude.
2. Priority Integrity
Do stated priorities actually govern what gets worked on when pressure rises?
This condition is about whether changes to what the organisation is committed to are explicit, carry a visible cost, and are actually enforced. It is not about who has the authority to set priorities, which is the previous condition. It is about whether the priority, once set, holds.
Healthy priority integrity has a simple tell: when something new is added mid cycle, something else visibly comes off, and the team can name what it was. The trade off is explicit, and someone with the authority to make it actually made it. Stakeholders who want to inject work understand that there is a cost and a process, and the cost is paid by the person asking, not silently absorbed by the team.
When this is failing, work is added without anything being removed. Every addition is framed as a one off exception, while exceptions arrive every single cycle. The backlog quietly swells beyond anything anyone actually decided to commit to. The planning ceremonies can look immaculate while the real priority is set informally, in corridors and in the last loud conversation before the deadline. The striking thing is that nobody made a single bad decision. There was simply no mechanism forcing the trade off into the open, so the cost of saying yes was never visible to the person saying it.
The misdiagnosis. Broken priority integrity is usually read as a planning problem, and the response is more planning. More ceremonies, more refined backlogs, more elaborate roadmaps. But the ceremony is not the missing piece. The enforced trade off is. You can plan beautifully every fortnight and still have no mechanism that makes adding work cost something, and if you do, the plan will diverge from reality by the second week, every time, and you will conclude that the team cannot plan.
3. Outcome Visibility
Can the organisation tell the difference between activity and value?
This condition is about whether the organisation can see the difference between doing things and changing things. Whether work is connected to the effect it was meant to produce, or whether shipping has quietly become the goal in itself.
Where outcome visibility is healthy, work is tied to the change it is meant to create, and done means something happened in the world, not merely that something left the building. Delivery reviews contain at least one measure of effect, not only measures of volume. Teams and the people they serve, asked separately what success looks like, give answers that broadly match.
Where it is failing, completion is defined as delivery for its own sake. Reviews are full of output measures and contain no measure of whether any of it mattered. Teams and stakeholders, asked separately, describe success in terms that do not meet. An organisation can be extremely busy and extremely efficient in this state, and that is exactly what makes it dangerous. The machine runs beautifully in a direction nobody checked. Nothing feels wrong day to day, because everything is moving.
The misdiagnosis. This one is usually read as a stakeholder or relationship problem. The stakeholders seem unhappy despite all the delivery, so someone concludes that the relationship needs managing, and invests in communication and expectation setting. But the stakeholders are not unhappy because of poor rapport. They are unhappy because a great deal was delivered and very little changed, and no amount of relationship management closes the gap between effort and effect. The failure stays hidden until someone senior finally asks the dangerous question out loud: what has all of this delivery actually produced.
4. Constraint Transparency
Are the real blockers visible to the people with the power to remove them?
This condition is about whether the genuine obstacles to delivery reach the people who can actually clear them, or whether they accumulate, unseen, at the level of the people who cannot.
When this works, a constraint that needs action above the team reaches someone who can act on it, with a named owner and a date, and teams can see that surfacing a problem leads to something happening. The act of raising a blocker is reliably followed by movement on the blocker. That reliability is the whole mechanism.
When it fails, constraints pile up at the team level and never reach resolution. There are two distinct ways this happens, and they look identical from a distance while requiring opposite responses. In the first, the pathway to surface a constraint was simply never built, so the constraint has nowhere to go. In the second, the pathway exists but the teams have learned not to use it, because past experience taught them that raising a problem brings scrutiny of the team rather than help with the problem. The first is an absence. The second is a scar. Treating a scar as an absence, by building a pathway that already exists, changes nothing, because the pathway was never the obstacle.
The misdiagnosis. Accumulated constraints get read as team passivity or a poor escalation culture, and the response is to ask teams to escalate more proactively, or to introduce a new tracking tool. If the real condition is the second kind, the learned silence, then asking people to escalate more is asking them to repeat an action that has previously cost them, and they will decline, quietly, and you will conclude they are disengaged. The organisation slowly loses the ability to see itself, and it mistakes its own blindness for calm.
5. Behavioural Consistency Under Pressure
Do the operating principles survive when the stakes rise?
This is the condition that separates structural health from aspiration, and it is the one most organisations never measure, because they measure themselves on a calm day. The real design of an operating model is only revealed under pressure. Anything you put in place during calm is only as real as its survival in the storm.
When this is healthy, the way decisions get made and the way problems get raised do not change when a deadline looms or a crisis hits. The delegated decision stays delegated. The collaborative process stays collaborative. Bad news still travels upward at the same speed. The operating model is stable because it is structurally supported, not merely intended.
When it fails, the operating model quietly reverts the moment pressure arrives. Delegated decisions snap back to the top. Collaborative calls become unilateral directives. Status reports drift optimistic as the pressure rises, precisely when accuracy matters most. Leadership answers bad news with more monitoring, which teaches everyone to bring less of it. There is a milder version, where this happens only occasionally and the system recovers, and there is a severe version, where the reverted model is the real one and the calm behaviour was the performance all along. The severe version is the dangerous one, because the organisation believes its good days are the truth and its bad days are the exception, when it is exactly the reverse.
The misdiagnosis. Reversion under pressure gets read as a process breakdown during a crisis, and the response is to add checklists and escalation protocols for next time. Those will be bypassed again at the next pressure event, because the reversion was never a process gap. It was the structure showing its true shape under load. A protocol designed in calm and abandoned in pressure is just another thing that collapses when it is needed.
6. Structural Load
Is the system asking more than any system could deliver well?
This condition is about whether the total demand placed on the delivery system is within the range any system could sustain. Not the volume of work alone, but the coordination and context switching overhead that the way the work is organised piles on top of the work itself.
Healthy load is not the absence of pressure. It is a sustainable ratio between doing the work and coordinating it, and a habit of weighing new demand against existing commitments before accepting it. When new demand arrives, it is evaluated, not simply absorbed.
Failing load looks like teams who are completely occupied and not remotely productive, because their capacity is being eaten by coordination, by context switching across too many parallel commitments, and by the upkeep of a prioritisation system that has stopped working. Quality starts to slip. And here is the cruel part, the feedback loop that makes this condition uniquely self sustaining: when quality drops, the instinctive organisational response is more oversight, more reporting, more coordination, which consumes the very capacity that was already short. The system becomes busier and slower at the same time, and every attempt to fix it makes it worse, because every fix is itself another draw on the missing capacity.
The misdiagnosis. Overload is read as a talent or capability gap, and the response is to hire. Adding people to an overloaded system adds coordination cost before it adds output, so it tightens the very spiral it was meant to relieve. This is the condition behind the phrase I hear most often from exhausted leaders: we have tried everything and nothing sticks. Of course nothing sticks. Every initiative is competing for capacity that is already spent. The only move that creates capacity is removing work. Everything else, including the well meant initiative to fix the overload, adds to the pile.
Part III Reading the gap
There is one more idea that does more diagnostic work than any single measurement, and it is almost embarrassingly simple. Ask leadership and teams the same question about the same structural condition, separately, and measure how far apart their answers are.
The gap is the finding. Not the average of the two answers. The distance between them.
When leadership describes teams as fully empowered and the teams describe waiting for approval as a normal part of their day, that distance is not noise to be averaged away. It is the single most important thing in the room. It tells you that the structure as designed and the structure as lived have come apart, and it tells you precisely where the seam is. The same logic applies to priorities, to the definition of success, and to which constraints leadership believes are being handled. In each case the disagreement between the two vantage points reveals more than either vantage point on its own ever could.
This matters for an uncomfortable reason that most diagnostic instruments are built to avoid. The people who commission a diagnostic are usually leadership, and leadership is describing the structure it intended to build. The teams are describing the structure they actually inhabit. These are not the same structure, and the difference between them is exactly the thing worth knowing. Most instruments collect only one of these views, or, worse, blend them into a single average that mathematically erases the gap that mattered most. A score of fifty can mean everyone agrees things are mediocre, or it can mean leadership thinks things are excellent while teams think things are broken. Those are completely different organisations, and the average hides which one you are looking at.
Measuring the distance deliberately is what turns a vague managerial unease, a sense that something is off between us and the teams, into a specific and locatable finding. It also does something useful in the room when the findings are delivered. A gap is harder to argue with than an opinion, because it is not one side telling the other side it is wrong. It is both sides, on the record, describing the same thing differently. That tends to move a conversation past defensiveness faster than any amount of advocacy, because the question stops being who is right and becomes why do we see this so differently, which is the question that actually leads somewhere.
A gap is not automatically a fault, and it should not be treated as one. Some difference between how leadership and teams see a structural condition is normal and even healthy, because the two genuinely sit at different distances from the work. The signal is not the existence of a gap but its size, and the conditions on which it appears. A small, expected difference on most things and a wide, surprising chasm on one specific condition is a far more useful finding than uniform mild disagreement everywhere. The chasm is pointing at something. The job is to follow where it points rather than to rush to close it.
Part IV Why identical symptoms need opposite cures
If you take only one practical idea from this paper, take this one. Two organisations can present with the same surface symptoms, score similarly on the obvious measures, and still require interventions that point in completely opposite directions. The symptom is shared. The structure underneath is not. This is precisely why generic best practice so often fails: it is matched to the symptom, and the symptom is the least informative thing in the room.
Over years of looking at delivery systems, the same structural configurations recur. Not infinitely many. A small, finite set of recognisable patterns, each one a particular combination of the six conditions failing together in a particular way. What makes a pattern worth naming is not the symptom it produces, which is usually mundane and shared with several other patterns, but two other things: the specific way it is almost always misdiagnosed, and the specific way the standard fix makes it worse. A pattern, properly understood, is a warning about which obvious response to avoid.
What follows is the catalogue of eight. For each, I have described how it forms, what it looks like from inside, why the instinctive fix backfires, and the direction the real fix has to take. I have deliberately not described how each one is detected, because the detection is the part that takes method and judgement, and because a list of triggers in the wrong hands produces exactly the false confidence this whole approach exists to prevent. The point here is recognition, not self diagnosis. If one of these reads like a description of your own organisation, that recognition is the useful part.
Captured Delivery
Teams appear to own their work, but every real decision, about what gets built, how conflicts get settled, and what counts as finished, is made above them. The signature is the gap from Part III: leadership sincerely describes the teams as empowered, while the teams experience constraint as their daily normal. It forms gradually, usually with good intentions, as each individual decision is pulled upward for a sensible reason until upward is simply where decisions live. This gets diagnosed as weak teams or low ownership, and the response is more process or more training, neither of which touches the cause. The real risk is dependency. The system only functions while a particular layer of leadership is present to make its decisions, and when that layer changes, retires, or is simply on holiday, nothing underneath it knows how to run. The direction of the fix is to move authority back to where the information sits, deliberately and visibly, and then to protect those decisions when they turn out imperfect, because the first reversed decision teaches everyone whether the change was real. This cannot be done with a workshop. Captured authority is held in place by ambiguity, and only explicit, jointly agreed boundaries remove it.
Efficient Misdirection
This is the pattern that hides inside good news. Delivery is functioning well by every internal measure. Commitments hold, work flows, the teams have real authority and use it. The problem is that the whole capable machine is pointed at the wrong outcome, because the connection between the work and the effect it is supposed to produce was never established at the level where the work is chosen. It gets misdiagnosed as a stakeholder or relationship problem, since the people downstream are oddly unsatisfied despite all the visible competence. So the organisation invests in managing the relationship and communicating better, while the actual gap, between effort and effect, goes on widening. The risk is that confidence keeps rising right up until the moment a senior stakeholder asks what all this excellent delivery has actually changed, and there is no good answer. The direction of the fix is not more delivery and not better rapport. It is to reconnect the work to the outcome at the point where work is selected, so that producing something and changing something stop being treated as the same event.
Invisible Constraint Accumulation
Constraints pile up faster than they are resolved. A pathway to raise them exists, on paper, but using it does not produce resolution, so items are logged, reviewed, carried from cycle to cycle, and never closed or consciously accepted. Teams quietly build workarounds, because a workaround produces less friction than another fruitless escalation, and leadership is then genuinely surprised by blockers the teams have been carrying for weeks, because by the time a constraint becomes visible upward it has already been routed around. The impediment list has become a holding space rather than a resolution mechanism. This gets read as team passivity or as a tooling problem, and a new tracking system gets introduced, which changes nothing, because the issue was never that constraints were untracked. The direction of the fix is to make resolution structural: every constraint that persists beyond a cycle and needs action above the team acquires explicit ownership and a real decision, resolve it or consciously accept it, with the absence of a decision made visible at the level that should have made it. Adding tools, or asking teams to surface more before the pathway has been shown to work, only deepens the problem.
Pressure Reversion
In normal conditions the modern operating model is real and works. This is not a facade. The failure is conditional, and it appears only when the stakes rise. Under pressure, the organisation reverts to the centralised, control oriented model it is still, underneath, designed for: leaders take direct control, collaborative decisions become directives, and people quietly adjust what they report upward to match the consequence environment rather than the actual state of the work, so status drifts optimistic until a problem can no longer be contained. When the pressure passes, the good model returns, and the reversion is filed as a one off. It gets misdiagnosed as a crisis process breakdown, and the response is more crisis protocols, which are themselves abandoned at the next pressure event, because the structure that rewards reversion has not changed. The direction of the fix is to design the high pressure moments deliberately, deciding in calm and in advance who holds which authority and how status is reported when the stakes rise, and then examining honestly after each pressure event whether that held. It is specifically not a psychological safety initiative, because the problem is structural, not interpersonal.
The Overload Spiral
Total demand structurally exceeds capacity, quality begins to slip, and the organisation responds to the slipping quality by adding oversight and coordination, which consumes still more of the capacity that was already gone. Load creates degradation, degradation triggers oversight, oversight adds load. The pattern is self reinforcing and almost never recognised for what it is, because the symptom, slow delivery, gets attributed to talent gaps or process failures or team performance, none of which is the cause. This is the one pattern where the standard response is not merely ineffective but is itself a larger dose of the disease.
The direction of the fix is the one that feels least like progress and is hardest to authorise: cap the work in progress well below where it sits now, and enforce the cap at the point where new work would enter, so that adding anything forces an explicit removal. The resistance this provokes is not a side effect. It is the point, because it forces the real priority decision the system has been avoiding. And when delivery quality drops, the first move has to become removing something from scope rather than adding control. Hiring into the overload before reducing it, or launching an improvement programme on top of it, simply tightens the spiral. Resolving this pattern is less a matter of cleverness than of nerve, because it asks a leader to remove committed work in the middle of a quality crisis, at the exact moment every instinct says to add control.
Structural Suppression
Teams have learned, through repeated experience, that raising a problem produces no resolution and sometimes produces a cost, so they stop raising problems. Silence becomes the rational choice, not the cowardly one. This is the most dangerous pattern in the catalogue and the most reliably misread, because from the outside it looks exactly like disengagement, low trust, or a culture deficit, and it tends to be present not only under pressure but as the everyday baseline. The instinct is to ask people to be more open, to run safety workshops and communication sessions and retrospectives. Doing that while the consequence of openness stays the same is worse than doing nothing, because you are now asking people to take a risk that the structure still punishes, and when they decline, you have confirmation, in your own mind, that the problem is their attitude. The direction of the fix is never to exhort transparency. It is to change, visibly and repeatedly, what happens when someone surfaces a problem, so that every problem raised above the team gets a real, owned response or a conscious decision to accept it, until the teams accumulate fresh evidence that contradicts the old lesson. The exhortation is free and changes nothing. The changed consequence is expensive and changes everything.
Decoupled Governance
Here the teams genuinely have autonomy, and they are working hard on real, committed work. The problem is that the strategy at the top and the work at the bottom no longer correspond. There is no working mechanism that translates strategic priority into what teams actually pick up, so two coherent pictures, leadership’s strategy and the teams’ workload, simply fail to meet. This is what separates it from captured delivery: there, authority is the issue; here, the teams are genuinely autonomous and the problem is directional. They are deciding freely, in a direction that was never connected to the strategy. It gets read as a strategy communication failure, and the response is more all hands meetings and more goal cascades, which treat an information deficit. But the teams are not under informed. The deficit is mechanical, not informational, and you cannot talk your way across a missing mechanism. The direction of the fix is to build the connection that was missing, so that any change to stated strategy is required to name the change it produces in actual team commitments, before that strategy change is considered finished. Deploying a goal setting framework as the first move treats the symptom and leaves the disconnection intact.
The Transformation Facade
The organisation has all the artefacts of change. New titles, a new delivery framework, the right vocabulary in every meeting. The structural pieces score reasonably because they genuinely exist; someone really did install them. The behaviours score badly because nothing about how people actually operate has changed underneath the relabelling, and, unlike pressure reversion, the old behaviour is the everyday baseline rather than a thing that appears only under stress. The old operating model is still running, now wearing new words. This gets diagnosed as incomplete adoption, and the response is more of the same programme, more training and more rollout, which only deepens the facade by stacking more vocabulary on top of unchanged behaviour. After enough cycles, leadership concludes that the whole approach simply does not work in this organisation, when the truth is that the approach was relabelled rather than installed. The direction of the fix is to find the few specific interactions where the gap between the stated model and the real behaviour is widest, usually formal reviews, post mortems, and the decisions made during delivery conflict, and to redesign those interactions so the intended behaviour becomes the path of least resistance, while quietly retiring the transformation machinery that is consuming energy and producing no behavioural change. Another workstream is the one thing guaranteed not to help.
There you have the eight. Notice how often two of them share a symptom and split on the cause. Captured delivery and decoupled governance both look like teams pulling in the wrong direction, but one is a captured authority problem and the other is a missing translation mechanism. The transformation facade and pressure reversion both look like a good model that is not holding, but one has never really been installed and the other works until it is tested. Invisible constraint accumulation and structural suppression both look like teams that have stopped raising problems, but one has a pathway that does not resolve and the other has a pathway that has been learned to be unsafe. In each pair, the symptom is nearly identical and the correct response is nearly opposite. The whole discipline is in telling them apart, because the structure is the only thing that tells you what to do, and, just as importantly, what to avoid.
Part V Two areas, one company
Illustrative composite. The example in this part is assembled from recurring structural patterns. It is not an account of a real client engagement.
Let me make all of this concrete with a single example. It is an illustrative composite, not an account of a real client engagement: it is assembled from structural patterns that recur across organisations, so the logic is easy to follow. I use it because it controls for almost everything people normally reach for to explain delivery failure.
Consider one organisation, several thousand people, and two delivery areas inside it. In this composite, both are examined with the same instrument, by the same person, within the same week. The same senior leaders sit above both. The same hiring standards filled both. The same company culture, the same values on the same wall, the same incentives, the same calendar. If delivery failure were a property of culture, or of talent, or of leadership philosophy, the two areas would look broadly alike. They did not. They looked like two different companies.
The first area, a customer facing group, was structurally healthy on all six conditions. Teams resolved the decisions that belonged to them. Priorities held when work was added. Reviews referenced outcomes, not just output. Constraints reached the people who could clear them. The operating model did not change shape under pressure. Load was within range. And, tellingly, leadership and teams described all of this in broadly the same terms; there was no meaningful gap between the structure as intended and the structure as lived. The only signal worth noting at all was a faint, low confidence hint that behaviour might shift somewhat under sustained pressure, not strong enough to act on. This was, in short, a well built delivery system, and the diagnosis said so plainly.
The second area, a product delivery group reporting into the same leadership, was a different world. Decision authority, priority integrity and constraint transparency were all in the failing range. Behavioural consistency and structural load were at the most severe level the instrument records. And the gap between leadership and teams was widest exactly where it did the most damage: leadership described the teams as having the authority they needed and the priorities as stable, while the teams described waiting for approval and absorbing constant mid cycle change as the ordinary texture of their week. The reading of behaviour under pressure was the most sobering part. The reverting, optimistic reporting, problem burying behaviour was not a stress response that appeared when things got hard. It was the everyday baseline. People had learned that surfacing a problem brought scrutiny rather than help, and had adjusted accordingly, all the time, not just under load.
Read structurally, this was not one problem but four, locked together and feeding one another. Authority had been captured above the level where the work was understood. Constraints were accumulating because surfacing them produced nothing. The system was carrying more than it could hold. And underneath all of it, people had learned that candour was unsafe, so the organisation had lost the ability to see itself. Each of these made the others harder to fix. The suppression hid the overload. The captured authority meant the teams could not relieve the load even where they could see how. The unresolved constraints fed the sense that raising things was pointless. It was a single reinforcing system, and no one piece of it could be lifted out and fixed on its own.
Here is the part that matters most for anyone tempted by the obvious move. The company had already reached its own diagnosis of the second area, and it was the usual one: a talent and morale problem. They were recruiting to fix the delivery, and running engagement initiatives to fix the mood. Both responses were rational given how the problem looked, and both were guaranteed to fail. Hiring into a structurally overloaded system adds coordination cost before it adds output, so it tightens the spiral. And morale work cannot move a structure that punishes candour; it asks people to feel better about a situation that is, from their point of view, accurately bad.
The order of repair could not start with the obvious moves either. You cannot open with asking the teams to speak up, because the structure has spent a long time teaching them not to, and the request, unbacked by any change in consequence, simply confirms that leadership does not understand the problem. You cannot open with hiring, for the reason just given. The only first moves that create any room are to take work off the list, which is the one thing that frees capacity, and to change, visibly and repeatedly, what actually happens when someone raises a problem. Only once load has eased and candour has stopped being punished does it become possible to move authority back to where the work is, and to rebuild the constraint pathway so that it resolves things rather than collecting them. Get that order wrong and each correct intervention fails in turn, teaching the organisation the false lesson that none of it works.
But return to the two areas side by side, because that is the whole point. Same company. Same leadership. Same talent pipeline. Same culture. Diagnosed in the same week. One area healthy, one in a four pattern compound failure. Whatever was wrong in the second area was not a property of the organisation, because the organisation was held constant and the outcomes still diverged completely. It was a property of how that one area was built. This is also why the instruments most companies would reach for would have missed it. An organisation wide engagement score would have averaged the two areas together and diluted the failing one against the healthy one into a forgettable middling number. A company wide culture programme would have spent most of its energy where it was not needed and almost none where it was. Structure is local. It is built area by area, it fails area by area, and it has to be diagnosed area by area. That is not a limitation of the approach. It is the reason it works.
Part VI Why the fix is structural, and why sequence matters
A consequence runs through everything in this paper, and the two areas just described put it beyond doubt. If the cause of a delivery problem is structural, then training, coaching, and workshops are almost never the primary fix. They act on the people. The cause is in the arrangement the people are working inside. This is not an argument against developing people, which is valuable on its own terms. It is an argument about target and about order.
The target has to be the mechanism that generates the behaviour, not the behaviour itself. When authority is misplaced, you change where the decision sits, not how confident the team feels about deciding. When trade offs are invisible, you build the mechanism that forces them into the open, not the enthusiasm to make them. When surfacing a problem carries a cost, you change the cost, demonstrably and repeatedly, before you ever ask anyone to be more open. If the intervention lands anywhere other than the generating mechanism, the behaviour returns the moment attention moves elsewhere, and it brings with it the most damaging conclusion an organisation can reach: we tried that, and it did not work. That conclusion is almost always false, and it is expensive precisely because it feels earned. The thing that did not work was the intervention aimed at the wrong level, not the possibility of change.
There is a quieter reason to be sparing with interventions, which is that an organisation under strain has very little spare capacity, and every intervention spends some of it. A long list of recommendations is not generous; it is a way of handing the prioritisation problem back to the person who commissioned the work, who is the least placed to solve it. It is more useful, and harder, to name the one or two structural changes that matter most and to say plainly what to do first.
Which brings up sequence, because structural changes cannot simply be stacked and started in parallel. Some of them have a strict order, where the second cannot succeed until the first has taken hold. The clearest example is the one from the worked area above. If teams have learned not to surface problems, then building a better pathway to surface them accomplishes nothing, because the new pathway sits unused, and you conclude, wrongly, that the pathway was the problem. You have to change the consequence of surfacing first, until teams have fresh evidence that raising a problem is safe, and only then is the improved pathway worth building, because only then will anyone walk down it. Reverse the order and you waste both interventions and learn the wrong lesson from the failure.
The same logic recurs across the patterns. Captured authority usually has to be released before teams can participate meaningfully in fixing anything else, because captured teams cannot engage with a problem they have no authority to act on. Overload usually has to be relieved before any other change can land, because exhausted teams have no capacity to absorb a change, however good it is. Sequence is not a refinement applied after the analysis. It is part of the finding. A correct diagnosis with the wrong order of operations still fails, just more expensively, because it spends scarce capacity proving that the right idea introduced at the wrong time does not work.
A list of ten things to fix is not a strategy. It is the prioritisation problem, handed back to the person least able to solve it.
Part VII How to tell whether your problem is structural
You do not need an instrument to begin. You need a few honest questions, asked separately to leadership and to the teams, and the discipline to compare the answers rather than reconcile them too quickly. The instinct, when two answers differ, is to decide which one is correct and move on. Resist it. The difference is the data.
What follows is a short self assessment, organised loosely by the six conditions. It will not give you a diagnosis, and it is not meant to, because the patterns overlap and the same answer can point at different causes depending on what surrounds it. But it will tell you, fairly reliably, whether the problem you are wrestling with lives in the structure or somewhere else. Read each question and answer it honestly about your own organisation, and pay attention to the ones that make you uncomfortable, because discomfort here is usually accuracy.
On authority
- When a team makes a decision inside its own remit and it turns out to be wrong, what actually happens to the team. If the honest answer involves a cost the team would rather avoid, you may be looking at an authority problem, not an ownership one.
- Think of the last three decisions a team escalated to you. How many genuinely required your authority or information, and how many could the team have made alone. If most could have been made alone, the boundary has never been set.
On priority
- When new work was added in the last cycle, can the team name what came off to make room for it. If it cannot, the priority mechanism is probably not real, however good the planning looks on paper.
- Ask a team its top three priorities, then ask its manager separately. If the lists do not match, the stated priority and the operating priority have already diverged.
On outcomes
- In your last few delivery reviews, was there a single measure of whether the work changed anything, or only measures of how much was produced. If only the latter, activity and value have likely come apart.
- If a stakeholder is unhappy despite strong delivery, ask whether the work actually moved the outcome it was meant to move, before you reach for relationship management.
On constraints
- When did a team last surface an uncomfortable problem early, and what happened next. If you struggle to recall an example, the silence may be learned rather than accidental.
- If you believe you have an open door and nobody brings you problems, consider seriously that the second explanation, learned silence, is more likely than the first, that everything is fine.
On pressure
- Think of the last real pressure event. Did decisions get made the same way they do in calm conditions, or did the operating model quietly change. The pressure version is the true one.
- As pressure rose, did the reports coming up the line get more accurate or more reassuring. If more reassuring, you are being managed, and the structure is teaching people to manage you.
On load
- When quality last dropped, did the response add oversight or remove work. If it added oversight, you may be feeding a spiral rather than breaking it.
- If your teams are fully occupied and still not delivering well, ask how much of their capacity goes to the actual work and how much to coordinating, reporting, and switching between commitments.
If several of these landed uncomfortably, your delivery problem is probably structural, and there is concrete good news buried in that conclusion. Structural conditions can be changed by specific, identifiable interventions, because they are arrangements, and arrangements can be rearranged. Sentiment cannot be changed directly at all; it moves only when the structure beneath it moves. So finding that your problem is structural is not the bad news it can feel like in the moment. It is very often the first piece of genuinely actionable information you have had, because for the first time the thing you need to change is a thing you can actually reach.
Part VIII What a structural diagnosis actually involves
It is reasonable, having read this far, to want to know what it looks like in practice to diagnose a delivery system structurally rather than read about it. I will describe the shape of it without the mechanics, because the shape is what tells you whether this is the right approach for your situation, and the mechanics are what take training and judgement to apply well.
A structural diagnosis is run on one defined area at a time, not on an entire organisation at once. An area is a coherent slice of delivery: a product group, a platform function, a delivery unit. The boundary matters, because structural conditions are properties of a system, and a system has edges. As the two areas in the previous part showed, diagnosing everything at once produces an average across several different structures and tells you about none of them. One area, properly diagnosed, is worth more than a whole organisation surveyed shallowly.
It is run by a single experienced person, not a large team and not a self serve platform you log into. This is deliberate. The instrument produces signals; it does not produce conclusions. Turning a signal into a finding requires someone who can sit in a room, test a hypothesis against what people actually say, and recognise when the data and the reality have come apart. A platform cannot do that, and a large team mostly adds coordination cost to something that needs a single coherent point of view. The economics of this are unusual in a good way: one skilled person can produce a defensible structural finding for a single area in weeks, not the quarters a large transformation programme consumes before it has said anything at all.
A mixed group of people from the area answer a structured set of questions about observable behaviour, not about how they feel. Crucially, people at team level and people at management level answer in a way that lets the two vantage points be compared rather than blended, because, as Part III argued, the gap between those vantage points is frequently the most diagnostic thing available. The questions are about what happens, not about what people think of what happens, because what happens is observable and what people think of it is sentiment, and we have already established what sentiment can and cannot tell you.
What comes out is not a score to frame on a wall and not a dashboard to monitor. It is a finding: a clear statement of which structural condition or conditions are generating the symptoms the organisation came in worried about, expressed as a hypothesis that has been tested rather than as a verdict handed down. Alongside the finding comes a direction: the specific structural change that would address the cause, and, where order matters, what has to happen first. The aim is one defensible finding and a clear first move, not a comprehensive list that returns the prioritisation problem to you.
It is worth being equally clear about what this is not, because the boundaries are part of the value. It is not a maturity model, and it does not place you on a level or a journey. It is not an engagement or culture survey, and it does not measure morale. It is not a framework installation check, and it is genuinely indifferent to whether you run one delivery framework, several, or none, because the conditions it examines sit underneath any framework. It is not a performance evaluation of teams or individuals, and it is built specifically so that its findings point at the architecture rather than at the people inside it. And it is not a benchmark that ranks you against other organisations, because the question it answers is not how you compare but what, specifically, is generating your problem.
Findings of this kind are, by their nature, confidential and often uncomfortable, because a structural finding frequently implicates the people who commissioned it, not as a matter of blame but as a matter of where authority and design actually sit. That is handled with care and in private, and it is one more reason the work is done by a person rather than a platform. A dashboard cannot tell a leadership team, with the necessary tact and the necessary firmness, that the structure they built is the thing generating the behaviour they find frustrating. A person can, and that conversation, more than any document, is where the change actually begins.
Part IX What this is, and what it is not
Everything in this paper comes out of a diagnostic method I have spent a long time building and refining, called S.A.I.D., which stands for Structural Analysis and Intervention Direction. I have deliberately not set out its mechanics here, for two reasons. The mechanics are not the point of the paper; the way of seeing is, and the way of seeing is what most diagnoses are missing. And a method is only ever as good as the judgement applied to it, so a description of the machinery without the judgement would be worse than useless, because it would invite exactly the false confidence this whole approach exists to prevent.
What I wanted to put on the record is the argument. That delivery failure in capable organisations is usually structural, not personal. That the behaviour we see at the team level is most often the visible edge of a condition configured one or two levels above it. That instruments built on sentiment can register the problem but cannot locate it, and tend to point confidently in the wrong direction. That six conditions, observed through behaviour, account for most of what goes wrong, and that the gap between how leadership and teams describe those conditions is the most useful signal of all. That a small set of recurring patterns explains how those conditions fail together, and that two organisations with identical symptoms can require opposite cures. And that the fix, when it comes, has to land on the structural mechanism and arrive in the right order, or it joins the long list of things that were tried and concluded not to work.
If any of the patterns in this paper felt like a description of your own organisation, that recognition is the genuinely useful part, and it is yours to keep, with me or without me. You can take the six questions in Part VII into your next leadership conversation and learn something real before you speak to anyone. And if, having done that, you want to know precisely which structural condition is generating the symptoms you keep treating, and what to change first, that is a conversation worth having, and it is the one I exist to have.