# Trap 7 - The waste

> Programs are rarely slow because people work slowly. They are slow because work spends most of its life waiting.

Source: https://www.bluewise.fr/why-programs-fail-the-waste-trap  
Author: Marc Morel  
Published: 2026-10-15  
Category: Programs  
Series: Why programs fail, part 8

## The one-hour flight that takes five

You book a one-hour flight. Perfect: a quick trip.

Then reality unfolds. A train to the airport. A queue at bag drop. Another at security. A walk to the gate, which has changed. Boarding by zones. Twenty minutes on the tarmac. And, at the other end, the baggage carousel, the taxi line, the traffic.

Door to door, five hours. The flight itself, the only part you actually paid for, was one of them.

Nobody in this story did a bad job. The pilot flew well. The security staff checked carefully. Every step made sense on its own. The trip was slow because of everything *between* the steps.

Most programs travel exactly like this. The real work, writing code, testing, deciding, is the flight. Everything else is the airport. And in many programs I've seen, the airport takes four hours out of five.

## Everyone is busy, nothing moves

Here is the paradox at the heart of this trap. In a wasteful program, nobody is idle. Calendars are full. People work late. Ask anyone how they are doing and they'll say: "Swamped."

And yet a small change still takes six weeks to reach production.

The reason is that we watch the people, not the work. People are busy, so we assume work is flowing. But a piece of work spends most of its life sitting still: in a queue, in an inbox, in a backlog of another team, waiting for a meeting or a signature. Nobody is responsible for those waits, so nobody sees them.

When a program is late, the natural reflex is to push the people harder: more hours, more pressure, more staff. That speeds up the flight. The airport stays exactly the same.

**That is the waste trap: optimizing how busy people are, while the work itself spends most of its time waiting.**

## The ten faces of the trap

Ten shapes, in three families: waiting, handing over, and busywork. Most slow programs suffer from five or six at once.

### Waiting

- **Waiting for the tools.** A ticket to get a test environment, another for database access, a third for a firewall rule. Each takes days, and each blocks a developer who was ready to start.
- **Waiting for a signature.** The work is done, and it sits until the next architecture board, security review or change committee. A few minutes of review, weeks of queue.
- **Waiting for another team.** You need one small change in a shared service. It goes into their backlog, behind their own priorities. Your sprint ends before their next one starts.

### Handing over

- **The relay race.** The analyst writes, the architect designs, the developer builds, the tester tests, the ops team deploys. At every baton pass, context is lost and questions pile up. Five handoffs, five translations of the same need.
- **Ticket ping-pong.** "Can you clarify?" "See comment above." "That's not what we meant." A question that would take two minutes face to face takes two weeks through a ticketing tool.
- **The unread document.** Forty pages of specifications that took a month to write and nobody reads end to end. The real decisions get made later, in a hallway, and never make it back into the document.

### Busywork

- **Meeting overload.** Recurring meetings that outlived their purpose, status meetings where people read out what they could have written, and invitations sent to twelve people "just to keep them informed." Calendars fill up, and the work happens in the gaps.
- **The reporting tax.** The same status rewritten four times, for four committees, in four templates. More effort goes into explaining progress than into making it.
- **Doing it twice.** Requirements misunderstood, defects found late, features rebuilt after the first demo. Rework is the most expensive waste, because you pay for the work twice and for the delay in between.
- **Manual toil.** Manual deployments, manual regression tests, data copied by hand between systems. Every repetition is slow, error-prone and quietly exhausting.

## Measure the airport, not the flight

Lean thinking has a simple measure for this: **flow efficiency**. It is the time someone actually works on an item, divided by the total time from request to delivery.

Take a typical example. A change needs three days of real work: analysis, coding, testing. It reaches production after six weeks, about thirty working days. Flow efficiency: 10%. The other 90% is the airport.

That number explains why the usual fixes fail. Hire faster developers and cut the three days of work to two: delivery goes from thirty days to twenty-nine. Remove one two-week queue, and delivery drops to twenty days without anyone working a minute harder.

There is a second, counterintuitive effect. Queueing theory, popularized for product development by Don Reinertsen, shows that as people approach 100% utilization, queues don't grow gently; they explode. A team with no slack can't absorb the smallest surprise, so every request waits behind every other one. The program that keeps everyone fully busy is precisely the program where nothing moves.

The human cost follows. People who spend their days waiting, chasing and reporting lose the satisfaction of finishing things. Busy and unproductive is the most tiring way to work.

## Early signals

You can spot an oversized airport without any tooling:

- Nobody can say how long a typical change takes from request to production.
- "Blocked" is the most common status on the board.
- A ticket crosses four teams before anything ships.
- Developers have less than half a day a week without meetings.
- The same status lives in several decks, each slightly different.
- New joiners wait weeks for access before writing their first line.
- Every release needs a weekend and a war room.
- Everyone is overloaded, yet the delivery rate isn't improving.
- The answer to every delay is "we need more people."

## How to shrink the airport

The answer isn't to work harder. It is to **watch the work instead of the workers, and remove what it waits for.**

1. **Follow one item, end to end.** Pick a recent change and reconstruct its journey: every queue, handoff and signature, with dates. One afternoon of this teaches more than a month of status reports. It is the value stream map in its simplest form.
2. **Measure flow efficiency and lead time.** Two numbers, tracked monthly: how long work takes from request to production, and what share of that time someone was actually working on it.
3. **Attack the biggest wait first.** It is almost never coding. Usually it is an approval, an environment or another team's backlog. Remove that one, then measure again.
4. **Make the tools self-service.** Environments, access and test data on demand, in minutes, with the controls built in. Every ticket you remove gives back days.
5. **Build teams that own the whole flight.** A team that can design, build, test and deploy its own capability needs no relay race. Fewer handoffs beat faster handoffs.
6. **Give meetings a budget.** Each team gets a weekly meeting budget and protected focus time. Status meetings become written updates; meetings are kept for decisions and real conversations.
7. **One status, generated from the work.** Pull progress from the board, the pipeline and the tests, and share the same view with every committee. Nobody rewrites it.
8. **Automate the repetitive.** Deployments, regression tests and data copies are the first candidates. The goal isn't elegance; it is to stop paying the same toll every week.
9. **Keep some slack on purpose.** A team that is never fully booked can absorb surprises and help others. Slack isn't laziness; it's what keeps the queues short.
10. **Remove one thing a month.** A meeting, a report, a gate, a template. Waste regrows quietly, so pruning has to be a habit, not a project.

## What to avoid

- Measuring how busy people are instead of how fast work flows.
- Adding people to a program whose bottleneck is a queue.
- Approvals with no maximum waiting time.
- Inviting people to meetings "for information."
- Writing documents nobody has asked to read.
- Creating a new report for every new committee.
- Planning everyone at 100% capacity.

## The AI twist

AI shrinks the flight, not the airport.

Coding assistants and agents can make the hands-on work dramatically faster. But go back to the example: if real work is 10% of the lead time, halving it saves 5%. Computer scientists will recognize Amdahl's law: speeding up one part of a process can never save more than the time that part takes. A six-week journey with a faster flight is still a six-week journey.

Worse, faster coding can make the airport more crowded. More changes arrive at the same approval boards, the same test environments and the same release windows. The queues grow, and the gain evaporates.

The good news is that AI can work on the airport too. It can draft the clarifying answer before the ticket bounces, generate the status from the work itself, prepare test data, and spot the items that have been waiting the longest. Pointed there, it pays off far more than on the flight alone.

## Look at the clock, not the calendar

The fastest programs I have worked on were not the ones with the busiest people. They were the ones where someone kept asking a simple question: *where is the work waiting right now?* And then removed that wait, one at a time.

So this week, try it on one item. Pick a change that just reached production, and trace its journey back to the first request. Count the days of work and the days of waiting. The result is usually surprising, and it is the best place I know to start.

How long is the airport in your program? I would genuinely love to hear your numbers, and your stories.

*All situations described here are composites, drawn from many programs over 25 years.*