Can you grow your business without growing your headcount to match?
Read: 5 min | Written by: Catherine Duggan 
Image source: Unsplash
Yes, but don’t assume AI is the answer.
Anyone who knows me knows that I ask a lot of questions. Depending on who you ask, the response to these questions can range anywhere from “that’s so embarrassing” (11 year old daughter) to “that’s a persistent line of questioning” (husband) to “that’s a great question” (thankfully, from our clients).
One of my favourite questions to ask our clients is how their businesses actually work. Not how the target operating model says they work, but how they actually work day to day. These two are almost always different, and often for good reason : businesses are on the path to their target operating model and haven’t yet got there, leaving the day-to-day operations working the old way.
Take a conversation I had last week with a client about how a new deal lands on their desk:
The documents arrive by email. Someone opens them, reads through them for the details, and writes an email to the operations team asking for the accounts to be set up. Operations reads that email, keys the details into the core system, and replies to confirm. Someone else checks the details to confirm that they are correct. If a detail is wrong, the thread starts again.
Three people and four emails before anyone had done any actual work. And that’s the version where nothing was wrong.
There is nothing wrong with this process because it works and has worked for years. But, it also means the number of people doing the manual activities in the business has to go up at the same rate as the number of deals coming in. So it might come as no surprise that the question I get asked is often: Can I really grow my business without proportionally growing the number of people needed to support it?
The ratio that runs away with us
Plot two lines for your business: revenue and headcount. For most firms, in 2020 the two moved together, and nobody minded. Growth meant hiring, and hiring is what growth looks like. Draw the same two lines for 2026 and, in the businesses I’m talking to, they’re still moving together. The majority of clients I’ve sat down with this year described a version of their operations in the same way as above: a heavy reliance on people to grow the business. The income to cost ratio really hasn’t shifted in years.
It runs away quietly, one justified person at a time. Each one makes sense on its own. Volume is up, the team is stretched and burning the midnight oil because the work has to get done. The person approving the fifth new joiner in the team is rarely asked why the systems couldn’t absorb the extra work instead.
The real question only surfaces when you are offered more business, and you have to think about whether you can take it. That moment, when demand is there and the operation is what says no, is the capacity ceiling. It isn’t a market ceiling. It’s a systems one.
Why hiring is the default and the other workarounds
Hiring is the default answer because it’s the one everyone can visualise. You know what a person costs and you know roughly what they’ll do. But it’s also the wrong answer to a systems problem. A person covers what one person covers, and when the volume rises again you need another. The cost is permanent, but the problem it was hired to solve was a throughput problem that a system might have solved once.
The other default is to live with it. Workarounds on workarounds. We all have that spreadsheet with the title “filename_today’sdate_final_CD”, or the process step that only one person knows how to do that can take hours to do. These can often cost more than just hiring, namely the opportunity cost of the work you never took on because everyone was already at capacity.
The pattern is the same whether the thing arriving is a deal, a claim or a new product. Something comes in as a document, a human turns it into structured information by hand, and the coordination happens in inboxes. The more of it there is, the more humans it takes.
Both defaults are the short-term answer. There’s another path.
Same team, far more impact
Go back to the deal. Now imagine there is a system for it. The details are captured once, in a structure, at the point they arrive. Operations gets a record, not an email. The check is a step in a process, and if something is missing, the system says so before anyone downstream has started work on the wrong version.
Nothing about the team has changed. The same people are doing the work. What’s gone is the coordination overhead: the reading, re-keying, chasing and confirming that consumed hours in activities that were not a part of anyone’s day-to-day responsibilities.
The number of people doesn’t fall to zero, and it mustn’t, because we always need human oversight. The goal is that the hiring line stops tracking volume. Twice the deals no longer means twice the people, because most of the effort per deal was never in the deal. It was in the handling of the deal.
This asks something of the team. A system changes how a deal is handled, and change creates tension. But the old way was tension too. It was just spread across inboxes where nobody added it up. The difference is that this effort is spent once, and it makes the work better rather than merely faster.
I should say that this argument is playing out inside StructureIt too. We have more clients, so the obvious answer was to hire. But innovation prevailed. Our software delivery lifecycle has been turned on its head and AI now does the lion’s share of it. What’s left is the judgement needed to make the code safe, secure and production ready. So we’ve been adding senior people incrementally, as opposed to proportionally. Thankfully, our own headcount line has stopped tracking our project count, for exactly the reason I’m describing to clients.
Building it is now worth it
For years the honest answer to “why don’t you have a system for this?” was that the payback on building something didn’t make sense. Custom software was expensive and time-consuming to build, and the existing manual process was cheaper or simpler to live with. So people lived with it, and hired.
That payback period has changed. In our own delivery, the cost and time of building systems has fallen, and it has fallen because of how we build them, with AI doing a large share of the code and a senior team doing the judgement. That is the one place AI belongs in this story: in the delivery, making the system worth building. A build that never cleared the business case can now reasonably be asked to pay for itself within a year.
Note what this isn’t. It isn’t Copilot in the inbox. Give the person writing the email to operations a chatbot and you get a faster email. More convenient, but not necessarily better.
The much larger dividend everyone is talking about, where the work itself gets done differently, comes later, and it only comes if the system exists first. That’s a story for another day.