Prove You're Short-Staffed Before You Hire: A Bottleneck Test
Busy and short-staffed are different conditions. Before your first hire, run a two-week time audit, try three cheaper alternatives, and count the full cost of a headcount commitment.
For a company with fewer than ten people, the first salary is usually the most expensive expense in its history. Not because of the amount, but because it turns "running a business" into "managing people." Until that day, you are only accountable to yourself. From that day on, you have someone who needs context, feedback, and performance judgment. And the money leaves your account every month, regardless of your mood or product progress.
Take a hypothetical example: a six-person product team, growing user feedback, founder replying to messages during the day and fixing bugs at night for three weeks straight. Monday all-hands: "We need to hire an operations person." Classic. But busy and short-staffed are two different diseases.
Busy can come from a broken rhythm, an unfiltered request stream, or you doing work you shouldn't be doing. Short-staffed means there is a category of tasks that occupies the critical path, recurs predictably, and can only be absorbed by fixed headcount. The entire hiring decision is the difference between the two.
My position: hiring is not a milestone, it's a commitment. It changes your cost structure, your time allocation, and your company's communication radius every single month. So a small team should treat hiring like launching a new product: data first, hypothesis second, cheapest validation third.
Step 1: Two weeks of time audit
Don't say "I'm busy" from feeling. Busy is a feeling; a bottleneck is a measurable position.
Take a sheet of paper or a simple table. Every half hour, write down what you're actually doing. Do this for two weeks. On the weekend, sort the records into three piles:
- One-off decisions: writing plans, making choices, firefighting. Hiring can't fix these — you still make the decisions.
- Coordination: replies, meetings, explaining context. This grows as headcount grows. Hiring doesn't digest it; hiring creates it.
- Repetitive execution: adjusting styles, writing copy, handling support, importing data. This is transferable, measurable, predictable work.
A bottleneck is a task category that meets three conditions at once: it takes the most time, it blocks others, and it will appear again next week. The "blocks others" part is critical. If only you are waiting on it, it's your anxiety, not the company's bottleneck. If three or four people are stuck behind it, it has hiring value.
A quick contrast:
- Busy firefighting → rhythm problem, not a headcount problem.
- Busy waiting → process problem, not a headcount problem.
- Busy with predictable repetitive execution → we are finally talking about headcount.
If you can't name such a task after two weeks, what you lack is not people but judgment.
Step 2: Try three cheaper solutions first
Before writing a job post, run three tests. Each one costs far less than a month of salary:
- Eliminate: Does anyone actually wait for this task? Stop it for a week. No user complaints, no colleague follow-ups — the cheapest labor is the labor you don't need.
- Simplify or automate: Cutting 50% of a recurring task's time is like gaining half a person. Find a tool, write a script, compress a five-step flow into two. Don't chase 100% automation; recovering 20% of your hours is already a good deal.
- Outsource or go part-time: Cut the task into a one-month package and give it to a freelancer. Think of it as a reversible experiment. If the delivery makes you happy, the task is delegable. If you spend the same hours fixing the result, the problem isn't the workforce — the requirement was never clear.
After these three steps, most "we need to hire" conclusions land in one of two places: the problem disappeared, or it shrank into one specific detail you actually want to solve.
Step 3: If you still want to hire, count three costs
Hiring cost is not salary × 12. There are at least three more lines:
- Tax and social contributions: in China, an employee typically costs about 1.3× the gross salary (assumption). It becomes a fixed monthly outflow.
- Recruitment cost: posting, screening, interviewing, waiting. A founder's hours, priced at market rate, often exceed a candidate's monthly living cost.
- Management cost: in the first months, expect 3–5 hours per week on context, check-ins, and unblocking. For a founder who still writes code, this is real product time lost. A twenty-person company can absorb this tax; a three-person company may not.
So hiring means: starting from some month, you pay a fixed amount monthly, and in return you get a person who needs managing — not just a person who does work. Press the confirm button only when the bottleneck can be quantified well enough that this fixed cost removes a predictable constraint.
Be careful: calculating it doesn't mean you should hire. If your runway is 6 months and hiring drops it to 4, the answer is not simply "no." The real question is the second thing: can this person's delivery change the slope of your revenue curve within that window? That's another test. But at least you moved the decision from feelings to arithmetic.
Step 4: Write an output spec, not a job description
The most common hiring mistake in small teams is copying big-company JDs: senior, self-driven, resilient. None of these are verifiable.
Instead, write an output spec: one paragraph describing what will be different in the company 30 days after this person joins. For example: "After 30 days, Monday mornings start with the support queue at under 20 open messages (down from 120); every Friday, a categorized user-problem report is ready for the product meeting." Date, numbers, visible output. If you can't write this paragraph, your understanding of the bottleneck isn't specific enough.
The same spec can serve as the trial plan. Start with a four-week project-based collaboration and evaluate both sides against the same output spec. Fit should be decided by plan, not by mood.
When hiring is actually right
I still believe a small team must go through a stage where people outnumber projects. Three signals make hiring a responsibility rather than a choice:
- The bottleneck sits on the growth path: validation is done, demand exceeds the ceiling of one person, and the work can be standardized.
- A single point of failure threatens the company: if the only person who understands the core logic gets sick, development stops. But before hiring, remember that a new person doesn't inherit context by walking in. Cheaper first steps: documentation and access.
- You are ready to become a manager: willing to spend 15–20% of your week on meetings, context, and retrospectives. If the thought makes you resist, you're not looking for an employee — you're looking for a pill to calm your anxiety.
The last signal is the most ignored. Founders expect hiring to feel like relief. In reality, hiring usually makes the first three months harder. It solves the capacity bottleneck and creates a management bottleneck at the same time.
Closing
The essence of this decision is: is this company willing to pay a fixed commitment for a measurable bottleneck? If you can't articulate the bottleneck, hiring just postpones organizational complexity until after the first paycheck. A small company's structure isn't defined by an org chart — it's defined by the commitments it decides to take on. Prove the shortage first. Then hire.
PaxLee