The No-Surprise IT Playbook
This is Chapter 1 of 8 in a short series on why IT spend and delivery “surprises” are usually operating-model failures, not talent failures. The through-line is simple: make the truth cheap. Route demand into a single hub, run one ordered queue, force explicit trades when urgent work cuts the line, limit WIP, enforce minimum intake, and make exceptions visible with a ledger.
Chapter one starts with the most common leak: side doors. Work that bypasses intake creates invisible commitments, surprise spend, and delivery drag. The first fix isn’t a new tool or a bigger status meeting. It’s routing discipline.
Growth companies can usually get real progress visibility out of most functions without turning it into ceremony. Sales has pipeline mechanics. Ops has throughput mechanics. Customer Success has churn mechanics. You may not like the answers, but you can usually get answers that map to reality.
IT tends to lose that clarity earlier for a structural reason: it’s the utility company and a household member at the same time. It runs shared systems underneath everyone, and it sits inside each business unit’s daily workflow. Demand is not just “projects.” It’s interruptions, dependencies, access, vendor handoffs, break/fix, and the constant drip of “small” asks that quietly become the operating system. As the company grows, those asks multiply faster than headcount and faster than the team’s ability to keep the work legible.
AI turns that dial further by making it easier to generate requests than to classify, price, and own them. If intake is soft, AI doesn’t create speed. It creates a larger exception path. That’s where transparency collapses, not because people are hiding and not because “technology is hard,” but because real work often doesn’t enter through the same door leadership thinks it does.
Most companies have a front door. It has an intake record, a named owner, a definition of done, and at least a chance of forecasting. Then there’s the side door: everything routed around the system because it felt urgent, political, or simply easier.
Side doors are not rare edge cases. They are normal behavior in a growing org. The mistake is pretending they don’t exist or treating them as “relationship work” that doesn’t count. If it consumes capacity, it counts.
Side doors create two categories of surprise at the same time. Spend surprises happen because exceptions ship without lifecycle ownership. Delivery surprises happen because exceptions consume real capacity without entering the same ordering as the work leadership is tracking.
None of this requires bad intent. It’s what happens when exceptions ship without a ledger.
The common response in growth companies is to ask IT for “better status.” That often improves the status function: cleaner decks, more meetings, more reassurance language, more carefully worded updates. Meanwhile the side door keeps running. The underlying problem isn’t the report. The problem is that work can enter without being priced, owned, and bounded.
This is not a tool change and not a big process rollout. It’s routing discipline. Don’t fight side doors by pretending they won’t exist. Redirect them into a single prioritization hub where they can be classified, owned, and ordered against everything else. You keep the customer dialogue and the appearance of responsiveness, but you regain transparency and the ability to make explicit trade-offs. Exceptions stop being invisible and start becoming managed.
Simple principle: if it enters through the side door, it needs a ledger.
A ledger isn’t a finance artifact. It’s an operating artifact. If an exception is real enough to consume time, it’s real enough to carry minimum fields so it can be owned, bounded, and revisited.
That last one is the forcing function. If urgent enters and nothing leaves, you are buying hidden debt.
A lot of companies create a “hub” and still don’t get the result. Everything routes to the hub, nothing is truly ordered, the hub becomes a mailbox, urgency keeps winning via escalation, and the shadow backlog quietly rebuilds.
If the hub can’t answer three questions without a performance, it’s not a hub:
A hub is not a location. It’s a single ordering.
Progress transparency isn’t a meeting and isn’t a deck. It’s the ability to answer basic questions cheaply because the system makes exceptions visible by default: what are we doing, what did we stop doing, and what did this urgent thing cost in time and displacement. Side doors create surprises because they bypass ownership. Route them to a hub. Put them on a ledger. Make the truth cheap.