The short version
- Hiring fixes a missing capability or a costly handoff. A rule that nothing enforces is neither.
- An audit of 200 of our own posts found 2,801 breaches of a documented house rule of zero.
- Systems count only when they run in the path of the work: 44 content pages behind a validator, a QA script in front of a newsletter issue.
- The hire worth making here was engineers into a marketing team, because the constraint was the handoff between writing a page and shipping it.
Hiring fixes two things: a capability nobody in the building has, and a handoff that costs more than the work crossing it. A rule that nothing enforces is neither of those. We had a documented house rule against one punctuation mark, restated in every brief, and 200 published posts carried 2,801 breaches of it.
What kind of problem does a hire actually fix?
Two shapes. The first is a capability gap, where nobody here can do the thing at all. The second is a handoff that costs more than the work crossing it. Most of what feels like a staffing shortage is neither.
Watch the failure before writing the job description. Work that comes out different on each pass has no defined process, and a second person doubles the variation. Work everybody agrees should happen and nobody starts needs a name against it, not another person.
What the symptom usually means:
| Symptom | The actual constraint | What fixes it | What a hire does instead |
|---|---|---|---|
| A written rule broken across the library | No mechanism behind the rule | A checker in the publish path | Catches it only in what they review |
| The same note given every issue | Taste never written down | Standing rules plus a QA script | Gives the note again, in their own words |
| Work sitting between two functions | No owner | One name against it | Adds a person nobody assigns it to either |
| Pages ship, then get pulled | No gate before publish | A validator that exits with an error | Another review meeting |
| Writers waiting on a build queue | A handoff | Hire the engineer | Correct. This is the one a hire fixes |
Why does adding a person to a process problem make it worse?
The process gets encoded in them. A standard held in a head is unwritten and gone the week they are on leave, and it does not survive the next person joining, because two defensible versions of it now exist and reviews start arguing about the rule.
Nobody had decided to ignore our em-dash rule. It was written down and restated in briefs and had nothing mechanical behind it, which is a different failure from a shortage of people and does not respond to one.
Which systems replaced a hire here?
The mechanical ones, sitting in the path of the work rather than in a document. 44 content pages on one account run through a validator before publish that exits with an error. A newsletter on another account runs against nine standing editorial rules and a QA script before an issue is queued, and 11 issues have shipped through it, numbers 20 to 30.
Those rules were written at issue 20 rather than issue 1, because that is when the same notes started coming back. A note given twice is a rule nobody has written down, and it costs attention every issue until somebody does.
When is the hire the right answer?
When the constraint is a handoff. We hired engineers into a marketing team, which sounds like a category error and was the most useful hire we have made. The people who write the page can now build it, and the queue between those two jobs stopped existing.
Nobody was short of skill before that hire. The work had to cross a boundary twice, and each crossing cost a briefing and a wait for the next standup.
Two hundred posts, 2,801 breaches, and a rule everybody in the building could recite. No extra writer changes that number.
What has to be true for a system to count?
It runs where the work runs, and it returns a number or an error rather than an opinion. A rule that lives in a document competes with a deadline, and the deadline wins.
It also has to be narrow enough to be right. The moment a check starts failing work that is fine, somebody builds a way around it, and that becomes the normal way to run it.
The two cases either side of this one are hiring engineers into a marketing team and what happens when nobody’s name is on the work.
Frequently asked questions
Should you hire or build a system first?
Build the system when the work already happens and comes out different every time. Hire when it cannot happen at all, or when it crosses a handoff twice. A rule that keeps getting broken is the clearest case for a mechanism.
How do you tell a process problem from a staffing problem?
By the shape of the failure. Different output on each run means the process is undefined. Nothing happening while everybody agrees it should means nobody owns it, and a name fixes that faster than a hire.
What happens when you hire to fix a broken process?
The process gets encoded in the new person, so it leaves when they do and their judgement becomes the standard. Add a second person and two defensible versions exist, at which point reviews argue about the rule.
What should a small team automate before adding people?
Anything with a threshold: banned characters, required fields, minimum length, the presence of a table. 44 content pages on one account sit behind a validator that refuses to publish below the standard.
Does hiring senior people remove the need for systems?
No. The 2,801 breaches of our house rule were spread across 200 posts written by people who could have recited the rule on request. At volume, memory competes with deadline pressure and loses.
When is a hire clearly the right call?
When the constraint is a handoff rather than a rule. We hired engineers into a marketing team and the queue between writing a page and shipping it stopped existing. Nobody had been short of skill.
Sources
- Chua Network delivery data across 8 client accounts (internal fact bank)
- Chua Network engagement records, anonymized (internal experience bank)
