Systemise before you hire: the order matters

Systemise first, hire second. A new hire dropped into an undocumented business inherits your chaos and returns it with a salary attached — a junior BDR alone runs £35k+ a year, or £2,900+ a month before you add management time. The order matters because a documented, measured process makes an average hire productive, while an undocumented one makes even a strong hire dependent on you for every decision.

Why does hiring first usually fail?

Because the hire has nothing to run. When a founder hires to escape a bottleneck they have never documented, the new person spends their first months reverse-engineering how the business actually works — usually by interrupting the founder. The bottleneck does not move; it acquires an assistant. I have written about this pattern at length in The Founder-as-Bottleneck Report: owner-dependence is a design problem, and headcount on its own is not a design change.

There is a second failure mode, and it is quieter. Without a defined process there is no baseline, so when results disappoint you cannot tell whether the hire is underperforming or the process is broken. Most founders resolve that ambiguity by replacing the person, then repeating the experiment with a new salary. Two failed hires at BDR rates is £70k+ spent learning that the problem was never the people.

What does "systemise" actually mean?

Not a hundred SOPs and a wiki nobody reads. A business system is a documented, repeatable process with a named owner, a defined input, a defined output, and a number attached — I have set out the full definition in What is a business system, actually?. For hiring purposes, three tests matter:

• Written down. The process exists outside your head, in enough detail that a competent stranger could follow it.
• Measured. There is at least one number that tells you whether this week's execution was better or worse than last week's.
• Trigger-based. Each step starts on a condition, not on someone remembering. "When a proposal goes out, then a follow-up task is created for day three" — not "chase proposals when you get a chance".

If a function passes those three tests, a hire can run it from week one and you can judge them against the numbers. If it fails them, you are not hiring into a role; you are hiring into a fog.

In what order should you systemise?

The sequence I use with clients is deliberately boring:

1. Pick the function eating the most founder hours. Usually it is prospecting, follow-up, or reporting — rarely delivery, which founders tend to protect.
2. Record yourself doing it for two weeks. Not writing about it — doing it, with a log of each step, decision, and exception as it happens.
3. Extract the triggers. Convert the log into when-X-then-Y rules. When a lead replies, then it is answered within one working day. When a list is built, then every address is verified before sending.
4. Run the document, not your memory. For a fortnight, follow your own written process exactly. Where you deviate, the document is wrong — fix it.
5. Only then decide who runs it. Some steps go to software, some to a hire, some stay with you. The point is that the decision is now about a defined process, not a vague hope.

Data work is the cleanest example. Building a prospect list — sourcing, enriching, verifying — is a fully definable process, which is why we treat it as an engineering problem in The B2B Database Building Guide rather than the first task thrown at a new hire.

When is hiring the right move?

When the work genuinely needs judgement, relationships, or presence — and the system around it already exists. Hiring a closer once your pipeline reliably produces booked calls is a good trade: the system generates the flow, the human converts it. Hiring a "growth person" to invent the flow, define the process, and hold themselves accountable is delegating the founder's job to someone with less context and less authority.

The honest test: could you write the new role's first-month checklist today, with numbers? If yes, hire. If no, you have found the work to do before the job advert goes out.

What should you do this quarter?

Choose one function, run the five steps above, and see what falls out. In practice much of what founders plan to hire for turns out to be automatable or deletable, and revenue can grow well before headcount does — I have covered that path in Growing revenue without growing headcount. The salary you were about to commit is a year of system-building budget; spend it in the right order.

---

Next step: the Growth System Audit — £450, seven days, credited against any build — maps where your growth system leaks and what to build first.