Document your workflows

The surgeon who forgot to wash his hands

In 2001, Peter Pronovost, a critical care specialist at Johns Hopkins, created a five-step checklist for inserting central venous catheters. The steps were basic: wash hands, drape the patient, clean the skin with chlorhexidine, avoid the femoral site when possible, remove the catheter when it's no longer needed. Every ICU doctor already knew these steps. They were taught in medical school, reinforced in residency, and practiced thousands of times.

Pronovost observed the process for a month before introducing the checklist. Doctors skipped at least one step in more than a third of insertions. Not because they were incompetent. Because the workflow lived in their heads, and heads are unreliable containers for sequential processes.

After the checklist was introduced, the ten-day line infection rate dropped from 11 percent to zero. Over 15 months, Pronovost estimated the checklist prevented 43 infections, 8 deaths, and $2 million in costs. Atul Gawande, who documented this case in The Checklist Manifesto (2009), observed that the resistance from doctors was fierce — not because the checklist was complicated, but because it implied that experienced professionals couldn't be trusted to remember five steps they'd performed a thousand times.

They couldn't. And neither can you. Not because you're careless, but because that's how human cognition works.

The act of writing a workflow down is the first and most consequential upgrade you can make to any repeatable process.

Why your brain is a terrible workflow engine

Daniel Kahneman's dual-process framework explains the problem precisely. Your System 1 — the fast, automatic, unconscious processor — handles most of your daily workflows. You don't consciously think through your morning routine or your email triage process. You run them on autopilot. System 1 is efficient. It's also error-prone in ways you can't detect from the inside.

System 1 works by pattern-matching against past experience. When conditions are stable and familiar, it performs admirably. But it degrades in three predictable ways. First, it drops steps. Not dramatic failures — small omissions that accumulate. You skip the review step in your publishing workflow because the last three posts didn't need edits. Then the fourth one goes out with a broken link. Second, it drifts. Your workflow slowly mutates through small unconscious modifications until the process you're actually running no longer matches the process you think you're running. Third, it resists introspection. You can't examine System 1 processes because they run below the threshold of conscious awareness. Asking yourself "what are all the steps in my publishing workflow?" is like asking yourself "how do you ride a bicycle?" — you can do it, but you can't fully articulate it without deliberate effort.

System 2 — the slow, deliberate, effortful processor — is what documentation activates. When you sit down to write out your workflow, you force System 2 to reconstruct what System 1 has been running automatically. This reconstruction is where the value lives. Not because the document itself is valuable (though it is), but because the act of documentation reveals the hidden structure, the skipped steps, the implicit decisions, and the accumulated drift that System 1 has been papering over.

This is not a metaphor. Nelson Cowan's working memory research established that your conscious workspace holds approximately three to five items at a time. A workflow with twelve steps cannot be held in working memory simultaneously. You can only see fragments of it. Documentation is what makes the entire sequence visible at once, turning a process that exceeds your cognitive workspace into an external object you can examine as a whole.

Extended mind: documentation as cognitive architecture

Andy Clark and David Chalmers proposed the extended mind thesis in 1998: cognitive processes don't stop at the skull. When you use a notebook to remember a phone number, the notebook is part of your cognitive system — not a supplement to it, but a functional component. The criterion they proposed is simple. If the external resource plays the same functional role that an internal cognitive process would play, and if the person treats it as reliably available, then it's part of their mind.

Workflow documentation meets every criterion. A documented workflow stores procedural knowledge (the steps), encodes conditional logic (the decision points), maintains sequence information (the order), and remains stable across time (unlike memory). When you consult your documented workflow before starting a task, the document is doing the work that your memory would otherwise attempt — and fail — to do reliably.

This isn't about having a bad memory. It's about recognizing that memory is the wrong tool for the job. Memory is associative, reconstructive, and context-dependent. Workflows are sequential, precise, and context-independent. Using memory to store workflows is like using a paintbrush to hammer nails. It can technically work, but there's a tool designed for exactly this purpose, and refusing to use it doesn't make you more skilled — it makes you less reliable.

Tiago Forte's Building a Second Brain (2022) extends this into a complete framework. Forte argues that your external knowledge system — notes, documents, checklists, templates — constitutes a "second brain" that handles the storage and retrieval your biological brain handles poorly. Workflow documentation is the operational layer of your second brain. It's not the interesting part. It's the essential part. The infrastructure that makes everything else possible.

The curse of expertise: why experts need documentation most

Here's the counterintuitive finding that Gawande returns to throughout The Checklist Manifesto: the more experienced you are, the more you need documentation. Not less. More.

The reason is what cognitive scientists call the curse of expertise or expert blind spot. As you gain proficiency in a process, individual steps get chunked into larger cognitive units and eventually automated entirely. An experienced chef doesn't think "preheat oven, prepare mise en place, season protein, sear on high heat." They think "make dinner." The substeps have been compressed into a single cognitive unit.

This compression is efficient for execution. It's catastrophic for reliability, handoff, and improvement. The compressed expert can't easily articulate what they do, can't teach it to someone else without lengthy apprenticeship, and can't systematically improve it because they can't see the individual steps anymore. The steps are still there — they're still being executed — but they've dropped below the level of conscious access.

Documentation forces decompression. When you write your workflow, you have to re-expand those compressed chunks back into explicit steps. And this is where you discover things. The decision you make at step four that you've never consciously examined. The step you always skip when you're tired. The three steps that could be done in parallel but you've always done sequentially because that's how you learned them.

This is why the military documents everything. Not because soldiers are forgetful, but because combat is high-stakes, high-stress, and high-complexity — exactly the conditions where System 1 automation fails. Standard Operating Procedures exist to ensure that the process survives the degraded cognitive state of the person running it. Your daily workflows aren't combat, but the principle transfers: the more important the outcome, the less you should depend on your brain to manage the process.

Writing is thinking: documentation as discovery

William Zinsser, in On Writing Well, made an observation that applies far beyond writing: "Writing is thinking on paper." The act of writing doesn't just record what you already know — it generates new knowledge. You discover what you think by trying to articulate it.

This is precisely what happens when you document a workflow. You sit down thinking you know the process. You start writing. By step three, you realize there's a decision point you've never made explicit. By step six, you notice that the order depends on a condition you've never named. By step nine, you discover an entire sub-workflow you've been running unconsciously.

The documentation doesn't just capture the workflow — it reveals it. Before documentation, you had a vague sense that you "know how to do X." After documentation, you have an explicit, examinable, improvable representation of exactly what doing X entails. These are profoundly different things.

This is why the minimum viable documentation isn't a bureaucratic manual. It's a numbered list of steps with decision points marked. That's it. You don't need headers, formatting, version numbers, or approval workflows. You need the sequence externalized in a form where you can see all of it at once. A sticky note with seven numbered steps is infinitely more valuable than a detailed process manual you never write because the effort feels disproportionate.

The format is: Step 1. Step 2. If condition, Step 3a; otherwise Step 3b. Step 4. Done.

That's a documented workflow. It took three minutes to write. It will save you from errors, drift, and invisible complexity for as long as you maintain it.

What documentation actually prevents

Undocumented workflows fail in four specific ways, all of which are invisible until they compound into visible consequences.

Drift without detection. Every time you run an undocumented workflow, it changes slightly. You skip a step because you're rushed. You add a step because something went wrong last time. You reorder two steps because it felt more natural. None of these changes are tracked. Over months, the workflow you're running bears little resemblance to the workflow you started with. Some drift is improvement; some is degradation. Without documentation, you can't tell which is which, because you have no baseline to compare against.

Knowledge loss on handoff. You go on vacation. Someone else runs your workflow. They produce a different result because the workflow in your head was never transferred to theirs. Or you leave a role, and the person who replaces you spends six months reconstructing what you could have documented in an afternoon. The U.S. military estimates that undocumented process knowledge costs organizations 20 to 30 percent of operational capacity during transitions. Your personal workflows carry the same risk on a smaller scale.

Invisible bottlenecks. When a workflow lives in your head, you can't see where the time goes. You know your weekly review takes two hours, but you don't know which steps consume most of that time. Documentation makes the time distribution visible. Step 1 takes two minutes. Step 2 takes two minutes. Step 3 takes 45 minutes. Now you know where to focus improvement.

Resistance to improvement. You can't improve what you can't see. Every workflow improvement methodology — Lean, Six Sigma, Theory of Constraints, even simple iteration — requires a visible representation of the current process as the starting point. Without documentation, every attempt at improvement is working from a distorted mental model of a process that may have already drifted from reality. You're optimizing a hallucination.

The documentation spectrum: from minimum to mature

Not every workflow needs the same level of documentation. The spectrum runs from a mental note (documentation level zero) to a fully specified procedure with error handling, branching logic, and quality gates. Most personal workflows need something in the middle: a numbered sequence with decision points.

At the lightest end, a workflow is simply a numbered list. "1. Pull up analytics dashboard. 2. Screenshot key metrics. 3. Compare to last week. 4. Write three bullet points on trends. 5. Send to team channel." This takes two minutes to write and eliminates the possibility of forgetting step 3, which is the step where the actual thinking happens and the step most likely to be skipped when you're in a hurry.

At the next level, you add decision points. "If metric X declined more than 10%, add root cause analysis step between 3 and 4." This captures the conditional logic that experienced practitioners hold in their heads and never articulate — the "it depends" knowledge that makes processes feel impossible to document. It's not impossible. It's just conditional. And conditions can be written down.

At the mature end, you add inputs and outputs for each step, specify the tools required, note common failure modes, and define what "done" looks like for each step. This level of documentation is appropriate for high-stakes, high-frequency workflows — the processes where an error costs you significant time, money, or trust.

The mistake most people make is assuming that documentation means the mature end. It doesn't. A three-line checklist counts. Start there. You can always add detail when the workflow earns it.

The third brain: AI as workflow analyst

When your workflows are documented, AI can operate on them in ways that are impossible with undocumented processes. This is where the second brain meets the third brain — the AI layer that processes, connects, and optimizes what you've externalized.

A documented workflow is structured text. Structured text is exactly what large language models excel at analyzing. Feed your documented workflow to an AI and ask: "Where are the decision points that could be simplified? Which steps could be automated? Where is the bottleneck likely to be?" The AI can reason about your process because the process exists as an external object, not as a pattern locked inside your neural circuitry.

More powerfully, AI can compare workflows. Document your content creation workflow and your project planning workflow, and an AI can identify structural similarities — shared patterns you've developed unconsciously across different domains. It can suggest that the three-step review process that works well in your writing workflow might solve the quality problem in your project planning workflow. These cross-domain connections are nearly impossible to see when each workflow exists only as automated behavior in your head.

But AI cannot document your workflows for you. It can help you refine documentation, suggest steps you might have missed, and restructure your sequence for clarity. The initial capture — the act of forcing System 2 to reconstruct what System 1 has been running — is cognitive work that only you can do. The discovery happens in the writing, not in the reading.

The bridge to triggers

You now have a documented workflow — a sequence of steps externalized, visible, and available for examination and improvement. But a sequence of steps doesn't run itself. Every workflow needs a clear signal that says "start now." Without that signal, even a perfectly documented workflow sits inert, waiting for you to remember that it exists and that the conditions for running it have arrived.

The next lesson addresses this directly: what triggers a workflow, how to make triggers explicit, and why implicit triggers are the most common reason documented workflows go unused. You've built the artifact. Now you need the activation mechanism.