Go faster
You are past the question of whether this works. A few things are built, they are deploying, and the numbers are landing. Which is exactly why this has become uncomfortable: once you can see what one initiative returns, you can see what the next twelve would return, and you can see what every month of not building them costs. The constraint is no longer conviction or a list. It is firepower.
Ninety seconds: what the queue is costing you every month, how it gets valued and sequenced, and how the capacity to clear it is resourced without overstaffing for a peak. Everything below is the same argument in detail, for whoever wants it.
There is a particular kind of pressure that only arrives after something works. Before the first build, the risk of moving slowly is theoretical. After it, the cost of the queue is a number you can calculate, and it gets worse every month you look at it. That is what brings most people to this page.
Return maximized consistently over time, rather than in bursts. That phrasing is deliberate and it is the whole of what this situation buys.
In practice it means two things running together. Initiatives sequenced so that the highest return lands first rather than the loudest request, with an owner on each. And enough of the right capacity, internal and external in whatever mix the moment calls for, to build them fast and clean instead of one at a time whenever somebody has a gap in their week.
Underneath that: a quality standard your builders work against, what is already built hardened so the team can depend on it rather than on its author, deployment and adoption run as work instead of hoped for, and a team that absorbs the next release of the tools without waiting for us.
Time to value, and here it is measurable rather than rhetorical: you already know what your first initiatives returned, so you already know roughly what the queue is worth and what each month of delay costs. Closing that gap sooner is the entire return on this work. Second, senior time: the program runs without the chief executive or the technology lead personally carrying it.
The real risk here is the shape of the resourcing curve, and it catches almost everyone.
You have internal people, and they are the right long-term answer. Ramping them up takes time you do not have right now. But staffing permanently for the peak leaves you overstaffed the moment the peak passes, and nobody wants to be the person who hired six people for a surge. So the honest design is a curve rather than a number: external capacity arriving at a moment's notice while your own people ramp, a delivery rate high enough that the queue actually shortens, and then a deliberate handover as your team comes up. Later, when something important lands that should not wait, the same capacity comes back for the bump without you hiring against a temporary spike.
The other two hold throughout. Speed cannot cost quality, so a lightweight build standard comes first, empirical rather than doctrinal. And advice does not substitute for capacity, so this situation always comes with hands: we build while your people validate and adopt, and no internal development is required to go faster.
Worth asking out loud, because the answer decides everything else on this page and almost nobody has been asked it directly. There are three honest answers and we work with all three.
A technology business that needs a hand getting up to speed on this specific shift, not a lecture on software. You have engineers. What you are short of is the pattern knowledge for building with these tools well, and you would rather acquire it in weeks than discover it over a year.
Not a technology company in what you sell, but one in how you operate, and deliberately so. That is a real strategy, and it comes with a real investment of your own resources. It is a serious decision, because doing it halfway will cost the company more than deliberately capturing the gains without becoming one. The work here is building the capability, not renting it.
Your core business is not technology, what has made you successful is not technology, and neither of those changed because AI arrived. It does not follow that you now have to build a technology function in order to stay competitive. This is the most common answer and the least often said out loud.
If the third one is you, the argument is short. You do not smelt your own steel, you do not build your own payroll and accounting software, and you brief outside counsel rather than keeping lawyers on staff. That is how you keep your effort on what makes the company successful. A digital supply chain is that idea one layer further in: somebody supplies you with an AI workforce and keeps it running, while you carry on doing the thing that makes you worth hiring.
Between building the capability and buying it in, most companies land somewhere in the middle, and the shape is consistent. Nearly everyone gets augmented, a small internal capability holds maintenance and anything genuinely mission critical, and the rest goes outside. Some of those arrangements last a quarter. Some last a decade, and that is a normal outcome rather than a failure to graduate.
Each of those three parts is worth looking at on its own, because they are bought and owned in completely different ways.
The tools end up in most people's day, in most functions. That part is not outsourced to anyone and cannot be. It is your own people working differently, and it is the largest share of the value by a distance.
Usually maintenance, and anything genuinely mission critical. You do not want to be phoning somebody else when the thing that runs your operations stops at seven in the morning. That argues for a small internal capability rather than a department.
Where technology sits beyond your edge, a specialized provider builds it, runs it, monitors it and improves it as things drift, and you pay for what you use. What decides the term is how central the thing becomes, not how long you have had it.
Deciding this deliberately is worth more than any single item on your queue. It settles who you are hiring for, what you will still be maintaining in five years, and which things on the list you should never own at all. Most companies arrive at it by accident, one build at a time, and then discover they have acquired a technology function nobody chose. The three sizes and who runs them is the same decision taken item by item.
The list is rarely the problem. The problem is that nothing on it has been valued, sized or sequenced, so every item looks equally urgent, the loudest one wins, and the queue never moves. Three steps fix that.
What the item is actually worth, calculated on your own volumes rather than a benchmark, with a named owner attached. This is also where the honest answer sometimes arrives: a few things on most lists turn out to be worth very little, and knowing that is worth the exercise on its own.
Every item goes through the same five questions we ask before any build. That puts it in a lane, tells you how quickly it could realistically start, and stops an item that needs a diagnostic from being scheduled as though it were a two-week job.
Value against effort gives the order. Then the part most backlogs never reach: whether your own people can carry that sequence alongside their day, and where extra build capacity is warranted so the queue actually clears rather than being re-sorted every quarter.
Everything lands on the same map: impact up the side, effort across. Not four quadrants, because the bottom half does not deserve two names. Three zones.
High impact, low effort. The top right corner, and the reason this situation is worth resourcing properly. A skill that changes how an entire department works, built in a session or two with the person who does the job, running inside the tools they already have. Almost nobody has a shortage of these. They have a shortage of anyone free to build them.
Medium to high impact, and real effort behind it. Pebbles and rocks: a light system that has to live somewhere and be maintained, or a genuine build with dedicated technical people around it. These earn their place, and they need sequencing, a business case and a decision about who runs them afterwards.
Anything that is not at least medium impact, whatever the effort. Cheap and low value is still a distraction, and it consumes the one thing you are actually short of. A list this size usually contains several, and naming them is the least popular and most useful part of the exercise.
Effort decides sequence and shape. Impact decides whether an item belongs on the list at all. Most backlogs are sorted on effort alone, which is how a queue fills with things that were easy rather than things that mattered.
Two numbers settle the resourcing argument and almost nobody has written either down: what the waiting queue is worth, and what rate you want to hold. The second one matters more than it sounds, because the queue does not empty. It refills, and the question is never how fast you clear it once. It is the rate you can sustain.
Roughly what has one completed initiative returned you, a year?
How many initiatives are waiting in the queue today?
What sizes are they mostly? Sand, pebbles and rocks
How many would you want landing every quarter?
How much build capacity do you have on this today?
Are you building internal capacity for this?
Answer each one to see the sizing.
Tell us who you are and it appears below, yours to use with or without us. If you do book a call afterwards, we open on the numbers rather than on discovery.
A patient portal that already worked and had been paid for, with adoption stuck at about a third because linking each patient to their own record meant searching a database of a hundred thousand people by name.
Read the caseA new aircraft program arrived with one hundred and twenty thousand parts, and every one of them had to be classified before anyone could say which plant would make what, so no manufacturing plan existed at all. Two months of hand classification had cleared somewhere between ten and twenty thousand, and no amount of hiring was going to close the rest.
Read the caseThe builds, sized and assigned an owner (see How we work). Then Stay in control, once several things are running.
Thirty minutes is enough to put the first few items in lanes, agree what a business case would need to show, and tell you what could realistically start within two weeks.