Most technology teams are stuck on the same problem, and almost none of them would name it out loud. It is not a skills gap, it is not a budget line, it is that the function was built to do one job and is now being asked to do two.

Run the tech that keeps the business moving day-to-day; drive the innovation that takes it forward. Every technology team has both jobs whether anyone wrote them down or not. The run keeps the lights on: the tickets, the patches, the integrations that break at 4pm on a Friday. The drive is everything the business actually notices: faster decisions, new capability, the thing a competitor just shipped that your board is now asking about. When run swallows the week, drive gets whatever is left. Which is usually nothing. We call this the run/drive ratio. 

Here is the part that should bother you: nobody decided this. No leadership team sat down and agreed that four days in five would go to keeping existing systems upright. It happened by accretion, one workaround and one fragile dependency at a time, until the balance tipped and stayed there. Gartner and Forrester benchmarking puts most mid-sized functions at something like an 80/20 split, four-fifths of capacity spent on run. That is not a team failing, it is a design that was never revisited.

The 80/20 trap is a structural problem, not an effort problem

What happens when a capable team hits this wall?

They work harder. They get better at the run: sharper triage, tighter change control, a runbook for every recurring fire. And it helps, for a quarter. Then the gains get absorbed, because optimising the run inside the same structure just lets you run more efficiently. It does not free you to drive. You end up with a very well-managed treadmill.

The instinct at this point is to ask for more. More headcount, more budget, a new platform that promises to make the pain go away. Sometimes that is the right call but usually it is not, because the constraint was never really resourcing. In our experience the capacity to drive is already sitting inside the function. It is buried under a run that has grown heavier than it needs to be, and no amount of hiring fixes a shape problem. You cannot add your way out of a structure that reclaims every hour you free up.

That is the trap. The harder a good team works, the more invisible the real issue becomes, because effort is masking a design flaw that only shows up when you measure where the capacity actually goes.

What “the business pays” actually looks like

Leaders reach for soft language here. “IT is a bit stretched.” “We are working through a backlog.” The cost is more concrete than that, and it lands on the business, not on the tech team.

Decisions slow down. A commercial team waits three weeks for a report that should take an afternoon, so they stop asking and start guessing. Growth work queues behind maintenance, so the initiative the business is counting on slips a quarter, then two. People route around IT entirely. Someone in finance buys a SaaS tool on a personal card because going through the proper channel means joining the back of a line that never moves. That is how shadow IT starts. Marketing builds or buys the AI tooling they need to better serve customers. Not rebellion, just people trying to get their jobs done.

And risk compounds quietly the whole time. A function stretched across two jobs with capacity for one cuts corners it does not mean to cut. Security posture drifts. The estate gets more fragile, not less, because nobody has the headspace to harden it. The longer the imbalance holds, the more expensive it gets to unwind.

None of this shows up as a line item called “cost of a stuck tech function.” It shows up as a business that feels slower than it should, for reasons the board struggles to pin down.

Why better execution never breaks the cycle

There is a comforting story that says the way out is discipline. Run a tighter ship, mature your processes, and eventually you will earn your way back to strategic work.

It does not happen, and the reason is mechanical. Freed-up time is the most reclaimable resource in any technology function. The moment an engineer finishes a piece of toil early, the next BAU fire is already waiting, and it will take the slack before anyone gets to spend it on something that moves the business. Efficiency without a deliberate rebalance just means you absorb more run. The split holds.

Breaking it takes two things that feel counterintuitive when you are underwater. First, you stop the value leaks properly rather than heroically: the toil, the waste, the fragile dependencies that keep pulling the team back into survival mode. That is not glamorous work and it rarely makes a roadmap, but it is what creates genuine slack instead of borrowed slack. Second, and this is the part most teams skip, you protect that recovered capacity so the run cannot quietly take it back.

Do those two things and the recovered hours stop being theoretical. They become the funding for everything that comes next.

What to actually do about it

If any of this is familiar, resist the urge to jump to a solution. You do not yet know whether you have a workload problem, a budget problem, or a structural one, and the fix for each is different.

Start by measuring the split. Not a vibe, an actual number: what proportion of your function’s capacity went to run last month versus drive. Most leaders have never put a figure on it, and the figure itself tends to change the conversation, because “we spend 82% of our capacity keeping existing systems upright” is a sentence a CFO understands in a way that “IT is stretched” never was.

Then ask a sharper question than “how do we do more?” Ask where the capacity is leaking, and what a rebalanced function could deliver if you got even ten points of it back. Ten points of an eighty-point run is a lot of Fridays.

A capable team buried in run is the most common waste in ambitious tech teams, and the least discussed. The people are not the problem. The shape of the job is. And a shape can be redesigned.

Schedule a call today to diagnose your Run/Drive ratio and find out how much of your capacity you could get back.