Schon 1983 The Reflective Practitioner

A Practical Walkthrough of Reflection-in-Action

Most people who read Schön come away with the idea that "reflective practice" means sitting down after a meeting and writing in a journal. That's only half the book, and honestly the easier half. The part that actually matters for anyone doing real work is reflection-in-action, the idea that skilled professionals can notice something going wrong mid-stream and reframe the problem before they've even finished the current sentence. I ran into this directly when leading a requirements workshop for a hospital scheduling system. We were two hours in, the clinicians were giving polite but vague answers, and the architect next to me was already sketching database schemas on a whiteboard. Something felt off. Not wrong necessarily, but misaligned. So I stopped. I put the marker down and said, "I want to check something. Are we solving for appointment availability or for provider continuity?" The room went quiet for about four seconds. Then the head nurse said, "We don't actually have availability data like that. We have shift handoffs." That single reframing shifted the entire project scope. We ended up building a shift management interface instead of a booking engine. That's reflection-in-action. It's not philosophical. It's noticing a disconnect in real time and pivoting before you've committed to the wrong direction.

Schon 1983 The Reflective Practitioner

The full title is Schon 1983 The Reflective Practitioner, and it came out of his lectures at MIT. The core argument is that professional practice doesn't work the way the academic model says it should. The standard view, which Schön calls "technical rationality," holds that professionals apply scientific theory and research findings to solve problems. You diagnose, you apply the correct method from the textbook, you get the right answer. Schön spent years studying what architects, psychologists, engineers, and teachers actually do, and he found that in the messy middle of real work, this model breaks down pretty quickly. Problems are uncertain, values are conflicting, and situations are unique. You can't look it up. What professionals actually do instead is engage in a kind of dialogue with the situation. They try something, watch what happens, and adjust. Schön calls this a "reflection-in-action spiral." You frame the problem, act on that frame, the situation "talks back" through feedback, and you reframe. It's iterative in the same sense that agile development is iterative, except Schön was describing it thirty years before that terminology existed, and he was talking about cognition, not methodology. There's a second mode he identifies: reflection-on-action. This is looking back after the fact. It's slower, more deliberate, and usually more honest because the pressure of the moment has lifted. Most organizational learning programs focus exclusively on this second mode because it's easier to schedule and measure. That's a mistake. The first mode, reflection-in-action, is where most of the skill actually lives. You can teach someone to write a post-mortem. Teaching them to notice mid-flow that their current approach isn't landing is harder, and it's what separates competent practitioners from the ones who seem to just know what to do when things get complicated.

Here's a detail most summaries miss. Schön distinguishes between knowing-in-action and reflection-in-action. Knowing-in-action is the tacit competence you're using without thinking about it. A senior surgeon's hands know the tissue plane. A senior dev looks at a codebase and just sees the smell. That's knowing-in-action. Reflection-in-action is what happens when knowing-in-action stumbles. The surgeon feels resistance that shouldn't be there. The dev sees a pattern that doesn't fit. That's when the reflective process kicks in. Most people conflate the two, and they're not the same thing. One is fluent performance. The other is the intervention that happens when fluency encounters something unexpected. I tried to formalize reflection-in-action once. I wrote up a checklist of "signals to watch for" during client meetings: vague language, repeated clarifications, sudden agreement from someone who'd been earlier, shifts in body posture. It lasted exactly three meetings. The problem is that the signals are highly contextual. What counts as a red flag in one domain is normal behavior in another. A clinician being terse might mean they're focused, or it might mean they've already solved the problem in their head and are waiting for you to catch up. The checklist approach turns reflection into a mechanical process, which defeats the whole point. Schön would probably say I was trying to codify what can't be fully codified, and he'd be right. The workaround I found was to stop treating it as a diagnostic tool and start treating it as a habit of curiosity. Instead of checking boxes, I started literally saying out loud, "Help me understand why that seems right to you." It's crude, but it forces the reflection loop open without requiring you to perfectly interpret every signal. The main limitation nobody likes to admit is that reflection-in-action requires cognitive surplus. You need bandwidth to notice the mismatch while you're still executing the task. Under time pressure, during a production outage, or when you're being yelled at by a stakeholder, that bandwidth disappears. You fall back on pattern matching, which is fine if you've seen this exact situation before and terrible if you haven't. Schön acknowledges this but doesn't offer a clean solution. The practical implication is that organizations need to create conditions where people actually have room to pause. Not retrospective reviews, not blame assignments, just a cultural permission to say "wait, let me think about this" without it being interpreted as weakness or stalling.

Another overlooked nuance: reflection-in-action isn't just for individual practitioners. Teams can do it too, but the mechanics are different. A team's reflection-in-action looks like a developer pair-programming and saying "hold on, I think we're solving the wrong problem here" or a design team doing a live critique and redirecting mid-session. It requires shared situational awareness and a degree of psychological safety. Without both, you just get groupthink with extra steps. If you're looking to actually develop this, the literature suggests starting with reflection-on-action because it's trainable. Keep a decision journal. Write down what you thought, what you did, and what happened. Do this for three months and you'll start recognizing your own recurring blind spots. Then, gradually, try to catch yourself earlier. The jump from reflection-on-action to reflection-in-action is small but it takes deliberate practice. Most people never make it because they're not given the space, and space is the scarce resource here, not insight. The original text is dense in places and occasionally repetitive, but the core ideas hold up. If you're coming to this from a design or engineering background, the connection to iterative design and incident response will be immediate. If you're coming from a more formal disciplines like law or medicine, Schön's critique of technical rationality will feel more provocative because those fields have stronger claims to scientific foundations. Either way, the practical takeaway is the same: the skill isn't in applying the right method. It's in noticing when the method doesn't fit and having the presence of mind to rebuild the frame before you've walked too far down the wrong path.