Your first ten engineers

The first ten people you hire are writing your company's constitution, and none of them know they're doing it.

Not the values document. The real one.

How code review actually works here. Whether it's fine to ship on Friday. What happens when somebody is wrong in a meeting. Whether the person who says "that's not my job" gets away with it.

Everything the first ten do repeatedly becomes what the next ninety learn by imitation, because a company at fifteen people has no formal way to teach anything and imitation is the entire mechanism.

Which is why the stakes here sit so far above everything else you're worried about at this size.

A bad architecture choice costs you a rewrite. A bad tenth hire costs you a culture you then fight for three years.

Range beats depth in the first five

Your first five engineers will each do four jobs, and you cannot predict which four.

The person you hired for backend ends up owning deploys, because nobody else will. Somebody discovers they're the one who can talk to customers without translating everything into implementation detail. Somebody becomes the de facto person making the hard call at 6pm on a Thursday.

So hire for range.

People who have shipped whole things end to end. Who have been the last line of defence on something. Who get uncomfortable when a problem sits next to their box and nobody is picking it up.

The résumé signal is variety plus depth in at least one place, which tells you they can go deep when it matters and don't need permission to go wide.

Specialists come later, once the specialty has become a permanent load.

A brilliant infrastructure engineer at company number four is a gift. Hired first, they spend eighteen months building something excellent for a scale you may never reach, miserable throughout, because the job on offer is still a different one.

One caveat matters. Range here means breadth of responsibility, and plenty of people hear it as junior.

The people carrying the most of it are usually mid-to-senior engineers who have worked somewhere small.

A team of ten generalists with nobody who has seen a system survive three years is its own failure mode.

There's a second-order cost nobody warns you about. Read it as a caution attached to hiring for range.

The person who can do everything shallowly is exactly right for the job that exists at five people. They get things running.

Then the team grows, and two things start to matter that were never being selected for. Depth in a specific area. And the interpersonal range to work across teams, where before they'd have worked around them.

Depth starts beating do-it-all.

Nothing went wrong with the person. The job changed underneath them.

Completely different problem from tolerating a flaw, and it wants a different response. A conversation about where their depth is going to be, held early, while it's still a development question.

Sometimes the honest answer is that the depth isn't there and doesn't want to be. Then it is an exit.

But the sequence starts with the conversation, because they did the job you actually hired them for.

The best one probably won't feel comfortable

Worth saying plainly. At ten people you're hiring almost entirely on instinct, and instinct carries a known bias.

The best early hire I've made was a bit the opposite of me. Structured, educated, pushed back.

Over time I found real comfort in that. And the trap sits exactly there, in one word doing two jobs.

Comfort at the end is earned. It's what you have after two years with somebody who disagreed with you and turned out to be right.

Comfort at the start is free. Recognition, familiarity, a person who reminds you of somebody.

The two are identical in memory. So you remember the earned one and go looking for that feeling at the front of the funnel, where only the cheap version is available.

We tend to forget that. I forget it regularly. The bar lesson carries the mechanism for guarding against it, and the short version is that the mechanism has to sit outside you.

The two roles founders hire too late

Design, and product.

Almost every technical founder does this, and the reasoning never varies. We can't afford a designer yet. I know what we're building. Engineers can do the UI.

True right up until the founder becomes the bottleneck on why anything is being built at all. By then the pattern has set.

Engineering receives finished decisions and stops asking about them. That habit is much harder to reverse later than it is to avoid now.

Design is a partner in framing the problem. Hire it at engineer number twelve and the first eleven have already learned that the "why" arrives from somewhere else.

Same with product. The founder who holds product single-handedly until forty people has built an org that can execute and cannot originate.

The rule I'd hold. By the time you have five engineers, one of the next three hires is design or product.

Not both, necessarily. But the trio has to exist in some form before the habits calcify, even when two thirds of it is part time and the third is you.

The first bad hire costs about a year

Here's the arithmetic founders consistently get wrong. It's also why I'm blunt about speed on the exit side.

The hire is wrong.

You notice at month two and don't act, because it's early, and maybe it's onboarding, and you hate this. You act at month five. The conversation and the wind-down take a month. You start hiring again, two months. The new person takes two more to be useful.

Ten months of a seat producing nothing, in a company of maybe eight people.

The real cost landed on the other seven. They watched.

They saw that the standard is negotiable, that a person can be visibly not working out and nothing happens for months. And one of them, usually the best one, has quietly updated their view of whether this is a serious place.

You do not get to keep both the slow kind decision and the high standard. Pick.

Selling a job that doesn't exist yet

At ten people you're recruiting against companies that pay more, offer stability, and can name the team a person would be joining.

You lose on all three. So don't compete there.

What you have is scope and proximity.

This person owns something whole, from decision to production, with nobody in between. They sit in the room where things get decided.

Genuinely rare. And the people who want that want it badly.

Be specific about the bad parts too, and do it before they're interested.

There's no platform team, so you carry your own pager. Half of what we build will be wrong and we'll delete it. The comp is below market and the equity is a lottery ticket whose odds I can describe honestly.

If somebody hears all that and leans in, you've learned more than any interview loop will tell you.

The dishonest version describes the company you intend to be in two years as though it exists today.

It works, in the sense that people accept the offer. Then they arrive, find the actual company, and you have a disengaged senior engineer plus a reputation inside their network.

Small-company hiring is a repeat game with a very small pool.

The tolerance test

Once a quarter, at this size, ask yourself one question: what have I let slide?

As a factual audit. There's no use in flagellating yourself about it.

Whatever you've tolerated for three months is the standard now, and the people around you have learned it more precisely than you have.

The engineer who doesn't review anybody else's code. The one whose changes always break something, always somebody else's fault. The person everyone routes around.

At ten people, every one of those is a constitutional amendment rather than a personnel issue, and you're the only one who can veto it.