Do I need to raise to hire more engineers?

Usually, no. If engineering can’t keep up with what the business needs, the capacity you’re looking for is usually already in the building. It’s just held up by work waiting in queues, unclear priorities, code nobody fully understands, and the cost of coördinating everyone. Free that first. If you still need more people afterwards, at least you’ll know how many, and you can decide whether to raise, how much, and how, on evidence rather than hope.

That’s the short answer. The rest of this piece is how to tell which situation you’re in, what raising to hire really costs, when it’s the right call, and what to do first.

Why doesn’t hiring more engineers make us faster?

Because every new person adds a little capacity and a lot of coördination.

Fred Brooks put it bluntly in 1975: adding people to a late software project makes it later (Brooks’s law). New engineers take months to become useful, and the people who teach them are your most experienced ones, so output dips before it rises.

Then there are the conversations. A team of 6 has 15 possible lines of communication between its members. A team of 12 has 66. Double the people and you more than quadruple the ways a message can be lost, delayed, or misread. Complexity grows faster than headcount does.

I’ve seen this from the inside. Seventy engineers in six teams were shipping on a three-month cycle, in a company that had spent a long time trying to fix speed with pressure. Everyone knew that speed was a problem. But nobody had bothered to go and find what was actually slowing it down.

The TLDR: it was confusion.

We moved the six teams from waterfall to scrum, and the delivery managers who had been running them became scrum masters or engineering managers depending on their skills and passions, rather than being replaced. Where possible it’s better to retain and retrain, because the people who know where the work was buried were the ones best placed to dig it out. Three months became two weeks or less (and getting faster), and in the same year the function returned the only positive eNPS score in the department.

So what delivered that speed … it was clarity around their roles, clarity around what mattered to the business and to the customers, and the autonomy to make the decisions needed to reach those ends.

It wasn’t free. It cost me my standing with some of the senior leadership, in a company that expected leaders to know every detail. Giving direction and then leaving room to decide meant walking into meetings without the answers they expected, and being honest about the ambiguity instead. It didn’t always go down well, but the results I produced in the end did.

Where is the capacity hiding?

In the teams I’ve led, in four key places.

Work that waits

Work spends far longer waiting than being worked on: for a decision, a review, a test environment, another team (the list would be endless). Every queue is capacity you’re already paying for and not getting. Adding people adds to the queues at the same rate it allows the queues to be handled, it’s the exact same problem … just bigger.

Priorities nobody can name

When everything’s urgent, nothing is. If your team can’t tell you what matters most this week, they’re busy, but on what? More people means more of that. More decision makers, more decisions to be made, more voices. Sure you end up with more. But more what exactly?

Code nobody uses

Code is inventory. Every line has to be stored, understood, tested, secured, and carried into every change you make, whether anyone uses it or not.

At one company, about a quarter of the front end’s code (measured in lines) was never referenced and could never reach a user. So I deleted it, and changed the pipeline to stop building and testing code that nothing used. Builds went from around 20 minutes to around 3, for every team building on that front end. Deleting code is deflationary. It can be some of the cheapest capacity you’ll ever buy.

Communication

Most problems are people problems, and most people problems are communication problems. Every hand-off between a customer and the engineer who builds for them is a chance for the reason behind the work to get lost. Bad news that travels slowly arrives as a crisis. A team that can’t say who its work is for drifts.

A post-merger engineering team of a little over 30 people was working in silos and shipping reliably less than half the time. The technology wasn’t the problem. Six months of building the foundations (structures, a shared language, and clarity about what the work was for) took delivery reliability from below 50% to above 90%, and a $300K account that was leaving, stayed.

How can I tell if we’re short of people, or short of clarity?

Ask these, honestly:

How long does a typical piece of work wait, compared with how long it’s actually worked on? If you don’t know, that’s the first thing to find out.
Can each team tell you what matters most, and for who, and is it the same answer you’d give?
How often do priorities change once work has started?
When did someone last delete more code than they wrote?
How many people does a decision need, and how long does it take?
Have your engineers heard a customer describe a problem in their own words?
Are your most experienced engineers building, or in meetings?

If most of the answers point to waiting, churn, and slow decisions, more people will make it worse. If work flows, priorities are clear, and the team is still at full stretch on the right things, you may genuinely be short of people. That’s a good problem, and a much easier one to fund.

What does raising to hire really cost?

The equity, first. The share you sell doesn’t come back.

Then control. Investors are owed a say, and an expectation about how fast you’ll grow and how they’ll get their money out. That’s fair; it’s the deal. It’s also a different deal from the one you had.

Then, sometimes, the mission. When the growth rate is set by someone else’s model, what the company is for can shift without anyone deciding it should.

And time. A raise takes months of your attention. Hiring takes months more, and new engineers take months after that to be fully useful. If headcount is how you grow, the next stage needs the next round.

It’s also rarer than it can feel. In 2024, UK small businesses closed about 5,400 equity deals between them (British Business Bank, Small Business Equity Tracker 2025), against about 2.7 million businesses registered for VAT or PAYE (ONS, 2025). Most companies grow without it. You can too.

What if I borrow instead?

Then you keep your equity, and your control. A lender wants its money back with interest, not a share of your company or a seat at your table. For a lot of founders that’s the better trade, and it’s the oldest one there is.

But debt changes the shape of the risk rather than removing it. Repayments are due every month, whether or not the people you hired have made you faster. And engineers are a fixed monthly cost too. Borrow to hire, and you’ve turned an uncertain bet (will more people fix this?) into a fixed obligation. If the real problem was waiting, priorities, or communication, you’ll be paying interest on a bigger version of it.

So debt suits spending with a return you can predict. Freeing the capacity you already have, first, is what makes the return of any hire predictable.

If you’ve done that, and the numbers work, the options in the UK include:

A bank loan or overdraft. Lenders look at your cash flow, and how comfortably it covers the repayments. Many will ask for security, or a personal guarantee.
A government-backed loan, through the British Business Bank’s Growth Guarantee Scheme. You apply through an accredited lender, and the government guarantees part of the loan, which can help when a lender would otherwise say no.
Revenue-based finance. You’re advanced a sum, and repay it as a share of your revenue until an agreed total is reached, so repayments rise and fall with your takings. It suits recurring revenue, and it usually costs more than a bank loan.

And before borrowing anything, check what you’re owed. If your engineers are solving technical problems that haven’t been solved before, R&D tax relief can return part of what you spend on them. It isn’t a loan, and it isn’t equity. Ask your accountant whether the work qualifies.

When is raising to hire the right call?

Sometimes it is. When:

you’ve freed the capacity you have, and the team is still stretched on work that clearly matters;
you know what you’d build with more people, and can show what it would return;
a window is genuinely closing, and speed now is worth the equity;
you need skills the team doesn’t have and can’t grow in time.

If that’s you, raise. You’ll raise knowing exactly what the money is for, and what it can’t fix. That’s a far better conversation to walk into than “we need more engineers”.

Which kind of money is a separate choice. Equity suits a big, uncertain bet where you want partners who share the risk (and bring their backing and network). Debt suits a return you can predict and repay from revenue. Either way, the question comes first: is it people you’re short of, or clarity?

What should I do first?

Find out where work waits. Pick a handful of recent pieces of work and trace them from idea to customer. Note every pause, and why.
Name the one thing that matters. Write down this quarter’s single most important outcome. Ask each team lead to do the same, without seeing yours, and compare.
Delete something. A feature nobody uses, a report nobody reads, a meeting nobody needs. Watch what gets faster.
Put the people building it in front of the people buying it. Even one customer call a fortnight changes the questions engineers ask.
Then decide. With the waiting, the priorities, and the inventory in front of you, the hiring question usually answers itself.

If you’d like help with it, that’s what I do. In two weeks, find out whether your next stage needs capital, or whether the capacity is already in the building. It’s called the Growth Without Dilution Plan: three or four days of my time inside your company, then a written plan showing where your capacity is trapped, what unlocking it takes, and what the alternative raise would cost you in equity, side by side. You keep the plan whatever you decide. Let’s find another way.

Who this is for

This is for founders and CEOs of companies that have grown on their own revenue, exist to do something rather than only to reach an exit, and are being told the next stage needs capital and more engineers.

It isn’t for VC-backed companies that have already chosen capital and hypergrowth, for private equity portfolio operations, or for anyone looking for a CTO to run sprints.

Let’s find another way