Should You Hire or Automate?

"We need to hire" is usually the first sentence out of a founder's mouth when a team is overloaded, and it's usually said before anyone has actually looked at what the overload is made of. Sometimes hiring is right. Just as often, the honest answer is that the person you'd hire would spend half their week doing something that shouldn't need a person doing it at all.

This isn't a budget question dressed up as a strategy question. Hiring and automating solve different problems. Treating them as two prices for the same fix is how businesses end up paying salary for work a system could have done, or automating something that genuinely needed a person's judgment and then wondering why customers are annoyed.

The Question Underneath the Question

"Hire or automate" sounds like it's about capacity: not enough people, not enough hours. But capacity is a symptom, not the actual question. The real question is what kind of work is filling the hours that are missing.

Some work requires a decision that depends on context a system doesn't have: reading a client's tone, negotiating a scope change, judging whether an exception is worth making. That work needs a person, and adding a system to it either fails outright or produces something that technically ran but didn't actually help anyone.

Other work is the same decision made the same way every time it comes up: format a quote, chase a status update, move data from one place to another, send the reminder nobody remembers to send. That work doesn't need a new judgment call. It needs the existing judgment call, made once, turned into a rule the system follows from then on.

Most overloaded teams have both kinds of work sitting in the same task list, which is exactly why "we need to hire" feels true. The team is genuinely underwater. The mistake is assuming the fix for all of it is the same fix.

When Hiring Is Actually Right

Hiring is the right call when the bottleneck is judgment, relationships, or work that changes shape every time it shows up. A few honest signals:

• The task requires reading a person, not just processing information: negotiating, de-escalating, closing.
• No two instances of the task look the same, so there's no stable rule to encode.
• The output depends on expertise that took years to build, not steps that could be written down.
• The relationship itself is the value being delivered, and a client would notice, and mind, if a person weren't behind it.

If a task fits that description, automating it doesn't save the time it looks like it should. It either can't do the job, or it does a worse version of the job and someone still has to check it, which is often slower than just doing it right the first time.

When Automating Is Actually Right

Automating is the right call when the task is the same decision repeated, at a volume where a person's time is the expensive way to make that decision. Signals here look almost like the mirror image of the hiring list:

• The steps are the same every time, even if the specific details (a name, a number, a date) change.
• The task exists mainly to move information from one place to another, or to trigger the next step once a condition is met.
• Someone on the team could write the rule down in a sentence, because they've been silently following it for months already.
• The task happens often enough that the minutes add up to real hours, even though no single instance feels significant.

This is the pattern behind most quoting delays, status-chasing, and reporting work: not hard, just constant, and constant is expensive at scale even when it's cheap per instance.

Run the Numbers Before You Decide

Both options cost money. Hiring costs a salary. Automating costs the time and budget to build and maintain the system. Neither is free, so "which is cheaper" only means something once you know what the task itself is actually costing today.

The same calculation used to size any capacity constraint works here:

Run that on the specific task in question, not the team's workload in general. A task that costs a few hundred pounds a year doesn't justify either a hire or a build. A task that's quietly draining tens of thousands doesn't need more debate, it needs a decision, and the judgment-vs-repeatable test above tells you which one.

Common Mistakes

• Hiring to absorb a capacity constraint. A new hire doing the same manual task the existing team was already doing doesn't remove the work, it adds a salary to keep doing it. The constraint just moved to a bigger team.
• Automating a task that's actually about judgment. Rules-based systems handle rules-based work. Forced onto a task that depends on reading a situation, they produce a worse outcome that a person then has to notice and fix.
• Deciding at the team level instead of the task level. "We need more capacity" is rarely true of every task the team does. It's usually true of two or three specific ones, and the rest don't need touching.
• Skipping the number and going with instinct. Without the time × frequency × cost calculation, both hiring and automating get decided on how busy things feel, which is exactly the measure most likely to be wrong.

How You'll Know You Got It Right

The judgment-heavy work is being done by someone whose time is actually justified by the decisions they're making, not by tasks that happened to land on their desk. The repeatable work is running without anyone's attention, and the hours it used to cost show up as hours the team now spends on something that grows the business instead. Neither side is generally overworked or artificially padded, because the task, not the org chart, decided where it landed.

Frequently Asked Questions

Can the same role need both a hire and automation?

Yes, and this is the most common outcome, not an exception. A role built around client relationships and judgment calls still usually has admin sitting inside it: reporting, data entry, chasing information. The right move is usually keeping the person for the judgment work and removing the admin from around them, not choosing one for the whole role.

What if we can't afford to build anything right now?

That's a real constraint, but it's a sequencing question, not a reason to default to hiring instead. Running the calculation still tells you which manual tasks are costing the most, so when there is budget to automate, it goes toward the task that actually matters rather than whichever one comes to mind first.

Isn't automation risky if the process changes later?

A rule-based task built around a process that's still changing every few weeks will need rework, that's fair. But that's an argument for stabilizing the process first, not for defaulting to hiring instead. A person doing an unstable process manually still has to relearn it every time it changes, they just don't file a ticket about it.

Where to Start

Before deciding whether to hire or build, find out what the specific task is actually costing, honestly, using the calculation above. That number, not a hunch about how busy the team feels, is what should decide it.