The method of diagnosis

Distribuidora Norte asked for a churn model. As usual, the request arrived with the solution already chosen, and the real problem sat one step further back: incentives that blocked information sharing among the salespeople. The work of sociotechnical diagnosis is to cover that distance, from the request to the problem, and this chapter explains how it is done. It is the point where a method either earns its keep or gives itself away. Concepts of our own defines the diagnosis and The four links places it as the deliverable of link 1; what follows is its procedure.

The chapter organizes it into principles, phases and a deliverable, without turning it into a checklist. Its core is partly and irreducibly tacit, and that tension is part of the method. A warning at the outset: almost everything that follows is a construction of the paradigm, a way of working of its own and not the finding of any author. The currents that ground it are in Authors and currents; here they are cited only where they support a step.

The Distribuidora Norte case (the same story told in The four links) accompanies the protocol as a contrast, not as a template. When the company comes back a year later, with delivery routes and dashboards (SMEs), the five readings will give different answers, but the order of the protocol will be the same.

What it is and what it delivers

The sociotechnical diagnosis is the reading of the organization done before proposing or touching any technology. It does not describe systems. It describes the human fabric that will receive them (power, incentives, real processes, resistance, the situated meaning of the data) and, on that basis, rules on where AI pays off and where it only destroys value.

Its output is not an opportunities report but the document that conditions every link that follows. If link 2 builds, it builds what this diagnosis identified; if link 3 models the data, it models it for the decision this diagnosis pointed to; if link 4 designs the AI, it designs it for the person this diagnosis made visible. That is why it is the precondition of the project and not merely its first step. A mistaken diagnosis does not delay the project: it points the whole thing in the wrong direction, and the wrong thing ends up being built well, which is the most expensive way to fail.

The deliverable is twofold. On one side, a verdict: where it really hurts, what can change and what cannot, who gains and who loses, where AI pays off. On the other, a maturity profile grounded in field evidence, which is its measurable face. The verdict provides the account and the judgment; the profile, the measurement and the priorities. A verdict without measurement is unfalsifiable consulting, and a measurement without a verdict is a number with no story. Together, the number becomes auditable and the story, actionable. → IMIA — the maturity instrument.

Three principles

Three principles govern the whole protocol. They work as conditions, not as advice: if one is broken, the diagnosis is compromised, however neat the phases turn out.

The first is read before touching, the rule from the thesis that maturity is measured first and technology chosen afterward. In the diagnosis it means that no solution is proposed, or even hinted at, until the reading is complete. Proposing early contaminates the listening: people start responding to the imagined solution instead of describing their work.

The second is separate the declared problem from the real problem. What the organization asks for is almost never what hurts it. The declared problem is a solution someone has already imagined (“we need a chatbot”, “we want a dashboard”). The real one is what that solution is trying to cover up, and it usually sits one or two steps further back: a broken process, a twisted incentive, data that lies. The diagnosis does not take the request at face value; it treats it as the first symptom and not as the statement of the problem.

The third holds that the participation of those who do the work is requirements engineering, not courtesy. Listening to the people who run operations is not a gesture of good change management: it is where the true requirements come from. It is the corollary of Mumford’s ETHICS method¹: a design that does not involve those who will use the system produces systems that people sabotage, avoid or misuse. A requirement that did not come from listening to a real user is an assumption in disguise, and it is flagged as such.

Beneath all three runs an epistemic principle: much of the knowledge being sought is tacit. “We know more than we can tell”, in Polanyi’s formula². That is why the techniques do not aim to get people to declare what they know, because they cannot, but to watch them work and read between the lines.

The protocol: five readings

The protocol consists of five readings in order of priority. It is not a rigid schedule, because it iterates: a resistance that surfaces sends you back to reread power, and an odd piece of data sends you back to observe the process again.

The first is the reading of the people, through interviews and observation, in three rings. The first ring is whoever decides and sponsors, who supplies the declared problem and the formal power. The second is whoever does the work every day, who supplies the real process; this is the most valuable source and the one least interviewed in bad diagnoses. The third is whoever ended up in the middle or at the margin, who supplies the friction between areas and, quite often, the resistance nobody else names.

None of them is asked “what problem do you have?”, because that question returns the declared problem. Instead, one asks “tell me what you do on a normal day, step by step”. Or “what part of your work would you not hand over to anyone?”, which guards against automating what the person sees as the core of their value, which is where sabotage is born. Or “when the system fails, what do you do to get the work done anyway?”. That shortcut, the workaround, is the direct trace of the real process: expert knowledge encoded in a practice nobody wrote down, and an open question about why it is needed.

Tacit knowledge is not asked about; it is inferred. It shows up in the workaround, in the exception that “So-and-so always handles”, in the discomfort at a simple question. When it surfaces, the response is to observe, not to keep asking.

The second reading is the process map, drawn twice. One is the formal map, the one in the manual and the org chart. The other is the real one, which the interviews reconstruct with its shortcuts and its undocumented steps. The gap between the two is the finding, not a defect to be fixed in a hurry. It shows where the formal process is dead, where tacit knowledge is holding up the operation and, above all, where automation should not happen yet: automating the formal process while people work by the real one is automating a fiction. If there are event logs from an ERP or a workflow system, process mining can contrast both maps with evidence. Always as a complement to observation and not a substitute, and with privacy governance in place before any analysis.

The third is the map of power and incentives. Every technological change redistributes power, visibility and work, and the diagnosis makes this explicit before the change does it the hard way. It identifies who gains (the natural allies), who loses (informal power, a role that justified it, a monopoly over some knowledge) and who controls resources and agendas, which does not always match the org chart. Those who stand to lose do not resist out of irrationality but out of rationality, and their resistance is predictable and legitimate. That map is the raw material of translation, because an interest that was never mapped cannot be translated. → Authors and currents.

The fourth reads resistance as information, not as obstruction. Those who resist almost always know something the sponsor does not. They may know that the process has an exception the new system does not account for, that the data the AI will rely on does not mean what management thinks, or that there was already a failed attempt nobody mentions. Before trying to overcome a resistance, it is read as a hypothesis, and depending on what it reveals it calls for a different response:

• If it is knowledge (“this won’t work because…”, with a valid reason), it is a missing requirement and gets incorporated.
• If it is loss, because whoever resists loses power, it is a problem of transition design and not of communication.
• If it is a scar (“we already tried something like this and it went badly”), it is the debt of a previous attempt, and it must be dug up before proposing anything.

To design the response, it helps to cross those three readings with the channel of intervention: cognitive, emotional, pragmatic or political. Communicating more does not help if the blockage is pragmatic, and negotiating power is not enough if the blockage is only a lack of training.

The fifth is the reading of the data. The question is not “what is its technical quality?” but “does it say what people believe it says?”. Well-typed data with no nulls can lie, because its meaning depends on a context that was lost. That is why it is traced back to the human act that produces it: who enters it, when and with what incentive. A “closing date” field filled in when it suits the bonus, rather than when the deal actually closes, is data that lies and the trace of a badly incentivized process. The categories the organization uses to record the world are also audited, because a model trained on a badly drawn category inherits its blind spot and amplifies it at scale. Without a business-side data owner who answers “what does active customer mean?”, and without an audit by dimension (accuracy, completeness, consistency, timeliness, validity, uniqueness), the diagnosis inherits metric anarchy before any model exists. This reading is also an early bias check.

The five readings at Distribuidora Norte (first pass)

As an exercise, not a template, this is how the readings would look for the initial request for at-risk customer alerts:

For an immediate predictive model, the verdict would be not yet, or destroys value if it competes with the salesperson’s incentive. For a tool that gives power back to the salesperson, it would be pays off, with conditions on IMIA’s data dimension (D2). That judgment is what IMIA later quantifies.

Field signals (SME)

In SMEs, the protocol adds questions and observations drawn from recent evidence (Amanollahnejad et al., 2026):³

• If the technical lead were gone, would this keep going? Detects champion dependency: all digital progress tied to a single person.
• Where is the decision really made: in the system, in a meeting, in an informal conversation? Names the coffee economy: legitimate decisions that do not go through the org chart.
• Which report would you use for an irreversible decision? If nobody agrees on the number, there is epistemic uncertainty and it is not yet time to model.
• If strategy calls for innovating with AI, what happens to someone who makes a mistake or tries something different? Reveals a culture-strategy misalignment (Schein; Gupta et al.).
• Taking inventory of manual exports and hand re-keying of data shows the real sociotechnical bricolage: how operations actually hold together today, beyond the official diagram.

Broad engagements

In larger transformations (an ERP rollout, a data platform, a multi-year programme), the diagnosis works through several layers before proposing a solution. It reviews processes, formal and real; data, what it means and who looks after it; portfolio strategy, which projects compete for the same resources; infrastructure and continuity, what happens if something goes down on a Friday; and the minimum legal frame, what the sector’s regulation requires. It documents the assumptions of the initial brief and compares serious alternatives (do nothing, move incrementally, transform all at once) without selling technology for its own sake.

If change management accompanies the intervention, four layers need measuring, not only the easiest one: outcome (did what mattered improve?), delivery (was what was promised done?), real adoption (do people use it in operations?) and consolidated capacity (can the organization sustain it without the consultant?).

The deliverable

The verdict has fixed sections. The form is stable so that the judgment is comparable and auditable across organizations; the content belongs to each case. It includes the real problem versus the declared one, the formal versus the real process map, the map of power and incentives with the possible coalition and the pockets of resistance, the data reading with the categories to audit before modeling, the maturity profile with its roadmap and, at the center, the verdict proper.

That center issues one of three verdicts for each candidate opportunity. Pays off when the process is understood, the data is faithful, someone gains and the resistance is manageable. Not yet when the opportunity is real but a condition is missing, in which case it says which one to unblock first. Destroys value when automating would amplify a broken process or data that lies, or would dismantle critical tacit knowledge; in that case it is not done, and the reasons are explained.

The value of the method lies above all in that third verdict. A diagnosis that only finds opportunities is suspect, because it is selling rather than diagnosing. Saying “not here” is what distinguishes a verdict from a brochure.

A note on paradigm: diagnosis is pre-sales done right. What the software industry calls pre-sales (discovering the problem, designing a solution, sizing it and proposing it before the client signs) is, in this method, the sociotechnical diagnosis and its verdict. The four moments of pre-sales match the sections above. Discovery is the five readings. Solution design and its sizing are the alternatives the diagnosis compares and its three verdicts, with the negative finding (the “not here”) as an honest part of the scope. The proposal is the verdict. The bridge’s thesis on pre-sales is a single one: committing scope and price is the moment when the translation gap costs the most, so whoever discovers and sizes must be whoever builds, not a salesperson who hands off the engagement. → integrated pre-sales, the pre-sales handoff (Concepts of our own).

Antipatterns

The typical ways of getting it wrong deny a principle or skip a phase:

• Taking the request at face value and solving the declared problem.
• Interviewing only whoever signs and missing the real process.
• Treating resistance as an obstacle to overcome instead of reading what the resisters know.
• Confusing the technical quality of the data with its faithfulness.
• Proposing the solution during the diagnosis, because it is the one you know how to sell or build.
• Reducing everything to a checklist that returns a number.
• Always finding opportunities and never a “not here”.
• Diagnosing against “what a big company does” without mapping one’s own workflow (scale misfit).
• And the one that denies the entire thesis: diagnosing and walking away, leaving someone who did not listen to do the building, which reopens the translation gap the bridge exists to close.

The honest tension: the repeatable and the artisanal

What remains is the uncomfortable point, which is also the one that demands the most honesty. Everything above (the phases, the guiding questions, the structure of the deliverable, the mapping to maturity) is real and can be proceduralized: it can be taught, transferred and carried out with discipline. That is the codifiable part.

The core of the diagnosis, however, is irreducibly tacit. Knowing what to ask after an answer that was not in the script, sensing that the declared problem is covering another, reading in three seconds that a resistance is knowledge and not whim, intuiting that data lies before being able to prove it: none of that is in the protocol, and none of it can be. The protocol is the scaffold that holds up the judgment, not the judgment itself.

Honesty criterion. That the method does not scale linearly is not a defect to hide. It is the other side of what makes it valuable: knowledge that does not pass through handovers that degrade it. An entirely proceduralizable diagnosis would be a checklist, and maturity checklists, which return an optimistic and non-actionable number, are exactly the problem the maturity instrument addresses. The artisanal part is the value, not the debt.

Hence a tension the method does not hide. The practice rests on an integrated person, the same one who reads and builds, translation in flesh and blood, and that runs into the question of scale: how do you transfer something that lives in someone’s judgment? What can be codified is codified: the protocol, the templates, the maturity instrument with its rubrics. Codification is not denied; what is denied is that it exhausts the knowledge. The tacit part is passed on as a craft, through situated learning: accompanying real diagnoses, watching it done and doing it under supervision. It is slow by structure, and admitting that is part of the rigor.

See also: The four links · Concepts of our own · IMIA — the maturity instrument · Authors and currents