Schön and Reflective Decision Making
Donald Schön described the only kind of thinking that holds up when the ground moves beneath you.
A senior engineer I know described what her week had become. She opens her editor, sketches the intent of a service in a few paragraphs, lets the model generate an implementation, reads what comes back, finds that it has misunderstood a constraint she had not articulated, rewrites the intent, tries again. She does this half a dozen times before the service is ready. The work is faster than it used to be; AND it is different work. What she is doing now, most of the day, is watching the material talk back to her and deciding what to do about it.
She was describing, without using the phrase, what Donald Schön called a reflective conversation with the situation. Schön died in 1997, before any of this was possible; his subject was architects, urban planners, psychotherapists, and engineers working at drawing boards and with paper. But the shape of what he described is the shape of AI-augmented work. Every move is provisional; every output is a response; every specification is a hypothesis the material will shortly refute or refine. The plan does not survive contact with the artefact. The question Schön asked, and that this phase of the series has to answer, is what kind of thinking survives the collision.
1. The Swamp and the Hilltop
Schön’s most enduring image appears in The Reflective Practitioner (1983). The professional landscape, he says, has a high hard ground on one side and a swampy lowland on the other. On the high ground, problems are well-defined; techniques apply cleanly; rigour is possible. In the swamp, problems are messy, confusing, embedded in values and context; rigour in the technical sense is not available and the problems that matter live there regardless.
The dominant epistemology of the professions, which Schön called technical rationality, trains people for the high ground and then sends them into the swamp. You learn a body of scientific theory and a set of techniques; you apply the theory to solve well-defined problems; rigour equals adherence to method. The difficulty, Schön noticed, is that almost nothing of significance in professional life looks like this. Architects do not derive buildings from theorems. Managers do not produce optimisation problems to decide who is promoted. Engineers do not generate systems by deduction. They make moves, watch what happens, reframe, and move again.
Technical rationality is not wrong; it is wrong about where the real work happens. Simon’s bounded rationality, covered earlier in this series, sits on the high ground: an analytic account of how decisions are made when the problem can be stated. Schön’s critique was that most decisions in practice cannot be stated cleanly, and that the act of reaching for method before the problem has revealed its shape is itself where competence fails.
2. Knowing-in-Action
What do practitioners know, then, if not theory? They know how to do things they cannot quite say how they do. A skilled manager reads a room; a surgeon’s hands find the tissue plane; a jazz pianist alters a chord before the ear has named it. Schön called this knowing-in-action: knowledge bound up in the doing, not prior to it.
This is the same terrain Bourdieu covered with habitus and Giddens with practical consciousness. Nonaka calls it tacit knowledge and describes the process (SECI) by which organisations try to convert it into explicit form. Gigerenzer’s adaptive toolbox, covered in the article just before this one, is its empirical cousin: a repertoire of fast and frugal rules that experienced practitioners select by feel. Klein’s recognition-primed decision is the same idea operationalised for fire-ground commanders. All of these thinkers describe expertise that is demonstrable, real, and resistant to articulation.
The implication for AI adoption is uncomfortable. The most valuable thing inside your organisation, the thing that makes experienced people better than new hires with the same credentials, is the part your specifications cannot capture. This is why “document the process and automate it” keeps producing automations that work on paper and fail in the building. The process was never the work. The work was the judgement running over the process.
3. Reflection-in-Action
Knowing-in-action is enough when the situation is familiar. The interesting question is what happens when it is not. When the ground shifts, when the artefact surprises, when the result is not what was expected, what does the practitioner do?
Schön’s answer is reflection-in-action: thinking on one’s feet. The practitioner does not stop to consult a theory. She reflects on the tacit understanding implicit in her action while continuing to act. She asks, silently and quickly: what assumption did I just make; what does the situation seem to be telling me; what would happen if I saw it differently. Then she makes a new move. The situation talks back again. She adjusts.
This is not iteration in the modern software sense, though the two are related. Iteration is repeating a process with refinement. Reflection-in-action is conducting a conversation in which both parties may change. The practitioner learns from the situation; the situation, in responding, takes new shape. Schön proposed five questions to judge whether a reframing is worth keeping: can the problem be solved as now framed; do I like what I get; is the new framing coherent; is it congruent with my fundamental beliefs; and has inquiry been kept moving. These are not metrics. They are the conscience of a practitioner who is still in the work.
4. Virtual Worlds
The reflective conversation needs a place in which to happen. Schön called these places virtual worlds: sketchpads, models, physical prototypes, simulations, any representation that lets the practitioner try a move and see its consequences without bearing the full weight of commitment. The drawing does not have to be right to be useful; it has to be wrong in an informative way.
This is perhaps the most exact anticipation of AI-augmented work in twentieth-century management thought. An AI coding assistant is a virtual world. A generated prototype is a virtual world. A simulation of a process before it is rolled out is a virtual world. The purpose of these artefacts is not to produce the right answer on the first attempt. Their purpose is to let the material talk back, early and cheaply, so that the practitioner can reframe.
The organisations that will get most from AI are not the ones with the best prompts. They are the ones whose people treat AI outputs as moves in a conversation, not as finished products. Whether they develop that capacity is not a tooling question; it is a cultural one, which returns us to Argyris and the defensive routines that close reflection down long before the tools arrive.
5. The Specification Delusion
A large part of enterprise technology practice has assumed, for forty years, that the main difficulty is getting requirements right at the front. Waterfall projects institutionalised this. Agile reacted against it but retained the assumption that, given the right techniques, intent could be captured upstream of the build. The Deciding phase of this series has been quietly dismantling that assumption from several directions. Evans showed that a domain model is not discovered before the code; it emerges through the code. Taleb showed that planning under deep uncertainty is a category error. The object-oriented design tradition, profiled in an earlier article, showed that every interface is a decision about what to hide. Schön is the philosophical floor beneath these arguments.
The belief that you can specify what AI should build before building it is, in Schön’s vocabulary, a pure expression of technical rationality. In practice, specification is a reflective conversation. You specify; the model generates; the output talks back; you respecify. Specification is not upstream of the build. Specification is the build, conducted in words rather than keystrokes. Organisations that still treat specification as a one-time activity at the front of a programme are preparing to deliver systems that met the early description and missed the later reality. Organisations that treat specification as a live conversation will produce systems that surprise them, sometimes for the better.
6. Repertoire and the Problem of the New Practitioner
There is a hard edge to this argument that deserves acknowledgement. Reflection-in-action depends on repertoire: the accumulated stock of examples, patterns, and half-remembered analogues the practitioner draws on to see a new case as like some older one. “Seeing as,” Schön called it, borrowing from Wittgenstein. Without repertoire, there is nothing to reflect with.
This is where the AI adoption argument gets awkward. The practitioners best positioned to work well with AI are experienced people whose repertoires are deep. The practitioners most threatened by AI are junior ones who have not yet built those repertoires, and whose traditional training pathway (doing simple work under supervision) is the same work AI is now doing. The industry has not yet produced an honest answer to how the next generation acquires repertoire when the apprenticeship work has been automated. “They will learn by reviewing AI output” is the current answer, and it may turn out to be right; it has not been shown to be. Leaders planning AI adoption who ignore this question are accepting an unfunded liability on their organisation’s future capability.
7. Beyond the Stable State
Schön’s earlier and less-read book, Beyond the Stable State (1973), argued that there is no stable state to defend; institutions and the societies that contain them are in continuous transformation; belief in a fixed state to which things can return is itself the obstacle to learning. This is the premise of the series. It is also the premise that makes reflection-in-action a permanent requirement rather than a crisis response.
If the ground moves constantly, then every artefact in the organisation is provisional; every specification is a draft; every structure is a hypothesis about a world already different from the one it was designed for. The practitioner who treats this as catastrophic will suffer. The practitioner who treats it as the normal condition of professional life, which Schön argued it always was, will find the work richer and less anxious. The swamp is not a failure mode. It is where the work happens.
(An Organisational Prompt is something you can do now to test the ideas of this article in your own organisation.)
Organisational Prompt
Name your reframings.
In the next project review, do not ask what went wrong or what went well. Ask three things:
(1) what the team was trying to do when the work began;
(2) what the material told them that changed their framing;
(3) and what they are trying to do now.
If nobody can answer the second question, the team is either working on a problem too simple to reward reflection or is pretending they never changed their minds. Both are warning signs. A team that can name its reframings is learning in action. A team that cannot is running a script.
Further Reading
Donald Schön, The Reflective Practitioner: How Professionals Think in Action (1983). Demanding but every page rewards patience.
Donald Schön, Beyond the Stable State (1973). The earlier, broader statement of the social theory behind the practice idea.
Chris Argyris and Donald Schön, Organizational Learning II: Theory, Method, and Practice (1996). Where Schön’s epistemology meets Argyris’s diagnostic framework.
Mark K. Smith, “Donald Schön: learning, reflection and change,” infed.org: https://infed.org/mobi/donald-schon-learning-reflection-change/. The most thorough free overview.
I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.