How to Run a Workflow Review Meeting
A workflow review is a recurring meeting where the people in a workflow examine how the path itself is performing — where work is waiting, what's changed since last time, and what to adjust — rather than the status of individual items. Monthly is enough for most teams. Forty-five minutes is enough for most workflows.
The distinction from a status meeting is the entire point. Status meetings are about items: what's done, what's late, what's next. Workflow reviews are about the path: why items take as long as they do, where they consistently stall, and whether the structure still fits the work. A team can hold status meetings every week for years and never once examine the workflow producing the statuses.
Before the meeting
Pull three things and send them out in advance. This takes about ten minutes once it's routine.
Aging work in progress — everything currently in flight, sorted by time in its current stage. This is the agenda's backbone; the oldest items are what you'll spend most of the meeting on.
Cycle time since last review — median and a high percentile (85th or 95th), ideally segmented by work type. One number is noise; the trend across reviews is the signal.
Wait time by stage — where items sat, and for how long, since the last review.
Sending these in advance matters more than it sounds. If the data is first shown in the room, the meeting becomes a data-reading exercise and the discussion gets compressed into the last ten minutes. If people have seen the numbers, the meeting can start at interpretation.
The agenda
1. What changed since last time (5 min). Actions from the previous review: what was adjusted, and did the numbers move? This goes first, not last, because it's the item most likely to be skipped and the one that determines whether the meeting is a decision-making forum or a discussion group. If nothing from last month was implemented, that's the meeting's first real topic.
2. The oldest items (15 min). Walk the top of the aging list. For each: what is it waiting on, and is that a one-off or a pattern? Resist the urge to solve individual items here — the useful question is what the item's age reveals about the path. Three aging items all waiting on the same approval is a design finding; three aging items with unrelated causes is just Tuesday.
3. Flow numbers (10 min). Cycle time trend, wait time by stage, WIP levels. Look for movement rather than absolute values: which stage's wait grew, where accumulation is building, whether the intake-to-start gap is widening. Compare against what you expected to happen after last review's changes.
4. One structural question (10 min). Pick a single element of the design and examine it: an approval gate, an intake channel, an exception path, a stage boundary. Rotating through the workflow's parts over successive reviews means the whole design gets examined roughly annually without any review turning into a redesign session.
5. Decisions and owners (5 min). What's changing, who's doing it, by when. Zero to two changes per review. More than two and none of them get implemented; more importantly, several simultaneous changes make the next review's numbers uninterpretable.
Who should be there
Everyone who owns a stage, plus the workflow owner, who runs it. Keep it under about eight people — beyond that, participation collapses into an audience.
The workflow owner running the meeting matters. If a manager who isn't in the path chairs it, the meeting drifts toward status reporting and the participants perform rather than diagnose. If nobody owns the workflow, this meeting will not work, and that gap is the thing to fix before scheduling anything.
Invite the requesters occasionally — once a quarter is plenty. They see the lead time you don't, and their account of what it's like to submit work into your path is usually more informative than the intake metrics.
What ruins these meetings
It becomes a status meeting. The strongest gravitational pull in the room. Individual items are concrete and urgent; the path is abstract and never urgent. The corrective is the agenda's structure — items appear only as evidence about the path, and item-level problem-solving gets taken offline explicitly.
Nobody prepared. Without the numbers circulated in advance, the meeting becomes narrative — people describing their impressions of how things are going, which reliably differ from the data and are much harder to argue with.
It becomes about people. The moment aging items are treated as evidence about the person holding them, the meeting's value ends: participants start managing perceptions instead of surfacing problems, and the honest reporting the review depends on disappears. Aging items are properties of the path — a stage that consistently accumulates work is a routing, staffing, or authority problem, and the person there is usually the symptom.
Too many changes. Ambitious reviews produce five changes, of which one gets done and none can be evaluated. Two is the ceiling.
No follow-through loop. A review that never checks whether last month's change worked is a discussion, not a management practice. This is why the agenda opens where it does.
The first one
Your first review will be mostly discovery, and that's the correct outcome. Expect to find that nobody agrees on what the stages mean, that some stage has no owner, that the wait times are much longer than anyone believed, and that a chunk of in-flight work is far older than expected. Don't try to fix all of it. Pick one thing, change it, and see whether the next review's numbers move.
The habit is worth more than any individual session. A workflow that gets examined monthly by the people who run it will outperform a better-designed workflow that nobody looks at, because paths drift — volume changes, staffing changes, exceptions accumulate — and the only real defense is periodic attention from someone accountable for the whole.
FAQ
How often should you review a workflow? Monthly suits most teams — frequent enough to catch drift, infrequent enough that the numbers change meaningfully between sessions. High-volume workflows can justify biweekly; stable, low-volume paths do fine quarterly. What matters more than the interval is that it's fixed and that someone owns it.
Who runs a workflow review meeting? The workflow owner — the person accountable for the path's design and performance. When someone outside the path chairs it, the meeting tends to drift into status reporting, since that's the format participants default to when the person asking questions isn't in the work.
What's the difference between a workflow review and a retrospective? Retrospectives examine how a team worked together over a period, usually qualitatively and often after a bounded effort. Workflow reviews examine how the path performed, using flow data — aging work, cycle time, wait by stage — and produce changes to the workflow's structure. They complement each other; neither substitutes for the other.
What data do you need for a workflow review? Three things: aging work in progress sorted by time in current stage, cycle time (median plus a high percentile) since the last review, and wait time by stage. All three should be circulated before the meeting so discussion starts at interpretation rather than at reading numbers.
How long should a workflow review take? About 45 minutes for most workflows, with the data reviewed in advance. Sessions that run longer are usually solving individual items rather than examining the path — the most common way these meetings lose their purpose.
