A request sits for nine days. When someone finally asks about it, the answer is that it was handed to the next team and everyone assumed it'd been picked up. No one was idle during those nine days and no one made a mistake. The work was simply between steps, and nothing in the system was watching that space.

Ask where the delay happened and you'll get an honest answer from each team about their own part, and no answer at all about the gap. That gap is where a large share of delivery time lives, and it stays invisible for as long as the flow itself hasn't been named.

Why IT accumulates more of these gaps than other functions

Other functions can usually describe their output in a few flows. IT has a harder time early on, and it isn't because IT is less organized.

IT runs its own services and also sits inside everyone else's. It's the utility and the household at the same time. That double role produces a long tail of work types and a much longer tail of handoffs, and the handoffs are where things go quiet.

The volume isn't the problem on its own. The problem is that when there are many kinds of work and none of them are named, there's no unit to manage. You can manage a team's workload and you can manage an individual ticket. Without named flows there's nothing in between, which is the level where waiting actually happens.

Name a few flows, not a taxonomy

The useful move is to identify the small number of flows that carry most of the work. Not every request type and not every team. A handful.

Which ones depends on the organization. In the environments I've worked in, they tend to fall out along lines like restoring service, delivering change, managing access, running vendor relationships, and the internal work that removes friction for everyone else. Those names aren't a standard and I'd expect a given organization to end up with a different set, or with four instead of five. The value is in the naming being true to how the work actually moves, not in matching someone else's list.

Cataloguing everything defeats the purpose. A flow you can see and reason about is worth more than a complete inventory that nobody's using.

What a flow needs to be manageable

Naming a flow is only useful if the name carries structure. Six elements make it real:

  • Entry. What qualifies as this flow, where it comes in, and what has to be known before it starts.
  • Owner. Who owns it from entry to finish, including the quality of the handoffs inside it.
  • States. The few conditions work is genuinely in, with a clear test for moving between them. Not a status vocabulary. The real ones.
  • Handoffs. What leaves one step, in what condition, and who takes it.
  • Acceptance. What the next step checks before the transfer counts as complete.
  • Finish. What closed means for this flow, including any verification that matters.

The two that get left out are acceptance and finish, and they're the two the nine-day gap depends on. A handoff without an acceptance condition isn't a transfer. It's a hope that someone noticed.

Seam failures aren't communication failures

When work goes missing between steps, the finding is usually written up as poor communication or as a vendor not being managed closely enough. I'd push back on both.

A transfer fails when nothing defined what leaves the first step, who takes it, and what makes it complete. Under those conditions, two people communicating well will still produce a gap, because there's nothing for them to be accurate about. They'll each hold a reasonable belief about who has it, and both beliefs will be defensible.

The same applies where a vendor sits in the middle. A vendor working to the terms in front of them isn't the cause of a seam failure. If a step is contracted out without an acceptance condition on either side of it, the gap belongs to the flow design.

This matters practically, not just as a courtesy. If you diagnose it as a communication problem you'll respond with more meetings, and the gap will persist. Diagnose it as a missing acceptance condition and there's something you can actually write.

What becomes answerable

Once the flows are named, questions that were previously arguments turn into observations.

Where's work piling up. Which handoff's holding things longest. Which flow is consuming the most capacity, and whether that matches what the business says matters. Which work that was described as temporary is now a permanent flow with no owner.

None of those require anyone to agree about effort or intent first. They're properties of the flow, and two people who disagree about everything else can usually look at the same waiting time and see the same thing.

When the flow is named, waiting and ownership can be seen. What can be seen can be changed, without the diagnosis becoming a judgment about the team.