Workflow iteration

The workflow you ran last week is already obsolete

You have a workflow. Maybe you designed it deliberately — following the earlier lessons in this phase — or maybe it accreted through habit. Either way, you ran it. It produced a result. And embedded in that execution is information you do not yet possess: what to change next.

The previous lesson, Workflow measurement, established measurement — tracking cycle time, throughput, error rate, energy cost. Measurement gives you numbers. But numbers alone do not improve anything. A dashboard full of metrics is just a wall of facts. The engine that converts measurement into improvement is iteration: the disciplined practice of changing one thing after each execution, observing the result, and folding what you learn back into the next cycle.

This sounds simple. It is not. Most people either change nothing (they run the same mediocre workflow for years) or change everything (they redesign from scratch every time something feels slow). Both patterns fail. The first produces stagnation. The second produces oscillation — bouncing between configurations without converging toward better. Iteration is the narrow path between them: small, deliberate, measured changes that compound over time into workflows you could not have designed from first principles.

The discipline of continuous improvement

Taiichi Ohno, the architect of the Toyota Production System, built an industrial empire on a radical premise: no process is ever finished. Every workflow, no matter how refined, contains waste that can be identified and removed. The Japanese word for this philosophy is kaizen — continuous improvement through small, incremental changes made by the people who actually do the work.

Ohno did not hire consultants to redesign Toyota's factories from the top down. He trained every worker on the line to observe their own process, identify one source of waste, and eliminate it. Then do it again. Then again. The gains from any single change were often trivial — saving two seconds on a motion, repositioning a tool bin to reduce reaching, eliminating one unnecessary inspection. But Toyota made thousands of these changes per year, across thousands of workers, for decades. The compound effect was not trivial. It was the most efficient manufacturing system the world had ever seen.

The critical insight from Ohno's system is that iteration is not a project. It is not something you do during a quarterly review or an annual process redesign. It is a stance toward every execution: this run produced data, and that data contains at least one improvement I can make before the next run. The improvement need not be large. It must be specific, it must be singular, and it must be observable.

Plan-Do-Check-Act: the iteration loop formalized

Walter Shewhart first described the iterative cycle in the 1930s, and W. Edwards Deming popularized it so widely that it bears his name: the PDCA cycle. Plan-Do-Check-Act.

Plan: Before the next execution, identify one specific change based on what you observed in the previous execution. Not three changes. Not a redesign. One hypothesis about what will make the workflow better. "I think moving the research step before the outline step will reduce rework" is a plan. "I think I should completely restructure how I write reports" is not — that is a project, and it belongs in a different conversation.

Do: Execute the workflow with the single change in place. Do not also make other changes during this execution. Controlled experiments require controlling variables. If you change three things and the workflow improves, you do not know which change helped. If you change three things and the workflow degrades, you do not know which change hurt. One variable. One cycle.

Check: After execution, measure the result against your previous measurements. Did the change reduce cycle time? Did it reduce error rate? Did it reduce the energy cost — the subjective sense of friction and fatigue? The measurement infrastructure from Workflow measurement makes this step possible. Without measurement, "check" degenerates into vibes, and vibes do not compound.

Act: Based on what you observed, decide. If the change helped, keep it — it is now part of your standard workflow. If it did not help, revert it and try a different change in the next cycle. If the results are ambiguous, run the same change for one more cycle to gather more data. Then identify the next single change for the next cycle, and the loop begins again.

The PDCA cycle is not a framework you apply occasionally. It is the operating rhythm of a workflow that improves itself. Every execution is simultaneously a production run and an experiment. You are always doing the work and learning about the work at the same time.

The compound effect of marginal gains

In 2003, Dave Brailsford became performance director of British Cycling with a mandate to do something that had never been done: win the Tour de France with a British rider. His strategy was what he called "the aggregation of marginal gains" — finding a 1% improvement in everything the team did.

The team redesigned the seats for more comfort during long rides. They tested different massage gels for faster muscle recovery. They painted the inside of their transport truck white so they could spot dust particles that might contaminate a finely tuned bike. They tested different pillows and mattresses so riders would sleep better. They taught riders proper hand-washing technique to reduce illness during the Tour.

No single change won the Tour de France. But within five years, British Cycling had won seven of ten gold medals at the 2008 Beijing Olympics. Within seven years, Bradley Wiggins won the 2012 Tour de France — the first British rider to do so. Within ten years, the team had won five of six Tours.

James Clear formalized the mathematics in Atomic Habits: if you improve by 1% each day, you end the year approximately 37 times better (1.01 raised to the 365th power equals 37.78). If you decline by 1% each day, you approach zero. The arithmetic is exponential, not linear. Small improvements are not small when they compound.

But the mathematics only works if you actually iterate. The 1% improvement does not find itself. It requires the deliberate act of looking, after each execution, for one thing to change. Brailsford's genius was not that he discovered marginal gains as a concept — the concept is obvious. His genius was that he built a system where marginal gains were identified and implemented continuously, by everyone, as a non-negotiable part of every execution cycle.

Faster loops win: the OODA framework

John Boyd was a fighter pilot and military strategist who observed that the outcome of aerial combat was determined less by the speed of the aircraft and more by the speed of the pilot's decision cycle. He formalized this as the OODA loop: Observe-Orient-Decide-Act.

Boyd's critical insight was not that the loop existed — all living systems operate in feedback loops — but that the pilot who cycles through the loop faster gains a cumulative advantage that becomes insurmountable. Each pass through the loop updates your model of reality. If you are updating faster than your opponent, you are operating on more current information. You are making decisions based on what is happening now while your opponent is still responding to what happened two loops ago.

Applied to workflow iteration: the frequency of your iteration loop matters as much as the quality of each iteration. A team that reviews and adjusts its workflow weekly will outperform a team that does quarterly process reviews, even if the quarterly team is more thorough in each review. The weekly team runs 52 iteration cycles per year. The quarterly team runs 4. After a year, the weekly team has compounded 52 small improvements. The quarterly team has compounded 4.

This is why Agile retrospectives exist. At the end of every sprint — typically every two weeks — the team asks three questions: What went well? What did not go well? What will we change? The retrospective is a PDCA cycle compressed into an hour. The questions are simple. The power comes from frequency: the team iterates on its own process 26 times per year, every year, for as long as the team exists.

The lesson for personal workflow design is direct. Do not save iteration for when something goes visibly wrong. Build the iteration step into the workflow itself. After every execution, spend two minutes asking: what is the one thing I would change? Then change it before the next execution. The loop is the asset.

One change per cycle: the discipline that makes iteration work

The hardest part of iteration is not finding things to improve. After any workflow execution, you can probably identify five or ten things that could be better. The discipline is in choosing one.

This is not arbitrary minimalism. It is experimental design. When you change multiple variables simultaneously, you lose the ability to attribute results to causes. If you restructure the order of steps, change the tools you use, and modify the timing all in one cycle, and the workflow improves, you have learned nothing about which change produced the improvement. You have a better workflow — for now — but no knowledge about why it is better. And without that knowledge, you cannot make the next improvement with confidence. You are guessing, not iterating.

Controlled experiments change one variable at a time. The scientist testing whether a drug works does not also change the patient's diet, exercise routine, and sleep schedule. They change one thing and measure the result. This gives them causal knowledge — not just correlation, but understanding of what produces what.

Your workflow iteration cycle is a personal experiment. One change per cycle. Measure the result. Keep, revert, or try something else. The constraint feels slow. Over time, it is faster than any alternative, because every improvement you make is grounded in observed cause and effect rather than hope and hypothesis.

Iteration versus oscillation: the critical distinction

There is a failure mode that looks like iteration but produces the opposite result. Oscillation.

Oscillation happens when you bounce between two or more configurations without ever stabilizing long enough to learn. You try approach A for two weeks, feel frustrated, switch to approach B for a week, feel frustrated again, switch back to approach A. Each switch feels like progress — you are "doing something about the problem." But you are not converging toward better. You are bouncing between alternatives, and each bounce resets your learning.

The difference between iteration and oscillation is convergence. Iteration narrows toward an optimum. Each cycle, the workflow gets a little better — or you learn that a change did not work and you revert, which is also information. Over time, the trendline moves in one direction: toward less friction, less time, fewer errors, lower energy cost.

Oscillation does not converge. It cycles. After six months of oscillation, you are in roughly the same place you started, having spent considerable energy and time switching between approaches that were never given enough cycles to reveal their true performance.

The antidote to oscillation is measurement and patience. Measure the result of each change. Give each change enough time to produce measurable data — usually at least three to five executions. Only then decide whether to keep or revert. If the data is ambiguous after five cycles, the change probably does not matter much, and you should move on to a different variable. What you should not do is switch after one bad execution, which is reacting to noise rather than signal.

Diminishing returns are a feature, not a bug

Early iterations produce large gains. The first time you look at a workflow with fresh eyes, the waste is obvious. You are spending twenty minutes on something that could be automated. You are doing step three before step two, which creates rework. You are using a tool that introduces friction at every use. These are low-hanging fruit, and plucking them produces dramatic improvement.

Later iterations produce smaller gains. After you have removed the obvious waste, the remaining improvements are subtler — saving thirty seconds here, reducing one small error there. The curve of improvement follows a power law: rapid gains early, diminishing returns later.

This is not a signal to stop iterating. It is a signal that the workflow is maturing. Diminishing returns mean you have already captured the large improvements and are now in the refinement zone. The aggregate of many small refinements, compounded over months and years, often exceeds the initial large gains. Brailsford's team did not stop improving after the obvious bike and training changes. They continued into pillows, hand-washing, and truck paint. The marginal gains in the long tail were what separated "very good" from "best in the world."

The only time to stop iterating on a workflow is when the workflow itself should be replaced — when the context has changed so fundamentally that incremental improvement is no longer the right strategy. That is the topic of the next lesson, Context-dependent workflows, on context-dependent workflows. Until then, the stance is: this workflow can be 1% better, and I will find that 1% after the next execution.

The third brain: AI as iteration accelerator

Iteration depends on observation — seeing what happened, identifying friction, proposing a change. You are limited in this by the same cognitive biases that affect all self-assessment: you habituate to your own inefficiencies, you develop blind spots about your own patterns, and you tend to notice the problems that annoy you most rather than the problems that cost you the most.

AI changes the observation step. When you log your workflow executions — even as simple text notes recording what you did, how long it took, and what felt hard — an AI system can analyze patterns across dozens or hundreds of executions that you would never detect yourself. "You spend an average of 22% of each writing session on research that could be batched into a weekly block." "Your error rate doubles when you execute this workflow after 3 PM." "You have reverted the same change three times in the last two months, suggesting an underlying structural issue you are not addressing."

AI does not replace your judgment about what to change. It expands your observation. It is a pattern-recognition layer operating across more data than your biological memory can hold. The iteration loop remains yours — you still choose the one change, you still execute it, you still measure the result. But the "observe" step becomes dramatically more powerful when you have a system that can see trends, correlations, and recurring patterns in your execution history.

The prerequisite, as always, is that the data must exist. If you do not log your executions, AI has nothing to analyze. The measurement infrastructure from Workflow measurement and the iteration log from this lesson are not just personal discipline practices. They are the dataset that makes AI-assisted iteration possible.

From measurement to adaptation

Workflow measurement gave you the instruments: cycle time, throughput, error rate, energy cost. This lesson gives you the engine: after each execution, find one thing to improve, change it, measure the result, and repeat. Measurement without iteration produces awareness without progress. Iteration without measurement produces change without learning. Together, they form a self-correcting loop that makes your workflows converge toward their best version — not through grand redesign, but through the quiet accumulation of small, deliberate, observed improvements.

But here is the tension that the next lesson resolves. Iteration assumes the workflow should continue to exist in roughly its current form, getting incrementally better over time. What happens when the context shifts — when the same type of task needs a fundamentally different workflow because the environment, constraints, or goals have changed? That is the boundary of iteration, and it is where context-dependent workflow design begins.