Don't hire until your operations are designed

8 min readSimon BudziakBy Simon Budziak

On this page8 sections
A navy panel holding a chain of four connected nodes joined by glowing gold lines, with a fifth node floating above it, unattached, its would-be connectors fading into nothing.

Nine weeks into running Soba Labs, one of the very first fully AI-native agencies, I was ready to hire a marketer, and probably a salesperson after that. I did not, and the reason is the most useful thing I have learned so far. A hire cannot fix an operation that was never designed. It can only staff it, at which point the missing design becomes permanent and expensive.

The question that stopped me

The reasoning felt obvious. Marketing was inconsistent, outbound was slow, and I was doing both between client work. The standard answer is to hire someone whose job that is.

So I argued it out instead of deciding it: a long session with Claude, the research on how firms our size actually win work, and a recent post by people who have built much bigger companies than mine. I came out with a different diagnosis than I went in with.

The problem was not the door. It was that not enough people were knocking on it. The offer was not wrong and the messaging was not broken. There were simply too few people arriving at the top, and a marketer is the reflex answer to that.

Then I asked what I would hand that marketer, and I could not answer. No defined process for finding a prospect, no qualification bar, no message standard, no place where the outcome of an attempt got recorded. I would have been paying a salary for someone to invent all of that while also doing the work.

A mock job advertisement for a Marketer role, marked draft, never posted. The week-one responsibilities are to decide what a good prospect looks like, invent the qualification process, write the message standard from scratch, and build somewhere to record whether any of it worked, and then, if there is time, the marketing. It reports to someone who cannot describe it yet, and success is to be determined by the hire.
The job ad I would have had to write, if I had written an honest one.

A competent marketer would have produced roughly what I could produce in a few days of concentrated thinking, only slower and at several times the cost. The bottleneck was never capacity.

The moment you cannot write down what the new person will do on their first Tuesday, you are not hiring. You are outsourcing a decision you have not made.

Why a hire cannot fix an undefined process

W. Edwards Deming put it in one line at a seminar in Phoenix in February 1993, recorded by the Deming Institute: “A bad system will beat a good person every time.”

Hiring into an undefined process does not import structure. It imports one more person improvising inside the same vacuum.

Adding a second person to an undefined process does not halve the confusion. It doubles it, and now the two of them have to agree with each other.

What changed with AI is not the principle, it is the price of the alternative. You can sit with a capable model, work out how qualification should run and where the state lives, and have a serviceable first draft in an afternoon. That is what you were going to pay someone to produce over three months.

Design for the model you will have in three months

The mistake I see people make: they measure what a model does today, decide it falls short of a person, and hire.

The relevant question is not what the model does this week. It is what it will do by the time your new hire has finished onboarding.

A role you open now is a decision you live with for years, while the capability you measured it against moves in months. Scope to today’s ceiling and you have built for a constraint that lifts before the process runs.

The tooling is already well past a chat window. Agentic harnesses are general-purpose, not coding tools. Claude Code, OpenAI’s Codex and OpenCode run the same loop: read the context, use real tools, do multi-step work, write the result back. We use it for CRM records, the outbound pipeline, research and long workflows, and only sometimes for code. If your mental model is “autocomplete for programmers”, you are pricing a hire against a product that stopped existing a year ago.

xAI’s Grok Bot, in early beta, shows where this goes: “AI teammates you can give real work to”, bots that “sign in to your tools, use them just like you do, and come back with finished work”.

The Grok Bot desktop app: a sidebar of named bots including Chief, Sales Outbound, Inbox Manager, Account Manager, Talent Scout and Expense Manager, and a thread in which the Account Manager and Chief bots hand work to the Sales Outbound bot, which reports pulling accounts from Salesforce and queueing 36 drafts with none sent pending review
xAI's Grok Bot, early beta. Note the sidebar: these are named roles, not tasks. Screenshot from xAI.

The unit you design is no longer a task you automate, it is a role you define. Better to have thought about that before you write a job description than after.

What the agency data shows

SparkToro released the sales and marketing results of its State of Digital Agencies survey in February 2026. 79% of agencies have nobody dedicated to their own marketing, and 70% have nobody working sales full-time. In most firms it lands on the founder, which is where I was standing.

So hire one. Except only 14% describe their pipeline as healthy, and of the 59% who tried outbound sales, just 9% call the results very effective against 33% not effective at all.

Four out of five agencies have no marketer, and the ones who go outbound have roughly a one in ten chance of calling it very effective. The hire is not what produces the pipeline.

What does produce it is unglamorous: client referrals remain by far the biggest driver, partner referrals top for another 15%, and speaking at events climbed from sixth to fourth, overtaking outbound. None of that is a job you hand a new starter. It is a consequence of how the firm works.

One number explains the urgency. 53% of agencies now agree AI poses a significant threat to their business model, up from 44% the year before (launch post, 376 respondents). The most exposed are those whose operations live in people’s heads, precisely what cannot be handed to an agent.

What we built instead

Outbound now runs as a system rather than a habit. Prospects, campaigns and every recorded action live in a database, a deterministic sweep decides what is due, and it runs on its own server rather than my laptop. A human approves every message before it leaves.

The company’s knowledge is written in plain text under version control, readable by me and by the agents doing the work: decisions and why, the patterns we reuse, the qualification bar. Repeated work is packaged as skills, so a task done well once is done the same way next time. A gate blocks a session from ending until what was learned is written back.

The point is that it is written, so it can be handed over, criticised, improved, or given to an agent. An operation that exists only as my judgement in the moment can be handed to nobody.

The exception, because there is one

None of this replaces people, and it is not close. A company is not a hundred agents and nobody, least of all at the start, when there is no defined operation for an agent to run.

We are hiring a few engineers. Client delivery is genuinely capacity-bound: a defined standard, a defined process, more work than one person can do inside it. The roles exist because the system they plug into already exists. That was not true when we started the company. How work gets specified, reviewed and gated is now designed and written down, so whoever joins inherits a repeatable process, not my habits.

Labour is still leverage, but applied on top of an operation rather than instead of one. McDonald’s is the clean version: the franchise did not scale because they hired more people, it scaled because they specified the operation precisely enough that a new location could reproduce it. The people came after the system, the only order in which adding them multiplies anything.

We will hire a marketer too. This is about sequence, not headcount. What changes is who the role is written for: not someone who executes by hand, but someone fluent with agents and harnesses, who can pick up Claude Code or Codex and extend the operation rather than only work inside it. Designing the system first is the only way to tell those two apart at interview.

Decision card contrasting two situations before opening a role: the constraint is capacity, where a defined standard and process already exist and hiring is right, versus nobody has decided how the work runs, where the operation should be designed first
The question to answer before a role is opened, not after the first candidate impresses you.

If the honest answer is “nobody has decided”, a hire will not decide it for you. It will add someone with an opinion, a salary, and a reasonable expectation that you knew what you wanted.

Conclusion

Design the operation, then decide whether it needs a person. In that order the role is specific and the new person compounds what already works. In the other order you are paying someone to do the thinking you avoided, and you will not know for months whether they did it well.

I am writing one of these every week, mistakes included, rather than saving it for a retrospective I have not earned.

Sources

See this working in a system we built