Flow Efficiency: Why Most of Your Lead Time Is Just Waiting

Introduction

Here is an exercise worth doing before reading further. Pick the last feature your team shipped that took about three weeks end to end. Now estimate how many hours of actual work went into it.

Most people answer somewhere between twenty and fifty. Three weeks of elapsed time is roughly 120 working hours. So the honest version of "it took three weeks" is "it was worked on for two days and waited for thirteen".

That ratio has a name and once you have measured it, a lot of conversations about team speed stop making sense in their old form.

What Is Flow Efficiency?

Flow efficiency is active work time divided by total elapsed time, expressed as a percentage. If an item took ten working days from start to finish and had two days of actual work in it, flow efficiency for that item is twenty percent. Measured across a team, most software teams land somewhere between five and twenty percent, and fifteen is a common figure.

The number is usually a shock the first time, which is the useful part. It is not a sign of a bad team. It is the normal condition of any system with handoffs, and knowing it changes where you look for improvement.

What the Number Implies

Suppose your flow efficiency is fifteen percent and you want to halve delivery time. You have two options.

Option one is to make the active work faster. Better tooling, more experienced people, less yak-shaving. To halve total delivery time this way you would need to eliminate the active work entirely and then some, because it is only fifteen percent of the total. It is arithmetically impossible.

Option two is to reduce the waiting, which is eighty-five percent of the elapsed time. Cutting waiting by forty percent gets you the halving. And waiting is usually cheaper to attack than skill, because it is structural: a review that sits for two days does not sit there because anyone is slow.

This is the practical value of the metric. It does not tell you to work harder. It tells you that working harder is the wrong lever, and it does so with a number rather than an opinion. If your instinct on hearing "delivery is slow" is to look at the engineers, this is the metric that should redirect you.

The Four Places Time Goes

In practice the waiting concentrates in four places, in roughly this order.

Waiting for review

Code is written on Tuesday and merged on Friday. Nobody is blocked in the sense of being unable to work, so nobody escalates, and three days disappear per item. This is usually the single largest contributor and the easiest to fix, because the fix is a norm rather than a system: review before starting something new, and treat an open review as more urgent than a new task.

Waiting for a decision

An item is built, a question comes up, the question goes to someone who is in meetings until Thursday. For small teams with a founder in the loop this is often the top contributor rather than review. See async communication.

Waiting for QA or verification

Particularly acute when verification is a separate person's job or when it happens in a batch before release. The batch version also distorts your measurements; see the staircase shape in reading a cumulative flow diagram.

Waiting for a dependency

Another team, a client's content, a third-party API key. The least controllable of the four, and the one where the best intervention is usually to start the item later rather than to chase harder. An item started before its dependency is ready is a slot of WIP consumed for nothing; see WIP limits.

How to Measure It Without Timesheets

The obvious objection is that measuring active time means tracking hours, and nobody wants to reintroduce timesheets to a team that has escaped them. You do not need to.

Three practical approaches, in increasing order of accuracy and cost:

• Sample by hand. Take ten recently finished items. For each, ask the person who did it for a rough active-hours figure. Ten items and twenty minutes gets you a number accurate enough to act on, and you only need to do it twice a year.
• Use a blocked or waiting status. If the team marks items as blocked or in review, the time in those states is your wait time, and elapsed minus wait approximates active time. Cheap, ongoing, and undercounts waiting because not all waiting gets marked.
• Use logged time if you already log it. Teams doing client billing usually already have this, in which case flow efficiency is a division away.

Do not build a measurement programme for this. The number does not need to be precise, because no decision changes between twelve percent and eighteen percent. The decision changes between fifteen percent and seventy percent, and you will not mistake one for the other.

What Good Looks Like

Do not chase one hundred percent. A system running at high flow efficiency has no slack in it, which means every unplanned event propagates immediately and cycle time becomes wildly variable. The same queueing behaviour that makes a motorway seize at ninety percent occupancy applies here.

For a small software team, moving from fifteen to thirty percent is a large, achievable improvement and the delivery time roughly halves. Forty percent is excellent. Chasing beyond that usually means you have started measuring the wrong thing or squeezed out the slack that absorbs surprises.

Note also that flow efficiency is about a single item's journey. It says nothing about whether the team is busy, and a team can be fully occupied while every individual item waits most of its life. That is, in fact, the normal case, and it is why utilisation is a poor proxy for delivery.

Where FlowBoard Fits

FlowBoard does not compute flow efficiency as a dashboard tile. What it gives you is the denominator for free: cycle time and lead time per item, from status transitions, with no setup. Pair that with a hand sample of active hours across ten items and you have the ratio in under half an hour.

If you want the ongoing version rather than the sampled one, using a blocked status consistently is the lowest-effort path, and it has the side benefit of making stuck work visible on the board while it is still stuck.

What to Do This Week

Take the last ten finished items. Divide estimated active hours by elapsed working hours. Write the percentage on a wall. Then pick the single largest wait state from the four above and change one norm about it, most likely the review one.

Then read cycle time vs lead time, which tells you whether the waiting is happening before work starts or during it, and the flow metrics guide for how this fits with the rest.