The Flow Lens: Why Work Stops

A team can be moving fast while the work itself barely moves. Flow efficiency shows you the waits, handoffs, and approval rules that keep complex operations from reaching the finish line.

The feeling of speed

In a complex, regulated organization, work can feel like one long heroic effort. Everyone is busy, people are staying late, and each task gets done quickly, and still a loan approval, a compliance finding, or a client contract takes weeks to reach the finish line.

The explanation is usually simple once you look for it: most of the time, the work isn't being worked on. Being busy and moving work forward turn out to be two different things, and an organization can have plenty of the first while the second barely happens.

The natural leadership response is to ask for more effort, through overtime, extra staff, or faster processing, and the bottleneck rarely lives in how quickly people work. In most operations, a piece of work spends most of its life sitting still, in a shared inbox, waiting for a signature, or stuck because some piece of information hasn't arrived.

In regulated settings the cost goes beyond productivity. While work sits, audit trails go cold, handoffs get fuzzy, and compliance exposure quietly grows. The Flow Lens is a way of separating the noise of activity from how the work actually moves.

---

Doing and waiting

The Flow Lens is a simple diagnostic that splits any process into two kinds of time:

1. Process time, when someone is actively touching the work, making a decision, or adding something to it, usually measured in minutes or hours.
2. Wait time, when the work is sitting in an inbox, waiting for approval, or stalled for missing information, usually measured in days or weeks.

Picture a loan approval that takes eleven days from start to finish.

Type of time	What it looks like in the office
Process time	40 minutes for intake, one hour for file review, and 20 minutes for a data correction
Wait time	Three days in a shared inbox, four days awaiting a signature, and two days awaiting a client reply

Managers naturally try to speed up the doing: they buy tools that help someone type faster or automate the forty-minute intake form, and when the doing is a small slice of the total, those gains barely register. Automate the forty minutes, leave the three-day wait alone, and the client waits almost exactly as long as before.

---

The arithmetic

Flow efficiency measures how much of the elapsed time a piece of work is actually being handled.

Flow Efficiency = (Value Time / Total Lead Time) × 100

Take a path from intake to completion that takes nine days:

• Active work: 40 minutes of intake, an hour of review, and 20 minutes of correction, two hours in all.
• Elapsed time: nine days.
• Flow efficiency: about 9 percent.

The interesting part is the gap. A low percentage means the operation can usually get much faster by cutting waits, well before anyone needs to work harder.

---

What a wait is made of

Waits have causes, and each one can be named, measured, and fixed. A simple register of waits usually turns up the same few patterns.

The handoff

Information gets lost or delayed when work passes between teams and nobody owns the space in between. The item sits in a digital no-man's-land because everyone assumes someone else has it, so the fix is about boundaries and flow.

The approval batch

A policy says an approver reviews files once a week, so work can wait six days for a five-minute signature. The delay comes from the rule rather than from the effort involved.

The missing field

Incomplete information at the start sends work backward to be fixed, and every trip around that loop adds days, which makes it a problem of feedback as much as flow.

The unowned step

Work stops because nobody is responsible for moving it from one step to the next. In regulated operations, those unowned gaps are also where audit risk quietly builds.

---

Where to push first

A slow system doesn't always need a new tool or a new hire. The Revuity Operating System ranks fixes by how much each one changes the whole system:

1. Change the goal: stop doing work that no longer needs to exist.
2. Change the rules or incentives: remove policies that force batching or delay.
3. Add tools or automation: support a flow that's already understood and working.
4. Add people or hours: add capacity once the structural problem is clear.

The order matters, since technology applied to a broken flow just makes the wrong thing happen faster.

The same thinking sits at the heart of the Theory of Constraints, which observes that a system only moves as fast as its tightest point, so pushing every desk to produce more often just piles up work in front of that point. The alternative runs in five steps:

1. Identify the step holding everything up.
2. Protect it, keeping it focused on the most valuable work.
3. Pace the surrounding steps to match it.
4. Expand that specific step with capacity or technology when needed.
5. Repeat once the constraint moves somewhere else.

---

Fix the flow, then the machinery

Two principles hold throughout. Improve the flow before automating it, because automating a bottleneck gives you a faster mess, and keep work you don't yet understand out of software until it has been mapped and settled.

Start with one real piece of work. Map the path it actually took, name every wait and its cause, and fix the biggest wait with a change that costs nothing before buying any software. That might mean naming a backup approver, retiring a batching rule, or making a required field visible at intake.

Back to articles