Skip to main content

The practice didn’t fail. The system did.

A 40% SLE stretch and a great delivery manager who quit. The flow check-in didn't fail her, it stopped. Why WIP control is a protection mechanism, not an optimisation, and how to design the practice as a pressure valve rather than a habit.

·1406 words·7 min read
The practice didn’t fail. The system did.

She was one of the best delivery managers I’d worked with; both consistent and curious in equal measure. She’d taken the flow check-in and made it her own; not a ritual she performed for my benefit, but a genuine daily conversation she had with her team about their system. In the coaching sessions, I used to score the quality of the check-in from 1 to 10, and she consistently scored 7s and 8s. The team were reading the board rather than reporting tickets, and the oldest items led the conversation. The expedites got named and challenged.

Then I stepped back, as you’re supposed to.

Five weeks later, I rejoined a check-in one morning on her request, and the board told a different story. The 30-day SLE had gone south by 40%. The check-in had quietly stopped happening. And two weeks after that, she handed in her notice.

She told me, “I can’t hold back the swell or steer the ship.”

That sentence has stayed with me.

What happened in those five weeks
#

It wasn’t a failure of skill or commitment, but a pressure event. A sustained period of high demand, with expedited requests piling in from multiple directions, and stakeholders wanting things now if not sooner, the kind of organisational noise that makes everything feel urgent and nothing feel manageable.

And when everything feels urgent, the first thing to get sacrificed is the practice that kept urgency in proportion.

The flow check-in stopped because there wasn’t enough time. Except there was, I have yet to meet a team who don’t have five minutes. What there wasn’t was a system robust enough to survive this kind of pressure. The practice had been built into the calm. It hadn’t been designed into the chaos.

So the check-in went. And with it went the only daily mechanism that surfaced how much work was actually in flight, how old the oldest items were, and how far beyond capacity the team had drifted. The expedites kept arriving. The WIP kept climbing. The SLE stretched. Nobody saw it happening, because the thing designed to make it visible had been the first casualty.

This is what drift looks like. Not a dramatic collapse. A quiet, reasonable, entirely understandable series of small decisions that each make sense in isolation and are catastrophic in aggregate.

The bit nobody writes about
#

There’s a standard critique of Kanban that I’ve heard many times. It’s cold. Mechanistic. Focused on tickets, flow, and metrics, not on the people doing the work. A process that treats humans as throughput variables.

I want to push back on that hard.

Because what happened over those five weeks was not a flow problem but a human one that first showed up in the flow data. The SLE going south 40% isn’t an abstract metric. It’s a signal that a team was overwhelmed. More was being asked of them than the system could absorb. That someone, somewhere, was carrying a weight that the work items on the board were only partially describing.

WIP control is not a productivity optimisation. It’s a protection mechanism.

When you actively manage what’s in flight, when you name the expedites, challenge the urgency, make visible what’s actually being carried, you are doing something fundamentally humane. You are making it harder for demand to overwhelm people invisibly. You are creating the conditions for someone to say, “We are at capacity, and this new thing needs to wait.”

That conversation is only possible if the system is making the situation visible. Without it, the answer to every new request is “yes” because there’s no shared picture of what yes actually costs.

She couldn’t hold back the swell. But the swell shouldn’t have been invisible.

The flow check-in is a pressure relief valve. Design it like one.
#

The flow check-in, when it’s working, is part of what makes demand visible before it becomes damage. Five weeks of expedites with no check-in means five weeks of that demand landing without being named, without being challenged, without anyone asking: what are we stopping in order to start this?

The practice didn’t fail her. The practice stopped. And it stopped because it had been built as a habit, not designed as a valve.

A habit depends on conditions staying roughly the same. A valve is specifically designed for the moments when they don’t. You don’t skip the pressure relief mechanism when things get hard. That’s precisely when it matters most.

This is why I’m pedantic about how the flow check-in is designed and who owns it. Not because of process correctness. Because a valve that only works when the delivery manager is in the room isn’t a valve, it’s a person. And people get overwhelmed. People hand in their notice. People, quite reasonably, are the first thing to buckle when the swell comes up.

A valve that functions as protection has three properties:

  1. The team owns it, not the delivery manager. I’ve written before about what it looks like when a team starts reading the system themselves, and what it takes to get there. If the check-in only happens because one person runs it, the practice is one absence away from stopping. The reason I work hard to transfer facilitation to the team and get to the point where anyone in the room can run a recognisable check-in is not about resilience for its own sake. It’s because a team that owns the practice has a collective pressure relief mechanism. A team that watches someone else run it has nothing to fall back on when that person is swamped.
  2. The artefacts are always visible, not summoned. If the Work Item Age chart only appears when the delivery manager opens it, the signal requires a person to exist. When it’s always on the board, and part of the shared environment the team lives in, the oldest item is visible to everyone, all the time. The data doesn’t wait for someone to notice. And crucially, when the pressure is highest, and the check-in feels most skippable, the board is still there. Still showing what’s ageing. Still making the swell visible, whether or not anyone has called a meeting about it.
  3. Every expedited arrival raises a cost question. What waits for this to move? Not as a bureaucratic gate, but as a shared understanding. When the cost of urgency is invisible, demand is limitless. When it’s named, the team has something to stand behind in the conversation with the stakeholder; I have written more about what unpriced urgency actually costs here. The valve releases pressure only if it can also indicate the source of the pressure. To be clear, none of this would have automatically saved her. Some swells are too strong, some organisations are too committed to the fiction that everything is urgent, for any system to absorb fully. But a check-in designed this way, i.e., team-owned, always visible, cost-aware, gives people something to point at that isn’t themselves. It turns “I’m overwhelmed” from a personal admission into a systems observation. And that is a profoundly different conversation to have.

The question the SLE was trying to answer
#

A 30-day SLE stretch by 40% means work that was typically completed in 30 days now takes 42 days. That’s not just a number. It’s five weeks of accumulated pressure made measurable after the fact.

The thing about flow metrics is that they tell you the truth, even when nobody in the system is comfortable saying it out loud. The SLE doesn’t care about stakeholder politics, the urgency of the expedited request, or the fact that the delivery manager was doing her absolute best. It just shows what happened.

And what happened was: the system was overwhelmed; the practice that was making it visible stopped; and by the time the signal was unmistakable, the person carrying it had already decided she couldn’t stay.

That’s what drift costs. Not always. But sometimes.


The goal of the flow check-in was never a better standup. It was a team that could read their own system, and a system that could protect them when things got hard.

Simple isn’t easy. Sustaining the practice through pressure is the actual work. And that work starts not with a better check-in, but with a structure that doesn’t depend on calm conditions to survive.

She shouldn’t have had to hold back the swell alone. The system should have been making the swell visible.

Paul Brown
Author
Paul Brown
Partner at Thrivve Partners. Product and flow practitioner. I help organisations build delivery systems that scale capability, not dependency, and shape product decisions with evidence rather than opinion. ProKanban Trainer.