When to Hire and When to Automate

When work exceeds capacity, the options get compared on price. A person costs a salary. Software costs a subscription. The subscription is smaller, so software wins, and the business automates.

Sometimes that is right. Often it answers a question nobody asked, because people and automation do not provide the same kind of capacity, and the work does not always need the kind that is cheaper.

Two different kinds of capacity

Automation provides throughput on a known rule. It does the same thing quickly, consistently, and without complaint, as long as the situation matches what it was built for.

A person provides judgement on an unknown case. They notice when something is unusual, work out what the customer actually meant, and decide what to do when the rule does not fit.

Almost all work is a mixture, and the mixture is what the hire-or-automate decision should be about. The question is not "can this be automated" but "what proportion of this work is a known rule, and who handles the rest".

The trap of automating the average

Most processes have a common case and a long tail. The common case is 80% of volume and 20% of the difficulty. The tail is the reverse.

Automation handles the common case beautifully. It is built from the common case, and its accuracy is measured against the common case. The tail either falls through to a person or, more often, gets handled badly by a rule that was never designed for it.

Here is the part that surprises people: automating the common case does not reduce the need for judgement, it concentrates it. Whoever is left handles nothing but exceptions, all day. That is harder work than the mixed job it replaced, requires more expertise, and burns people out faster.

So the honest version of the decision is not "hire or automate". It is: if we automate the routine, do we have someone capable of handling a queue that is now entirely difficult cases?

What automation genuinely does better

It does not forget. It does not get bored on the fortieth repetition and skip a step. It does not have a bad week. For anything where consistency is the main virtue — reminders, filing, routing, formatting, scheduled checks — it is not merely cheaper but better, and hiring for that work is a poor use of a person.

It also scales without a lead time. A person takes weeks to hire and months to become effective. If the volume is genuinely temporary, automation absorbs it and then costs nothing extra when it recedes.

What it does badly, and does not tell you about

It fails silently. A person who cannot do their job says so; an automation with a wrong assumption keeps running and keeps reporting success. This is the cost that never appears in the comparison, and it is the largest one.

It cannot tell you the rule is wrong. It applies the rule. When circumstances change — a supplier alters their format, a tax rate changes, a customer segment starts behaving differently — a person notices something feels off. Automation applies the old rule to the new world with perfect consistency.

And it duplicates when it should not. Anything crossing a network boundary faces the situation where a request succeeds but its confirmation is lost, so the sensible response is to retry, and the result is the action happening twice. The protection is idempotency — the effect of repeated identical requests being "the same as the effect for a single such request" [1] — and it is worth asking about before you depend on the automation for anything that charges money or contacts a customer.

The hidden costs on both sides

Hiring costs more than salary: recruitment, onboarding, management attention, and the fact that a new person is a net drain for their first months.

Automation costs more than the subscription. Somebody specifies it, and specifying is the expensive part. Somebody maintains it when the world moves. And critically, somebody must own it. Automations without an owner do not degrade visibly; they persist, doing something slightly wrong, until an unrelated investigation finds them.

There is also an access cost that gets overlooked. Automation runs with credentials, and those credentials tend to be broad — an integration is easier to build with wide permissions than narrow ones. Every automation is therefore a standing grant of access that outlives the person who created it. The guidance on credentials is clear that rotation should not be arbitrary but "verifiers SHALL force a change if there is evidence of compromise" [3], and applying that requires knowing which automations hold which credentials. Most businesses that have automated steadily for a few years cannot produce that list.

The option nobody costs: stop doing the work

There is a third answer that rarely gets considered, because the question is usually framed as how to get the work done rather than whether it needs doing.

Work accumulates in a business the way possessions accumulate in a house. A report is produced weekly because it was once requested by someone who has since left. A field is filled in because it was mandatory in a process that changed. A check is performed because of an incident four years ago that the current controls already prevent.

Before deciding between a person and an automation, it is worth asking who consumes the output and what decision it changes. If nobody can name a reader, automating it is the worst possible outcome: the cost becomes invisible, so the work becomes permanent.

Automation is unusually good at preserving obsolete processes, because it removes the friction that would otherwise have prompted somebody to ask why they were still doing this. A tedious manual task eventually gets questioned. The same task, automated, runs silently for a decade.

A more useful way to decide

Ask what the work is mostly made of. If it is mostly a rule, automate the rule and keep a person for the exceptions. If it is mostly judgement, hire, and automate the administration around the judgement so the person spends their time on the part only they can do.

Ask what happens when it is wrong, and how fast you would know. Where the answer is "badly, and slowly", prefer a person — not because people are more accurate, but because their errors are individual rather than systematic.

And resist the instinct to automate the reporting layer first. Dashboards and status fields are the easiest things to automate and the least valuable, because they generate the appearance of control. That is the same reflex as collecting data speculatively "in case it is useful later" [2]: activity that resembles rigour without producing a decision.

The best answer is frequently both, in the specific order: automate the repetitive middle, hire for the judgement at either end, and make sure one named person owns each automation you come to depend on.