All Posts

A handoff is the transfer of accountability for a piece of work from one participant to another. Not the transmission of a file, not a notification, not a mention in a channel — the moment responsibility actually moves. Work that has been sent but not accepted has left one owner without reaching another, and in that interval it belongs to nobody. That interval is where most work in multi-step paths is lost. Not lost as in deleted — lost as in sitting, unowned and unnoticed, w

A workflow trigger is the defined event that starts a workflow — the moment a piece of work enters the path and becomes something the workflow is responsible for. A form submission, an approved offer, an arriving invoice, a ticket opened, a date reached. Without a trigger, work doesn't enter a workflow; it accumulates somewhere and gets noticed eventually. Of the five properties that make something a workflow — trigger, sequence, handoffs, ownership, completion — the trigger

Small teams need workflow management less than they're told and more than they think. Less, because most of what's written about workflow management assumes coordination problems that a five-person team doesn't have. When everyone can see everything and a question gets answered by turning around, elaborate structure buys clarity you already possess — and costs maintenance you can't spare. Plenty of small teams run beautifully on a shared board and conversation, and should kee

Workflow documentation is enough when someone new to the path can answer four questions without asking anyone: what starts this, what are the stages and who owns each, what must be true for work to move between them, and what happens when something doesn't fit. Everything beyond that is optional, and much of it is actively harmful — because documentation has a maintenance cost that scales with its detail, and documentation that has drifted from reality is worse than none at a

Most workflow problems can be fixed without touching the workflow's structure. The stages stay, the tools stay, nobody is retrained, and no rollout is required — because the common failures are rarely caused by the shape of the path. They're caused by things layered on top of it: ambiguous ownership, missing information at intake, unexamined thresholds, waits nobody has located. This matters practically, because redesign is expensive in a way that's easy to underestimate. It

Workflows fail in two distinct ways, and conflating them is why so many fixes miss. A workflow can fail operationally — work gets lost, stalls, or takes far longer than it should while the structure remains in use. Or it can fail by abandonment — the structure stops being used at all, people revert to email and improvisation, and the board becomes a decorative artifact nobody updates. The second kind is more common and much less discussed, because it leaves no evidence. An ab

The order in which you automate a workflow's steps determines whether the effort produces measurable improvement or a collection of rules that changed nothing. Most teams automate what is easiest to automate, which is a reasonable-sounding heuristic and the main reason automation projects disappoint: the easiest steps are rarely the ones costing time, and improving a step that isn't the constraint improves nothing at the level anyone cares about. A better sequence starts from

A human-in-the-loop workflow is one where automated participants perform steps and people review, approve, or intervene at defined points rather than at every step. The design question is not whether to keep humans involved — some involvement is nearly always warranted — but where, because checkpoint placement determines both how much error the workflow catches and how much of the automation's value survives. Placed badly, checkpoints produce the worst of both arrangements: a

AI changes who performs the steps in a workflow. It does not change what makes a workflow work. That sentence is the whole argument, and it's worth stating plainly because most writing on this subject asserts the opposite — that AI represents a break with how work has been structured, requiring new disciplines and new vocabulary. The evidence so far suggests something less dramatic and more demanding: the fundamentals of workflow structure (defined triggers, explicit handoffs

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

RACI is a responsibility assignment model that labels each person's relationship to a piece of work as Responsible (does it), Accountable (answers for it, one person only), Consulted (gives input before it's decided), or Informed (told after). Built for clarifying who does what on projects and deliverables, it has become the default answer whenever a team asks "who's supposed to handle this?" — including in workflows, where it partly fits and partly doesn't. The honest assess

A workflow has two distinct kinds of ownership, and confusing them is the source of most accountability failures in structured work. Stage ownership is who is accountable for a work item while it sits at a particular point in the path — answering "whose move is it right now?" Workflow ownership is who is accountable for the path itself: how it's designed, whether it's performing, and who decides when it changes. The first is operational and shifts constantly as work moves. Th

Work in progress (WIP) is the amount of work that has been started but not finished — every item currently somewhere between a workflow's trigger and its completion state. Limiting WIP means capping how many items may be in flight at once, so that finishing work takes priority over starting it. It is the most counterintuitive intervention in workflow management and, for most teams, the most effective: the same people, doing the same work, at the same pace, deliver noticeably

A workflow stage is a segment of a path with a single owner — work enters it, one person or system is accountable for it while it's there, and it leaves when that owner's completion criteria are met. The number of stages a workflow needs equals the number of times ownership changes hands between trigger and completion. Not the number of activities performed, not the number of teams involved, and not the number of status updates anyone would like to see. That single rule resol

Designing a workflow means deciding how work should move — choosing the trigger, the stages, the handoffs, the ownership, and the completion state deliberately, rather than letting them accumulate by default. Every workflow already has a design; the only question is whether anyone chose it. Paths that nobody designed still have stages (wherever work happens to stop), owners (whoever tends to pick things up), and completion states (whatever people treat as finished) — they're

Every department runs workflows, but they run different kinds of workflows — and the differences are structural, not cosmetic. Finance workflows are approval-dense and compliance-bound. Marketing workflows are revision-heavy and deadline-driven. HR workflows are handoff-heavy and cross-functional. Operations workflows are volume-driven and exception-prone. Each shape fails in its own characteristic way, which means each responds to a different kind of structure. This guide wa

Workflow metrics measure how work moves — how long items take, where they wait, how much is in flight, and how reliably the path delivers. They are distinct from productivity metrics, which measure how much people produce. The distinction is the whole game: flow metrics diagnose the path, and paths are fixable. Output metrics evaluate people, and evaluating people rarely fixes a path that's broken by design. Most teams measure the wrong things first — usually volume, because

A workflow bottleneck is any point in a path where work accumulates faster than it moves through — the constraint that sets the pace of the entire workflow, regardless of how efficient every other stage is. Bottlenecks are why teams that are individually busy and responsive still deliver slowly: the work isn't waiting on effort, it's waiting at a single choke point that no one is watching. The seven below account for the overwhelming majority of what actually slows knowledge

Mapping a workflow means making the path work actually follows visible: the trigger that starts it, the steps and decisions it moves through, the handoffs where responsibility transfers, and the waits where it sits. The goal isn't a diagram — it's shared, accurate knowledge of how the work really moves, which is the prerequisite for fixing anything about it. The diagram is just one way to hold that knowledge. That distinction shapes everything in this guide. Most workflow map

Task management is the practice of organizing individual units of work — capturing tasks, prioritizing them, tracking them to completion. Workflow management is the practice of structuring the paths that connect units of work — the sequence, handoffs, and ownership that carry an item through multiple steps and multiple hands. The difference is connective tissue: task management sees the pieces; workflow management sees how the pieces join. A team can be excellent at one and t