Build the System Before You Add the Person

The test

When the pressure is on, hiring feels like the obvious move. Work is not getting done, and a person does work. The logic is clean and it is frequently wrong.

Here is the question I would ask before writing any job description: if the best possible candidate started tomorrow, could you tell them precisely what to do on their first Monday?

Not the mission, not the area of ownership. The actual work. What arrives, what they do with it, what leaves, and how anyone knows it went well.

If you can answer that, you have unstaffed work and hiring is correct. If you cannot, you have undefined work, and hiring a person into it means they will spend their first quarter discovering the process, inventing it, and getting judged against a standard nobody wrote down.

That usually ends with someone concluding it was a bad hire. It was not a bad hire. It was a bad requisition, and I think this is the single most common expensive mistake in early teams.

The uncomfortable part is that the definition work is the same work whether you do it before or after hiring. Doing it first is cheaper and does not cost someone their confidence.

What a system actually is

The word gets used loosely enough to be useless, so here is the version I mean. A system has four parts and if any one is missing it is not a system, it is a habit.

A trigger. What starts it. A form submission, a date, a threshold being crossed, a stage change. If the answer is "when someone notices," the trigger does not exist and the process runs on whoever happens to be paying attention.

An owner. One name. Not a team, not a rotation without a schedule. Shared ownership of an operational process reliably means nobody owns it, and this becomes visible only when it fails.

A defined output. What exists at the end that did not exist before. Written down, in a form specific enough that two different people would produce recognizably the same thing.

A place it lives. Where the state is visible without asking anyone. A queue, a board, a table. If the only way to know the status is to interrupt a person, you have a person, not a system.

Build it in the boring order: write down what already happens, remove the steps nobody can justify, automate what is genuinely mechanical, and only then decide what human judgment remains.

That last part is the point. Automation is not the goal. The goal is that the remaining human work is the part that actually needs a human, which is also the part worth paying for.

When hiring is the right answer

I would rather be honest about this than sell a rule that does not hold, because the advice to systemize first gets applied to situations where it is wrong.

A capability you do not have. You cannot systemize your way into design, security, or a function nobody on the team understands. Trying produces a process that encodes a misunderstanding, and someone will be paid to unpick it later.

Volume on a process that already works. If the system is defined and running and the constraint is genuinely hours, that is exactly what hiring is for, and delaying it to build more process is procrastination wearing a strategy costume.

Judgment that cannot be specified. Some work is decisions all the way down, and writing it as a process produces a document nobody follows because it does not describe the job.

Something you need to move faster than you can learn. Buying experience is legitimate. It is expensive and it works.

And when you do hire, the written process pays for itself twice more. It becomes the interview, because you can ask a candidate to walk through the actual work rather than answer hypotheticals. And it becomes the ramp, because a new person can see what the job is instead of reconstructing it from meetings over six weeks.