Ask a team how long a typical case takes, and they will often answer with the time it takes to do the work: two hours to review a contract, a day to prepare a quote, half a day to process an application. Ask the customer how long it took, and the answer is very different: three weeks, a month, sometimes more.
The gap between those two answers is waiting. In most offices, projects and case-handling teams, work spends far more time sitting in a queue than being actively worked on. It waits for someone to have time, for an approval, for a missing piece of information, for the next meeting. Nobody is idle. On the contrary, everyone is busy. But the work itself is mostly standing still.
This article explains why that happens and what to do about it. The ideas come from manufacturing and software development, but they apply just as well to any team that handles cases, requests, projects or documents. None of it requires a new system or a large programme. A team can start in two weeks.
Why work waits
Consider what happens to a typical piece of office work. A customer request arrives by email. It sits in an inbox until someone picks it up. That person does a first assessment and sends it to a colleague for a price. The colleague is busy with other things, so it waits. The price comes back, but a manager needs to approve it. The manager is travelling, so it waits again. Finally the answer goes back to the customer, who has a follow-up question, and the cycle starts over.
Each of these steps might take only minutes or hours of actual work. But between the steps there are queues, and the queues are where the time goes.
There are a few reasons why work waits so much:
- Too much work is started at once. When everyone has many things on the go, each one gets a little attention at a time and progresses slowly.
- Work passes between many people. Every hand-off creates a new queue, because the next person is rarely ready the moment the work arrives.
- Work moves in large batches. Cases are collected and handled once a week, or decisions are saved for a monthly meeting.
- Priorities are unclear. When everything is urgent, people switch between tasks constantly, and the most important work does not necessarily move first.
- Nobody can see the whole flow. Each person sees their own inbox, but no one sees where the work is piling up.
Flow efficiency, explained simply
A useful way to think about this is flow efficiency. It is the share of the total time that work is actually being worked on.
Say a customer request takes twenty working days from the moment it arrives until the customer gets a final answer. If you add up all the time someone was actively working on it, you get two days. The flow efficiency is two days out of twenty, or ten per cent. The other ninety per cent of the time, the request was waiting.
This is a made-up example, but teams that measure their own work are often surprised by how low the figure is. The important insight is where the improvement lies. If you make people work faster, you can shave a little off the two days. If you reduce the waiting, you can take a large bite out of the eighteen.
The quickest way to speed up work is rarely to make people work faster. It is to make work wait less.
This also changes how you look at efficiency. Traditional thinking focuses on keeping people busy, on resource efficiency. Flow thinking focuses on keeping the work moving. The two are not the same, and they often pull in opposite directions. A team where everyone is fully loaded is usually a team where work waits a lot, because there is no slack to pick up the next step when it arrives.
Queues and work in progress
The amount of work that has been started but not finished is called work in progress. In an office, it is the open cases, the half-written reports, the projects under way and the requests waiting for an answer.
There is a simple relationship between work in progress, how much a team finishes and how long work takes. It is known as Little's law, and in plain words it says:
Average lead time equals work in progress divided by throughput.
Lead time is how long a piece of work takes from start to finish. Throughput is how many pieces of work the team finishes in a given period.
Here is a made-up example. Say a team finishes ten cases a week, and at any given time it has forty cases open. On average, each case then takes forty divided by ten, or four weeks, from start to finish.
Now say the team decides to start fewer new cases and focus on finishing the ones it has. Over time, the number of open cases falls to twenty. The team still finishes ten cases a week, because the people and the work are the same. But the average lead time is now twenty divided by ten, or two weeks. The customers get their answers twice as fast, without anyone working harder.
This is the core of flow thinking. If you want shorter lead times, you have two levers: finish more per week, or have less work in progress. The second lever is usually much easier to pull, and it is almost always underused.
Little's law describes averages over time and works best when the flow is fairly stable. It is not a precise forecast. But as a way of thinking it is powerful, because it shows that starting more work does not lead to more being finished. It only leads to everything taking longer.
Make the work visible
You cannot manage a flow you cannot see. The first practical step is almost always to make the work visible on a board.
A simple board has columns for the main stages of the work, for example:
- Ready to start
- In progress
- Waiting for others
- For review or approval
- Done
Each piece of work is a card, physical or digital, that moves from left to right as it progresses. The board shows at a glance how much is in progress, where work is piling up and what is stuck.
A few tips for making the board useful:
- Use the stages your work actually goes through, not an ideal process.
- Include a column for waiting. It is often the most revealing column on the board.
- Put all the work on the board, including the small tasks and the requests that come in by phone or in the corridor.
- Mark cards that are blocked, and note why.
- Keep the board where the team can see it, and use it in a short daily meeting.
The daily meeting should be short, around fifteen minutes, and focus on the work rather than on the people. Instead of each person reporting what they did yesterday, walk the board from right to left: what is close to being done, and what does it need to finish? What is blocked, and who can help?
Limit work in progress
Once the work is visible, the next step is to limit how much of it is in progress at once. This is the single most effective change most teams can make, and also the one that feels most unnatural.
A limit on work in progress is a simple rule: no more than a set number of cards in a column, or per person. When the limit is reached, nobody starts new work. Instead, people help finish what is already in progress, or remove whatever is blocking it.
Where to set the limit is less important than having one. A reasonable starting point is a little lower than what the team currently has in progress. If the limit is never reached, lower it. If it causes constant frustration, look at what is blocking the flow before raising it.
The effect is usually felt quickly. People switch between tasks less often. Work that was half-done gets finished. Problems that used to be hidden, such as a slow approval step or a colleague who is a bottleneck, become visible, because work piles up in front of them and the limit stops the team from simply starting something else.
The hardest part is cultural. In many workplaces, saying no to new work, or saying not yet, feels like failing. A work-in-progress limit gives the team a shared, neutral reason: we finish before we start.
Fewer hand-offs, smaller batches
Every hand-off between people adds a queue and a risk that something is misunderstood. Look at the stages on your board and ask which hand-offs are truly necessary.
Some practical ways to reduce them:
- Let the person who starts a case follow it through to the end where possible, rather than passing it along a chain.
- Give the people doing the work authority to make routine decisions, so that fewer cases need approval.
- Bring the people who need to contribute together for a short session, instead of sending the work back and forth by email.
- Set clear criteria for what a case needs before it moves to the next step, so that it does not bounce back.
Batch sizes matter in the same way. When work is collected and handled in large batches, every item in the batch waits for the slowest one. A report that is reviewed once a month waits an average of two weeks just for the review. A team that handles applications in a weekly batch adds days of waiting to every application. Smaller, more frequent batches mean shorter queues and faster feedback.
Priorities and expedites
A flow only works if the team knows what to work on next. That requires a clear way of prioritising the work waiting to start. The simplest version is an ordered list in the first column of the board: the card at the top is the next to be started.
Who sets the order should be clear. Often it is a team leader or a product or service owner, in regular dialogue with the people who request the work.
There will always be urgent cases that need to jump the queue. Rather than pretending they do not exist, handle them explicitly:
- Have a separate lane on the board for urgent work.
- Limit how many urgent cards can be in progress at once, often to one.
- Agree on what qualifies as urgent, so that the lane is not used for everything.
- Keep track of how often the lane is used. If urgent work is common, it is a sign of a deeper problem upstream.
Measure lead time and throughput, not busyness
Most offices measure how busy people are: hours logged, utilisation, number of tasks per person. These figures say little about whether work is flowing. A team can be fully booked while its customers wait longer and longer.
Two simple measures say much more:
- Lead time: how long each piece of work takes from the moment it is started, or requested, until it is done. Record the start and finish date on each card.
- Throughput: how many pieces of work the team finishes each week.
Add the amount of work in progress, which you can count on the board, and you have the three numbers in Little's law. Track them weekly. Look at the spread in lead time, not just the average. A few cases that take far longer than the rest are often the most useful to study, because they show where the flow breaks down.
Avoid using these numbers to compare individuals. They describe how the system works, not how hard people try, and using them to rank people quickly makes the numbers less honest.
Where to start: two weeks
A team can start improving its flow in two weeks, without new tools or a large programme.
Week one: see the work.
- Gather the team for an hour and agree on the main stages your work goes through.
- Build a simple board, on a wall or in a tool you already have.
- Put every piece of work currently in progress on the board, with the date it was started.
- Start a fifteen-minute daily meeting at the board.
- Count how much work is in progress and how many items you finish this week.
Week two: start to manage the flow.
- Set a work-in-progress limit slightly below what you have today.
- Agree that when the limit is reached, the team finishes or unblocks work before starting anything new.
- Agree how urgent work is handled, and give it its own lane.
- At the end of the week, look at lead time, throughput and where work has been waiting.
- Pick one hand-off or one waiting point to improve in the next two weeks.
After that, keep the rhythm going: a short daily meeting at the board, and a slightly longer review every two weeks to look at the numbers and choose the next improvement. The changes are small one by one, but together they turn a busy team where work waits into a team where work moves.