The workflow review

Your workflows are silently rotting

You have spent the preceding lessons in this phase learning to design workflows, document them, measure them, and iterate on them one execution at a time. If you have been practicing, you now have a collection of workflows — some deliberate, some inherited, some that accreted through habit. Each individual workflow may be functioning well enough on any given day. But the collection as a whole? Nobody is watching it. Nobody is asking whether every workflow in the portfolio still deserves to exist. Nobody is asking what is missing.

This is the gap between iteration and review. Workflow iteration established the practice of improving a single workflow after each execution — the PDCA cycle applied at the ground level. That practice is essential. But it has a blind spot: it only examines workflows you are actively running. It never examines workflows you have stopped running but never formally retired. It never examines workflows that have accumulated so many patches and workarounds that the original design is unrecognizable. And it never notices the absence of a workflow for a recurring task you keep handling ad hoc.

The workflow review is the practice of stepping back from execution to examine the portfolio. Not a single workflow. All of them. Which ones are alive? Which ones are dead? Which ones are limping? Which ones are missing? This is maintenance at the system level, and without it, your workflow collection degrades in ways that per-execution iteration cannot catch.

The weekly review as existence proof

David Allen, the creator of Getting Things Done, called the weekly review "the critical success factor" of his entire productivity system. Not the capture habit. Not the two-minute rule. Not the context-based task lists. The weekly review. Everything else in GTD can degrade gracefully — you can miss captures, skip processing, let your contexts get sloppy — as long as you do the weekly review. Because the weekly review is the moment when you look at the whole system and bring it back to current.

Allen's weekly review is not a workflow review in the sense this lesson describes. It is primarily about clearing inboxes, updating projects, and reviewing upcoming commitments. But the principle underneath it is exactly what we need: periodic examination of the entire system, not just the piece you happen to be working on today. Allen understood something that most productivity advice ignores: systems do not maintain themselves. They drift, accumulate debris, and lose alignment with reality unless someone periodically examines them from the outside and corrects what has gone wrong.

The weekly review works because it is scheduled. It happens at a fixed cadence, regardless of whether anything feels broken. This is counterintuitive. Why review when everything seems fine? Because the decay is invisible until it is catastrophic. The workflow that is slowly becoming obsolete does not announce itself. The growing gap between your workflow portfolio and your actual responsibilities does not trigger an alarm. These degradations are silent, and the only way to detect them is to periodically look.

Process debt: the invisible weight

Ward Cunningham coined the term "technical debt" in software development to describe the accumulated cost of expedient decisions. When a programmer takes a shortcut — writing code that works but is poorly structured — they incur a debt. The code functions today, but every future change will be harder because the underlying structure is compromised. Like financial debt, technical debt compounds. Small shortcuts accumulate until the codebase becomes so fragile that even simple changes require disproportionate effort.

Your workflows accumulate the same kind of debt. Call it process debt. Every time you patch a workflow instead of redesigning it, you add process debt. Every time you add a workaround for a tool that changed, you add process debt. Every time you keep a step that made sense six months ago but no longer does, you add process debt. The workflow still produces its output. But it takes longer than it should, requires more energy than it should, and carries more risk of failure than it should — because the underlying structure no longer matches the reality it was designed to serve.

Process debt, like technical debt, is invisible in day-to-day execution. You do not notice the extra three minutes on a workflow you have run a hundred times. You do not feel the cognitive overhead of a step that no longer has a clear purpose but which you perform out of habit. You do not see the risk embedded in a handoff point that was designed for a team that no longer exists. Each of these is a small cost. Multiplied across dozens of workflows, executed hundreds of times per year, the aggregate cost is enormous — and entirely hidden until you step back and look.

Software teams address technical debt through code reviews and periodic refactoring. They read through existing code with fresh eyes, identify patterns that have become liabilities, and restructure before the debt compounds further. The workflow review is the personal equivalent: a periodic, systematic examination of your workflow portfolio for accumulated process debt.

What the review looks for

A workflow review is not a general reflection session. It has specific diagnostic targets, and knowing what to look for is what separates a productive review from aimless navel-gazing.

Dead workflows. These are workflows that you designed or inherited for a context that no longer exists. The client onboarding process for a client you no longer serve. The weekly sync agenda for a meeting that was dissolved three months ago. The content publishing workflow for a platform you stopped using. Dead workflows clutter your system. They occupy mental space even when you are not executing them, because they appear in your inventory and create a vague sense of obligation. Retiring them is not losing something. It is recognizing that the thing was already gone.

Zombie workflows. Worse than dead workflows are zombie workflows — workflows that are technically still running but have degraded so far from their original design that they barely function. The morning routine that was once a crisp thirty-minute sequence but has accumulated so many additions and exceptions that it now takes ninety minutes and still feels incomplete. The project kickoff process that includes seven steps nobody follows and three that everyone silently skips. Zombie workflows are expensive because they consume real time and energy while producing suboptimal results. The review asks: should this workflow be redesigned from scratch, or should it be simplified back to its essential steps?

Consistently failing steps. Some workflows function well overall but have one step that fails repeatedly. The deployment process works except for the manual database migration step, which causes an incident roughly once a month. The weekly report comes together smoothly except for the section that requires data from a system with unreliable exports. These recurring failure points are invisible when you iterate execution by execution — you fix the failure each time and move on. The review reveals the pattern: this step has failed four times in the last three months, and patching it each time is more expensive than redesigning it once.

Disproportionate time sinks. Some workflows or steps within workflows consume far more time than their output justifies. The quarterly business review that takes two full days to prepare for a one-hour meeting. The expense report that requires an hour of manual data entry for twelve transactions. You tolerate these because they have always taken this long, and the per-execution iteration lens is focused on marginal improvements within the existing structure. The review lens asks a different question: is the time investment proportional to the value produced? If not, the workflow needs more than iteration. It needs structural change.

Missing workflows. Perhaps the most valuable finding from a review is the absence of a workflow for something you do regularly. You have been running the monthly stakeholder update as an ad hoc scramble for six weeks — gathering data from different sources, writing the narrative from scratch, formatting slides one at a time. You do it every month, but because it never became a formal workflow, you never applied the design principles from this phase. You never identified the trigger, defined the steps, documented the inputs, or established checkpoints. The review makes this gap visible and creates the impetus to fill it.

Three altitudes of review

Not all reviews need to examine every dimension. The key is matching the depth of review to the cadence.

Weekly: the execution check. This is the lightest review, taking ten to fifteen minutes. You are not examining the workflows themselves. You are checking whether you executed the workflows you intended to execute, whether anything obvious broke, and whether any urgent iteration is needed before next week. This is close to Allen's weekly review — a quick scan to ensure the system is running, not a deep examination of whether the system is right.

Monthly: the portfolio review. This is the core review described in this lesson. You examine every workflow in your active portfolio. Which ones did you run this month? Which ones have you not run in sixty or more days? Are there steps that consistently caused friction? Are there recurring tasks that lack a workflow? The monthly review takes forty-five minutes to an hour and produces three kinds of actions: retirements, updates, and new workflow drafts.

Quarterly: the strategic review. This is the highest-altitude examination. You are not looking at individual workflows or even the portfolio as a whole. You are asking whether your workflow system is aligned with your current goals, roles, and context. Have your responsibilities shifted? Have your tools changed? Has your team changed? Strategic shifts often invalidate entire categories of workflows simultaneously — a job change, a project ending, a new tool adoption. The quarterly review catches these shifts before the process debt compounds.

The three altitudes echo the Agile retrospective cadence. Sprint retrospectives examine execution every two weeks. Release retrospectives examine the broader process every quarter. Annual retrospectives examine organizational strategy. Each altitude catches different kinds of drift, and all three are necessary because drift operates at every timescale simultaneously.

The Marie Kondo principle applied to process

Marie Kondo built an organizing empire on a single question: does this spark joy? The question works because it bypasses rationalizations. You can always construct a reason to keep something — it might be useful someday, it was expensive, someone gave it to me. But your emotional response to holding the object reveals the truth that your rationalizations obscure.

Applied to workflows, the parallel question is not about joy but about function: does this workflow still serve the purpose it was designed for? You can always construct a reason to keep a workflow — it has always been part of the process, someone might need it, it only takes five minutes. But when you honestly assess whether the workflow produces value proportional to its cost, the answer is often no. And the Kondo insight applies: the act of letting go creates more value than the thing you are holding onto. Retiring a dead workflow does not just save the time of executing it. It saves the cognitive overhead of maintaining it in your inventory, the guilt of not running it, and the confusion of having a cluttered system where live workflows are indistinguishable from dead ones.

The review is the moment where you give yourself permission to let go. Workflows are not permanent. They are tools, and tools that no longer serve their function should be retired with gratitude for what they once provided and clarity about why they are no longer needed.

The refactoring mindset

Software developers distinguish between fixing bugs and refactoring code. Fixing bugs makes the code work correctly. Refactoring makes the code work well — improving the internal structure without changing the external behavior. Refactoring does not add features. It does not fix visible problems. It reduces complexity, eliminates duplication, and makes the code easier to understand, modify, and extend.

The workflow review is a refactoring session for your process portfolio. You are not fixing broken workflows — that is iteration (Workflow iteration). You are examining the structural quality of the whole system. Are there two workflows that overlap significantly and should be merged? Are there workflows with fifteen steps that could be simplified to seven without losing output quality? Are there naming conventions that have become inconsistent, making it hard to find the right workflow when you need it?

Martin Fowler, who literally wrote the book on refactoring, argues that you should refactor continuously — not in large, dedicated "refactoring sprints" but as a regular part of development. The same principle applies to workflow review. The monthly cadence is not a massive overhaul. It is a regular, moderate investment in structural quality that prevents the need for massive overhauls later. Forty-five minutes per month to keep your workflow system clean is far less expensive than the ten-hour emergency redesign you will need after a year of accumulated process debt.

The review is itself a workflow

There is a satisfying recursion here. The workflow review is a workflow — a repeatable sequence of steps executed at a regular cadence to produce a consistent output. Which means everything you learned in this phase applies to it. It has a trigger (the calendar reminder). It has defined steps (list workflows, evaluate each one, take action). It has inputs (your workflow inventory, your execution logs, your current context). It has outputs (retirements, updates, new drafts). It has checkpoints (after listing, after evaluating, after acting). And it should be measured and iterated on, just like every other workflow.

This recursion is not a philosophical curiosity. It is a practical safeguard. If your review process itself becomes stale or poorly designed, it will fail to catch the staleness in your other workflows. The review must review itself. Each time you conduct a monthly review, spend the last five minutes asking: did this review catch real issues? Did it take an appropriate amount of time? Is there a step in the review process itself that I should change? This self-referential quality is what makes the review a genuinely self-correcting system rather than just another item on your calendar.

The third brain: AI as portfolio analyst

The hardest part of the workflow review is not executing it. It is seeing clearly. You are biased toward your own workflows. You designed them, you invested time in them, and you identify with them. Retiring a workflow you built feels like admitting you were wrong. Recognizing that a workflow has accumulated insurmountable process debt feels like acknowledging your own neglect. These are not rational calculations. They are emotional attachments that distort your assessment.

AI provides a dispassionate lens. If you have been logging your workflow executions — even as simple text entries recording what you ran, how long it took, and what friction you encountered — an AI system can perform the portfolio analysis that your biases make difficult. "You have not executed the client feedback workflow in 87 days. Three of your workflows contain a step called 'export to CSV' that could be replaced with a single API integration. Your weekly planning workflow has been iterated nine times in the past year but your average execution time has not decreased, suggesting the iterations are not addressing the actual bottleneck."

AI can also identify missing workflows by analyzing your task logs and finding recurring patterns that lack formal structure. "You have performed a version of 'prepare stakeholder update' eleven times in the past three months. Each instance took between forty and ninety minutes with no convergence, suggesting this is an ad hoc process that would benefit from workflow design."

The human role in this partnership is judgment. AI can identify the patterns, flag the anomalies, and surface the data. But only you can decide whether a workflow should be retired, redesigned, or left alone. Only you understand the political context, the emotional significance, and the strategic direction that inform those decisions. The review remains yours. AI makes it sharper.

From portfolio maintenance to portfolio sharing

The workflow review ensures that your workflow portfolio is current, clean, and aligned with your actual life. Dead workflows are retired. Zombie workflows are redesigned or put down. Process debt is paid before it compounds into crisis. Missing workflows are identified and drafted. The system maintains itself, not through continuous vigilance, but through periodic, structured examination at the right cadence and altitude.

But a clean, well-maintained portfolio of workflows creates a new possibility. When your workflows are current, well-documented, and free of accumulated cruft, they become legible — not just to you, but to others. And legibility is the precondition for sharing. The next lesson, Workflow sharing, examines how to document a workflow well enough that someone else can execute it without your presence. That transition — from personal process to transferable process — is one of the most valuable capabilities in any collaborative context. But it only works if the workflows you are sharing are actually worth sharing. The review ensures they are.