The No-Surprise IT Playbook (Operator Insights)
If you’re joining on chapter four: Chapter one covers why side doors create surprises, and why the first fix is routing exceptions into a single hub. Chapter two covers the One Queue Rule, because once work is routed you still fail if the org runs on two backlogs. Chapter three covers the Urgent Trade, because urgent will break the ordering unless you force explicit displacement.
This chapter is the next constraint in the same system. Even with a hub, one queue, and explicit urgent trades, the “when” question stays unanswerable if everything is started and nothing is finishing. Busy is a symptom. Work-in-progress is the cause.
If you want to understand why IT can’t answer “when,” don’t start with effort. Start with work-in-progress. Most teams aren’t failing because they’re lazy or because the work is uniquely complex. They’re failing because they’re running too many partial commitments at once, so lead time becomes a weather system: occasionally sunny, mostly unpredictable, and impossible to forecast with confidence.
High WIP creates the illusion of progress. Everything is started. Everyone is busy. The board looks full. The standup sounds productive. And yet nothing is finishing on time. Work stalls in handoffs, waits for decisions, and gets reopened because the context that mattered was dropped two days ago and the person who held it is now on three other “urgent” threads. The system looks active, but it isn’t flowing.
When too much work is in flight, you don’t just slow down. You lose predictability. People context-switch across partial commitments, queues form behind bottlenecks, and lead time spreads out. A two-day item becomes a two-week item because it sits idle between touches, and every idle gap compounds. That’s why estimates become meaningless under load. The estimate might be right for hands-on time, but it says nothing about waiting time, and waiting time dominates.
This is where theater creeps in. When the system can’t tell the truth cheaply, it starts telling a story expensively. The organization tries to compensate for unpredictability with meetings and reporting, because meetings feel like control. Status decks grow. “Alignment” sessions proliferate. Everyone spends more time narrating work than finishing it, which increases WIP further, which increases the need for narration. It’s a self-reinforcing loop.
Finance usually experiences high WIP as downstream symptoms, not as an upstream cause. Deadlines move. Vendor spend creeps. Quality problems return. Overtime quietly becomes normal. The org develops a constant sense that “we’re always close,” which is another way of saying “we have a lot started and very little closed.” The money isn’t always wasted, but the predictability is, and predictability is what keeps spend intentional instead of reactive.
If you want a quick diagnostic: ask how many initiatives are “in progress,” then ask how many actually shipped in the last two weeks. In high-WIP systems, the first number is large and stable. The second number is small and volatile.
The fix is simple and unpopular: stop starting. Start finishing. Put a soft cap on WIP at the individual and team level, then treat WIP breaches as a management signal, not a personal failure. The goal isn’t to slow the business down. The goal is to make lead time stable enough to be forecastable, because stable lead time is what turns “when” from theater into an answer.
“Soft cap” matters here. You’re not trying to police people. You’re trying to surface that the system is overloaded or mis-routed. If a team repeatedly breaches WIP, that’s rarely an execution issue. It’s a demand and prioritization issue: too many inputs, too many owners pulling in different directions, or too many dependencies waiting on decisions. WIP limits make those conditions visible fast, which is the point.
WIP limits work when they are paired with the rules from the prior chapters. The hub controls intake. The queue controls ordering. Urgent forces displacement. Then WIP control prevents the ordering from being diluted by “start everything” behavior.
One concrete pattern that helps: when WIP is at the limit and someone brings a new “urgent” request, don’t debate urgency first. Ask what leaves. If nothing leaves, it doesn’t start. That’s not stubbornness. That’s protecting lead time from collapse.
When it works, teams finish more, faster, with less drama. Work becomes legible. Lead time tightens and stabilizes, which makes forecasting possible without a performance. The org also learns a useful discipline: starting is not progress. Closing is progress.
Simple principle: protect lead time by limiting WIP.