Your work spends 95% of its life waiting. AI doesn't touch that.

What does your day as a developer look like these days? You head over to GitHub to see which PRs you've been asked to review. There are three of them, each with more than 100 files changed, so you spin up a Claude session to do an initial pass. You also have comments on one of your own PRs to address, so you get a Codex session started on those. Then you pull up the new feature and start working through the implementation. An hour later, you check on the review session and realize it has been waiting 30 minutes for you to look at its findings on the first PR before moving on to the next. Once you get that sorted, you discover the session resolving your PR comments was running in manual mode: it asked for permission to read the GitHub comments one minute in and has been waiting ever since. This cycle, or one like it, repeats throughout the day, including for the coworkers who need to review and resolve the comments on your PRs. What's worse, you know all of these sessions need babysitting, so you're constantly switching contexts and losing track of your own work. While the AI is working, it's making you faster. You're losing that gain in the spaces in between.

There's a name for what's happening here. Lean manufacturing calls it flow efficiency: the share of total lead time that work spends being worked on rather than sitting in a queue. Measured across knowledge work, it typically lands between 5% and 15%. Work spends 85% to 95% of its calendar life waiting. Your day is that statistic at the scale of one desk.

It scales up, too. Ask your team how long it takes for a feature to get from "we decided to do this" to "a customer is using it." Then ask how much of that time someone was actually working on it. The first answer is usually weeks. The second, once you pull the timestamps, is usually a day or two. In our mapping sessions, teams misremember their own queues by two to five times, always in the flattering direction.

Flow efficiency explains three years of disappointing AI results better than any model benchmark, and the explanation is arithmetic. Cut the working time in half, a result no tool reliably delivers, on a stream that's 5% efficient, and lead time improves by about 2.5%. The working minutes got faster. The waiting hours didn't change.

A map of where the time goes

The instrument that makes this visible is a value stream map: trace one unit of work, a feature or a fix, through every step between idea and production, and record two numbers at each step. Touch time, when someone or something is actively working. Wait time, when the work sits in a queue. Then draw the rework loops, the arrows going backward, and total it.

Here's a representative composite for a mid-size B2B SaaS feature stream, traced along the developer's path through it. Touch time comes to about 24 hours, and it doesn't arrive in one block: it shows up as short AI-assisted bursts scattered between the queues. Lead time comes to about 21 days.

Twenty of the twenty-one days are queues: a decision queue, a sprint boundary, a PR review queue, an environment ticket, a release train, a monitoring and rework loop. Only two of those are engineering waiting on engineering. The rest are where product is deciding, platform is provisioning, release management is batching, security is reviewing — each of those functions running its own version of that day, short bursts of work separated by long waits on somebody else. Nothing you buy for the working bursts gets those days back. Donald Reinertsen spent a career on this point: queues are the dominant cost in product development, and they stay invisible because nobody owns them. Every team on that map is busy. The work itself is idle most of the time.

Run the map in a week

You don't need a consulting engagement, and you don't need to own the process to start. You need one product stream, the people who actually do the work (the stream is longer than the IDE: product, design, dev, QA, platform, security), and two working sessions. If you're a developer reading this, draft a version for yourself first. An afternoon with your own tickets and PR timestamps gets you a rough map with real numbers on it. Then compare it against a couple of peers' maps. If the same queue shows up on three desks, it isn't how you work, it's how the system works.

• Day 1: pick the stream and the unit of work; recruit one person per role that touches it.
• Day 2, session one, two to three hours: walk a recent real feature backward from production to idea; draft the steps, queues, and rework loops on a wall.
• Days 3 and 4: pull timestamps from your last 20 to 30 completed items (ticket transitions, PR opened-to-merged, deploy logs) and let the data correct the anecdotes.
• Day 5, session two, two hours: reconcile data against memory, compute flow efficiency, and name the single longest queue out loud.
• Output: one page holding the map, the two totals, and the constraint. If it doesn't fit on a page, you've drifted into modeling.

Draw the current state as it is, not as the wiki says it should be. The map is done when the room agrees it matches what actually happens.

What the map does to your AI strategy

Two disciplines fall out immediately. First, AI opportunities get chosen by evidence instead of by demo. Heat-map the queues and rework loops and ask of each one: is this starved of capacity, of clarity, or of automation? Some answers will be AI. Many will be ordinary: a CI pipeline that actually runs the tests, self-service environments, deleting an approval that exists because of an incident nobody remembers. The boring automation has to come first; agents added to a stream with no test automation just hit the queues faster.

Second, the map keeps you honest about when the answer isn't AI at all. We watched a team conclude that its "AI opportunity" in error triage was actually an observability product it was already paying for, configured properly in an afternoon. The map made that visible. A vendor demo wouldn't have.

Give the agents a lane

One genuinely new habit for the AI era: agents are now workers in your stream, so map their lane too. An agent's task has its own touch and wait times: context gathering, tool calls, CI runs, and above all waiting for human attention (an approval, a review, an answer to a clarifying question). This is the day at the top of this post, drawn as a map. That Claude review session sat for 30 minutes waiting on you; the Codex session sat for an hour waiting on a permission click; you sat between them, switching contexts and losing state. Teams that map the agent lane find the same thing every time: the agents spend most of their calendar time waiting on people, and the people spend a growing share of theirs waiting on agents. Neither workforce is the problem. The queues between them are.

The Sigao take

Map before you automate. It's a week of work, it costs almost nothing, and it converts an AI strategy from a purchasing decision into an aiming decision. Mapping is the first of three moves (map, aim, manage) that we lay out in full in our whitepaper The Bottleneck Isn't the Model, including what to do with the constraint once you've found it. And if you'd rather run the first map with people who've drawn a few hundred of them: we do this with client teams in a week, your engineers co-running it, so the skill stays when we leave. Write chris@sigao.io.

Sources

• Niklas Modig and Pär Åhlström, This Is Lean: Resolving the Efficiency Paradox, Rheologica, 2012: flow efficiency in service and knowledge processes commonly measured under 20%.
• Mike Rother and John Shook, Learning to See: Value-Stream Mapping to Create Value and Eliminate Muda, Lean Enterprise Institute, 1998.
• Donald Reinertsen, The Principles of Product Development Flow, Celeritas, 2009: queues as the dominant, invisible cost in product development.
• DORA, State of AI-assisted Software Development 2025: individual gains lost to downstream disorder.