Context-dependent workflows

The workflow that works perfectly — until it doesn't

You built a solid morning writing routine. Ninety minutes, coffee, noise-canceling headphones, three-pass drafting process. It produces excellent output when you have a quiet morning, a clear topic, and the cognitive energy to sustain deep focus. Then Tuesday arrives. You slept poorly. Your kid was up at 4 a.m. You have a hard deadline at noon and the draft has to ship. You sit down, open the document, start your usual three-pass process — and produce nothing. The routine that made you a better writer on Monday made you a paralyzed one on Tuesday.

This is not a discipline problem. This is a context-recognition problem. The workflow was designed for one set of conditions and deployed into a completely different set. The task type is identical — produce a written document — but the context has changed along every axis that matters: available energy, time pressure, cognitive resources, and stakes of the outcome. A single workflow cannot absorb that much variation.

Most productivity advice ignores this entirely. It teaches you to build "the" workflow for a given task and then apply it consistently. Consistency sounds virtuous, but when the context shifts and the workflow doesn't, consistency becomes rigidity. The person who always follows the same exercise routine regardless of sleep quality, injury status, and schedule constraints is not disciplined — they are inflexible. And inflexibility, in a world where context shifts daily, is a slow-motion operational failure.

The real skill is not building a great workflow. It is recognizing which workflow a given context demands and selecting accordingly.

What "context" actually means for workflow selection

Context is not a vague feeling. It is a set of concrete variables that change the constraints on how you can effectively complete a task. When you learn to read these variables explicitly, workflow selection becomes a design decision rather than a guess.

Urgency determines how many steps you can afford. A task due in twenty minutes cannot support a five-stage review process. A task due in two weeks can. The workflow must compress or expand to fit the time horizon, and the steps you cut under urgency should be the lowest-value ones — not whichever ones happen to come last.

Stakes determine how much error-checking the workflow needs. A quick internal update to your team can tolerate a typo. A contract sent to a client's legal team cannot. High-stakes contexts demand more checkpoints, more review loops, and more cooling-off periods between drafting and sending. Low-stakes contexts demand speed and simplicity. Using a high-stakes workflow on a low-stakes task wastes your most limited resource — cognitive energy. Using a low-stakes workflow on a high-stakes task courts disaster.

Available energy determines the cognitive complexity the workflow can sustain. This connects directly to Phase 36 (energy management): your available cognitive resources are themselves a context variable. On a high-energy morning after solid sleep, you can run a workflow that requires sustained analytical focus — multi-source research synthesis, complex argument construction, detailed code review. On a depleted afternoon, you need a workflow that relies on structure and checklists rather than raw cognitive horsepower. The task is the same. The brain running the task is not.

Environment determines what tools, interruptions, and social dynamics the workflow must accommodate. Writing in a private office supports deep-focus workflows. Writing in an open-plan office during a busy afternoon does not. Exercising at a fully equipped gym supports complex strength training. Exercising in a hotel room with no equipment requires a bodyweight variant. The physical and social environment constrains what a workflow can contain.

Audience determines the output standard. A brainstorm document for yourself can be messy, full of fragments, nonlinear. A presentation for the executive team needs to be polished, structured, and anticipating objections. The downstream consumer of the workflow's output is a context variable that shapes how many finishing steps the workflow requires.

These five dimensions — urgency, stakes, energy, environment, audience — form a context signature for any given instance of a task. Two instances of "write a report" with different context signatures are, operationally, different tasks. They deserve different workflows.

The research: why experts adapt and novices don't

Gary Klein spent decades studying how experts make decisions under pressure — firefighters, military commanders, intensive-care nurses, chess grandmasters. His Recognition-Primed Decision model, published in its mature form in Sources of Power (1998), revealed something that overturned the classical model of rational decision-making. Experts do not generate a list of options and compare them against criteria. Instead, they rapidly assess the situation, match it to patterns they have seen before, and select a response that fits the pattern.

A fireground commander arriving at a burning building does not list five possible strategies and weigh their pros and cons. She reads the context — building type, fire behavior, wind direction, crew availability, civilian risk — and recognizes which type of situation this is. That recognition triggers an associated action script: a workflow for this context. If the situation is novel or the initial script fails, she adapts. But the starting point is always pattern-matched selection, not blank-slate deliberation.

This is exactly what context-dependent workflow selection looks like in daily operations. You encounter a task. You read the context signature. You recognize which variant of your workflow fits. You deploy it. The speed comes not from skipping analysis but from having pre-built workflow variants indexed by context — so the matching step takes seconds rather than minutes.

Dave Snowden's Cynefin framework formalizes this at a higher level of abstraction. Snowden identifies four primary domains that a situation can inhabit, and each demands a fundamentally different operational approach.

In clear (formerly "simple") domains, the relationship between cause and effect is obvious. Best practices exist and should be followed. The workflow is: sense the situation, categorize it, respond with the established procedure. Cooking a familiar recipe, filing a standard expense report, running a backup script — these are clear-domain tasks. The appropriate workflow is a checklist.

In complicated domains, cause and effect exist but require expertise to discern. There may be multiple right answers, and analysis is required to identify the best one. The workflow is: sense, analyze, respond. Debugging a production incident, designing a database schema, writing a legal brief — these require a workflow that includes diagnosis, expert consultation, and deliberate evaluation of options.

In complex domains, cause and effect are only visible in retrospect. You cannot analyze your way to the right answer because the system is too dynamic and interconnected. The workflow is: probe, sense, respond. Launch a small experiment, observe what happens, amplify what works and dampen what doesn't. Building a new product in an uncertain market, navigating a significant organizational change, or figuring out how to motivate a struggling team member — these require an experimental workflow, not an analytical one.

In chaotic domains, there is no discernible relationship between cause and effect at the system level. The priority is to establish order. The workflow is: act, sense, respond. A server is down in production and customers are losing money. You do not convene a committee. You act immediately to stabilize, then assess, then improve. The workflow is triage, not analysis.

The critical insight is that applying a clear-domain workflow (follow the checklist) to a complex-domain problem (how do we enter this new market?) produces confident, decisive, wrong answers. And applying a complex-domain workflow (run experiments, observe) to a clear-domain problem (file the quarterly tax return) wastes weeks on exploration when a known procedure exists. The failure is not in the workflow itself. The failure is in deploying the wrong workflow for the domain.

Context-dependent memory and the cognitive case for adaptation

The research on context-dependent workflows has a deeper cognitive substrate. In 1975, Godden and Baddeley conducted their famous diving experiment. Divers learned word lists either underwater or on land, then were tested for recall in either the same or the opposite environment. Recall was significantly better when the learning and testing environments matched. The physical context — literally where you are and what surrounds you — affects which cognitive resources are available and how effectively you can access stored knowledge and procedures.

This finding has been replicated across dozens of studies and extended beyond physical environment to mood state (Eich & Metcalfe, 1989), physiological arousal, and even body posture. The implication for workflow design is direct: the cognitive resources available to you are not constant. They change with your physical environment, your emotional state, your energy level, and the social context you are operating in. A workflow designed for one cognitive state may be poorly matched to another — not because the steps are wrong, but because the brain executing those steps has different capabilities depending on the context.

This is why the advice to "just be consistent" with your workflows can backfire. Consistency assumes the operator is a constant. You are not. You are a context-sensitive system running on variable resources. The workflow needs to adapt to the operator's state, not just to the task's requirements.

The strategy pattern: a design principle borrowed from software

Software engineers encountered this same problem decades ago and formalized an elegant solution. The Gang of Four's Design Patterns (1994) describes the Strategy pattern: define a family of algorithms, encapsulate each one as a separate object, and make them interchangeable at runtime. The client code doesn't need to know which algorithm it is using — it just calls "sort" or "render" or "compress," and the system selects the appropriate strategy based on the current context.

Your personal workflow system should work the same way. "Write a document" is the interface. Behind it sit multiple concrete strategies: the deep-focus three-pass strategy, the time-boxed rapid-draft strategy, the outline-first analytical strategy, the freewrite-then-edit creative strategy. At runtime — meaning the moment you sit down to write — you assess the context and select the strategy.

The key design principle is that each strategy must be self-contained. The deep-focus strategy does not depend on having time left over to run the rapid-draft strategy. Each variant is a complete workflow that produces a finished output appropriate to the context. They are not degraded versions of each other. The rapid-draft workflow is not the deep-focus workflow with steps removed. It is its own workflow, designed from scratch for time-constrained, high-urgency contexts, with its own strengths and trade-offs.

This reframe matters because most people think of adaptation as "doing less of my real workflow." That framing guarantees guilt. If your three-pass deep-focus process is the "real" workflow and everything else is a shortcut, you will feel like you are cutting corners every time you adapt to a constrained context. But if you have five workflow variants, each designed for a specific context and each producing context-appropriate output, then selecting the rapid-draft variant for a time-constrained situation is not cutting corners. It is correct engineering.

Building your context-recognition skill

The meta-skill underneath all of this is recognition — the ability to read the context before you start the task and select the appropriate workflow variant. This is the operational equivalent of Klein's Recognition-Primed Decision model applied to your own life.

Step one: name the dimensions. Before you can read a context signature, you need to know what you are reading. The five dimensions above — urgency, stakes, energy, environment, audience — are a starting framework. You may discover that your particular work has additional dimensions that matter. A software engineer might add "codebase familiarity" as a dimension: writing code in a system you know well versus one you are seeing for the first time demands different workflows. A manager might add "relationship history" as a dimension: giving feedback to a trusted long-term colleague versus a new hire requires different conversational workflows.

Step two: build the variants. For each recurring task type, design at least two or three workflow variants that cover the most common context signatures. You do not need to cover every possible combination. Cover the contexts you actually encounter. Your writing workflow might need three variants: deep-focus (high energy, low urgency, high stakes), rapid-draft (any energy, high urgency, moderate stakes), and template-based (low energy, any urgency, low stakes). Your exercise workflow might need two: full-gym (high energy, equipment available, sixty minutes) and maintenance (low energy or constrained environment, twenty minutes).

Step three: practice the pause. The hardest part of context-dependent workflow selection is not the selection itself. It is remembering to select at all. The default behavior is to start a task with whatever workflow you used last time, because habit is powerful and context assessment requires a moment of deliberate thought. The intervention is a ten-second pause at the start of each task: what is the context? Which variant fits? This pause is cheap and the return on investment is enormous. Over time, the pause becomes automatic — you will start reading context signatures without conscious effort, the same way an experienced driver reads road conditions without thinking about it.

Step four: review and refine. After completing a task, spend thirty seconds asking: did the workflow variant I selected match the context? If yes, that pairing is reinforced. If no — if you used the deep-focus variant when you should have used rapid-draft, or vice versa — note the mismatch. These mismatches are the raw material for calibrating your context-recognition skill. Over time, your pattern library becomes more accurate, your selection becomes faster, and the quality of your output-per-context improves.

The third brain: AI as a context-assessment partner

Context-dependent workflow selection is a domain where AI tools can provide genuine leverage — not by doing the work for you, but by helping you see the context more clearly and select more appropriately.

When you face a task, you can describe the context to an AI partner: "I need to write a project proposal. I have two hours, my energy is moderate, the audience is the VP of Engineering who is skeptical of this initiative, and the stakes are high because funding depends on it." The AI can then help you assess which workflow variant fits, identify which steps are essential given the constraints, and flag risks you might miss — such as the fact that a skeptical audience means you need more time on objection-handling than on vision-painting.

More powerfully, AI can help you build your variant library in the first place. You can describe a task type and the contexts you encounter, and the AI can help you design distinct workflow variants for each — drawing on patterns from multiple domains that you might not have considered. A workflow variant inspired by military planning (commander's intent plus decentralized execution) might be exactly what you need for delegating work under time pressure, even if you have never studied military operations.

The key principle remains: the AI assists with assessment and design, but the recognition happens in real time, in your body, at the moment the task begins. The ten-second pause is yours. The context reading is yours. The selection is yours. The AI helps you prepare better variants and reflect on past selections, but the operational moment of deployment is a human skill that improves only through practice.

From iteration to libraries

In Workflow iteration, you learned to iterate on a workflow — to improve it one change at a time after each execution. That skill assumed a single workflow being refined. Now you see that a single workflow is often not enough. The same task type, in different contexts, demands different workflows. Iteration refines each variant. Context-dependence multiplies the number of variants you maintain.

This naturally raises a question: if you have three variants of your writing workflow, two variants of your exercise workflow, four variants of your meeting-preparation workflow — where do all of these live? How do you organize them so that selection is fast, maintenance is manageable, and new variants can be added without chaos?

That question is the subject of Workflow libraries: building a workflow library. A context-dependent workflow system without a library is a collection of ad hoc adaptations. With a library, it becomes a personal operations manual — indexed by task type and context, versioned over time, and available for rapid deployment whenever you read a context signature and know which variant fits.

The progression is clear. First you build a workflow (earlier in this phase). Then you learn to iterate on it (Workflow iteration). Then you learn that one workflow is not enough — you need variants for different contexts (this lesson). Then you organize those variants into a library (Workflow libraries). Each step makes your operational infrastructure more adaptive, more resilient, and more aligned with the reality that your life does not present identical conditions twice.