In twelve months we hired fifty engineers.
That sentence sounds like a recruiting achievement. It is not, or at least not mostly. Hiring fifty people is a logistics problem. Turning fifty strangers, spread over three continents, into a team that ships is the actual job. Most growth stories skip that part, and most growth stalls right there: the headcount arrives, and the output does not.
Here is what worked for us, in the order it happens to a new engineer.
Track hiring like a product
You cannot fix a funnel you cannot see. Before we sped anything up, we made the whole pipeline visible: every open role, every candidate, every stage, how long each stage took, and where people dropped out.
It changed the conversations immediately. "Hiring is slow" became "candidates wait four days for a technical slot" or "we lose people between the offer and the signature". Those are problems you can solve on a Tuesday. "Hiring is slow" is a problem you complain about for a quarter.
Treat the funnel the way you would treat a product: instrument it, look at it every week, and fix the biggest leak first.
Hire fast: three conversations, three days
Good engineers are on the market for days, not weeks. A five-round process spread over a month mostly selects for the people nobody else wanted to hire.
Our process is three steps, and we aim to finish it in three days:
- Screening. Is there a real match: the role, the level, the expectations on both sides.
- Technical. A conversation about real problems, close to the work they would actually do. Not trivia, not puzzles.
- Team fit. The people they would work with every day meet them, and they meet us. It is an interview in both directions.
Speed is not the same as lowering the bar. Every step has a clear owner and a clear question it answers. When the questions are clear, the decisions are fast.
Day 0: everything is ready before they arrive
The worst first day is the one spent waiting: for a laptop, for access, for someone to remember you were starting.
So our new engineers arrive to find everything already in place. Their accounts and permissions are set up. They are in the right channels, and the conversations they need to read are already pointed out to them. Their first meetings are on the calendar. And they get written 30, 60 and 90 day goals, so on the first morning they know what good looks like at the end of the first month, and the second, and the third.
None of this is glamorous. It is a checklist, followed every time. But a first day where everything works tells a new person something no welcome speech can: this place has its act together, and they were expected.
Ship to production in week one
Every new engineer ships something to production in their first week.
It is usually small: a fix, a tweak, an improvement someone had been meaning to make. The size is not the point. Shipping in week one walks you through the entire path, from the repository and the pipeline to the release and the monitoring, while you still have the beginner's eyes to notice what is confusing. And it answers the one question every new hire quietly carries: can I actually do this here?
If shipping in week one is hard, that is not a fact about the new hire. It is a finding about your system, and now you know where to look.
Gather onboarding feedback, and act on it fast
New people see your organization more clearly than you ever will again. Their confusion is data. So we ask for it, early and often, and we act on it quickly.
Every rough edge someone hits, a missing permission, an outdated page, a step nobody explained, gets fixed before the next person starts. With fifty people coming through in a year, that loop compounds: the onboarding the fiftieth engineer had was built, in part, by the forty-nine before them.
The speed matters more than the format. Feedback that sits in a document for a month teaches people that giving feedback is pointless.
Buddies are the wayfinders
Documentation tells you what exists. A buddy tells you where to go.
Every new engineer gets an onboarding buddy: someone who has been around long enough to know the shortcuts, and recently enough to remember being lost. The buddy is not a manager and not a mentor. They are the person you can ask the questions that feel too small to ask anyone else: who owns this, why is it like that, is it normal that this takes so long.
A good buddy saves a new hire weeks. It also turns out to be one of the best leadership training grounds we have.
AI as documentation
Traditional documentation has a familiar life cycle: written with care, accurate for a month, quietly wrong forever after.
We started writing more of our knowledge as skills for AI agents instead: how to add a service, how we structure a change, how to run and test things locally, how a release works. A skill is documentation that gets used every day, so it gets corrected every day. A new engineer does not have to find the right page and hope it is current. They ask, and the agent works from the same instructions the rest of the team relies on.
The side effect we did not plan for: when knowledge lives in skills, keeping it accurate stops being a chore someone forgets and becomes part of the work itself.
Harness engineering teaches how we work
This is the part I am most excited about.
The harness around our AI tools, the instructions, the skills, the checks and the guardrails, encodes how we work: our conventions, our standards, the mistakes we have already made once. When a new engineer works with an agent inside that harness, they are not just getting help writing code. They are being shown, change after change, what good looks like here.
It is onboarding that never stops. And because the harness is shared, every improvement one person makes to it, every rule added after a lesson learned, reaches every engineer the next morning, including the ones who started yesterday.
None of this works without HR
I have written this in the first person, but the most honest version of this essay would credit our HR team on every page.
Fifty hires in twelve months means sourcing in time zones on the other side of the world, contracts and paperwork in many countries, laptops that arrive before their owners do, and offers that go out the same day a team says yes. Our HR team made a three-day process possible, and made Day 0 possible, quietly and every single time. Engineering leaders like to talk about hiring as if it were an engineering problem. It is a partnership, and on our side of it we got lucky.
Thank you. You know who you are.
The takeaway
Hiring fast is a solved problem if you track it and respect the candidate's time. Growing fast without falling apart comes down to one idea: make the right way the easy way, from the first morning on. Have everything ready, ship early, listen to the new people, give them a guide, and put how you work somewhere they will actually use it, not in a wiki nobody opens.
Fifty engineers later, that is the part I would keep.