The Flow Lens: Why Work Stops

Your team may be moving fast while the work itself barely moves. Use flow efficiency to find the waits, handoffs, and approval rules that keep complex operations from reaching the finish line.

The illusion of speed

In an operationally complex, regulated organization, work can feel like a perpetual heroic effort. Teams are underwater, working late, and moving quickly—yet a loan approval, compliance finding, or client contract still takes weeks to reach the finish line.

That is because activity is not throughput. Being busy is not the same as moving work forward.

The leadership response is often to demand more effort: overtime, added staff, or faster processing. But the bottleneck is rarely how quickly people work. In most operations, work spends the majority of its life sitting still: in a shared inbox, waiting for an approval, or blocked by incomplete information.

In regulated environments, this is more than a productivity issue. As work stalls, audit trails grow cold, handoffs become ambiguous, and compliance exposure rises. The Flow Lens helps teams separate the noise of activity from the mechanics of movement.

---

The Flow Lens: doing versus waiting

The Flow Lens is a simple diagnostic. It breaks any process into two kinds of time:

1. Process time, or value time: the minutes or hours when someone is actively touching the work, making a decision, or adding value.
2. Wait time, or idle time: the days or weeks when work is sitting in an inbox, waiting for an approval, or stalled by missing information.

Consider a composite loan-approval process 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 focus on speeding up the doing. They invest in tools that help a person type faster or automate a 40-minute intake form. But if process time is only a small fraction of the lead time, those changes are rounding errors. Automate a 40-minute task and leave a three-day wait untouched; the client still waits nearly as long.

---

The math of operational health

Flow efficiency measures the share of elapsed time in which a unit of work is actually being handled.

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

Take an intake-to-completion path with a nine-day lead time:

• Active work: 40 minutes for intake + one hour for review + 20 minutes for correction = two hours total.
• Elapsed time: nine days.
• Flow efficiency: approximately 9%.

The important insight is in the gap. A low percentage does not mean people are failing; it means the operation can often get much faster by reducing waits rather than increasing effort.

---

Anatomy of a wait

Wait times are not random. They are structural defects that can be named, measured, and addressed. A wait register will typically reveal several recurring patterns.

The handoff

This is a boundary and flow defect. Information is lost or delayed when work moves between teams, and no one owns the seam. The item sits in a digital no-man’s-land because everyone assumes someone else has it.

The approval batch

This is a rules defect. A policy says an approver reviews files only once a week, so work may wait six days for a five-minute signature. The policy creates the delay, not the amount of effort required.

The missing field

This is a feedback and flow defect. Incomplete information creates a rework loop: poor data collected at the start sends work backward to be fixed, adding delay each time it cycles.

The unowned step

This is an ownership and resilience defect. Work stops because no individual is responsible for the transition. In regulated operations, these unowned seams are also where audit risk quietly accumulates.

---

Leverage over effort

The right response to a slow system is not always a new tool or a new hire. The Revuity Operating System prioritizes interventions by leverage:

1. Change the goal or purpose: eliminate work that no longer needs to exist.
2. Change the rules or incentives: remove policies that force batching or delays.
3. Add tools or automation: help a flow that is already understood and working.
4. Add people or hours: increase capacity only after the structural issue is clear.

The order matters. Technology applied to a broken flow makes the wrong thing happen faster.

The same logic is central to the Theory of Constraints. A system only moves as fast as its current constraint. Maximizing every desk’s local output often creates more backlog. Instead:

1. Identify the step holding the system up.
2. Exploit it by keeping it focused on high-value work.
3. Subordinate the surrounding steps to its pace.
4. Elevate that specific constraint with capacity or technology when needed.
5. Repeat once the constraint moves.

---

Fix the flow before the machinery

Two operating principles are non-negotiable:

• Optimize flow before automating. Automating a bottleneck creates a faster mess.
• Do not automate the ununderstood. A process should be mapped and stable before it is encoded into software.

Start with one real unit of work. Map the path it actually followed, name every wait and its cause, then fix the biggest wait with a zero-cost change before buying software. That might mean assigning a backup owner for approvals, replacing a batching rule, or making a required field visible at intake.

Back to articles