When should you stop hiring generalists?
Later than most companies do. Specialising early feels like maturity and usually buys idle capacity, because a specialist needs a steady supply of their own kind of work and a small product does not generate it. The generalist team stops working for a specific, observable reason, and until that reason appears the correct next hire is another generalist. Knowing what the reason looks like saves a year of paying for the wrong shape.
When does one developer stop being enough?
When the constraint changes from capacity to risk. One capable generalist gets a surprising amount done, and the reason to add a second is rarely that the queue is too long. It is that a single person is a single point of failure: nobody reviews their work, nobody can cover a holiday, and nobody can question a decision.
That means the second hire should look like the first. Another generalist gives you review, continuity and a second opinion, and those are the things you are actually short of. Hiring a specialist as the second engineer buys depth in one area and leaves the resilience problem exactly where it was.
The test is whether you would be comfortable if the current developer resigned tomorrow. If the honest answer is no, that discomfort is the reason for the next hire, and it should shape what you hire rather than being solved incidentally.
What shape does the team take at each stage?
Team shape follows the kind of problem that is currently expensive, not headcount targets. Read down the column that matches your symptom rather than the one that matches your size.
| Stage | Symptom | Right shape | Wrong hire |
|---|---|---|---|
| One developer | Everything routes through one person | One generalist plus external review | A specialist of any kind |
| Two to three | No cover, no review, decisions unchallenged | Generalists, at least one senior | An engineering manager |
| Four to six | Work queues behind one area repeatedly | Generalists plus the first specialist that area needs | A dedicated tester before automated tests exist |
| Six to ten | Coordination cost visible, releases collide | Two small teams with clear ownership | An architect who does not write code |
| Ten and up | Onboarding takes months, nobody owns the platform | Explicit platform ownership, defined interfaces | More product teams on top of shared foundations |
What actually triggers the first specialist?
A queue that forms in the same place three times. Not a hard problem, and not a single bad month, but the repeated observation that work stops in one area while everything else moves. That pattern means there is enough of one kind of work to keep a person busy, which is the only honest justification for hiring one.
The second trigger is a risk you have decided not to accept. If your product now holds data whose loss would end the company, the argument for depth is about exposure rather than throughput, and the arithmetic is different.
Both triggers are observable in the issue tracker. Categorise a quarter of completed work and see whether any single category is both large and consistently the slowest. If it is not, a specialist will spend most of their time doing generalist work while being paid for depth.
Why does adding people make things slower first?
Because every new person consumes the time of the people who already know the system, and that cost lands immediately while the benefit arrives in months. The old observation that adding people to a late project makes it later describes this exactly, and it is still true in small teams where the effect is easiest to see.
The size of the dip depends almost entirely on how much has been written down. A team with a working setup document, a deployment anybody can run, and decisions recorded near the code absorbs a new person in a fortnight. A team where all of that lives in one person's head absorbs them in a quarter, and the person whose head it lives in produces nothing during it.
So the cheapest thing to do before a hire is not recruitment. It is spending a week writing down what a newcomer will need, which shortens the dip for every hire afterwards.
Which hires are consistently made too early?
An engineering manager for three developers. At that size the management overhead is a few hours a week and the manager will invent process to fill the rest, which is the exact opposite of what a small team needs. Someone should own priorities and one-to-ones, and that someone can already be in the company.
A dedicated tester before there are any automated tests. Manual testing by a person does not scale with release frequency, and hiring one commonly delays the automation that would have solved it. The order matters: automate the regression checks, then hire someone to think about what should be tested.
A full-time infrastructure engineer while a managed platform would do. This one is defensible later and expensive early, because the role is only continuously busy once you have scale, complexity or a compliance requirement to justify it. Before then the same money spent on managed services covers more ground.
What should you do before the next hire?
Categorise the last quarter of completed work by area, and note which categories were slow. This takes an hour and it answers the shape question with your own data rather than with a general argument. If nothing dominates, hire another generalist.
Then write down what only one person knows. Every item on that list is a risk you are carrying, and several of them will be cheaper to remove with a fortnight of documentation than with a hire.
Finally, name what the new person will own within three months. If the answer is a share of everything, they will need considerable direction and you should hire accordingly. If it is a specific area, check that the area currently generates enough work to fill their time, because that assumption is the one that turns out wrong most often.
Common questions
- Should your second developer be a specialist?
- Usually not. The reason to add a second engineer is rarely queue length, it is that a single developer is a single point of failure with no review, no cover and nobody to question a decision. Another generalist solves that. A specialist hired second buys depth in one area and leaves the resilience problem exactly where it was.
- What justifies hiring a specialist developer?
- A queue that forms in the same area three times, meaning work repeatedly stops in one place while everything else moves. That pattern indicates enough of one kind of work to keep a person busy. The other justification is a risk you have decided not to accept, such as holding data whose loss would end the business, where the argument is about exposure rather than throughput.
- Why does hiring more developers slow a team down at first?
- Every new person consumes the time of those who already know the system, so the cost lands immediately and the benefit arrives months later. The size of the dip depends on how much is written down: a team with a working setup document, a deployment anyone can run and decisions recorded near the code absorbs someone in a fortnight, while a team relying on one person's memory takes a quarter.
- Which engineering hires are usually made too early?
- An engineering manager for three developers, where the real overhead is a few hours a week and the manager invents process to fill the rest. A dedicated tester before any automated tests exist, which commonly delays the automation that would have solved the problem. And a full-time infrastructure engineer while a managed platform would cover it, since that role is only continuously busy at genuine scale or under a compliance requirement.
- How do you decide what your next engineering hire should be?
- Categorise the last quarter of completed work by area and note which categories were slow. If no category dominates, hire another generalist. Then list what only one person knows, since several of those risks are cheaper to remove with a fortnight of documentation than with a hire. Finally, name what the new person will own within three months and check that area generates enough work to fill their time.
