Tales & Co.

Istanbul — San Francisco

Notes

Diagnosis before solution

6 min read

The Tool Decides Where the Cause Is Allowed to Be

Systemic diagnosis tools are not interchangeable. Each family asks one question, and the question chosen before any evidence is gathered decides which causes the diagnosis can reach at all.

A systemic diagnosis tool exists to stop the cause being placed where the symptom appeared.

Most organizational problems are reported by the function that is suffering them. Sales reports a pipeline problem. Support reports a quality problem. Finance reports a margin problem. Each of those reports is accurate about the symptom and unreliable about the cause, because the place a problem becomes visible is rarely the place it is produced.

A diagnosis that takes the report at face value goes to work on the function that filed it. It interviews that team, pulls that team's data, and produces a set of findings about that team. The work is competent and the finding is usually true: the reporting function is under strain, its process is ragged, its people are tired. It is also the least informative finding available, because strain in the place the complaint came from is the one fact that was known before the diagnosis started.

Where a problem surfaces is a fact about the org chart

Where a problem surfaces says more about reporting lines than about causation. A checkout conversion problem surfaces in the product team because product owns the number and product is the team asked about it in the monthly review. It may be produced three steps upstream: in a risk policy written for a different transaction volume, in a pricing change that no longer matches the acquisition mix, in an incentive that pays for volume the operation cannot fulfil. A systemic tool is a constraint on where a diagnosis is allowed to place the cause — not at the point of complaint, but somewhere on a traceable path that ends there.

Three families of tool are in circulation, and they answer three different questions.

The word systemic is attached to a wide and uneven set of instruments, some of them a century old and some invented for a single client deck. Sorted by the question each one actually asks, there are roughly three families.

  • Alignment models — congruence models, six-box models, seven-element frameworks — ask whether the parts of an organization are consistent with one another: whether the structure matches the strategy, whether the incentives match the stated priorities.
  • Flow models — value stream maps, process walks, handoff maps — ask where work waits, doubles back, or is passed to someone with no authority to finish it.
  • Feedback models — causal loop diagrams, stock-and-flow sketches — ask which behaviours reinforce themselves once started and which correct themselves.

What each family gives up

The three are not substitutes. An alignment model will not find a queue; it has no concept of elapsed time, so a two-week handoff delay and a two-hour one look identical inside it. A flow model will not find a misaligned incentive; it maps what work does, not what people are paid to want. A feedback model will reach both and will also produce a diagram nobody in the room can act on until somebody names which loop to cut. Each buys one kind of visibility by giving up another.

A tool is a hypothesis before it is an instrument

Choosing among them is the same class of decision as choosing among interviews, documents, data and observation — made before any evidence exists, and shaping everything found afterwards. Reaching for an alignment model is already an assertion that the problem is one of consistency. Reaching for a flow model asserts it is one of sequence. The assertion is unavoidable, because a diagnosis has to start somewhere. What is avoidable is leaving it unstated, so that the tool's built-in answer arrives later dressed as a finding.

Every one of these degrades into a template the moment it is filled in rather than traced.

The failure mode is the same across all three families and it is easy to recognize. A team gets hold of a six-box model, runs a half-day workshop, and by the end every box holds three bullet points. The artifact looks finished. It has the shape of a diagnosis, the vocabulary of one, and a page count. What it does not have is a single statement about what one box does to another.

The place a problem becomes visible is rarely the place it is produced.

A filled box records where something was observed. Only a link between boxes records a cause. The same workshop run as a tracing exercise produces a thinner-looking output and a more useful one: four boxes left empty because nothing in them bore on the question, and two arrows between the boxes that remain, each carrying a mechanism written in a sentence a line manager would recognize.

Count the arrows, not the boxes

The test is arithmetic and takes a minute. Count the boxes with content in them, then count the causal statements between them. A diagnosis with twenty populated boxes and no arrows is a survey of the organization's own self-description, and the organization could have assembled it without help. The arrows are the part that was not already known.

A tool has earned its place when it can return a finding nobody wanted.

The property separating a diagnostic instrument from a presentation device is whether it is capable of concluding something the people who commissioned it will not enjoy. A causal loop diagram that traces a delivery problem back to the sales compensation plan is doing its job. So is an alignment model that finds the structure sound and the strategy the thing that does not hold together. Both findings are commercially awkward, and the awkwardness is the evidence the instrument is still live.

Whether a tool keeps that capability is decided by sequence rather than by the tool. Run after the remedy has been named — in a proposal, a budget line, a board commitment already made — even a rigorous instrument narrows to the job of explaining why the named remedy is correct. The diagnosis inherits an answer it did not produce, and the tool becomes the format in which that answer is presented back.

The disconfirming question is the whole test

One question puts an instrument to the test before any evidence is gathered: what would this tool have to show for the leading explanation to be wrong, and is anyone prepared to act on that. A diagnosis with no answer to the first half is not systemic in any useful sense, whatever it is drawn on. A diagnosis with no answer to the second half is a documentation exercise with a good vocabulary.

Where choosing the tool becomes the actual work.

The instruments are not scarce. Most are published, most are decades old, and a competent team can learn any of them in an afternoon. What is scarce is the discipline of naming which question is being asked before picking the instrument that answers it, and of holding the diagnosis open long enough to reach a conclusion the sponsor had not written down in advance.

The part that does not come from the framework

That discipline is what diagnosis before solution means in practice, and it is the part of the work no framework supplies. A tool decides what a diagnosis is capable of seeing; the sequence decides whether it is allowed to say so. Where we run this with a leadership team, it starts with the question the organization has not yet written down, and the choice of instrument follows from that question rather than from habit — consulting, in the order that keeps the finding honest.