How I Onboard an Engineer

For a while I was the only engineer on the product. Then I onboarded the first engineer to join me, which meant turning a system that lived in my head into one another person could work in. That's a different job from building, and it taught me as much as any architecture problem.

Access on day one, not week two

The fastest way to make a new engineer feel useless is to make them wait for access. On day one I hand over everything they need to actually move: the staging environment and its admin, the cloud consoles, the design files, the data sources, the test accounts. The goal is that by the end of the first day they can run the thing locally, see it in staging, and change something real.

Scope the first tasks together

I don't hand a new engineer a spec and walk away. We scope the first real feature together, out loud, so they learn how I make decisions and I learn how they think. A recent example: for a new login flow we decided together to ship the passwordless paths first and refine the UI later against the designer's work, to support the two providers that mattered from the start, and to cut mobile out of the first estimate entirely. None of those are hard technical calls. They're scoping calls, and making them together is how judgment transfers.

Delegate ownership early

The temptation, as the person who knows everything, is to keep the interesting decisions. I try to do the opposite. Early on I'll say "you can build this one yourself" and mean it, then ask them to write the estimate rather than writing it for them. Ownership is how people grow. A new engineer who owns a real feature in week two becomes a peer far faster than one who's handed tickets for a month.

Unblock fast, decide slow

My rule for myself: unblock in minutes, but don't rush the decisions that are expensive to undo. When someone new is stuck on access, a link, a credential, or a "where does this live," I answer immediately, because every minute blocked is a minute of quietly doubting they belong. But when the question is architectural, we slow down and talk it through, because those are the choices we'll live with the longest.

Keep it low-ego

The tone matters more than the process. A quick "thanks," a "sounds good to me," a "good question, we don't have that yet, can you set it up?" These sound small, but they tell a new engineer that questions are welcome and that I don't need to be the smartest person in every thread. The best onboarding I can give is a place where someone feels safe being new.