Ask a technology leader what their team does and you will get a long answer. Ask what their team is for and the answer gets shorter and more revealing. Almost every ambitious technology function is being asked to do two jobs simultaneously: run the technology that keeps the business operating from day to day; drive the innovation that takes the business forward into what’s next. The kicker here: they were only ever set up – structurally, culturally, financially – to do job #1.  

This is the run/drive frame, and it is worth setting out in full, because once you see a function through it, most of the recurring arguments about IT stop being arguments and start being maths.

Run and drive are different jobs, not different moods

The run is the job of operating the technology that keeps the business moving. Availability, security, support, the integrations and platforms that other people’s work depends on. It is measured in uptime and mean time to recovery. Success looks like nothing happening.

The drive is the opposite kind of work. It is building what the business does not have yet: new capability, better decisions, the product feature or the internal tool that changes what the organisation can do. It is measured in outcomes the business can name. Success looks like something visible changing.

These are not two settings on the same dial. They pull in genuinely different directions. The run rewards caution, standardisation, and saying no to change, because change is what breaks things at 4pm on a Friday. The drive rewards the opposite: appetite for change, tolerance for the unproven, a bias toward shipping. A function optimised entirely for one is, by construction, bad at the other. That tension is not a sign anything is broken. It is the actual shape of the work, and pretending it away is where teams get into trouble.

Most functions were only ever built for one job

Here is the structural claim, and it is the one that matters. Most mid-sized technology functions were only ever designed to run. The org chart, the incentives, the way success is measured, the muscle memory of the team: all of it was built around keeping things upright. The drive got bolted on later, when the business started expecting more, and it never got a structure of its own.

So drive competes with run for the same people and the same hours. And in that fight the run wins every single time, because the run has deadlines with consequences attached. An outage has a clock on it. A strategic initiative does not. When both land on the same engineer’s desk on the same morning, the strategic work is the one that slips, and it slips again the next morning, and eventually it stops being scheduled at all because everyone has quietly learned it never survives contact with the week.

That is how a capable team ends up at an 80/20 split without anyone choosing it. Not because they are bad at the drive, but because the drive was never given anywhere to stand.

The run, managed well, is what funds the drive

The usual reading of this problem is pessimistic: run is a cost, drive is what we would do if only the cost were lower, and the two are locked in a zero-sum fight for a fixed budget.

We see it the other way round. A well-managed run is not the enemy of the drive. It is the source of its funding.

Think about where the run actually goes heavy. Manual toil that could be automated. Fragile dependencies that generate their own firefighting. Duplicated tooling nobody has rationalised. An estate that most organisations already pay for and use at a fraction of its capability. Every one of those is recoverable capacity sitting inside the run itself. Get the run properly under control and you do not just reduce cost. You liberate the exact hours and headspace the drive has been starving for.

This is why the sequence matters, and why it only runs one direction. You cannot drive your way to control; a team still firefighting has no stable base to build on. But you can absolutely control your way to drive. Stabilise the run, recover the capacity, protect it, then spend it deliberately on the work the business actually notices. Each phase earns the next. That is the whole idea behind getting a stuck function moving: not a leap of faith funded by a big upfront bet, but a rebalance that pays for itself as it goes.

What to do with the frame

The run/drive frame is only useful if it changes a decision. Here is how to put it to work.

Split your own numbers first. For last month, estimate what share of your function’s capacity went to run and what share went to drive. Rough is fine; the point is to have a figure instead of a feeling. Most leaders land somewhere near 80/20 and are quietly surprised to see it written down.

Then, before you approve the next hire or the next platform, ask a different question. Not “how do we get more capacity” but “how much capacity are we already spending on run that a redesign could give back.” In eight out of ten cases the honest answer is: more than enough to fund the drive. The constraint was the shape of the work, not the size of the team.

And when you plan the drive itself, protect it. Give it its own capacity, its own owner, and a wall between it and the run, so the next BAU fire cannot quietly reclaim the hours you fought to free. Unprotected drive capacity does not survive a busy week.

Two jobs, run the day to day and drive what is next, is the simplest honest description of what an ambitious technology function is for. Most teams are trying to do both from a structure built for one. You do not fix that by working harder inside the same shape. You fix it by changing the shape, and then spending what you get back on purpose.

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