The method of diagnosis

The sociotechnical diagnosis already has a name and a definition, but until now no one has said how it is done. The four links set it out as the deliverable of the first link, and Concepts of our own define it. What was missing was the how, which is where a method is either earned or exposed. This chapter proceduralizes it —phases, principles and deliverable— without turning it into a checklist, because its core is in part irreducibly tacit, and that tension is itself part of the method.

A warning at the outset: most of what follows is a construction of the paradigm, a way of working of its own and not the finding of any single author. The currents that ground it are in Authors and currents; here they are cited only where they hold up a step.

What it is and what it delivers

The sociotechnical diagnosis is the reading of the organization that is 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, resistances, the situated meaning of the data— and rules, on that basis, where AI pays off and where it only destroys value.

Its output is not an opportunities report. It is the document that conditions all the links that follow: if the second one builds, it builds what this diagnosis identified; if the third one models the data, it models it for the decision this one pointed to; if the fourth one designs the AI, it designs it for the person this one made visible. That is why it is the condition and not merely the first step: a mistaken diagnosis does not delay the project, it misorients the whole of it —the wrong thing gets built well, which is the most expensive way to fail—.

The deliverable is twofold: a verdict —where it really hurts, what can be changed and what cannot, who wins and who loses, where AI pays off— and a maturity profile grounded in field evidence, which is its measurable face. The first gives the account and the judgment; the second, the measurement and the prioritization. The verdict without measurement is non-falsifiable consulting; the measurement without the verdict is a number with no account. Together, the number becomes auditable and the account, prioritizable. → IMIA, the maturity instrument.

Three principles

Three principles govern the whole protocol. They are not advice: if one is broken, the diagnosis is already vitiated, however neat the phases turn out.

The first is read before touching, which is the rule of the thesis —first measure the maturity, then choose the technology—. In the diagnosis it means that no solution is proposed, nor even hinted at, until the reading is closed. Proposing early contaminates the listening: people start responding to the imagined solution instead of recounting 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, not as the statement of the problem.

The third: the participation of whoever does the work is requirements engineering, not courtesy. Listening to the operative worker 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 whoever is going to use the system produces systems that people sabotage, avoid or misuse. A requirement that was not born of listening to a real user is an assumption in disguise, and it is marked as such.

Beneath the three runs an epistemic principle: much of the knowledge being sought is tacit —“we know more than we can tell”, in Polanyi’s formula²—, so that the techniques do not aim to have people declare what they know, because they cannot, but to observe them doing and to read between the lines.

The protocol: five readings

The protocol is five readings with an order of priority, not a rigid schedule: it iterates. A detected resistance sends one back to reread the power; an odd piece of data sends one back to observe the process again.

The first is the reading of the people, by interview and observation, in three rings: whoever decides and sponsors —who gives the declared problem and the formal power—; whoever does the work every day —who gives the real process, and is the most valuable source and the one least interviewed in bad diagnoses—; and whoever ended up in the middle or at the margin —who gives the frictions between areas and, very often, the resistance the rest do not name—. One does not ask “what problem do you have?”, which returns the declared problem, but “tell me what you do on a normal day, step by step”, “what part of your work would you not hand to anyone else?” —which guards against automating what the person considers the core of their value, where sabotage is born— and “when the system fails, what do you do to get the work out anyway?”. That last shortcut, the workaround, is the direct trace of the real process: expert knowledge encoded in a practice no one wrote down, and an open question about why it is needed. Tacit knowledge is not asked for, it is inferred —from the workaround, from the exception “So-and-so always handles”, from the discomfort in the face of the simple question—, and when it appears, the response is to observe, not to keep asking.

The second is the process map, drawn twice: the formal one —that of the manual and the org chart— and the real one —the one the interviews reconstruct, with its shortcuts and its steps no one documented—. The gap between the two is the finding, not a defect to be fixed in haste: it says where the formal process is dead, where there is tacit knowledge holding up the operation and —critically— where one must not automate yet, because automating the formal process when people work according to the real one is automating a fiction.

The third is the map of power and incentives. Every technological change redistributes power, visibility and work, and the diagnosis makes it explicit before the change does so the hard way: who wins —the natural allies—, who loses —informal power, a function that justified it, the monopoly over some knowledge— and who controls resources and agendas, which does not always coincide with the org chart. Whoever is going to lose does not oppose out of irrationality: they oppose out of rationality, and their resistance is predictable and legitimate. It is the raw material of translation: one cannot translate an interest that was not mapped. → Authors and currents.

The fourth reads resistance as information, not as obstruction. Whoever resists almost always knows something the sponsor does not: that the process has an exception the new system does not contemplate, that the data on which the AI will rest does not mean what management believes, that there was already a failed attempt no one mentions. Before trying to overcome a resistance it is read as a hypothesis, and depending on what it returns it calls for a different response: if it is knowledge —“this will not work because…” with a valid reason—, it is a requirement that was missing and gets incorporated; if it is loss —whoever resists loses power—, it is a problem of transition design, not of communication; if it is a scar —“we already tried something like this and it went wrong”—, it is the debt of a previous attempt that must be dug up before proposing anything.

The fifth is the reading of the data, where the question is not “what technical quality does it have?” but “does it say what people believe it says?”. A well-typed piece of data with no nulls can lie because its meaning depends on a context that was lost. It is traced back to the human act that generates it —who enters it, when, with what incentive: a “closing date” field that gets filled in when it suits the bonus, not when the deal closes, is data that lies and the trace of a badly incentivized process—, and the categories with which the organization records the world are audited, because a model trained on a badly drawn category inherits the blind spot and amplifies it at scale. This reading is, also, anticipated bias control.

The deliverable

The verdict has fixed sections —the form is stable so that the judgment is comparable and auditable across organizations; the content is proper to each case—: the real problem versus the declared one; the process map, formal against real; the map of power and incentives with the possible coalition and the loci of resistance; the data reading with which categories to audit before modeling; the maturity profile with its roadmap; and, at the center, the verdict properly speaking. That heart issues, for each candidate opportunity, one of three verdicts: it pays off —the process is understood, the data is faithful, there is someone who wins and the resistance is manageable—; not yet —the opportunity is real but a condition is missing, and which one to unblock first is stated—; or it destroys value — automating here would amplify a broken process or data that lies, or would dismantle a critical tacit knowledge, so it is not done, and why is explained—.

The value of the method lies, above all, in that third verdict. A diagnosis that only finds opportunities is suspect: it sells, it does not diagnose. Saying “not here” is what distinguishes a verdict from a brochure.

The honest tension: the repeatable and the artisanal

Here is the uncomfortable point, and 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 proceduralizable: it is taught, transferred and executed with discipline. That is the codifiable part.

But the core of the diagnosis is irreducibly tacit. Knowing what to ask after the answer that was not in the script; smelling that the declared problem covers another; reading in three seconds that a resistance is knowledge and not whim; intuiting that data lies before being able to prove it —that is not in the protocol and cannot be—. The protocol is the scaffold that holds up the judgment, not the judgment.

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 collides with the question of scale. How does one transfer something that lives in someone’s judgment? What is codifiable gets codified: the protocol, the templates, the maturity instrument with its rubrics. The codification is not denied; what is denied is that it exhausts the knowledge. The tacit is transferred as a craft: through situated learning, accompanying real diagnoses, watching it done and doing it under supervision. It is slow by structure, and admitting it is part of the rigor.

Honesty criterion. That the method does not scale linearly is not a defect to hide: it is the other face of why it is scarce by structure and why the knowledge does not degrade in the handovers. An entirely proceduralizable diagnosis would be a checklist —and maturity checklists, which return an optimistic and non-actionable number, are precisely the problem the maturity instrument attacks—. The artisanal part is the value, not the debt.

Antipatterns

The typical ways of doing it badly are the negation of a principle or of a phase: taking the request at face value and solving the declared problem; interviewing only whoever signs off and missing the real process; treating resistance as an obstacle to be overcome instead of reading what whoever resists knows; confusing the technical quality of the data with the data being faithful; proposing the solution during the diagnosis, because it is the one one knows how to sell or build; reducing everything to a checklist that returns a number; always finding opportunities and never a “not here”; and, the one that negates the entire thesis, diagnosing and withdrawing, leaving someone else who did not listen to be the one who builds —reopening the translation gap the bridge exists to close—.

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