Process Flow Basics

When a team cannot point to where a process slows down, it guesses. It adds a status meeting, buys a tool, or tells people to work harder, and the request that took eleven days still takes eleven days. The reason is almost always invisible without a map. In most knowledge work, the share of total time that a piece of work is actively being touched, a measure called flow efficiency, sits in the 15-25% range. Highly tuned teams reach about 40%, and very few go higher. That means for a request that takes ten working days end to end, two days or less involves anyone doing anything. The other eight days, the work sits in a queue, waits for an approval, or bounces back for a redo.

That waiting is expensive and quiet. A support request that waits four days for an owner does not show up as wasted effort on anyone's timesheet, because nobody is working on it. It shows up as a slow customer, a tense escalation, and a team that feels busy while throughput stays flat. Speeding up the active work, the 20%, barely moves the total. Removing the waiting, the 80%, is where the time actually is.

The payoff of a good map is concrete. You stop arguing about who is slow and start looking at a shared picture. You can see that triage is fast, the real delay is the four-day queue before a request gets an owner, and the redo loop after review adds two more days for one request in five. Now the conversation has a target. The next section breaks down the moving parts so you can build that picture for your own work.

A process flow has a small number of moving parts. Once you can name them, you can draw any workflow. Walk the work item from the moment it arrives to the moment it leaves, and tag each thing that happens as one of these:

• Step : an action someone performs on the work. Name it with a plain verb: receive, triage, draft, review, approve, send.
• Decision : a point where the path branches. Write it as a yes or no question, for example "is this urgent?", and draw a branch for each answer, including the unhappy ones.
• Handoff : a point where the work passes to a different person, team, or system. For each handoff, write down what gets passed and in what form, because this is where information goes missing.
• Queue : a place where the work waits before the next step can start. Mark it explicitly. Queues are usually the largest part of the total time.
• Loop : a path that sends work backward, such as a failed review going back to the author. Loops add hidden time and are easy to forget.

Two measurements turn the picture into something you can reason about. Lead time is the total elapsed time from when work is requested to when it is finished, queues and all. Cycle time is the elapsed time once someone actually starts it. The gap between the two is waiting. Flow efficiency is the active time divided by the lead time, expressed as a percentage.

A short worked calculation

Suppose a request takes 10 working days from arrival to delivery. Across those 10 days, the active touches add up to 2 days; the rest is waiting in queues and one redo loop. Flow efficiency is 2 divided by 10, which is 20%. That single number tells you the win is in the waiting, not in working faster.

One more rule explains why backlogs grow. Little's Law says the average amount of work in progress equals throughput multiplied by cycle time. Hold throughput steady and pile on more work in progress (WIP), and cycle time rises in lockstep. This is why limiting WIP, deliberately capping how many items are open at once, shortens cycle time without anyone working faster. The bottleneck, the slowest constrained step, sets the throughput for the whole flow, and WIP stacks up just in front of it. Find that step and you have found where to look first. The next section runs a real request through all of this.

Take a support-or-request workflow on Maya's team. A request comes in, gets triaged, waits in a queue, is assigned, worked, reviewed, and sent back. Leads feel it is slow but nobody agrees on where. Maya sits with the two people who actually run it and maps the current state from real tickets, not from the runbook.

1. They agree on the edges: the flow starts when a request lands in the shared inbox and ends when the requester gets the answer.
2. They list the steps with plain verbs: receive, triage, assign, work, review, send.
3. They mark the one decision, "is it urgent?", and both branches.
4. They mark the handoffs: inbox to triager, triager to the assignment queue, queue to an assignee, assignee to reviewer, reviewer back to requester.
5. They write the time each part really takes, pulled from a sample of twenty recent tickets.

The numbers are revealing. Triage takes about 15 minutes. The active work is roughly half a day. Review is 20 minutes. But the queue between triage and assignment averages four days, because nobody owns the act of assigning, so tickets sit until someone has a slow afternoon. On top of that, one ticket in five fails review and loops back, adding two more days each.

Lead time averages about six days; active time is well under one. Flow efficiency is roughly 12%, below even the typical band, and the four-day assignment queue is the bottleneck. Maya does not touch triage or review, which are already fast. She makes one change: a named owner pulls from the assignment queue twice a day, and she caps work in progress so no one holds more than three open tickets. Within two weeks the assignment queue drops from four days to under one, and average lead time falls from six days to under three. The active work never changed. The waiting did.

The most common failure is mapping the process you wish you had. People draw the clean official version and leave out the workaround that everyone actually uses, so the map hides the very friction you are hunting. Draw what happens on a real, recent item, and ask the people who do the work to correct you out loud. The first map is usually wrong in an interesting way, and that is the point.

A second trap is recording only the active steps and skipping the gaps between them. The boxes feel like the work, so the eye skips the white space. Force yourself to mark every queue as its own block with its own time, because the waiting is usually most of the lead time.

A few edge cases break the simple version:

• No clear owner of a step : the assignment queue in Maya's case sat because owning "assign" belonged to no one. When a step has no owner, the queue in front of it is the symptom. Name an owner before you tune the step.
• A moving bottleneck : fix the slowest step and a different step becomes the new constraint. This is expected. The map is a baseline you revisit, not a one-time drawing. Plan to redraw it after the first fix lands.
• High variation, not high average : a step can average two hours but spike to two days for a tenth of items. Averages hide this. Look at the spread, not just the mean, and treat the long tail as its own problem.

State the better behavior plainly. Map the real path, give every queue a time, and expect the bottleneck to move once you fix it. With those habits, the practice holds up when more than one person depends on the flow, which is the next thing to plan for.

One person can map a flow on a whiteboard in an hour. Keeping it true as a team relies on it is the harder part, and it is where the practice earns its keep. A map drawn once and filed away goes stale the moment the process changes, and a stale map is worse than none because people trust it. Make the map a living artifact with a small cadence, not a deliverable.

Three lightweight habits keep it alive:

• A single intake queue : route all requests through one visible entry point instead of private inboxes. You cannot see a queue you cannot find, and hidden intake is where lead time goes dark.
• An explicit WIP limit : cap how many items are open at each stage. By Little's Law, less work in progress means shorter cycle time at the same throughput, and the limit makes the bottleneck visible as the place where work backs up.
• A standing review trigger : revisit the map whenever the bottleneck moves or a recurring exception appears, not on a fixed calendar. The signal to redraw is a surprise in the numbers.

At larger scale, the same map becomes the boundary object between teams. When work crosses from one team to another, the handoff on your map is a real handoff in the org, and the queue in front of it is often the worst delay in the whole system. That is the seam where this practice connects to the others. Use Handoff Quality to define what must be complete before work crosses each boundary, and Workflow Ownership to name a single accountable owner for each step before you change it. The durable principle is simple. Make the flow visible, watch where work waits, fix the one constraint that sets the pace, then look again.