A map for stuck organisations, mostly
Organisations, equal times making it possible to just build cool shit with cool people, and at the same time they can make it damn near impossible. Supposedly there's an art to developing them, but no amount of post-its can paper over the blank stares left after scheduling yet another alignment meeting.
However, due to a somewhat semi-succesfull history of not completely messing everything up, with reservations, I'm finding myself in roles where it falls on me to actually fix those things. I also believe that taking the right questions so seriously it feels silly is one way to start bringing a fuzzy solution into view, so I set out to collect some of those right questions into a reference document for myself.
But a note and a disclaimer: This reference below was written in several long conversations with Claude. I supplied the three broad categories while trying to suss out the ways in which the tools where rhyming with each other, but cross-cutting concerns are easy to find so view them more as lenses rather than truth. The tools themselves are a result of many years of hard thinking by their authors and the summaries carry crude approximations of that thinking.
At this point, while the AI voice is as telling and jarring and still as verbose as ever (though a revision through Claude Fable managed to tighten things up surprisingly, many things still need tightening), I've referenced and read through the whole thing several times, and I have enough of the books mentioned at home to be fairly confident in those sections. That would mainly be SPC, Rumelt, Team Topologies, Maister times two, the coaching section. The parts that were more unfamiliar to me was Immunity to Change, Polarity Management, and Schein (which I came to via exploring if Stan Slap's Under The Hood had enough depth for an inclusion), so take those with a greater grain of salt. Or perhaps I'm more willing to gloss over errors in the parts I know better too, so take it all with the salt ya' know.
I've been revising paragraphs in order of being particularly egregious. The overall flow reads fine (to me) now, but I'd like to go over the closing sections a bit more. Don't be surprised if the page changes, especially as I get more and more annoyed with the sloppy text, and unless I feel the need to share another reference, I don't imagine I'll post more non-PV words on the site overall. It has however become useful enough that I've wanted to share parts with other people, and sending a link is easier than a full clipboard.
If you're curious on how I've actually used it, beyond acting as a manual reference for my brain, I found it useful to get over something like an "empty page" effect when it came to start drafting diagnosis. I have daily notes with my own meeting notes, observations, and notes on workshop outcomes and the like that can act as raw material. Combining that context with the below as a somewhat extreme prompt to find different ways of looking at the challenges was quite helpful, and helped me towards sharpening the questions I was asking. Pretty sure there's better ways of doing it, and the richness of what comes out still depends (a lot) on what you're able to put in yourself.
Now, to get back from doing the meta-work and actually start doing the work...
Introduction
This is a reference collection of toolkits for organisational problems.
You can read the chapters in any order, land in whichever one fits the problem in front of you, and ignore the rest. The chapters share a structure so that they are browsable: each tool gets the same treatment, in the same order, every time.
The core argument
A "people problem" in an organisation can be three different things, and each calls for a different mode of work.
First, it can be a system problem in person costume. The product manager who will not commit to dates is often responding to a system that punishes wrong dates more than late ones. Fix the system and the behaviour changes. This is work for the diagnostic mode: figuring out what is actually true before acting.
Second, it can be a relational, developmental, or emotional problem. Two engineers who have burned trust with each other. A new tech lead who has not learned to delegate. A team carrying unprocessed strain from a layoff. The system is fine, or fine enough, and the work is with humans as humans. This is the developmental mode: repairing and growing the people, not the structure.
Third, it can be a problem of running the organisation while it changes. The true answer and the achievable answer diverge. The team has to ship next week regardless of what the diagnosis says. The job is to integrate diagnosis and repair under time pressure without stopping the line. This is the operating mode.
Most stuck situations contain all three at once. The skill is identifying which mode the current blocker calls for. A perfect Current Reality Tree will not repair broken trust. A well-run difficult conversation will not fix a broken incentive. And both fail without the operating judgement about when to do which, with what energy, and at what cost to the organisation's ability to keep functioning.
The diagnostic mode is defined by a stance: make implicit reasoning explicit so it can be examined. The developmental mode is defined by its subject: humans as humans, whether the unit is a single person, a pair, or the culture of a whole group, and it draws on a contested lineage in psychology, therapy, adult development, and organisational culture that the other two lack. The operating mode is defined by its context of use: you cannot stop, so you integrate under constraint. This is why the same idea can show up in more than one mode, a constraint analysed being diagnostic work and the same constraint managed while shipping being operating work. The modes are things you do, not boxes the tools live in, and a tool can be picked up in more than one of them.
The shared spine
Before the differences, it is worth noticing what a number of these tools have underneath them. Strip the notation away and several reduce to a single loop: decide what you want, choose a method, act, and then check what actually happened against what you predicted.
The clearest instances are the genuine improvement loops. Deming's PDSA is plan-with-a-prediction, do, study the gap, act on what you learned. The Improvement Kata sets a target condition, runs an experiment with a prediction, and goes to see the result. The Theory of Constraints Transition Tree names a current state, an action, and an expected new state. These are the same loop in different notation, and the load-bearing element in all of them is the same: the prediction, and the disciplined comparison of prediction to result.
A looser family of tools is merely three-part without closing the loop. Rumelt's kernel is diagnosis, guiding policy, and coherent action, a decision structure with no feedback term. David Maister's quick-strategy table is what you want more of, what you want less of, and what you will do differently, then a date to check whether the proportions moved. These rhyme with the improvement loop and borrow some of its discipline, but they are not the same object: the first two are about learning by experiment, the latter about committing and revisiting. Keep the distinction in view, because the thing that makes PDSA powerful, the written prediction you can be wrong about, is exactly the thing the decision-shaped tools do not supply on their own.
This matters for two reasons. First, it is a fast sanity check on any plan. Can you say what you want, how you will get there, and how you would know whether it worked? Teams routinely answer the first two and never the third, which is where most of the value hides. Second, it tells you when you do not need a heavy tool at all. If three questions on a whiteboard would do, three questions on a whiteboard are the right tool, and reaching for a Current Reality Tree is ceremony. The elaborate tools earn their weight only when the questions are genuinely hard, when causation is tangled, the goal is contested, or the path is unclear.
Choosing a mode
A rough decision procedure when you are staring at a stuck situation.
The principle under the procedure is a split between analysis and action. Because the modes are sorted on different axes, a problem is never in one of them; as the core argument said, most stuck situations contain all three at once. The analysis therefore decomposes into all three. The action does not: you work on whichever mode holds the binding constraint right now and let the other two wait their turn. That is the move the steps below are really making.
Sort the problem before picking the tool. Cynefin, covered in the diagnostic chapter, is the explicit version of this, but even a rough mental sort helps. Is this Complicated and analysable, Complex and requiring you to probe, or Clear and just needing the obvious thing done. Most stuck situations in mid-sized engineering organisations are Complicated with Complex elements, and the trap is treating them as purely one or the other.
Then ask what is actually blocking you right now. "I do not understand why this keeps happening" is diagnostic work. "I understand it and we still cannot move" is developmental if the blocker sits between specific people, operating if it is about the organisation's ability to focus. "The team is exhausted or scared or grieving" is developmental and operating, and a Current Reality Tree there will feel violent. "The decision has to happen by Friday" is operating: a premortem, then the call. The closing chapter compresses this routing into a reference table, symptom by symptom, with the specific tool to reach for first.
The verbs are convenient but they do not imply an order. It is natural to read "diagnose, develop, operate" as a sequence, and sometimes it is one, but just as often operating comes first. A bleeding team gets stabilised before anyone analyses why it is bleeding. The mode you start in is set by the blocker in front of you, not by the order of the words.
Watch for the failure modes of your own preferred mode. Diagnostic-default people, often ICs and consultants, reach for diagrams when the actual blocker is trust or fear. The diagram looks rigorous, the room goes quiet, and nothing moves. Developmental-default people, often coaches and HR-adjacent practitioners, reach for difficult conversations when the actual blocker is a broken incentive. People talk earnestly and the system keeps producing the same behaviour. Operating-default people, often managers, reach for rhythm and structure when the actual blocker is that the strategy is wrong. The organisation executes crisply on the wrong thing.
Move between modes rather than competing them. Sort the problem, use a Cloud to surface the conflict and find an injection, discover the conflict is really about identity or trust and switch to developmental work for that piece, return to diagnostic work for the structural follow-through, then operate the change while the organisation keeps shipping. The modes are not competing answers to the same question. They are different things to do, and a mature practitioner moves between them deliberately rather than defaulting to one.
A note on evidence across the three modes
It is tempting to read the modes as a quality ranking: diagnostic tools rigorous, developmental tools soft, operating tools somewhere between. That reading is wrong, and it quietly distorts how much weight you put on each tool.
The truth is that evidentiary status varies within every mode at least as much as it varies between them. Deming's statistical core is about as well-established as anything in this collection; the management philosophy built on top of it is a reasoned position, not a proven one. Wardley Mapping rests on practitioner face-validity and a community of practice, genuinely useful, but no better tested than the adult-development theory behind Immunity to Change, which sits in the contested developmental mode. The Theory of Constraints has a solid operations core and a general method that works in skilled hands but has a thin formal evidence base. Coaching, often treated as the softest thing here, actually has meta-analytic support showing it improves goal attainment, with the twist that the effect comes from the quality of the relationship and the questions rather than from any particular framework.
So each tool carries its own epistemic-status note, and you should read those notes rather than the mode label to decide how much to trust a tool. The developmental chapter is the most openly contested, but openly contested is not the same as least grounded.
Diagnostic Tools
These make implicit reasoning explicit so it can be examined, contested, and corrected. They share a stance, that careful structured thinking surfaces what intuition misses, but not a method or a lineage. The chapter covers six at depth: Cynefin, Goldratt's Theory of Constraints, Deming and Statistical Process Control, Systems Dynamics and its archetypes, Rumelt's strategy kernel, and Wardley Mapping, plus a section on lightweight structuring tools. These are lenses on the same situation rather than a sequence. The skill is knowing which one fits the question.
The shape of question they answer: what is actually going on here, where is the leverage, what assumption is keeping us stuck, what kind of problem is this.
The shape of problem they are ill-suited to: anything where the blocker is emotional, relational, developmental, or political. Anything where causation is not stable enough to analyse. Anything where you have to act before you can analyse.
Cynefin
Dave Snowden's framework※, developed at IBM in the late 1990s and refined since, is the diagnostic mode's sorting tool. It tells you what kind of problem you have, which determines what kind of approach fits. The point most people miss is that the dangerous state is not any of the named domains but the unnamed one, not knowing which domain you are in, which Cynefin calls Confused and which is where almost everyone starts. The cost is specific: each domain's wrong tools produce confident, well-executed, harmful action, analysis run on a problem that adapts under the analysis, or a runbook ceremony wrapped around something obvious. The single robust distinction worth keeping, between Complicated problems that yield to expertise and Complex ones that do not, matters precisely because acting as though a Complex problem were merely Complicated is the most expensive ordinary mistake in this collection.
Epistemic status. Cynefin is a conceptual framework rather than an empirical theory, and Snowden revises it regularly※, so it is best treated as a useful sense-making lens rather than a validated model. The headline distinction between Complicated, where analysis works, and Complex, where you must probe, is widely found useful and is the part worth keeping. The finer-grained claims and the more elaborate versions are more contested, and the framework is frequently misused as a tidy two-by-two, which Snowden himself rejects.
The core ideas
Cynefin sorts situations into five domains, each with a different approach.
Clear, where cause and effect are obvious to everyone, calls for sense, categorise, respond, applying best practice. A known incident type with a runbook.
Complicated, where cause and effect exist but require expertise to discern, calls for sense, analyse, respond, applying good practice. Most diagnostic tools live here, since they assume the problem is Complicated.
Complex, where cause and effect can only be seen in retrospect because the system adapts to your interventions, calls for probe, sense, respond, running small safe-to-fail experiments and amplifying what works. Culture change and novel product development sit here.
Chaotic, where there is no discernible cause and effect and the situation is unstable, calls for act, sense, respond, stabilising first and analysing later. A major outage in progress.
Confused is not knowing which domain you are in, the default and most dangerous state, because each domain's wrong tools produce confident but harmful action.
The most important boundary is between Complicated and Complex. A Complicated problem yields to expert analysis. A Complex one does not, because the system adapts to your analysis and the causal structure shifts. Treating Complex as Complicated produces confidently designed interventions that fail in ways the analysis did not predict.
In the Complex domain the right move is probes rather than pilots. A pilot assumes you know the right intervention and are testing scale. A probe assumes you do not yet know, so you run several small ones at once and amplify what produces good signals.
How to use it
Sort the problem before reaching for tools. The first move on any non-trivial situation is asking which domain it lives in.
For Clear situations, just apply best practice without over-thinking it. For Complicated situations, bring in the diagnostic tools. For Complex situations, design multiple small safe-to-fail probes and accept that what works may be partly opaque. For Chaotic situations, stabilise first, then move toward Complex or Complicated once the crisis passes.
Watch for category errors, since the most expensive failures come from them. Analysing while the building burns. Designing a solution to organisational culture. Over-thinking what should be a runbook.
What well-applied Cynefin looks like
A situation got re-sorted mid-flight and the approach changed with it: something being analysed as Complicated was handled as Complex once the system shifted under it, with safe-to-fail probes replacing the search for the one right answer.
The response visibly matched the domain rather than defaulting to one move: a checklist where it was Clear, probes where it was Complex, stabilise-first where it was Chaotic, instead of the same approach applied to all of them.
Anti-patterns
Drawing Cynefin as a two-by-two with axes of knowable and ordered. The domains have qualitatively different epistemic structures, not positions on a continuum, and this remains the most common misuse.
Sorting without acting, identifying the domain and then doing the same thing regardless.
Permanent domain assignment, treating a situation as forever Complicated or Complex when domains shift.
Complexity-claiming to avoid hard analysis, or its opposite, grinding through analysis on a problem whose adaptive nature makes it pointless.
Remaining in Confused, treating indecision as a stable state rather than working to sort.
When Cynefin is the wrong tool
When the situation is genuinely simple and obvious, where the framework's cost is not worth paying.
When introducing the vocabulary on a high-stakes problem to an audience that does not know it adds learning overhead to an already-hard situation. Use the underlying Complicated-versus-Complex distinction in plain language instead.
When the question is strategic rather than diagnostic, since Cynefin tells you what kind of problem you have but not what to do strategically. Rumelt or Wardley fit better there.
Theory of Constraints
Eli Goldratt developed the Theory of Constraints in manufacturing in the 1980s※, then generalised its reasoning into a set of logic tools, the Thinking Processes※, for problems beyond the factory floor. The tools answer three questions: what to change, what to change to, and how to cause the change.
Epistemic status. The underlying logic, that systems are limited by a small number of constraints and that surfacing hidden assumptions dissolves apparent conflicts, is sound and widely validated in operations contexts. The manufacturing results are real and replicated. The generalisation to organisational and strategic problems is more practitioner craft than established finding: it works well in skilled hands but has a thin formal evidence base outside operations, and the diagrams can manufacture false confidence when the underlying causation is not as stable as the notation implies. Treat the operational core as well-grounded and the general Thinking Processes as a strong but craft-dependent method.
The core ideas
The Thinking Processes are causal diagrams with strict semantics. Six of them work together.
The Current Reality Tree is a bottom-up causal diagram. You start by listing the Undesirable Effects you observe, which are symptoms rather than causes, things like releases slipping or incidents recurring or engineers avoiding review. You connect them with if-then arrows, asking why each exists, and where two causes are jointly required you bind them with an ellipse marking an AND relationship. You push downward until the arrows converge on one or two root causes, usually a policy, a measurement, or an assumption rather than a person. The payoff is that fixing eight symptoms often means fixing one root cause.
The Evaporating Cloud is for conflict, two options that seem mutually exclusive. It has five boxes: a shared Objective, two Requirements both needed for the objective, and two Prerequisites, one per requirement, that conflict with each other. The move is to write the assumptions on every arrow, especially the conflict edge between the prerequisites. Once you find an assumption that is false or context-dependent, you have an injection that dissolves the conflict rather than forcing a compromise.
The Future Reality Tree is the mirror of the Current Reality Tree, built top-down from a proposed injection. You trace its effects forward, checking that your Undesirable Effects are replaced by Desirable Effects, and you watch for two things: missing entities, where the injection alone does not produce the effect, and Negative Branches, where the injection produces a new problem.
The Negative Branch Reservation is a small Future Reality Tree focused on one worry of the form "if we do X, then Y will happen." You draw the chain from X to Y fully, then look for an assumption to break or an injection to add that severs it. It is the formal version of "yes, but," and it makes objections constructive rather than veto-shaped.
The Prerequisite Tree lists every obstacle between you and a chosen change, defines an Intermediate Objective that overcomes each, and sequences those objectives by dependency. The result is a directed graph of milestones rather than a Gantt chart.
The Transition Tree is the most tactical. For each Intermediate Objective it specifies current state, action, expected new state, and rationale. You usually build it only for the next objective or two, since building them all is over-planning. It is also one of the clearest instances of the shared spine from the introduction (current state, action, expected new state is the same loop as PDSA and the Improvement Kata), and it pairs directly with the Kata when you want experimental discipline for walking the sequence.
The distinctive stance underneath all six: most people problems are system problems wearing a person costume, underneath every persistent conflict is an assumption that dissolves it once named, and root causes are usually structural rather than individual.
How to use it
Run the Current Reality Tree as a workshop with sticky notes, Undesirable Effects at the top, working downward. The discipline is resisting the urge to jump to solutions before the tree is built.
Use the Cloud whenever a conflict recurs. It is cheap, so build it even when you think you already know the conflict. The value is in writing down the assumptions you did not know you were making.
When you have an injection, test it forward with a Future Reality Tree, and draw the Negative Branches explicitly rather than waving them away.
Sequence the rollout with a Prerequisite Tree, and detail only the next step or two with a Transition Tree.
Keep Undesirable Effects as observable present-tense symptoms rather than causes in disguise, bind jointly-required causes with an AND since the missing AND is the usual structural error, and validate a finished tree by reading it aloud from a root cause upward, because logic that sounds forced is wrong.
The tools chain in practice: the Current Reality Tree finds the core problem, the Cloud surfaces the conflict that keeps it in place, the injection seeds the Future Reality Tree, Negative Branch Reservations stress-test it, and the Prerequisite and Transition Trees plan the rollout. You rarely need all six. A stuck retro often needs only a Cloud. A strategic shift typically wants the Current Reality Tree, the Cloud, and the Future Reality Tree.
What well-applied TOC looks like
The tree ended in a decision or an injection that changed something, rather than a finished diagram presented and filed.
A Cloud surfaced an assumption no one had written down, and attacking it dissolved a conflict that had kept recurring.
A single change at a root cause improved several of the top-level symptoms at once, which is the convergence proving real rather than asserted.
Anti-patterns
Treating the diagram as the deliverable. The tree is a thinking aid. Teams sometimes spend three days perfecting one, present it, and change nothing. The output should be a decision or an injection.
Skipping the Cloud and jumping to a solution because you think you already know the conflict. You almost always miss the real assumption that way.
Undesirable Effects that are already causes. "We do not have enough staffing" is a hypothesised cause, not a symptom. If your symptoms already encode a theory, the tree just confirms what you walked in believing.
Person-shaped root causes. If the tree bottoms out at "the PM does not communicate well," you stopped too early. There is almost always a policy or incentive underneath.
Dismissing Negative Branches as objections. The correct response to a raised branch is to draw it fully, then either sever it with an injection or accept it as a real cost.
Using the tools to win arguments. The notation looks rigorous, so it is tempting to build a tree that proves your preferred answer. People can sense this, and it makes the tools feel like manipulation.
Methodology over toolkit. Insisting on the full sequence and full notation every time. For most problems a quick Cloud on a whiteboard with three assumptions listed is enough, and ceremony kills adoption.
When TOC is the wrong tool
When causation is not stable. The tools assume the causal arrows hold over the time horizon of analysis. In complex situations where the system adapts to your interventions, the tree you built last month is fiction now.
When feedback loops dominate. The notation is fundamentally a directed acyclic graph. The moment a meaningful loop appears, such as burnout reducing output which increases pressure which increases burnout, you are contorting the diagram. Systems dynamics handles this natively.
When the goal is contested. The Cloud requires a shared Objective. If half the room wants growth and half wants sustainability and that is the actual disagreement, the Cloud will paper over it with a fake objective nobody shares.
When the situation is political rather than analytical. The tools assume good-faith truth-seeking. Where the real constraint is that some truth is unsafe to say, the analytical surface looks rigorous while the substance is constrained.
The boundary worth flagging as genuinely unclear: the line between "complicated, so analyse" and "complex, so probe." Skilled practitioners disagree about where specific organisational problems fall, and the honest answer is that you often cannot tell in advance. When in doubt, treat a Cloud as a hypothesis to test rather than a diagnosis to act on.
Deming and Statistical Process Control
W. Edwards Deming's work, spanning the 1940s through the 1990s, is the foundational tradition for understanding variation in systems. Most people meet it through Out of the Crisis※ or the 14 Points, but the deeper contribution is the statistical understanding of variation that underlies the Toyota Production System, Six Sigma, and modern Site Reliability Engineering. Distinguishing signal from noise is the one move the Theory of Constraints cannot make, and it is where most "we have a problem" conversations should actually start.
Epistemic status. The statistical core, common cause versus special cause variation and the control chart, is mathematically rigorous and about as well-established as anything in this collection. The management philosophy built on top of it, the 14 Points and the System of Profound Knowledge※, is a reasoned position rather than a proven one, though it has held up well in practice and is broadly consistent with later evidence on motivation and systems. The often-quoted claim that the great majority of problems are systemic rather than individual is well-supported in direction, but the famous proportions (94/6 or 85/15; Deming gave different figures at different times, with no published derivation) are rhetorical estimates, not measured constants. Lean on the direction of the claim, not the decimal.
The core ideas
Common cause variation is the normal expected noise in a stable system. Special cause variation is the result of an identifiable exceptional event. They demand opposite responses. Treating common cause as special cause, by reacting to every blip, makes the system worse. Treating special cause as common cause, by ignoring real signals, misses actionable information. Most operational dysfunction comes from confusing the two.
The control chart operationalises the distinction. You plot measurements over time with statistically derived upper and lower limits, typically three standard deviations from the mean. Points inside the limits are common cause. Points outside, or runs that show clear trends, are special cause and warrant investigation. The chart is a decision tool: it tells you when to react and when not to.
The System of Profound Knowledge is Deming's later synthesis of four lenses applied together: appreciation for a system, knowledge of variation, theory of knowledge (we operate on hypotheses that need testing), and psychology (people are not interchangeable parts and motivation is mostly intrinsic).
PDSA, Plan-Do-Study-Act, is the improvement loop, and the canonical instance of the shared spine. Plan an experiment with a prediction, do it, study the gap between prediction and result, act on what you learned. The study step is where most teams fail, because they do and then move on without examining the result against the prediction.
Deming's repeated claim that the great majority of problems are systemic rather than individual is the same stance the Theory of Constraints takes, reached through statistics rather than causal logic.
How to use it
Before treating something as a problem, ask whether it is actually a signal. Three slow deploys this week, is that special cause or common cause? Without a baseline you do not know, so the first move is establishing what normal variation looks like. Many "we have a problem" conversations should start here and end here, once it turns out the variation is just the system being itself.
Build a control chart for your most important leading indicators, with a mean line and control limits, not just a dashboard with targets. SRE practice has internalised some of this through error budgets, which are control charts in different clothing.
When something exceeds the limits, investigate the special cause. That is where the real work is.
Run improvement as PDSA cycles with explicit predictions. The prediction is the learning mechanism. Without it you produce outcomes you then rationalise.
Distinguish system improvement from individual coaching. When metrics are bad, ask first whether the system is producing the result, which Deming argues is usually the case, before asking who is responsible.
What well-applied Deming looks like
The team makes fewer reactive changes than it used to, and can point to a recent case where the chart led it to leave something alone rather than intervene. People can say "that is just noise" or "that looks like a signal" and mean something specific.
A real signal crossed a limit and got investigated within the week, instead of surfacing later in a retro as something everyone had half-noticed.
A bad metric produced a documented change to the process and a named system cause, with no one's name attached to the number.
Anti-patterns
Reacting to common cause, which produces management whiplash and demoralised teams. The control chart exists to prevent exactly this.
Ignoring special cause, dismissing real signals as noise because they are uncomfortable.
Targets as control limits, setting arbitrary round-number goals disconnected from what the system can actually deliver, then reacting to anything below them.
PDSA without prediction, running the loop as ritual so it produces no learning.
Statistical thinking applied to individuals. Deming was clear that statistical methods work on systems, not people. Ranking people on a distribution and treating the bottom slice as underperformers, when most of that variation is the system expressed through them.
When Deming is the wrong tool
When the system is not yet stable enough to have control limits, as with brand-new processes or too few data points. You cannot characterise common cause without a baseline.
When the thing that matters is genuinely qualitative. Control-charting everything produces a culture that mistakes measurability for importance.
When the measurement itself is wrong, dirty, or gamed. The statistical machinery assumes the metric is meaningful, and when it is not, the analysis produces precise nonsense.
Systems Dynamics and the Archetypes
Systems dynamics, developed by Jay Forrester※ at MIT in the 1950s and popularised by Donella Meadows※ and Peter Senge※, is the tradition for understanding feedback loops, stocks, flows, and delays. Where the Theory of Constraints draws static causal graphs, systems dynamics handles the loops those graphs cannot represent where organisational dysfunction lives. The most usable entry point is not Forrester's mathematics but Senge's archetypes, a pattern language for recurring dysfunctions.
Epistemic status. Formal system dynamics modelling is a rigorous quantitative discipline with a solid track record where the variables are measurable. The archetypes, by contrast, are a qualitative pattern language. They are genuinely useful for recognition and communication but are not predictive in any rigorous sense, and it is easy to over-fit a situation to an archetype that does not quite hold. Treat the modelling as solid and the archetypes as a good vocabulary that aids thinking without proving anything.
The core ideas
Stocks are accumulations such as headcount, technical debt, trust, or burnout. Flows are the rates that change them, such as hiring rate or recovery rate. Conflating the two obscures what is happening. "We have a hiring problem" is ambiguous until you separate the stock of people from the inflow and outflow rates.
A reinforcing loop amplifies change in either direction, so success breeds success and decline accelerates decline. A balancing loop seeks an equilibrium, like a thermostat or market saturation. Real systems contain both, and the dynamic depends on which dominates at a given moment.
Delays are the often-invisible third element. An intervention's effect frequently lags the action by weeks or months, and the lag shapes behaviour: people see no result, push harder, then overshoot when the original action finally lands.
The archetypes are recurring patterns that show up across very different organisations. The ones most useful for engineering work:
Shifting the Burden. A problem has a symptomatic fix and a fundamental fix. The symptomatic fix is faster and relieves the symptom but atrophies the capacity for the fundamental fix, so the organisation becomes dependent on it. Hiring contractors to handle overflow rather than having the staffing conversation is the classic case.
Limits to Growth. Growth produces success which produces more growth until it hits a constraint that was invisible during the growth phase. Pushing harder on what worked makes things worse. Scaling a team by hiring until communication overhead becomes the limit is the engineering version.
Tragedy of the Commons. Multiple actors share a finite resource, and each individually rational decision to use more produces a collectively irrational outcome. Every team skipping shared maintenance to protect their own velocity, until the shared infrastructure rots, is the pattern.
Fixes That Fail. A solution to the immediate problem creates consequences that make the original problem worse, often after a delay. Adding process to prevent incidents, which slows shipping, which produces rushed work, which produces more incidents.
Success to the Successful. Two parties with similar capability get different initial investment, and the small early advantage compounds until the gap is enormous. The team that got the prestige project becomes the "strong team" in a self-fulfilling way.
Drifting Goals. Pressure on a hard-to-meet goal produces gradual relaxation of the goal rather than effort to meet it. SLO targets quietly lowered each time they are missed, until they mean nothing.
Escalation. Two parties measure themselves relative to each other and respond to the other's action with more of their own. Two teams in conflict where each defensive move provokes a harder one.
How to use it
Diagnose with archetypes first and model formally only when you genuinely need quantitative prediction. For most organisational work, recognising the pattern tells you what to look for and roughly what interventions tend to work.
Name stocks and flows explicitly. "We have a quality problem" is ambiguous. Is the stock of bugs growing, is the inflow high, or is the outflow low? Each has a different intervention.
Look for delays, since they are usually where overshoot and oscillation come from. Naming them prevents the "we did nothing, then we did too much" pattern.
Apply the archetype's known intervention as a starting point. For Shifting the Burden, invest in the fundamental fix and watch for atrophy. For Limits to Growth, stop pushing the growth driver and address the constraint. For Tragedy of the Commons, change the structure so individual incentives align with the collective good.
Watch for stacked archetypes, since real dysfunction often contains several interacting.
What well-applied systems thinking looks like
An intervention aimed at the loop structure changed the behaviour pattern rather than the latest incident, and the team held off re-intervening long enough to let it land.
Naming the archetype shortened the argument: people stuck debating the latest event recognised the pattern and shifted to talking about the structure producing it.
Anti-patterns
Archetype-spotting as a substitute for diagnosis. The pattern tells you what to look for, not what is specifically going on in your situation.
Stock-flow conflation, talking about rates as if they were quantities.
Ignoring delays and amplifying an action because its effect has not landed yet.
Modelling for its own sake, building elaborate diagrams where archetype recognition would have sufficed.
Treating archetypes as universal, forcing a situation into one that does not fit.
Systems thinking as fatalism, using "it is the system" as an excuse not to act. Senge's whole point is that systems can be redesigned.
When systems dynamics is the wrong tool
When the problem really is event-driven, when a specific decision was wrong and the response is specific. Looking for the system behind every event over-explains and misses the actionable layer.
When the timescale is too short. Systems thinking operates over months and years, so "let me think about the loop structure" is unhelpful for a decision due today.
When the data or history is too thin to be confident an apparent pattern is real. In new situations the archetypes are hypotheses to test, not diagnoses.
Coda: when the work is the stock
The chapter introduced stocks, flows, and delays in the abstract. There is one place in engineering work where the three stop being abstract and start setting the pace of everything else, and that is the flow of the work itself.
The connecting idea is Little's law※: average cycle time equals work in progress divided by throughput. A team with twelve things half-finished and two shipping a week is not slow because anyone is idle; it is slow because the work is idle, sitting in queues between people while each tends the next thing they started.
Starting less is how you finish more, and a team that feels productive because everyone is busy is often the clearest instance of the problem, the busyness being inventory accumulating rather than output leaving. Cap the team at three in-flight items, force the fourth to wait, and the first three usually finish faster than anything did before.
Two further moves come from the same picture, and both turn on delay.
Batch size: A large batch is a long delay built deliberately into the loop while small changes ship sooner, fail smaller, and return feedback faster, which is the whole mechanical case for shipping daily rather than saving a quarter into one release where the failures arrive together and the cause is buried under everything that shipped beside it.
Cost of delay, from Donald Reinertsen※, is the discipline of putting a number on the waiting itself: what it costs per week that this is not done, in revenue or in risk. It is the only honest way to order a backlog, because a feature worth a hundred thousand a month deferred and one worth nothing until a fixed deadline are different decisions that the label "high priority" flattens into a single word.
Rumelt's Good Strategy / Bad Strategy
Richard Rumelt's 2011 book※ is the diagnostic mode's tool for strategic-altitude work. Its sharpest and least-practised claim is that good strategy concentrates everything on a single decisive point, the crux※, and that finding which point is the crux is most of the strategic work and rarely the same as the general statement of the problem. The familiar half of Rumelt, that most strategy documents are goals and slogans in strategy clothing, is widely quoted and easy to agree with; the part that still defeats capable teams is that even an honest diagnosis usually names the challenge at the wrong altitude. A reliability problem is not addressed by a strategy to improve reliability. It is addressed by discovering that the crux is, say, that you cannot roll back fast enough, and then pointing everything there. The framework is structural: a test for whether what you have is even a strategy, and a method for finding the crux when it is not.
Epistemic status. This is a structured articulation of expert judgement rather than an empirical theory, drawn from a distinguished strategy scholar's experience. Its diagnostic value, telling real strategy from fluff, is widely found useful and hard to argue with once seen. Its prescriptive power is weaker, since the framework tells you what good strategy contains but not how to generate the insight at its core. Treat it as an excellent quality filter and a clarifying discipline, not as a generator of strategy.
The core ideas
The kernel of good strategy has three parts. Diagnosis names the challenge and identifies which aspects actually matter, simplifying overwhelming complexity by naming the one or two decisive things. Guiding policy is the overall approach to the diagnosed challenge, an approach rather than a goal, ruling things out as much as in. Coherent action is the set of concrete coordinated steps that implement the policy and reinforce each other rather than scatter. (The kernel is a decision structure, not an improvement loop, the introduction's spine distinction.)
The three are interdependent. A guiding policy without diagnosis is arbitrary. A diagnosis without policy is academic. Coherent action without the first two is execution without direction.
Bad strategy has four signatures. Fluff, which is gauzy abstraction that sounds strategic and says nothing. Failure to face the challenge, where the document does not name what is actually hard. Mistaking goals for strategy, where "be the market leader" stands in for how you will get there. And bad strategic objectives, either disconnected from the challenge or a long unprioritised list.
Good strategy concentrates resources and action on the decisive point. Bad strategy spreads them across a pyramid of sub-strategies and workstreams. The crux is the specific point where the challenge is hardest and most decisive, and identifying it is most of the strategic work. For a reliability problem the crux might not be "improve reliability" but "we cannot roll back fast enough," and the strategy concentrates there.
How to use it
Audit existing strategy against the kernel. Find the diagnosis, the guiding policy, the coherent action. Usually at least one is missing, and the missing piece is the work.
Write the diagnosis before anything else, and spend disproportionate time on it. If the diagnosis is right the guiding policy is often obvious. If it is wrong, no execution will save it.
Use the four signatures as filters when reading or writing strategy.
Identify the crux explicitly, since it is rarely the same as the general statement of the problem.
Test coherence by reading the actions together and asking whether they reinforce each other or merely run in parallel.
What well-applied Rumelt looks like
Someone who was not in the room can read the diagnosis and state the crux, the single hard thing the strategy turns on.
The strategy named what it would not do, and that no held when an attractive off-strategy opportunity appeared, rather than dissolving on contact.
The actions reinforce each other closely enough that dropping one would weaken the rest, and the whole thing bets on a specific diagnosis clearly enough that it could be wrong, which is what separates it from a vision statement a competitor could reuse.
Anti-patterns
Goal-as-strategy, dressing an aspiration in an implementation timeline.
Diagnosis-skipping, jumping to policy or action and addressing the wrong problem confidently.
Fluff-as-vision, the inspirational document a competitor could use verbatim.
No concentration of force, whether by trying to address every issue at once or by leaving nothing out of scope, so resources spread thin and nothing gets enough.
Strategy as document rather than decision, treating the artefact as the work.
When Rumelt is the wrong tool
When the problem is operational rather than strategic, where the framework over-engineers a situation that needs operational diagnosis.
When the strategic situation has not stabilised, as in a genuinely new venture where the diagnosis itself changes weekly, so locking in a strategy is premature commitment.
When political dynamics make honest diagnosis impossible. The framework requires naming what is hard, and where the real challenge is that a powerful person will not accept the answer, it produces documents that are diplomatically correct and substantively wrong.
Coda: Larson, and writing the strategy you already have
Will Larson's writing, across An Elegant Puzzle, Staff Engineer, The Engineering Executive's Primer※, and Crafting Engineering Strategy※, along with a large body of essays on his site, acts as a pattern language for engineering organisations. Rumelt tells you whether what you have is a strategy and what a good one must contain but, as the note above conceded, not how to produce the insight at its centre. Larson provides a generator for this gap.
It starts from how the organisation already decides. Most have a strategy already, implicit and unwritten, visible only in the pattern of their real decisions, so make them visible: write five honest design documents about decisions the organisation faced, read across them for how those decisions were really made, and that pattern, written down, is the strategy. A vision is the same move once more, five strategies forecast a couple of years out.
The failure it guards against is Rumelt's failure to face the challenge in its most seductive dress, and Larson names it in his own past work: an elegant strategy describing how his organisation wished it made tradeoffs rather than how it did, conceptually pure and useless. Good engineering strategy is therefore boring. It addresses the problems teams already have rather than the brilliant idea you arrived wanting to install, the discipline being to get those ideas out of your head first, write them down somewhere, and set them aside before writing from what the organisation does. The signal that it is time to write one is mundane: the same decision keeps getting relitigated.
The encouraging claim underneath it is that you can be a top-ten-percent engineering strategist simply by documenting your implicit strategy, because so few organisations do, and once it is on paper it can be argued with and improved.
Wardley Mapping
Simon Wardley's technique, consolidated in his book Wardley Maps※, is the diagnostic mode's tool for positional and evolutionary analysis. Where Rumelt asks what the strategy is, Wardley asks what the landscape is and where you sit in it, which has to be answered first. Lay out what your users need, place each component your delivery depends on along an evolution axis from genesis through custom-built and product to commodity, and look for the mismatches, the things you are custom-building that the market already treats as a utility, or trying to productise while they are still genesis.
That placement exercise is most of the value. The rest, the Pioneers-Settlers-Town-Planners split, the climate-doctrine-gameplay layering, and the named inertia at evolution boundaries, is depth that sharpens the reading once the map is honest, worth knowing but not worth front-loading. The technique is unusual in being explicitly visual: the map is the artefact, and the discipline is producing one accurate enough to reveal what prose would hide.
Epistemic status. Wardley Mapping is a structured practitioner technique, shared openly and refined by a community, rather than an academically validated method. Its central observations, that components evolve in a predictable direction and that different evolution stages need different methods and people, have strong face validity and are widely found to ring true, but the evolution axis is judgement-based rather than measured, placement is subjective, and the one-directional evolution claim rests on accumulated practitioner conviction rather than tested evidence. Treat it as a useful thinking discipline whose value comes from honest mapping and the conversations it forces, not from any formal proof that its model is correct.
The core ideas
A real map has an anchor, position, and movement. For Wardley Maps the anchor is user need, position is the relationship between components, and movement is evolution. Most business "maps" are actually diagrams, with position but no anchor and no movement, which is why they are less useful.
The two axes are the value chain, vertical, with visible user-facing components at the top and infrastructure at the bottom, and evolution, horizontal, running from genesis through custom-built and product to commodity.
Components evolve in a predictable direction even if the timing is unpredictable. Genesis becomes custom-built becomes product becomes commodity, one-directionally. This drives most strategic dynamics, because the methods that suit genesis, exploration and experimentation, are wrong for commodity, which wants efficiency and scale, and the reverse.
Climate, doctrine, and gameplay are three layers of strategic thinking. Climate is what you cannot change, such as the evolution of components, which you map and respond to rather than argue with. Doctrine is universal good practice, such as focusing on user needs or using appropriate methods for the evolution stage. Gameplay is context-specific moves that depend on the particular map.
Pioneers, Settlers, and Town Planners are the structural insight about people. Different parts of the value chain need different kinds of people and methods. Pioneers handle the uncertain genesis end, Town Planners handle the commodity end with efficiency and scale, and Settlers handle the middle, productising the pioneers' work for town planners to scale. Much dysfunction comes from mismatched assignment.
Inertia is what happens when a component evolves but the organisation does not. It is predictable, showing up at evolution boundaries, especially the move from product to commodity where incumbents resist losing margin.
How to use it
Start with user needs and work downward, since the map is anchored to what the user actually needs rather than to what the organisation wants to build.
Place each component on the evolution axis honestly. This is where the work is, and where the most common error lives, since organisations flatter themselves by placing commodity components closer to genesis than they really are.
Look for evolution mismatches. Custom-building what should be commodity produces cost overruns and no differentiation. Trying to productise what is still genesis produces premature standardisation.
Use the Pioneer, Settler, Town Planner distinction in organisational design, matching the kind of work to the kind of person and allowing handoffs between them.
Update the map when the landscape changes, since a map built once and filed becomes wrong over time.
What well-applied Wardley Mapping looks like
A specific decision changed because of the map: custom-building stopped on something the map showed commoditising, or an investment moved ahead of a component's shift, and the decision and the placement behind it can both be named.
Across two versions of the map, components have actually moved, and at least one earlier placement was corrected once reality contradicted it.
An evolution mismatch the map surfaced, commodity being custom-built or genesis being productised, got acted on rather than just noted.
Anti-patterns
Diagrams without movement, the most common failure, producing a static picture of the present that hides the dynamics that matter.
Misplacement on the evolution axis, especially placing components closer to genesis to flatter a sense of innovation.
Mapping as performance, producing impressive maps that change no decision.
Treating Pioneers, Settlers, and Town Planners as a career ladder rather than as types of work and people.
Apparatus over thinking, reaching for Wardley doctrine and vocabulary in place of the actual placement-and-movement work, which both ignores the specific gameplay the map suggests and produces fluent-sounding nonsense.
When Wardley Mapping is the wrong tool
When the question is operational rather than strategic, where mapping is overkill.
When the situation is not yet legible enough to map, as in a genuinely new market where components have not evolved enough to place reliably.
When the user need cannot be cleanly identified, as with some internal infrastructure or organisational-change work. The framework can be adapted but loses sharpness.
When the audience needs a different artefact. Maps take effort to read, and presenting one to an audience that needs an executive summary or a project plan fails to communicate even when the analysis is right.
Lightweight tools
The six tools above are substantial frameworks. Alongside them sits a family of small structuring devices, mostly quadrants and checklists, that do not need a chapter each but earn their place because they are fast, legible, and good at preventing specific oversights. Their epistemic status is simply that they are useful formats, widely used because they work.
RAID is a tracking checklist for Risks, Assumptions, Issues, and Dependencies. Its value is that the four categories are easy to confuse and each needs different handling: a risk has not happened yet and wants mitigation, an issue is already real and wants resolution, an assumption is something you are taking on faith and wants validation, and a dependency is something outside your control that wants tracking. Keeping the four columns separate stops a team from treating a live issue as a hypothetical risk, or from burying a load-bearing assumption in a list of tasks. It is most useful on projects with enough moving parts that things fall through the cracks, and it adds pure overhead on small, legible work.
Adjacent to RAID is the 4Ts of risk response, sometimes shown as a column on a risk register: Treat (mitigate, reduce likelihood or impact), Tolerate (accept, live with it and document why), Transfer (push to another party better placed to carry it, such as insurance, a vendor SLA, or a partner team), and Terminate (avoid, change the scope or the system so the risk no longer exists). The value of the column is that it forces a verb against every row, so a register becomes something other than a list of worries. Two caveats: Investigate is a hold-state while you scope, not a fifth T, and rows in it need a decide-by date; and Tolerate is a real choice rather than a non-answer, but only if the rationale is written down. Bow-tie analysis, a process-safety cousin that draws causes to the left of a top event and consequences to the right with responses as barriers across the diagram, asks one question the register alone does not, whether you have controls on both sides of the event, but is heavyweight for most engineering-org work. The operating chapter's lightweight section has the natural companions: the decision log as the home for the Tolerate rationale, and the pre-mortem as the source of register rows in the first place.
RACI clarifies decision rights by naming, for each task or decision, who is Responsible (does the work), Accountable (owns the outcome and is the single point of decision), Consulted (gives input before), and Informed (told after). Its single most valuable rule is that there is exactly one Accountable per item, since diffused accountability is the most common cause of decisions that never quite get made. It is worth reaching for when "who actually decides this" is genuinely unclear, and it becomes bureaucratic theatre when applied to work where everyone already knows. RACI is at least as much an operating tool as a diagnostic one, and it reappears in the operating chapter for that reason.
The Eisenhower matrix sorts work on two axes, urgent versus not urgent and important versus not important. The point it forces is the distinction between urgent and important, which people conflate under pressure, so that the not-urgent-but-important quadrant, the strategic and developmental work, stops being crowded out by the urgent-but-unimportant. It is a personal prioritisation aid more than an organisational tool, and it says nothing about what makes something important, which you have to supply.
A few others in the same family are worth knowing by name. A SWOT grid scans strengths, weaknesses, opportunities, and threats, useful as a conversation-starter and weak as analysis since it rarely survives a hard question. A two-by-two of impact against effort triages a backlog quickly, with the high-impact low-effort quadrant being the obvious first place to look. A risk matrix plots likelihood against severity to sort what to worry about, with the caveat that both axes are usually guesses dressed as numbers; FMEA, Failure Mode and Effects Analysis from reliability engineering, is the heavier sibling that adds a Detection axis to ask whether you would notice before damage was done, and earns its place when "we wouldn't catch it" is part of what makes a risk frightening. MoSCoW sorts requirements into Must, Should, Could, and Won't-this-time, and its real value is the explicit Won't, which forces the deprioritisation people otherwise avoid.
The Ladder of Inference, from Chris Argyris, deserves its own paragraph because it is the closest of the lightweight tools to the developmental mode. It is less a grid than a diagnostic ladder: it traces how you climb from observable data through selected facts, interpretations, and assumptions to conclusions and action, and its use is to climb back down when a disagreement has gone strange, asking what data the other person is actually working from. It pairs naturally with the assumptions work in an Evaporating Cloud, and the force-field sketch, listing forces pushing for a change against those resisting it, is a lighter cousin of the Cloud in the same spirit.
The shared discipline with all of these is to treat the format as a prompt, not as the analysis. The grid asks the question. You still have to answer it, and the neat quadrants can give a false sense that filling them in was the thinking.
Operating Tools
These are for running an organisation while it is also being diagnosed and repaired. They assume you cannot stop, that the work has to keep shipping, and that the job is to integrate analysis and people-shaped concerns under real time pressure. The chapter covers five: Grove's framework from High Output Management, Team Topologies, the Improvement Kata, Maister on strategy and commitment, and Barry Johnson's Polarity Management, plus a section on lightweight coordination tools.
This mode is defined by context of use rather than by a shared method, which is why several of its tools are diagnostic ideas applied under pressure. Grove's limiting step is Goldratt's constraint, seen from the manager's chair. The Improvement Kata is Deming's PDSA, drilled until it is a reflex. Team Topologies takes Conway's law as climate, in Wardley's exact sense of a force you map and respond to rather than argue with.
The shape of problem they are ill-suited to: deep root-cause work, which they tend to assume has been done already. Personal development work, since they are about role and rhythm rather than psychology. Genuinely novel situations with no operating template.
Grove's framework (High Output Management)
Andy Grove's 1983 book※ is the operating mode's equivalent of the Theory of Constraints. Different vocabulary, similar moves: find the leverage, subordinate everything else to it, watch the indicators that tell you what is actually happening.
Epistemic status. This is distilled wisdom from running one of the most successful manufacturing and engineering organisations of its era, refined into transferable principles. It has held up across four decades and underpins a great deal of modern management practice, which is strong evidence of practical value, though it is experience codified rather than experimentally tested. The production and leverage ideas generalise cleanly. Task-relevant maturity is a useful heuristic rather than a measured construct, so apply it as a lens, not a scoring system.
The core ideas
Management as production. A manager's output equals the output of their organisation plus the output of neighbouring organisations under their influence. This kills a great deal of activity that feels like work but produces nothing. The manager who writes long messages, attends every meeting, and stays informed is doing inputs, not outputs.
Indicators, especially leading ones. Grove is obsessive about the difference between indicators that tell you a result has happened and indicators that predict it. Deployment frequency lags. Review latency leads. The discipline is finding the two or three leading indicators that actually predict the outcomes you care about and watching those, rather than the dashboard everyone built because the data was available.
The limiting step. In Grove's breakfast-factory example, the longest step sets the throughput of the whole line, so you build the rest of the process around it. This is the constraint idea, predating Goldratt's popularisation, applied to where a manager spends time.
Task-relevant maturity. The single most important concept in the book and the one most often misremembered. It is not a general statement about how experienced someone is. It is how mature they are for a specific task. The same engineer can be high maturity for a refactor in code they have owned for years and low maturity for negotiating with a vendor. The right management style, directive or coaching or delegating, depends on maturity for the task at hand, not for the person in general. Most "this person is underperforming" conversations conflate the two.
Leverage. Grove's word for where small amounts of manager time produce disproportionate output. High-leverage activities include hiring decisions, the first time you train someone on something, and decisions that affect many people for a long time. Low-leverage activities include reading every message and attending meetings where you hold no decision authority.
The one-to-one as core management technology. Grove treats it as the primary high-leverage tool a manager has, ninety minutes that affect two weeks of work. The subordinate sets the agenda, and the manager listens, asks, and surfaces what has not been said. It is the one meeting Grove protects as essentially non-negotiable.
How to use it
Write down the production function of your role. What is the output, whose outputs do you affect, and what activity are you doing that produces neither? Most managers cannot answer the first two crisply, and most of the "I am so busy" energy lives in that gap.
Identify two leading indicators per critical outcome, not five. If an indicator does not let you predict tomorrow, it is not leading. Then build the rhythm to look at them weekly, since most leading indicators die because nobody checks them once the dashboard exists.
For each direct report, assess task-relevant maturity per major area of work rather than in general, then match your style to it. The mistake is picking a style from your own preference rather than their current maturity.
Run one-to-ones as the subordinate's meeting. Their agenda, their questions, your attention. If you need status, build a separate artefact for it, because using the one-to-one for status kills its leverage.
What well-applied Grove looks like
The manager's calendar has visibly shifted toward the high-leverage activities, and they can name a low-leverage thing they stopped doing to make the room.
The same report is managed directively in one area of their work and left alone in another, and the difference tracks their maturity for each task rather than a single label for the person.
A leading indicator flagged a problem before the lagging one moved, and the manager acted on the early reading.
Anti-patterns
Task-relevant maturity as personality assessment, treating someone as low maturity in general rather than for a specific task, which conflates capability with current expertise and makes the framework useless.
Leverage as a virtue rather than a measurement. "I should do high-leverage things" is a slogan until you have named and ranked the specific activities.
Indicator inflation, watching twenty indicators because the data exists. Two that predict the outcome beat twenty that decorate the dashboard.
One-to-ones as status meetings, killing the highest-leverage management activity by putting it to the lowest-leverage use.
Production-function thinking with no people layer. Read alone, Grove can be cold, treating people as inputs. The corrective is reading him alongside the developmental chapter and treating maturity development as the long game rather than just a routing function.
When Grove is the wrong tool
When the diagnosis is wrong. Grove assumes you know what you are producing and have identified the limiting step correctly. If the strategy is wrong or the goal is contested, optimising the production function optimises the wrong thing, which is diagnostic work.
When the team needs repair rather than execution. Grove has nothing to say about a team that is burned out or has lost trust, and running tighter one-to-ones on a broken team makes it worse. That is developmental work.
Team Topologies
Matthew Skelton and Manuel Pais's 2019 book※ gave engineering organisations a shared vocabulary for team design. The vocabulary, four team types and three interaction modes, is the part everyone adopts and the part that does the least work on its own. The load-bearing idea is underneath it: you do not fight Conway's law※, that systems come to mirror the communication structures that build them, you run it backwards, deciding the architecture you want and then drawing the teams whose mirror produces it. Everything else follows as relief. Most teams should be stream-aligned, owning one flow end to end, and the other three types exist only to keep them that way, each justified by a specific cognitive load it lifts off a stream-aligned team. Its subject is the container, not the problem inside it, which makes it the chapter's clearest case of shaping rather than executing.
Epistemic status. Practitioner synthesis with one empirically-supported claim holding it up. The Conway's law mechanism beneath it, that systems come to mirror the communication structures of the organisations that build them, has real evidence: studies matching codebases to the organisations that produced them (MacCormack, Baldwin, and colleagues)※ found the mirroring holds more often than not. The inverse Conway manoeuvre follows from that and is sound in principle. The four team types and three interaction modes are a clean, widely-adopted synthesis with strong face validity and no formal testing, which puts them on the Larson and Wardley shelf, not Deming's. The cognitive-load framing borrows a term from instructional psychology as a metaphor, not a measured quantity. So: trust the Conway core, use the types and modes as a shared language, and treat cognitive load as a question to ask, not a number to compute.
The core ideas
Team Topologies is a small kit: one law to design around, four kinds of team, three ways for them to interact, and a method for cutting the lines between them.
Conway's law is the thing you design around. Systems come to mirror the communication structures that build them, so the architecture you ship ends up shaped like your teams whether you meant it or not. Don't fight this and lose, run it backwards: decide the architecture you want, then draw the teams whose mirror produces it. This is the inverse Conway manouver.
The four team types. A stream-aligned team owns one flow of work end to end, a product or a journey or a segment, and is the default that the other three exist to protect. A platform team provides internal services that take load off the stream-aligned teams, run as a product whose customers are those teams. An enabling team is temporary: it grows a capability in another team and then leaves, which makes it the Coaching Kata wearing an org chart, succeeding exactly when it has made itself unnecessary. A complicated-subsystem team owns a part that needs specialist depth, a codec or a pricing engine, that would drown a stream-aligned team if smeared across it. Most teams should be stream-aligned, and the other three are there to keep them that way.
Cognitive load is what sizes a team. A team holds only so much in its head, and once it owns more domains than it can reason about it slows, decides worse, and starts to behave like a bag of individuals rather than a team. Do not measure this, ask it: is this team being asked to understand more than a team can understand. When the answer is yes, the other three types are the relief valves: the specialist part to a complicated-subsystem team, the undifferentiated heavy lifting to a platform, the missing skill to an enabling team.
The three interaction modes are how the teams talk. Collaboration is two teams working closely and noisily for a bounded stretch, right for discovery and too expensive to leave running. X-as-a-service is one team consuming another through a clean interface with almost no talking, right for predictable scale. Facilitating is one team helping another over a hump. The discipline is to name which mode each important pair is in and to put a clock on collaboration, so that it resolves into a service boundary instead of curdling into permanent coupling nobody chose.
Finding the boundaries is the step the types do not give you, and it is where domain-driven design※ can come in. DDD's bounded contexts and fracture-plane heuristics tell you where to cut: along domain seams, along change cadence so that what changes together stays together, along data ownership, along regulatory lines, and along cognitive load. A good boundary has a narrow interface and a single reason its insides change. This is to Team Topologies what GROW is to the Coaching Kata, the companion that supplies the move the headline only gestures at. The rest of DDD is its own subject and stays out of frame; the fracture planes are the slice that serves team design.
How to use it
Run the manoeuvre backwards. Start from the architecture you want and ask what team structure would mirror into it, rather than forwards from the org chart you happen to have.
Make most teams stream-aligned, and make every other team earn its name. A platform, complicated-subsystem, or enabling team justifies itself by the load it lifts off a stream-aligned team. If you cannot say whose load, it is overhead in a costume.
Cut on the fracture planes, not the org chart. The most common bad boundary is the one inherited from how the company happened to hire, slicing clean through a domain that changes as one.
Name the mode for each important pair, and put a clock on collaboration. "We collaborate with X until the end of the quarter, then it becomes a service" is the shape of a healthy interaction; open-ended collaboration is the shape of a missing boundary.
Run the platform as a product, which means asking whether its teams would choose it if they could. A platform people are forced onto hides its own failure to lift load.
What well-applied Team Topologies looks like
A collaboration that had run open-ended for months got converted into a clean service interface with a date on it, and the two teams stopped needing constant sync.
A boundary moved onto a fracture plane and the symptom went with it: what used to require three teams to coordinate on every change now changes inside one.
A platform team can point to the load it lifted, and the stream-aligned teams would choose it if they could, rather than being routed onto it.
The architecture shifted and the team shape moved with it, rather than the structure freezing after one reorg.
Anti-patterns
Renaming, not redesigning. Relabelling the existing teams with the four type names and changing nothing about boundaries or interactions. The most common failure, and it buys a vocabulary with no substance under it.
Platform as a dumping ground. Calling a team "platform" when it is really where unglamorous work goes to die, with no product discipline and no test of whether anyone would choose it.
Permanent collaboration. Two teams locked in open-ended high-bandwidth collaboration, which is almost always a missing or wrong boundary wearing the costume of teamwork.
Boundaries without the rest of the design. Moving the team boxes while leaving rewards, processes, and decision rights untouched, so the structure reverts.
Inverse Conway as a one-off. Running the manoeuvre once and freezing, when the architecture you want moves over time and the team shape has to track it.
When Team Topologies is the wrong tool
Small organisations. Below roughly four teams the kit is ceremony; you have a handful of people and the real question is who works on what this quarter, not which of four types each team is. Below this abstraction floor you are designing for people, not teams.
When the binding constraint is not structural. If the teams are reasonably shaped and the blocker is trust, a wrong incentive, or an unclear strategy, redrawing boundaries is an expensive way to dodge the actual work.
When you cannot move the boundaries. The tool assumes the authority and the slack to reshape teams. Where reporting lines are politically fixed it diagnoses a problem you cannot act on, which is dispiriting rather than useful, and the honest move is to name the constraint, work inside it and choose your battles.
Coda: the design axis, beside and behind
Team Topologies is a tool for organisational design, the generative work of shaping the container rather than acting on the problem inside it. At the same practitioner altitude sit a handful of Will Larson's observations about team shape, and behind the whole axis sit two deeper bodies of knowledge.
Larson's distinction between weak-versus-strong teams※ asks whether an organisation assigns work to teams or drives it through individuals and their relationships: a strong concept shows up as team-level sprints, tickets, and goals, a weak one as work that moves along personal lines. Small organisations run weak whether they choose to or not, and most drift to strong only past a couple of dozen engineers. Beneath sits a harder floor: a team of fewer than four engineers behaves like a set of individuals, where you track each person's on-call and leave and a single departure tips it from building to merely maintaining. Draw four crisp boxes over twelve people and you have a diagram, not a structure.
Two further choices quietly degrade the unit. Snowflakes are the accumulation of reasonable-sounding "this team needs special rules" exceptions, each defensible alone, that together produce an organisation that cannot move because every change must be negotiated against the pile, which is why part of the senior job is refusing reasonable exceptions to preserve the capacity to act. And splitting innovation from maintenance, spinning up a fresh team for the new work while existing teams keep the lights on, buys a two-tier system of innovators and maintainers whose morale cost usually outweighs the focus it bought; the harder, better move is to innovate inside the existing teams.
Galbraith's Star Model※ is the governing principle. Structure is one of five points that have to align along with strategy, processes, rewards, people. Moving any one alone, the reorg with no matching change to incentives or process, reverts within a couple of quarters. Whenever you reach for Team Topologies, the Star Model is the reminder that the boundaries are a quarter of the job: if the reward system still pays people for the behaviour the new structure is meant to end, the structure loses. This rhymes with Maister's commitment problem and with the collection's running line that behaviour is produced by context, not character.
Mintzberg's configurations※ are the treatise to know. Organisations cohere into a few types, each a matched bundle of a coordinating mechanism (mutual adjustment, direct supervision, or the standardisation of work, outputs, or skills) and a dominant part, and most structural dysfunction is a mismatch, controls built for one mechanism applied to work that needs another. The portable idea for an engineering organisation is the coordinating mechanism itself: when coordination is failing, ask which mechanism the work actually needs before adding more of the one you already have. The full typology is lower-resolution at the scale most software organisations run at, so it is named and set down rather than worked.
The Improvement Kata
Mike Rother's Toyota Kata※, from 2009, names the behavioural pattern that makes lean continuous improvement actually work, as distinct from the tools that get adopted as rituals without it. The Improvement Kata is a repeatable routine for moving a team from where it is toward a hard goal it cannot reach in one leap, by taking deliberate experimental steps through the unclear territory in between. The word kata is deliberate: a movement pattern practiced until it becomes second nature, not a methodology you consult.
Epistemic status. The Kata is a reverse-engineered articulation of how effective continuous improvement actually happens at Toyota, generalised into a teachable practice. The underlying experimental loop is essentially the scientific method applied to operations and is on firm ground. Whether the specific four-step and five-question forms are the best way to instil it is a reasonable design choice rather than a proven optimum, and the practice depends on disciplined coaching, so results vary with how well it is taught.
The core ideas
The Kata has two nested loops. The outer loop, run roughly monthly, sets up where you are heading. The inner loop, run daily or every few days, is the actual experimenting. Most of the value, and most of the failure, is in the inner loop.
The outer loop, setting direction, four moves.
First, decide the challenge. This is the far goal, usually months out and genuinely hard. "Cut the time from code-merged to deployed-in-production from four hours to under thirty minutes." It is directional and motivating, and you cannot reach it in one step, which is the whole reason the Kata exists.
Second, grasp the current condition. Before planning anything, measure where you actually are, in observable terms. Not "deploys feel slow" but "over the last twenty deploys, median time from merge to production was four hours and ten minutes, and the single biggest block of time, about ninety minutes, is the manual QA sign-off step". You need to spend time finding a sharp description, as you cannot navigate from a starting point you have not located.
Third, set the next target condition. The target condition is not the challenge and not a task. It is a description of how you want the process to be working at a specific near date. It names a measurable outcome and, importantly, the condition of the process that produces it. "In three weeks, the QA sign-off step is automated for low-risk changes, so that median merge-to-production time for those changes is under ninety minutes."
Fourth, identify the obstacles between the current condition and the target condition, and list them. You do not try to solve them all. You keep the list and work on one at a time, the single obstacle currently in your way. For the deploy example: QA sign-off is manual; there is no automated risk classification for changes; the staging environment takes twenty minutes to spin up. Three obstacles, tackled one at a time, not in parallel.
The inner loop, experimenting toward the target, run repeatedly.
This is the engine. Against the one obstacle you are currently working on, you run a cycle: state what you are working toward, describe where you are now relative to it, name the obstacle you are addressing, then design your next experiment as a prediction. The prediction is the heart of it. You write down, before acting, what you will do, what you expect to happen, and by when you will look. Then you run it, and you go and see the actual result against your prediction.
The learning lives entirely in the gap between prediction and result. If the result matches, you learned the approach works and you extend it. If it misses badly, you do not treat that as failure, you treat it as the most useful information you got this week: your model was wrong, and now you know to investigate why. Either way the next experiment is informed by what the last one revealed. You are not implementing a plan, you are conducting a series of small investigations, each one narrowing the uncertainty between you and the target.
A cycle, start to finish. To make the inner loop concrete, here is one full pass for the deploy example, working the first obstacle, manual QA sign-off.
- Target condition: in three weeks, low-risk changes deploy without manual QA, median under ninety minutes.
- Current condition: all changes require manual sign-off, median four hours ten minutes.
- Obstacle being worked: there is no way to tell automatically which changes are low-risk.
- Next experiment and prediction: "We will write a rule that flags any change touching only front-end display code as low-risk, and we predict it will cover about a third of our deploys with zero incidents over one week. We will check next Tuesday."
- The team runs it.
- Tuesday's result: the rule covered twenty-eight percent of deploys, close to predicted, but one flagged change caused a visual regression in production.
- The learning: front-end-only is not automatically safe, because display bugs still reach users. The next experiment narrows the rule, perhaps excluding changes to checkout-flow display, and predicts again.
Three or four such cycles in, the rule is trustworthy, the obstacle is cleared, and the team moves to the next obstacle on the list. That is the Kata: not a plan executed, but a target approached through a chain of small predicted-and-checked steps.
How to use it
Start with one team and one challenge, since the Kata is learned by doing. Rolling out "Kata thinking" across the organisation as an initiative is exactly the failure the book warns against.
Budget roughly a week of pure measurement before setting a target. If you cannot state the current condition in numbers, you are not ready to move.
Set the target condition two to four weeks out, near enough to picture concretely and far enough to need several experiment cycles to reach.
Work one obstacle at a time, and run the inner loop in small fast cycles of one change each, so you can see which change moved the result.
Use the five Coaching Kata questions exactly, in order. Managers reliably want to skip the current condition or jump to giving advice, and the fixed questions exist to prevent both.
What well-applied Kata looks like
A wrong prediction visibly changed the next experiment: the team can point to a cycle where the result missed and show how the miss reshaped what they tried next.
The target condition got reached through a chain of cycles on the board, each narrowing the gap, rather than a plan executed in one move.
A learner who could not run the loop at the start now runs it without the coach, which is the coaching having worked.
Anti-patterns
Skipping the current condition, jumping from challenge straight to action.
Target conditions that are really goals or tasks, "improve reliability" or "automate QA," rather than a specific near-term process condition with a measurable outcome.
Breaking the predict-and-check loop, either acting without a written prediction or declaring a change done without going to see the result against it, so the gap that produces the learning never forms.
Batching changes, running several at once so you cannot tell which one moved the outcome.
The coach solving the problem, answering the five questions for the learner instead of asking them.
Rolling the Kata out as an organisation-wide programme rather than letting it spread by being practiced and coached on one team first.
When the Kata is the wrong tool
When the direction is wrong. The Kata navigates toward a target but says nothing about whether the target is correct, so it will efficiently take you in the wrong direction if the challenge is wrong. Strategic work, including Rumelt and Maister below, happens before the Kata.
When there is no slack for experiments. The Kata requires capacity to try small things and observe, and a team in pure firefighting mode cannot run it until it has created breathing room first.
When the work is genuinely novel. The Kata assumes you can predict an experiment's result with at least rough confidence. For truly novel work the predictions are wide and the cycles long, which is closer to open-ended research than to the Kata's tighter improvement loop.
Coda: the Coaching Kata
Rother pairs the Improvement Kata with a coaching routine, because the practice is a skill and skills need a coach. The learner runs the improvement; the coach develops the learner's ability to run it, by asking five questions in the same order every time:
- What is the target condition?
- What is the actual condition now?
- What obstacles are in your way, and which one are you addressing now?
- What is your next step or experiment, and what do you expect?
- When can we go and see what we learned from taking that step?
The coach does not supply answers. The questions, asked consistently, train the learner into the pattern, and the fifth question, the go-and-see, is what keeps it experimental rather than theoretical.
Seen from the developmental chapter, the Coaching Kata is a tightly constrained coaching framework aimed specifically at improvement work, the same ask-don't-tell discipline as GROW, with the question set fixed.
Maister on strategy and commitment
David Maister's work, principally Managing the Professional Service Firm※ and the later essay collection Strategy and the Fat Smoker※, is the operating mode's answer to a problem the others assume away: that knowing what to do and doing it are different things. The knowing-doing gap is the famous part. The mechanism is the useful part, and it is quieter. Commitment does not fail at the moment of decision, when resolve is high and the choice feels clear. It fails in the weeks afterward, one individually reasonable exception at a time, the lucrative but off-strategy client, the urgent work that crowds out the developmental work, each defensible on its own and collectively fatal to the strategy. That is why this is an operating problem and not a planning one: the work is holding the commitment against a stream of sensible reasons to break it, long after the decision that felt like the hard part is made.
Epistemic status. This is seasoned advice from a career advising professional-service firms, articulated more sharply than most and widely recognised by practitioners as true to life. It is experience distilled into argument rather than tested theory, and it is rooted in a specific context, partnerships and service firms, that transfers well to consultancies and engineering organisations and less cleanly to product companies or manufacturing. Treat it as a clarifying lens on the knowing-doing gap, not as a method that produces strategy.
The core ideas
The fat smoker. Maister's central image is the person who knows exactly what they should do, eat less, exercise, stop smoking, and does not do it. Most organisational strategy is in the same position. The firm knows it should be more selective about clients, invest in developing juniors, and say no to work that does not build the practice. The knowing is not the hard part. The doing is, because the right behaviour requires giving up something good now, revenue, comfort, a busy calendar, for a benefit that is larger but later and less certain.
Strategy means saying no. Because the constraint is commitment rather than insight, Maister's strategic advice is mostly about subtraction. A real strategy shows up in what the firm declines, the clients it turns away, the work it stops doing. A strategy that adds priorities without removing any is not a strategy, it is a wish list, and it will be quietly defeated by the daily pressure to take the next available piece of work.
The quick-strategy table. When you do not need a full analysis and just need to get moving, Maister's blunt instrument is a short table: what do we want more of, what do we want less of, and what specifically will we do differently, starting now. Then you set a date to check whether the proportions actually changed. It is the operating counterpart to Rumelt's diagnostic kernel, useful precisely when the diagnosis is not the bottleneck and the honest answer is that everyone already knows what to do. It is a commit-and-revisit structure, not a predict-and-check one, the introduction's spine distinction.
Commitment is sustained, not declared. The fat smoker does not fail at the moment of deciding to quit. They fail in the weeks afterward, one reasonable exception at a time. Maister's point is that strategy execution is the same: the work is the ongoing discipline of holding the commitment against a stream of individually reasonable reasons to break it, which is why it is an operating problem and not a planning one.
How to use it
Separate the knowing from the doing explicitly. When a strategy stalls, ask whether the problem is that you do not know what to do or that you are not doing what you know. The interventions are completely different, and most stalled strategies are the second kind, where more analysis is avoidance.
Write the strategy as a set of noes. For any proposed direction, name what the organisation will stop doing or turn away to make room for it. If the list of noes is empty, the strategy is not real yet.
Use the quick-strategy table when the diagnosis is obvious. More of, less of, do differently, check by a date. It gets a team moving without the ceremony of a full strategic exercise, and it surfaces immediately whether anyone is actually willing to give something up.
Plan for the stream of reasonable exceptions. Since commitment fails one exception at a time, decide in advance how you will handle the predictable pressures, the lucrative but off-strategy client, the urgent work that crowds out the developmental work, rather than relying on willpower in the moment.
What well-applied Maister looks like
The organisation turned down something attractive that fit the old pattern but not the strategy, and can name the specific thing it said no to.
When the predictable off-strategy pressure arrived, the lucrative wrong-fit client or the urgent work crowding out the developmental work, the pre-decided handling held rather than willpower failing in the moment.
Anti-patterns
Analysis as avoidance, commissioning more strategic study when the real problem is that nobody wants to give anything up. The fat smoker does not need another diagnosis.
Strategy as addition, layering new priorities onto an unchanged workload, which guarantees the daily pressure wins.
Declaring commitment and stopping there, treating the decision to change as the change, when the work is the weeks of holding it afterward.
Confusing Maister with Rumelt. Rumelt tells you whether you have a coherent strategy. Maister tells you whether you will actually do it. Reaching for Maister when the diagnosis is genuinely unclear skips the diagnostic work that has to come first.
When Maister is the wrong tool
When the diagnosis genuinely is the bottleneck. If the organisation does not actually know what to do, Maister's commitment framing is premature, and the diagnostic chapter, Rumelt especially, comes first.
When the context is far from his. The advice is tuned to professional-service firms and partnerships. The knowing-doing gap is universal, but the specific dynamics, billable hours, partner incentives, client selection, may not map onto a product or manufacturing organisation without translation.
When the problem is capability rather than commitment. Sometimes the firm does not do the thing because it cannot yet, not because it will not. That is a development problem for the developmental chapter, not a commitment problem.
Polarity Management
Barry Johnson's framework, developed through the 1980s and consolidated in his 1992 book※, turns on a distinction that is easy to state and easy to half-learn. Some situations are problems, with a right answer that ends the issue; some are polarities, pairs of values both necessary and interdependent, where committing permanently to one is what makes things worse.
The distinction is the famous part. The discipline is the part people get wrong even once they hold it: a polarity is not managed by splitting the difference and settling in the middle, which reaches neither pole's upside, but by oscillating deliberately, riding one pole's upside until its downside starts to accumulate and then moving to the other before that downside hardens into a crisis that forces a clumsy overcorrection.
Managing that oscillation over months and years is a running-the-organisation discipline, which is what places the tool in the operating mode and makes it kin to Maister: where Maister is about holding a commitment against a stream of reasonable exceptions, this is about holding a deliberate balance against the constant pull to pick a side and be done. Both are the slow, sustaining work that the faster operating tools assume someone is already doing.
Epistemic status. The central distinction, between problems with solutions and polarities that require ongoing management, is conceptually clean and widely found illuminating, and it is the durable contribution. The fuller apparatus, the four-quadrant map and the infinity loop, is a useful structuring device rather than a measured model, and the framework rests on accumulated consulting experience rather than controlled evidence. The main risk is over-application, since labelling a genuine problem a polarity becomes an excuse to avoid deciding.
The core ideas
Problems versus polarities. A problem has a solution and stays solved. A polarity is a pair of values or approaches that are both necessary, both valuable, and interdependent, where the work is not to pick one but to manage the ongoing oscillation between them. Stability and change, individual and team, centralised and decentralised, short-term results and long-term capability. The diagnostic question: if I picked this option and stayed there forever, would problems eventually appear? If yes, it is a polarity.
The polarity map is a four-quadrant tool. Put the two poles on the horizontal axis and upside above, downside below. Each quadrant gets filled in, so for centralised versus decentralised decision-making you capture the upside and downside of each. The map makes visible what advocates of each pole already know about their own upside and the other's downside, and what they typically do not acknowledge about their own downside and the other's upside.
The infinity loop. Organisations move from one pole's upside, accumulate its downside, swing to the other pole's upside, accumulate its downside, and swing back. This is normal and unavoidable, and the work is not to stop the oscillation but to recognise it and move deliberately, catching the downside before it becomes a crisis that forces an over-correction.
Early warning signs. For each downside, identify the signals that show it is accumulating, which lets you shift toward the other pole before the downside forces the shift.
Its subject is human tension even though its discipline is operating, which makes it the collection's cleanest example of the introduction's point that the modes are sorted on different axes: here the subject pulls one way and the context of use the other.
How to use it
Diagnose first, asking whether this is actually a polarity. Genuine polarities have both sides advocating legitimate values, a history of oscillation, and problems that appear whenever one side is fully committed to. If the answer is "we just need to decide and stick with it forever," it is probably a problem.
Map both poles fully with both camps in the room. The value is in the mixed group, because each camp fills in its own pole's upside and the other's downside easily and struggles with the remaining quadrants, and doing the map together forces each side to acknowledge what the other sees.
Identify observable early warning signs for each downside.
Design action steps for each upside, concrete actions rather than "be more decentralised."
Set a cadence to revisit the map, since polarity maps die when built once and filed.
What well-applied Polarity Management looks like
The oscillation got named in real time and corrected before it became a crisis: someone could say we have swung too far toward centralisation and the group adjusted, rather than discovering it at the next breakdown.
An advocate of one pole defended the other pole's upside accurately, which is the sign the map stopped being a weapon and both sides found it fair.
Anti-patterns
Polarity Management as compromise, splitting the difference permanently and ending up in the middle where neither upside is accessed. This is the most common misunderstanding, since the work is managing the oscillation to access both upsides over time, not living in the middle.
Treating problems as polarities, making everything contestable when some things have right answers.
Treating polarities as problems, the more common error in diagnostic-default cultures, trying to solve stability versus change by picking one.
Filling the map with strawmen, where advocates of the favoured pole exaggerate the other's downside, so the map only works if both sides find the content fair.
No early warnings and no cadence, building the map once and being surprised when the oscillation hits a crisis.
When Polarity Management is the wrong tool
When the situation genuinely is a problem with a right answer, where polarity thinking produces unnecessary equivocation. The diagnostic question is the test.
When power is too asymmetric, so one side can permanently impose its pole regardless of consequences, in which case the intervention is at the power layer.
When the timescale is too short. Polarity Management works over months and years, so for an urgent decision it is unhelpful, and you should decide now and revisit when there is space for the longer frame.
Lightweight tools
As with the diagnostic chapter, a family of small structuring devices sits alongside the substantial frameworks. They carry no theory, and their epistemic status is simply that they are useful formats. The operating versions are mostly about coordinating people and work rather than diagnosing problems.
A3※, named for the paper size, fits one problem to one sheet: problem statement, current condition, goal, and root-cause analysis on the left, countermeasures, plan, and follow-up on the right. The page is the whole trick. It forces the analysis to fit and to come before the solution, and it puts one name on the problem. Think of it as a forcing function rather than a framework, with PDCA underneath it, the same loop as the Kata. Its best use is as the artefact a diagnostic workshop distils into: the Current Reality Tree or Cloud does the thinking, the A3 carries the decision and the check to the people who have to act. It is discussed, not filed as an A3 nobody walks through is a status report. It adds ceremony when the problem is too small to need a page or too tangled to fit one.
RACI, covered in the diagnostic chapter's lightweight section, is at least as much an operating tool. Naming a single Accountable person per decision is often the fastest fix for work that stalls because nobody owns the call.
A stakeholder map, listing who is affected by a change and sorting them by how much they care and how much power they have, is a quick way to anticipate where resistance and support will come from before a rollout rather than during it.
A pre-mortem is the lightest operating risk tool there is: imagine the initiative has already failed, ask why, and act on the answers. It takes minutes and reliably surfaces the risks a confident team was talking itself out of. It is also one of the few lightweight tools with real experimental support behind it. Gary Klein's work on the technique※ draws on research into prospective hindsight※, the finding that imagining an outcome as already having happened, rather than as a possibility, measurably improves people's ability to generate reasons for it. The format works because of how it reframes the question, not just because it is a tidy prompt.
A simple decision log, recording what was decided, by whom, when, and why, is unglamorous and disproportionately valuable, since most organisations relitigate settled decisions because nobody wrote down the reasoning. It is the operating counterpart to a strategy that exists on paper.
A decision framework names who drives a decision and who approves it, so that decisions get made rather than circling. RACI is the general version; DACI is a sharper variant for one-off decisions※, naming the Driver who runs the process, the single Approver who decides, the Contributors who inform it, and the Informed who hear the outcome. The lighter touch, when even DACI is too much, is simply to declare for a given decision whether it is one person's call after input, a consensus, or a vote, and to say so out loud before the discussion rather than discovering it during the argument.
A working-agreement or team-charter sketch, written once when a team forms or reforms, records how the team has agreed to operate: what "done" means, how decisions get made, when meetings happen, what response times to expect. It is lightweight and prevents a surprising amount of recurring friction by making the implicit explicit, and it connects directly to Larson's weak-versus-strong team concept, since writing the charter is part of how a team moves toward a stronger concept.
The same discipline applies as before: the format is a prompt, not the work. A filled-in RACI with the wrong person Accountable is worse than none, because it looks settled.
Developmental Tools
These work with humans as humans, with feelings, histories, identities, capabilities, competing internal commitments, and the shared assumptions a group forms over time. You reach for them when the diagnostic mode has done its work and the blocker turns out to be that two people do not trust each other, or that someone cannot yet do the thing they are being asked to do, or that the conflict is about identity rather than incentive, or that a whole culture has learned to behave in a way no one in it would choose. The chapter covers five: Difficult Conversations, Immunity to Change, coaching frameworks built around GROW, the Trusted Advisor, and Schein's model of organisational culture, plus a section on lightweight relational tools.
This is the mode with the contested lineage the introduction described, psychology, therapy, conflict resolution, adult development, and organisational culture, and contested is not the same as least grounded. The tools also run across a wide range of scale, from a single conversation up to the culture of an entire organisation.
The shape of problem they are ill-suited to: structural problems that have nothing to do with people, individually or collectively. Situations where there is a wrong incentive and no amount of conversation, and no amount of culture work, will fix it. Problems where the right answer is to change the system rather than to work with the people in it.
Difficult Conversations
The 1999 book by Douglas Stone, Bruce Patton, and Sheila Heen※, from the Harvard Negotiation Project, is the most useful tool here for the conversation where you know you must say something hard and do not know how. The move people already know is that a difficult conversation is really three conversations layered together. The move that decides whether it goes well is noticing the third one. The "what happened" layer is where everyone fights, the feelings layer is where the energy actually sits, but the identity layer, what the situation says about whether each person is competent or good or worthy, is the deepest and the one almost always invisible to the people in it. A conversation that keeps escalating past what the surface warrants has hit an identity layer nobody has named, and naming it is usually what lets the other two move.
Epistemic status. This is a structured distillation of negotiation and communication practice rather than an experimentally validated model, but it rests on decades of work at the Harvard Negotiation Project and is consistent with what is known about how people handle conflict and threat. The three-conversations decomposition has strong face validity and is widely reported as useful by practitioners across many fields. Treat it as a reliable framework for structuring your own preparation and listening, not as a predictive theory of what the other person will do.
The core ideas
Every difficult conversation contains three. The "what happened" conversation is about facts, fault, and intent, and it is where most people focus and the least useful work happens, because people disagree about facts when they hold different information and interpretations. The feelings conversation is about the emotions present on both sides, acknowledged or not, and the claim that holds up is that feelings are always present and that refusing to acknowledge them does not remove them, it just lets them drive the conversation from underneath. The identity conversation is about what the situation means for who each person is, whether they are competent or good or worthy, and it is the deepest layer and the one most often invisible to the participants.
Impact is not intent. People argue about intent, "I did not mean to dismiss you," when the issue is impact, "the effect was that I felt dismissed." Conflating them produces defensive spirals that are about neither.
Contribution, not blame. Move from whose fault this is to what each party contributed to the situation. Contribution is not symmetric, since sometimes one party contributed most of it, but the framing opens space for each side to see its own role without being on trial.
Stories, not facts. Each party brings a story built from selectively attended facts plus interpretation plus prior pattern-matching. The work is not to decide whose story is right but to surface both and find what each contains that the other lacks.
How to use it
Before the conversation, write out your three conversations. Your version of what happened, the feelings you are bringing named specifically, and the identity threat for you, what it would mean about you if you are wrong or if you raise this badly.
Anticipate the other person's three conversations too. You will be wrong about specifics, but the exercise prevents being blindsided by a layer you had not considered.
Open by acknowledging that the situation is hard rather than by stating your position. The recommended opening is a third story, the version a neutral observer would tell about the disagreement itself. "I think we see this really differently and I want to talk about it" is a third-story opening. "You did X and that was not okay" puts the other party straight into defence.
Separate impact and intent explicitly when they tangle. Saying "I am not claiming you meant to do this, I am telling you the impact, and those are different" resolves a large share of conversations stalled in arguments about intent.
Listen for what is not being said. Tone changes, topic shifts, over-explanation, sudden withdrawal. When someone reacts far more strongly than the surface warrants, you have hit an unnamed identity layer.
What a well-conducted difficult conversation looks like
Both parties leave understanding the other's story better than they did, even if they still disagree.
The identity layer surfaced for at least one party, even briefly, and feelings were named rather than driving from underneath.
Concrete next steps exist, but the conversation did not rush to them at the expense of understanding, and neither party feels they won.
Anti-patterns
Difficult conversations as performance management, using the framework as a script for delivering a predetermined decision while pretending to be open. People can tell, and it makes the harm worse.
Skipping the feelings conversation because it feels unprofessional, the analytical-thinker default. Suppressed feelings drive everything from underneath. Naming "I am feeling defensive right now" is more professional than letting defensiveness shape what you say unacknowledged.
Identity work as therapy, going deeper into identity than a workplace conversation should. The aim is to surface identity threat enough that it stops driving the conversation invisibly, not to resolve it.
Third-story openings that are not actually third-story, framed so it is clear which side is correct, which the other party sees through immediately.
Stopping at understanding, reaching mutual understanding and then dissolving without producing change. Understanding is necessary but not sufficient.
When Difficult Conversations is the wrong tool
When the issue is structural rather than interpersonal. If two people are in conflict because of genuinely incompatible objectives imposed by the structure, the conversation will not fix it, and the intervention is structural.
When power asymmetry makes openness unsafe. The framework assumes both parties can speak openly, and where there is significant imbalance, a history of retaliation, or ongoing harm, the right move may be to escalate or leave rather than to have a difficult conversation.
When the other party is acting in bad faith. The framework assumes good faith on both sides, and with someone manipulating or harming deliberately it hands them additional tools.
Immunity to Change
Robert Kegan and Lisa Lahey's 2009 book※ is the deepest tool in the developmental mode and the one most structurally adjacent to the Theory of Constraints. The core insight: when someone genuinely wants to change a behaviour and consistently fails, the failure is not weakness or insufficient motivation. The behaviour is protecting something else they also care about but have not named, and the system of competing commitments is functioning exactly as designed.
Epistemic status. The immunity-mapping method is a well-developed practical technique with a substantial body of case experience behind it, and the core mechanism, that a hidden competing commitment can hold a behaviour in place, is a genuinely useful and often revelatory frame. The broader constructive-developmental theory it sits within, Kegan's stages of adult development, is influential but contested in academic psychology: the evidence for the specific stage structure is mixed, most of it was generated by the theory's own developers, studies tend to be short relative to the timescale of development, and different assessment instruments give inconsistent results on the same people. Use the four-column method confidently as a practical tool and hold the developmental-stage theory more lightly.
The core ideas
The immunity map is a four-column exercise. The first column is the commitment, what you want to change, stated as a positive goal rather than a complaint, such as wanting to delegate more effectively. The second is what you are actually doing or not doing that works against it, in concrete behaviours, such as rewriting the team's work or taking back tasks you delegated. The third is the hidden competing commitment, found by imagining doing the opposite of the second column and noticing what feels threatening, then stating the positive form of that worry, such as being committed to never being seen as a manager whose team produces low-quality work. The fourth is the big assumption, what would have to be true for the competing commitment to be valid, such as believing that any quality problem in your team's work means you are a failing manager.
The four columns are a thinking process, not a worksheet, and the fourth column is the work, since the big assumptions are usually unexamined and often wrong.
The immune-system metaphor. The system of competing commitments is like a biological immune response, protecting the person from a perceived threat and working exactly as designed. The competing commitment is a feature whose purpose is no longer well served. The work is not to overpower it but to understand what it protects and update the assumptions that keep it active.
Big assumptions are testable. They are hypotheses, not truths, and they can be tested through small designed experiments. They are usually exaggerations of real but bounded concerns, and testing them safely is what lets them update.
How to use it
Pick a real commitment that has been stuck for a while, something specific to your work where you have genuinely tried and failed. Without a real history there is no contrast between stated commitment and actual behaviour.
Be specific in the second column. "I avoid difficult conversations" is too abstract. "When this person sends me a message that makes me defensive, I draft a reply, decide it is too harsh, and send nothing for three days" is the right grain.
Work the third column by asking what you would be worried about if you did the opposite of the second column. Keep asking until you find something with emotional weight. The surface answer, "low-quality output," usually hides a heavier one, "I will be seen as the manager who did not catch the problem."
Find the big assumption, what would have to be true for the competing commitment to drive behaviour the way it does, stated specifically enough to be tested.
Design small safe-to-fail tests rather than big leaps. The point is not to declare the assumption wrong and act, but to design an experiment that genuinely tests it, safe enough to run and meaningful enough to teach you something.
What well-applied Immunity to Change looks like
The person runs an experiment they would previously have avoided, and comes back with what it actually showed rather than what they expected.
A column gets rewritten as assumptions get tested, so the map visibly changes between sessions rather than standing as a one-time diagnosis.
Behaviour shifts on the original commitment, not just insight about why it was stuck.
Anti-patterns
Treating the third column as a confession of weakness, which makes people refuse to look at it. Competing commitments usually protect real values in outdated ways.
Skipping the fourth column and trying to overcome the competing commitment by willpower, which leaves nothing to test and the immune system intact.
Big assumptions that are too abstract to test, such as "I assume I have to be perfect," rather than a specific testable claim about a specific consequence.
Treating it as a one-shot exercise, achieving insight and changing nothing, when the framework requires the experimental loop.
Doing it alone for sticky cases. The big assumptions are invisible to the person holding them precisely because they feel like reality, so a coach or thinking partner who can ask the surfacing questions helps enormously.
When Immunity to Change is the wrong tool
When the situation is genuinely external rather than internal. Sometimes you cannot delegate because the team is too junior, not because of a competing commitment, and the method will manufacture an internal explanation for an external constraint. Check the structural and capability layers first.
When the person is not yet ready to examine themselves. The method requires real willingness to look at one's own contribution, and for people in crisis or genuinely unmotivated to change it is counterproductive.
For surface-level habits, where it is overkill and ordinary habit-formation tools fit better. The method is for patterns that have resisted years of attempted change.
Coaching frameworks (GROW and its relatives)
Coaching frameworks are structured ways to help someone think through a problem and arrive at their own next step, rather than being told what to do. GROW, developed by John Whitmore and colleagues in the late 1980s and set out in Coaching for Performance※, is the most widely used and the easiest to learn, which makes it the natural anchor for a family of related approaches. The reason coaching belongs in the developmental mode is that its central bet, that people commit to actions they reach themselves far more than to actions imposed on them, is a claim about human motivation, not about analysis.
Epistemic status. This is the tool in the chapter with the strongest empirical backing, which is worth stating plainly given the chapter's reputation. GROW itself is a practical structure distilled from coaching practice rather than a validated model, but workplace coaching as a whole has meta-analytic support: it improves goal attainment, performance, and well-being across studies※. The crucial finding for how you use it is that the coaching method does not significantly moderate the effect※ (GROW, cognitive-behavioural, and solutions-focused approaches produce broadly equivalent results), which means the effect comes from the quality of the relationship and the questions, not from the particular framework. Treat GROW as a reliable scaffold for a useful conversation, and treat the underlying skill, asking good questions and genuinely not supplying the answer, as the thing that actually matters.
The core ideas
GROW is four stages, usually walked in order though good coaches move between them fluidly. Goal is what the person wants from the conversation and from the situation, stated as "what would you have instead" rather than a problem to avoid. Reality is the current situation in honest detail, what has actually been tried, what is actually true, lay out the whole situation and not just the story the person walked in with. Options are the possible courses of action, generated by the person rather than the coach, trying to remove and surface the hidden constraints to prevent any pre-filtering, ideally laying out several before any is evaluated. Will, sometimes called Way Forward, is the specific commitment, what the person will actually do, by when, and how committed they genuinely are on a scale they name themselves. Treat "anything below an eight" as a sign that it won't happen and dig in to find the real obstacles, possibly looping back to Options.
The discipline that makes it work is that the coach asks rather than tells. The whole structure is a container for questions whose answers the coach does not supply. The moment the coach starts steering toward their own preferred option, it stops being coaching and becomes advice with extra steps, and the person's commitment drops accordingly.
Question quality is the real engine. "What have you already tried?" surfaces more than "have you tried X?" "What would you do if you knew you could not fail?" opens the Options stage in a way that "what are your options?" often does not. The framework gives you the stages; the skill is in the questions inside them.
The Relatives
Everything that matters about coaching is in GROW and in the discipline of asking rather than telling; the rest of this section is range, not foundation. The relatives below are variations you borrow from when GROW runs out of reach, and the chapter's own epistemic note is the reason to hold them lightly: the evidence says the method barely moderates the effect, so the schools' decades of differentiation matter far less than relationship and question quality. Read the table for when to reach past GROW, and the notes after it only if you want the texture.
| Approach | The question it takes most seriously | Reach for it over GROW when |
|---|---|---|
| GROW (Whitmore) | "What do you want, and what will you do toward it?" | The default, there is a specific goal to tackle |
| Co-Active (Whitworth and colleagues) | "Who are you trying to become, beyond solving this?" | The issue is the person, not a discrete problem |
| Solutions-Focused (de Shazer, Berg) | "When is the problem already not happening?" | Reality keeps spiralling into the problem and stalls |
| Humble Inquiry (Schein) | "Am I asking from real curiosity, or do I already know the answer?" | You catch yourself asking questions you already know the answer to |
| Coaching Kata (Rother) | "What do you expect to happen, and when will you check?" | The work is improvement toward a defined target condition |
Co-Active (Whitworth and colleagues)※ starts from the stance that the person is already creative, resourceful, and whole, and attends the person rather than the task. Its useful additions over GROW are three questions: whether the goal is even theirs (Fulfilment), whether the single perspective they are treating as reality is the only one available (Balance), and whether the work is to stay with a hard experience long enough to learn from it rather than rush past it (Process). It also names the inner critic as the Saboteur, a part to be examined rather than believed, whose claims are in effect the testable big assumptions of Immunity to Change.
Solutions-Focused (de Shazer, Berg)※ refuses to study the problem at all, on the bet that you do not need to understand a problem to build a solution, which puts it in direct tension with GROW's insistence on an honest Reality stage. It hunts for what is already working, through the exception question, the miracle question (if you woke and this were solved but did not know, what is the first small thing you would notice), and the scaling question (zero to ten, what makes it a four and not a two). Its risk is sharp: aimed at a real structural problem, a broken incentive or an untenable role, its relentless "when is it already better" reads as gaslighting, and it never reaches the mechanism, which is Immunity to Change's territory. The two sit at the chapter's poles, and knowing which a person needs is half the developmental skill.
Two of the five are not quite peers. Schein's Humble Inquiry※ is less a framework than a stance underneath all of them, the discipline of asking from genuine curiosity rather than asking questions whose answer you already have in mind. The Coaching Kata's question is the predict-and-check loop from the introduction's shared spine; it lives in the operating chapter as the engine of the Improvement Kata, and from here it is simply coaching with the question set clamped to one domain.
All this divergence then runs straight into the entry's own epistemic note: method does not moderate the effect. The schools spent decades differentiating, and the evidence says the differentiation matters far less than relationship and question quality. So the practical use of the relatives is to widen your range. More depth when GROW stays too shallow, exceptions when Reality spirals, the Saboteur when the block is an inner critic.
How to use it
Notice first whether the situation is even a coaching situation. Coaching fits when the person has the capability to find a good answer themselves and the value is in helping them reach and own it. It does not fit when they genuinely lack the knowledge, in which case teaching is honest and coaching is a frustrating game of guess-what-I-am-thinking.
With a new relationship, contract before you coach. Name that you will mostly ask, why, and that you will say so when you switch to giving your own view.
Hold the Reality stage longer than feels comfortable. The most common failure is rushing from Goal to Options without an honest account of the current situation, which produces plans built on the story the person told themselves rather than on what is actually happening.
Make the person generate the Options. If you supply them, you have switched from coaching to advising, and the commitment that coaching exists to produce evaporates. Several weak options the person generated are more useful than one strong option you handed over.
End on a concrete Will, and check the genuine level of commitment rather than the polite one. "On a scale of one to ten, how likely are you to actually do this?" and then, if the answer is below eight, "what would make it a nine?" surfaces obstacles the rest of the conversation missed.
What well-applied coaching looks like
The person does most of the talking, and the coach's turns are mostly questions rather than suggestions wearing question marks.
The Reality stage produced something the person had not articulated before, rather than confirming what they already believed.
The person leaves owning a next step they set themselves and acts on it, which is the commitment coaching exists to produce rather than the compliance that follows advice.
Anti-patterns
Advice in question form, the leading question that steers toward the answer the coach already has in mind. People recognise it immediately and it produces compliance rather than commitment.
Skipping Reality, rushing to options and action before the current situation is honestly mapped, which builds the plan on a fiction.
Coaching when teaching is needed, withholding knowledge the person genuinely lacks in the name of letting them find it themselves, which is just frustrating.
Framework as ritual, walking the four letters mechanically while asking weak questions, which mistakes the scaffold for the skill.
Coaching upward without consent, deploying coaching questions on a peer or manager who has not asked to be coached, which reads as manipulative or condescending.
Reaching for depth that was not invited, running Co-Active-style values or Saboteur work on someone who came with a discrete problem and a contract for help with it, which is how the developmental tools earn their reputation for overreach.
When coaching is the wrong tool
When the person lacks the capability or knowledge to reach a good answer, where honest teaching or direction serves them better.
When the situation is an emergency, where there is no time for the person to work it through and someone needs to make a call.
When there is a genuine power asymmetry that makes the questions feel like a test rather than an offer of help.
When the real issue is structural or interpersonal rather than within the person. Coaching an individual to cope better with a broken incentive or a damaged relationship can quietly shift the burden onto them for a problem that is not theirs to solve, which is the developmental mode's version of treating a system problem as a personal one.
When there is no felt goal or no felt gap yet. A person who cannot say what they want, or who sees no problem to work because the feedback that would reveal one is missing, is in the orienting register that precedes coachable work, treated in this chapter's closing section. Coaching has nothing to take hold of until that groundwork is done.
Coda: Before there is a problem to work
Every tool in this chapter assumes a problem to be worked. The difficult conversation needs something hard both parties can name; Immunity to Change needs a commitment the person has tried and failed to keep; coaching needs a goal, or at least a gap between where the person is and where they want to be. Without that, or a rough sense of which way is up and a willingness to look the frameworks can be applied correctly but nothing will move. Two common ways it can fail:
The first is the person who says, in effect, I do not know what I want. The direction is missing, not the willingness, and the tools stall because they all need a target. Asking harder what the person wants won't work because there's no signal in that question yet. Instead the move is to lower the cost of smaller moves and building the habit of noticing which ones pull, mirroring the actions for Cynefin in the chaotic mode on a personal level. The direction is not found by introspection, but generated by action and then noticed.
The second is the person for whom everything is fine. Here there is no felt gap at all, because the feedback that would reveal one is missing, and from inside their model there is simply no problem to work. The Immunity to Change entry touches this when it notes the method needs someone willing to look, but here they are not yet willing, because they cannot yet see.
Why the feedback is missing decides the move. Sometimes nobody has ever told them, and one clear, specific, kind observation (here is how this lands, which you cannot see from where you sit) creates the workable gap. Sometimes the feedback has been there and has not landed, which is closer to Immunity to Change, because an "everything is fine" held against contrary signals is usually protecting something. But it still needs them willing to look, so build readiness rather than mapping their immunity on day one. And sometimes they are right from where they stand, and the misalignment is that others hold a standard nobody has stated, in which case the missing thing is the organisation's feedback loop, the intervention is structural, and coaching them to "be more self-aware" is only shifting the burden without resolving the gap.
Both versions lack the same thing. The person who cannot find a direction and the person who cannot see a gap are missing the signal that comes only from contact with the world and honest feedback on the result. In the first it is present but untuned; in the second it never receives input. The orienting work here is the work of supplying that feedback, or the contact that produces it, before any framework has something to bite on.
The Trusted Advisor
The 2000 book by David Maister, Charles Green, and Robert Galford※, with the work Green carried forward afterward in Trust-Based Selling and, with Andrea Howe, The Trusted Advisor Fieldbook※, is the developmental mode's account of a precondition the other tools assume: that the person in front of you trusts you enough to let you work. A difficult conversation, a coaching contract, an immunity map all need standing, and this is the one well-developed treatment of how that standing is earned rather than assigned. It belongs in the developmental mode because its subject is the relationship itself, a claim about trust between people, not about analysis or execution. Its native setting is the external advisor and the client, and the reading that matters here is the transfer of that machinery to the internal case: how anyone working sideways or upward, with real expertise and no automatic seat, becomes part of the room.
Epistemic status. This is practitioner lore, seasoned consulting experience turned into three clean heuristics rather than tested theory. The models have strong face validity and are widely reported as useful, and Green's firm has gathered self-assessment data on the trust equation over many years, but that is a description of how people rate themselves, not evidence that the equation predicts who gets trusted. It earns a little more than its provenance because the decomposition rhymes with the empirically grounded model of organisational trust※, where trustworthiness resolves into ability, benevolence, and integrity, with credibility tracking ability and the reliability-intimacy-low-self-orientation cluster tracking the other two. Treat the equation as a reliable diagnostic vocabulary, treat the self-orientation insight as the durable contribution, and treat the staged process and the principles as useful structuring devices rather than measured findings.
The core ideas
The trust equation. Trustworthiness breaks into four parts: credibility (your words, what you know), reliability (your actions, whether you do what you say), intimacy (the safety someone feels confiding in you), and self-orientation (how much your attention is on yourself rather than on them). The first three sit in the numerator and self-orientation sits in the denominator, which is the whole point, because it governs the rest. High self-orientation, the visible interest in your own gain, your own cleverness, your own discomfort, divides down everything the numerator earns. The single most useful claim in the apparatus is that the largest lever on being trusted is lowering the denominator, and that most people pull the wrong one.
The denominator is the lever. People trying to earn a seat over-invest in credibility, in proving they are clever enough to be there, and under-invest in lowering self-orientation, in making the other person's problem genuinely more salient to them than their own standing. You get into the room by caring less about being in it. This is the coaching entry's discipline, that the moment the coach steers toward their own answer the commitment drops, raised from the scale of one conversation to the scale of a relationship.
Trust is built in conversations, in an order. Green's staged process, engage, listen, frame, envision, commit, is a claim that trust accumulates through a sequence whose early steps are the ones people skip. The neglected, high-leverage moves are listening past the presenting problem and framing the real issue, including the awkward one nobody has named, before any solution is floated. Rushing to the answer, what Green elsewhere calls the answer trap, is the characteristic failure of the capable.
Trust is reciprocal, and someone goes first. Trust requires a risk when we are risk-averse, and it is mutual: there is the trustworthiness you carry and the trusting the other party has to extend, and the relationship only forms when someone takes the first risk. The advisor usually has to be the one, through a candid observation, a piece of genuine disclosure, the naming of the thing in the room. This is the actionable core of becoming part of the room: standing is granted in response to a risk taken, not accumulated through credentials and waited out.
The principles behind the moves. At the organisational scale the same idea resolves into four habits: other-focus, collaboration as a default rather than a tactic, a relationship-over-transaction horizon, and transparency. They are worth noting because they feed straight back into the equation, transparency in particular both raising credibility and lowering self-orientation by keeping no secrets.
How to use it
Score your own equation for a specific relationship. Take one stakeholder and rate, as they would, your credibility, reliability, intimacy, and self-orientation. The exercise almost always locates the gap in the denominator or in intimacy rather than in credibility, which is where the instinct says to work.
Work the denominator first. Before adding evidence of your competence, remove the signals of self-interest. The fastest way to lose a room is visible concern with your own standing in it.
Slow down at listen and frame. Resist moving to a solution until the real problem, including the part no one has said aloud, has been named and recognised. The naming is often the moment trust forms.
Take the first risk deliberately. Offer the candid read, or the honest "here is what I am unsure of," that invites the other party to reciprocate, rather than waiting until you feel trusted to speak freely.
Spend the relationship slowly. Treat standing as a stock built over many interactions, not a balance to draw down to win a single point, which is the relationship-over-transaction principle applied in the moment.
What well-applied trust-building looks like
You are sought out rather than tolerated, brought the real problem instead of the sanitised version, and asked before decisions rather than informed after them.
You can name an uncomfortable truth and have it land, because the relationship can carry weight the credentials alone could not.
Your self-orientation is low enough that you will, visibly, tell someone something against your own short-term interest, which is the single most trust-building act available and the hardest to fake.
Anti-patterns
Trust as technique. Running the moves instrumentally, to manufacture standing you then mean to use, is high self-orientation wearing intimacy's clothes, and people feel the calculation even when they cannot name it. The safeguard is built into the model: the one term you cannot fake into existence is the denominator, because faking it is self-orientation.
Credibility-stacking. Trying to earn the room by piling up evidence of expertise, working the numerator while the denominator quietly sinks the score.
Intimacy as oversharing. Mistaking the safety someone feels confiding in you for a licence to disclose, which forces a closeness the relationship has not reached and reads as a different kind of self-orientation.
The answer trap. Skipping listen and frame to deliver the solution, which is how capable people signal that their own competence matters more than the other person's actual problem.
Confusing the two Maisters. The operating chapter's Maister is on whether an organisation will do what it knows it should; this one, with Green and Galford, is on whether you will be allowed to help it. Reaching for trust-building when the real blocker is commitment, or the reverse, misreads the problem.
When the Trusted Advisor is the wrong tool
When you already have standing. Among people who trust you, running trust-building is noise, and the chapter's actual tools, the difficult conversation and the coaching stance, are what the situation needs.
When the deficit is competence, not trust. The numerator is in the equation for a reason, and low self-orientation with nothing to offer is merely pleasant. Sometimes the honest answer is that you have not yet earned the seat on the merits.
When the context is far from its origin, or the power is too steep. The machinery is tuned to advisory and selling relationships, and the transfer to internal, lateral, and upward standing is real but needs translation. In steep hierarchies or bad-faith settings (the closing chapter's gaps), the candour that trust-building runs on is exactly what is unsafe, and no amount of it overcomes a structure that punishes the first risk.
When the problem is structural. Earning trust will not fix a broken incentive or an untenable role, and trying to relate your way through a system problem is the developmental mode's version of treating a structural fault as a personal one.
Schein's Model of Organisational Culture
Edgar Schein, a social psychologist at MIT Sloan, gave organisational culture its most-used academic model, set out first in a 1984 article※ and then in Organizational Culture and Leadership※ across five editions before his death in 2023. It has two halves worth separating from the start: a way to read a culture, and an account of how leaders, mostly without meaning to, build one.
Epistemic status. A conceptual lens rather than a validated theory, in the same family as Cynefin: widely taught, durable over decades, and convincing to anyone who has watched stated values diverge from how a place actually behaves, but not predictive and not measured. Its sharpest weakness is internal. The deepest level, the basic assumptions, is defined as unconscious and can only be inferred from the visible levels, which makes it hard to falsify and easy to read in a circle, explaining a behaviour by an assumption you read off that same behaviour. The model also treats a culture as more single and unified than most large organisations are; subcultures are the standing caveat. Trust the three levels and the embedding mechanisms as a vocabulary and a structure for looking, and hold any confidence that you have read the assumptions correctly more loosely.
The core ideas
Culture, for Schein, is the set of shared assumptions a group learned while solving its problems, assumptions that worked well enough to be passed to newcomers as the correct way to perceive, think, and feel. The definition does two useful things. It makes culture a product of a group's history rather than of its current personalities, and it explains why culture is invisible to the people inside it: once an assumption is taught as simply correct, it stops looking like a choice, the way water does not look like anything to a fish.
The spine of the model is three levels, sorted by how visible each is to an outsider.
Artifacts are everything you can see, hear, and feel: layout, tooling, dress, rituals, language, how meetings run. Easy to observe, treacherous to interpret, because the same visible thing can sit on top of opposite assumptions.
Espoused values are what the organisation says about itself: stated strategy, goals, the values on the wall. Real and worth knowing, but claims, sometimes describing how the group works and sometimes only how it hopes to.
Basic underlying assumptions are what Schein calls the essence of culture: the taken-for-granted beliefs about people, time, hierarchy, truth, and what counts as good work that actually drive behaviour. They are the hardest to see and the place durable change has to reach.
The point of the three levels is the relationship between them. You cannot observe assumptions directly, so you read upward from what you can see, and the gap between the espoused values and the artifacts is the cheapest route down to the assumption underneath. A place that says it prizes innovation while reliably punishing the people whose bets fail is telling you, in that gap, what it actually believes about risk.
The second half of the model is how a culture forms, and how leaders embed one whether they intend to or not. Schein divides the levers in two. The primary mechanisms carry most of the signal: what leaders pay attention to and measure, how they behave in a crisis, how they spend money, what they reward, and whom they promote or remove. The secondary mechanisms reinforce whatever the primary ones establish: structure, procedures, rituals, physical space, the stories a place tells about itself, formal statements of values. When the two disagree, a stated value of teamwork against a bonus paid for individual heroics, the group believes the reward and ignores the statement. A culture is built far more by what leaders do under pressure than by what they declare.
Finally, a large organisation is never one culture. It splits into subcultures, and Schein names three that recur, roughly the people who run the work, the people who design the systems, and the executives who answer to finance and the outside. A great deal of what gets blamed on personalities or bureaucracy is really two subcultures holding different assumptions about risk or quality, and failing to align.
How to use it
Read a culture from the outside in, in order, and resist interpreting until you have looked.
First, collect artifacts as an observer rather than a judge. Sit in meetings, read the onboarding docs, notice the language and what the space is arranged around, and write down what you see before deciding what it means.
Second, gather the espoused values from the official sources: the strategy deck, the values page, what leaders say at the all-hands.
Third, work the gaps. List the places where the artifacts contradict the espoused values. Each contradiction points at an assumption, and the contradictions are the actual data, not an embarrassment to explain away.
Fourth, test a candidate assumption against a critical incident rather than by asking. People cannot report their own assumptions, so "what do we assume here" just returns the espoused values, while "walk me through the last time a release broke in production, who did what" surfaces the real assumptions about blame and ownership inside the story.
To change a culture, name the assumption you want to move, then change the primary mechanisms, what gets measured, what gets rewarded, how the next crisis is handled, who gets promoted. Restating values does almost nothing on its own, because the group is reading the mechanisms, not the poster. Changing visible artifacts can work upward over time, but slowly, and only when the mechanisms back it.
And before treating a recurring collision between two groups as a personality problem, check whether you are looking at two subcultures with different assumptions, which is a more tractable thing to work on than two difficult people.
What well-applied Schein looks like
A change effort moved measurement, rewards, or who got promoted, and the assumption it targeted visibly shifted, rather than a values poster going up while nothing changed.
A recurring collision between two groups got re-read as two subcultures with different assumptions, and working the assumptions defused it where treating it as a personality clash had not.
A real assumption surfaced from a specific incident, walking through the last time a release broke rather than reading the values page, and it explained behaviour the espoused values could not.
Anti-patterns
Mistaking artifacts for culture, redesigning the office or rewriting the values and calling the culture changed, while the assumptions underneath go untouched and quietly win.
Reading the assumptions off too fast, especially from outside, and projecting your own culture's meaning onto another's artifacts.
Treating the culture as one thing, designing a single intervention for an organisation that is really several subcultures, so it lands in one and bounces off the rest.
Using the depth as an excuse, treating assumptions as too deep and unconscious to touch. They are reachable through the visible levels and movable through the mechanisms; the depth means work carefully, not give up.
Using the depth as an excuse, treating assumptions as too deep and unconscious to touch. They are reachable through the visible levels and movable through the mechanisms; the depth means work carefully, not give up.
When Schein is the wrong tool
When the problem is not actually cultural. A repeated behaviour can come from a broken incentive, a missing skill, or one bad structure, and excavating assumptions when the answer is a misaligned bonus is slow and expensive.
When you need a quick decision. The model works over the months and years on which assumptions form and shift, so for anything urgent it points at a layer you cannot move in time.
When you lack the access or standing to reach the deeper levels. Surfacing assumptions takes time inside a group and enough legitimacy to ask about real incidents honestly. From outside, or early, you will mostly collect artifacts and espoused values, and should not pretend otherwise.
Coda: Schein, Westrum and the stage-model writers
Schein is the descriptive anchor of a larger body of writing that takes the group, not the individual, as its unit, and most of the rest of it differs from him in one specific way: it adds a ladder. Schein tells you how to read a culture and how it forms, and stays neutral about which culture is better. Writers downstream of him add a direction, one with a mechanism and others with stages forming a ladder.
Ron Westrum※ studied how organisations in high-consequence fields (e.g. aviation, medicine) caught problems before they became a disaster. His definition of a good culture: one that gets the right information to the right person in the right form at the right time. With this reading culture is not values or vibe, it is a property of how information moves through a group, and what matters most is how the organisation treats whoever carries bad news.
Shoot a messenger once and you have not disciplined one person, you have taught everyone watching to stop reporting, which strips the organisation of its ability to see the next problem coming. That is a feedback loop of exactly the kind this part of the collection describes: suppressed information produces undetected problems, which produce failures, which produce more blame, which produce more suppression. Westrum's term for what a healthy culture preserves is requisite imagination, the capacity to anticipate what might go wrong, which a generative culture cultivates and a pathological one destroys, because the people with that imagination are the ones it punishes for voicing it.
His model is usually reduced to three culture types along six dimensions of how information is handled:
| Pathological (power) | Bureaucratic (rules) | Generative (performance) | |
|---|---|---|---|
| Information | hoarded | may be ignored | actively sought |
| Messengers | shot | tolerated | trained and welcomed |
| Responsibility | shirked | narrow, "not my department" | shared |
| Cross-team cooperation | discouraged | allowed but neglected | rewarded |
| Failure | scapegoating | finding who broke which rule | inquiry |
| Novelty | crushed | creates problems | implemented |
You do not assess these by asking, since people report their espoused values rather than their assumptions. You read them off how the last serious incident was actually handled, which is the same critical-incident move Schein's method uses. The caveats are the ones every typology carries: real organisations are mixtures, subcultures sit at different points, and the measure is survey-based, so the three types are a strong diagnostic vocabulary rather than boxes an organisation sits cleanly inside.
The stage-model writers take the same group-level unit and add an axis of maturity climbing from worse to better.
Three that often come up. Patrick Lencioni's Five Dysfunctions of a Team※ stacks trust, conflict, commitment, accountability, and results into a pyramid in which each layer fails without the one below it. It is fable-based and has essentially no independent validation, but is useful as a checklist of the order in which teams. Tribal Leadership※, by Logan, King, and Fischer-Wright, keys five cultural stages to the language a group uses about itself, from "life sucks" through "I am great and you are not" to "we are great," and casts leadership as nudging a tribe up a stage; it rests on one proprietary study and sits in the Spiral Dynamics family. Frederic Laloux's Reinventing Organizations※ is the far edge, a colour-coded developmental ladder climbing to a self-managing end-state, built on integral theory, with exemplar companies chosen to fit the thesis and a self-management track record that is mixed once you look past the showcases.
The portable parts are the diagnostics, not the ladders. They are fine prompts for what to check in a struggling team, and how a group talks about itself tells you something about its assumptions, which loops straight back to reading artifacts. What travels less well is the developmental ladder itself. Ranking whole organisations on a maturity scale imports a stage-theory problem: the stages are intuitive, but the evidence for them is thin and largely produced by the people selling the model, and the claim is harder to defend at organisational scale than at the individual one. Read the culture with Schein, Westrum when the question is whether information is flowing, borrow the stage writers' checklists as prompts, and treat their ladders as suggestive rather than as maps you can navigate by.
Lightweight tools
As in the other two chapters, a family of small devices sits alongside the substantial frameworks. The developmental versions are mostly about the fine grain of working with people: giving feedback that lands, naming what is happening in a conversation, and noticing what is making someone defend rather than engage. Several are the heavier tools above distilled to something useful for the moment.
The clearest of these is the set of moves underneath Nonviolent Communication※, which are worth far more than the method's stilted phrasing and work without it. There are four. Separate observation from evaluation: "in the last three meetings you arrived after the start" is an observation, "you are unreliable" is an evaluation, and the first invites engagement where the second invites defence. Name the actual feeling rather than a thought dressed as one, so "I feel hurt" rather than "I feel that you do not respect me." Find the need underneath the position, since a demand for an apology is usually a strategy for meeting a need such as acknowledgement, and the need is the thing to work with. And make a request that can be refused, which is what separates it from a demand. The discipline that makes these work is to practice them on the listening side first, hearing the observation, feeling, and need in what someone else says, and to carry them in your own plain language rather than the formula, which in many engineering and European workplaces reads as alien and costs credibility.
SBI, Situation-Behaviour-Impact※, is the lightest feedback structure there is: name the situation, describe the specific behaviour without interpretation, then state its impact. Its whole value is keeping feedback concrete and off the person's character, "in yesterday's review you cut Maria off twice and the room went quiet" rather than "you were dominating." It pairs directly with the observation-versus-evaluation move above.
SCARF, from David Rock※, is a checklist of five things people feel threatened over when a change lands badly: Status, Certainty, Autonomy, Relatedness, and Fairness. It rests on no neuroscience worth leaning on, but as a prompt for "why is this reasonable change provoking so much resistance" it is fast and often right, and it points at which reassurance to offer. Treat it as a set of questions to ask, not a model of the brain.
The Johari window※ sorts what is known and unknown about a person, split between what they see and what others see, into four quadrants, and its use is to locate blind spots, the things others see that the person does not, which is exactly the territory feedback has to cross. It is a way of seeing why a piece of feedback is hard to hear, not a measurement of anything.
Two relational-adjacent tools live in the diagnostic chapter's lightweight section and are worth reaching across for when the trouble is between people: the Ladder of Inference, for climbing back down to the data each person is actually working from when a conversation has gone strange, and the force-field sketch, for laying out what is pushing for a change against what is resisting it. Both are diagnostic in form and developmental in use.
The same discipline applies as in the other chapters: the format is a prompt, not the work. A well-run SBI delivered with no willingness to be wrong about the impact is still a verdict in a friendlier font.
Comparing the Modes
One problem, three modes
Take a concrete situation. An engineering team that was effective two years ago now ships slowly, misses commitments, and has lost two senior people in six months. The remaining engineers are disengaged. Leadership wants it fixed.
Each mode sees a different problem.
The diagnostic mode asks what is actually going on. A Current Reality Tree would gather the symptoms and push downward to what causes them jointly, and might land on a measurement system that rewards individual ticket throughput, which quietly discourages the collaboration and maintenance work that keeps the team fast. A systems lens would likely name this as Tragedy of the Commons stacked with a reinforcing decline loop: attrition raises the load on those remaining, which deepens disengagement, which drives more attrition. The diagnostic verdict is structural. The incentive system is producing the behaviour, and changing what gets measured would change the behaviour over time.
The developmental mode asks what is going on between and inside the people. The two departures may have followed a specific breach of trust. The disengagement the diagnostic frame reads as a measurement artefact may be grief and resentment. An Immunity to Change lens on the manager might find that their inability to delegate, which starves the team of ownership, protects a competing commitment to never being blamed for a failure. A Schein reading sits between the structural and the personal. The team's culture has learned an assumption, that here you survive by protecting your own throughput, taught by what leadership rewarded when it was under pressure, and the disengagement is that culture protecting itself.
The operating mode asks how to run the team while it is being fixed. It does not wait for the diagnosis. A Grove lens asks what the team is actually producing and whether the manager is spending time on leverage or on inputs. A Team Topologies lens asks whether the senior departures may have collapsed the team below the cognitive load it can hold, leaving a complicated subsystem no one now owns. The operating verdict is about sequence. You cannot analyse or repair a team that is actively bleeding, so first stabilise, then create the conditions for the other two modes to work.
Where they agree, and where they conflict
All three reject the naive reading, that the team is simply underperforming and needs pressure or replacement, and all three locate the cause in the situation rather than in the character of the individuals. Important, because the instinct under pressure is the opposite, to find the underperformers and act on them.
The genuine conflict is about what is fundamental and therefore what comes first.
| Mode | Treats as fundamental | Would act first by | Predicts this failure if ignored |
|---|---|---|---|
| Diagnostic | The structure and incentives | Changing what gets measured and rewarded | Conversations produce warmth the system then grinds back down |
| Developmental | The trust damage and human strain | Repairing trust, surfacing what the departures meant | Structural change is received as one more thing done to them, and fails |
| Operating | Neither, until the team can sustain an intervention | Stabilising and protecting the remaining people | You buy time without fixing anything |
Change the incentive while the team is in acute distress and the developmental mode predicts rejection. Run repair conversations while the incentive still rewards the destructive behaviour and the diagnostic mode predicts the system wins. Stabilise and stop there and both other modes predict you have only delayed the collapse.
The resolution is not to pick one but to recognise that the conflict is about ordering under constraints, which is itself an operating judgement. In most versions of this situation the workable sequence is operating first, then developmental, then diagnostic: stabilise and protect, then repair the trust and surface what the departures really meant, then change the structure once people can receive the change. But the ordering depends on specifics. If the structural incentive is so toxic that it actively prevents stabilisation, you may have to change it first and accept that the change lands badly. The judgement about sequence is where the real skill lives, and no mode supplies it from outside. Hold that thought; the last section is about exactly that judgement and where it actually comes from.
Choosing a mode: a reference
The introduction gave the reasoning behind the choice. This is the compressed lookup, organised by the symptom you notice first. Each row names the mode that holds the binding constraint, the one to act on first, not the only one in play.
| Symptom you notice | Mode | Reach for |
|---|---|---|
| "This keeps happening and I do not understand why" | Diagnostic | A Cloud for a recurring two-sided conflict; a systems archetype if it survives fixes; Deming first if it shows up as a metric moving |
| "I understand it and we still cannot move" | Developmental or operating | A difficult conversation if it sits between specific people; Immunity to Change if it is one person's stuck pattern; leverage and saying no if it is the organisation's inability to focus |
| "The team is exhausted, scared, or grieving" | Developmental, then operating | Stabilise first, then address the human layer. A diagnostic workshop here reads as cruelty |
| "We are busy and producing nothing" | Operating | Grove. Write down the production function and find the real leverage |
| "We are not even asking the right question" | Diagnostic (strategy) | Rumelt if the question is whether a coherent strategy exists; Wardley if it is positional |
| "We cannot tell whether to analyse or just try things" | Pre-sort | Sort with Cynefin before anything else |
| "This decision has to happen today" | Operating | A premortem, then make the call and revisit when there is space |
Two rows are not extra modes. "Diagnostic (strategy)" is the diagnostic mode aimed at a strategy question, and the pre-sort row is the step before any mode applies rather than a mode of its own. With those set aside, the consistent meta-move sits above the table: name which mode the current blocker calls for before reaching for a tool, and watch for the bias of your own preferred mode, since the tool you reach for first is usually the one you are most comfortable with rather than the one the situation needs.
What all three modes miss
While covering a broad range of structure, the three modes still share blind spots:
They assume good faith. Every tool assumes the people involved want, at some level, for things to improve. The Cloud assumes a shared objective; the difficult conversation assumes honest engagement; Grove assumes the organisation is trying to produce something real. None of this holds in organisations captured by bad actors, locked in zero-sum politics, or in decline where the rational individual move is to extract and leave. Applying good-faith tools to a bad-faith situation does not just fail, it hands the bad actors a more sophisticated vocabulary.
They under-serve power. The tools mostly assume participants can speak freely and that the analysis is not constrained by what is safe to say. In steep hierarchies the shared objective is whatever the powerful person says it is, and the difficult conversation is only as honest as the junior party can afford. None of the modes has a real account of working within power structures that distort the analysis itself.
They are weak on the genuinely novel. All three are strongest where there is precedent, stable causation, or a known pattern to match. For a truly unprecedented situation the tools offer a starting vocabulary but not answers, and the right move is closer to research than to diagnosis.
They cannot supply judgement. Every tool tells you how to think about a problem once you have decided which kind it is and which mode to bring. None tells you, from outside, how to make that decision. The collection can sharpen judgement by giving it more options and clearer names, but it cannot replace it.
And then a fifth, which the worked example above also ran straight into "the judgement about sequence is where the real skill lives", meaning: the tools cannot build the expertise that uses them well.
Knowing which mode a blocker calls for, sensing in the first thirty seconds of a stuck meeting that this is identity and not incentive, feeling that a diagnosis is about to fail before you can say why, that is tacit expertise, and the literature on how it actually forms is fairly clear that it does not come from frameworks. It comes from reps in an environment that gives fast, honest feedback. Research on naturalistic decision-making describes how experts mostly do not compare options at all; they recognise a situation as typical of a pattern they have met many times and the workable action comes with the recognition. The same body of work on accelerating expertise, and the deliberate- and purposeful-practice tradition behind it, is consistent on the conditions: repeated exposure to varied real cases, predictions made before outcomes are known, and feedback quick and clear enough to correct the pattern-matcher rather than confirm it.
This frames what this collection can and cannot do. The frameworks are not the expertise. They are scaffolding for the reps, a way to make your reasoning explicit enough that the feedback, when it comes, lands on something specific and corrects it. A practitioner who runs a hundred stuck situations while naming the mode, predicting which intervention will move things, and checking honestly whether it did, will build the judgement the frameworks cannot contain. A practitioner who collects frameworks and never closes that loop will have a richer vocabulary for explaining, after the fact, why the thing that did not work was always going to. The tools earn their place only inside the loop that turns reps into judgement.
Where this collection sits
Beyond naming what the modes miss, it helps to see the shape of the overall box they are in.
One useful framing comes from the research on business expertise: that what expert operators actually carry is not a single skill but a model with three legs: operations, market, and capital. Operations is how you run and improve the thing. Market is the demand you sell into and your position against competitors. Capital is how the whole enterprise is financed and how it sits in the wider economic cycle. The interesting empirical claim attached to this is that the best operators understand all three and the way a change in one moves the other two, and that people who predict business outcomes poorly tend to have a persistent blind spot in one leg.
The entire collection lives in the first leg. Everything in these four chapters is about operations: running and improving an organisation. The market leg (what customers actually want, how competitive position shifts) and the capital leg (cash flow, unit economics, how financing constrains everything else) are real parts of what expert operators reason about, they interact constantly with the operations work these tools address, and are out of scope for this collection. Rumelt and Wardley brush against the market leg, but as diagnostic methods, not as the domain knowledge itself. The point of naming the other two legs is so that when an operations diagnosis keeps failing, you remember to check whether the real constraint was in the operations leg at all.
A closing stance
The argument across the collection has been that organisational problems call for at least three modes of work, and that each mode has tools suited to it.
It is also a simplification, drawn from one vantage and scoped to one leg of a larger picture, and it will serve until it does not. The signs that you have reached its edge are the gaps above: bad faith, steep power, genuine novelty, and underneath them the irreducible matter of judgement, the expertise that only experience in a high-feedback environment will build. When you reach those edges, the move is not to force the situation back into one of the three modes, but to recognise that you have walked off the edge of this particular map.
Knowing when the tool in your hand has stopped fitting the problem in front of you is the one skill the collection most wants to leave you with, because it is the skill every individual tool depends on and that no individual tool can teach. The collection can hand you the modes, the tools, and the vocabulary. Whether they turn into judgement is a matter of how many real problems you take through the loop, and how honestly you check the result.