The short version
- Write the role against the constraint. Ask what stops work from going live, the same question that finds the approvals nobody listed on a launch plan.
- We put engineers inside the marketing team because the handoff was the bottleneck, not the skill at either end. Three AI engineers sit in the team rather than in a queue behind it.
- The build-or-buy test transfers to headcount: build when the workflow is the product, buy when the workflow is standard.
- A first hire sets where decisions get recorded. If theirs land in private messages, everybody hired after them copies that.
A first hire sets the standard for the role before anybody has written one down, and every hire after it is measured against that. The salary is the recoverable part. The expensive error happens earlier, when the role is written against a symptom rather than against whatever is actually stopping the work.
What does a first hire actually cost?
The salary stops when they leave. What persists is the definition of the role, because nothing was written down before the person arrived and what they do becomes the description. The second candidate gets interviewed against a job spec the first hire wrote by behaving.
Most constraints that present as a headcount problem are not one. Work waiting on a handoff, a note given twice, finished work that will not go live, a blog nobody restored, a product that shipped to nobody: one of those needed a person.
Five constraints we have hit, and what each one turned out to need:
| How it presented | What it turned out to be | What it needed |
|---|---|---|
| Pages waiting between the writer and whoever builds | The handoff, not the skill at either end | Engineers inside the marketing team |
| The same editorial note given twice | No written standard | Nine standing rules and a QA script |
| Finished work that would not go live | Two approvals nobody had listed | Every gate named with an owner at kickoff |
| A blog down for weeks | No single name against the restore | One owner |
| A product live and earning nothing | Distribution deferred to launch | Months of lead time, planned before the build |
How do you write the role against the constraint?
Ask what stops work from going live rather than what work exists. That question surfaces the approvals nobody listed on a launch plan, and it works the same way on a job description.
When pages waited between whoever wrote them and whoever built them, another writer would have added throughput to the side that was already fast. Three AI engineers sit inside the marketing team now, so the person who decides what a page says decides what it does.
When should you contract the work instead of hiring for it?
Use the test that decides build against buy. We built a learning centre in-house on one account rather than buying a course platform, because the workflow there was the product. Standard workflows go the other way.
The seat you create first should own something that stays yours. Anything a competent supplier already runs to a known standard costs the same to manage and hands back less.
What does a first hire set that you cannot undo later?
The bar. Every later candidate is compared against the person already in the seat, whether or not anybody intends it. A first hire below the standard makes it harder to raise than it was to set.
They also set where the record lives. We run one shared channel per relationship, because a decision only two people can see gets made a second time by whoever touches the work next. Whichever habit the first hire brings becomes the house default.
Hire against a symptom and you keep the symptom, now with a salary attached to it.
What does hiring against a symptom look like a year later?
The symptom has not moved. Pages still wait, because the queue was the constraint and the queue now contains one more person.
One of our own products makes the shape obvious. Designed, built, integrated with payments and fulfilment, shipped, and it earned nothing across its entire life. Every question had been answered except how the first hundred people would arrive, and that one was deferred to launch, where it turned out to need months of lead time.
The two decisions behind this one are covered in why our writers can also build and the build-or-buy decision.
Frequently asked questions
What does a bad first hire actually cost a company?
The salary is the part you stop paying. What persists is the definition of the role, because nothing was written down beforehand and what the first hire does becomes the description every later candidate is interviewed against.
How do you decide what your first hire should do?
Write the role against whatever stops work from going live, not against the longest list of tasks. We hired engineers into a marketing team because the handoff between writing and building was the constraint, and the skill at either end never was.
Should you hire someone or use a contractor for the first role?
Apply the build-or-buy test to headcount. Build the seat when the workflow is the product and nothing off the shelf knows it. Buy the workflow when it is standard, because a supplier whose whole business is maintaining it will run it better.
How do you avoid hiring against the wrong problem?
List what is blocked rather than what is busy, then name the cause of each blockage. Work waiting on a handoff, a note given twice, finished work stuck behind an unlisted approval and a blog nobody restored were four different constraints for us.
What does a first hire change about how a company works?
The default for where decisions live. A decision only two people can see gets made again by whoever picks the work up next, so a first hire who works in private messages teaches everybody after them that a private message is where a decision happens.
How soon do you find out a first hire was wrong?
As soon as the work ships often enough to produce a repeated correction. Weekly delivery gives around 50 correction opportunities a year against 12 on a monthly rhythm, so a mismatch surfaces in weeks.
Sources
- Chua Network delivery data across 8 client accounts (internal fact bank)
- Chua Network engagement records, anonymized (internal experience bank)
