How to onboard engineers fast so they release work in week one
We hire senior engineers, and we have watched the same thing enough times to be sure of it: two equally strong people can join the same team, and one releases real work in their first week while the other is still stuck a month later. The difference is almost never the person. It is the onboarding. A great engineer placed in a broken setup with no first task and no one to ask will look slow, because you have made them slow. And the cost of that is larger than most teams realize, because it is hard to see. Here is how we think about getting a new engineer productive fast, and why doing it badly is a cost you pay on every single hire.
Slow onboarding is a cost nobody puts in the budget
Start with the cost, because it is the part people underestimate. A new engineer who takes a month to release anything is a month of full salary for almost no output. That alone is expensive. But it is not the whole cost. For that month they are pulling time from everyone around them: the person who keeps helping them get the code to run, the reviewer who explains the same convention three times, the teammate who stops their own work to answer a question that a document should have answered.
Now multiply that by every engineer you ever hire. It becomes one of the largest ongoing costs in your whole engineering operation, and it never appears as a line item anywhere. That is what makes it a hidden cost. It is easy to miss, it is constant, and because no one sees it directly, no one fixes it. Teams will spend weeks optimizing a build pipeline to save minutes, then lose a month per hire to onboarding and never think to look. If you hire senior people, the number is bigger, because their time is worth more and there is more of it being wasted. That is why the standard for who does the reviewing is set so high. Spending that much to find them and then losing their first month to a bad setup is a strange way to treat the investment.
A working environment on day one
The single most valuable thing you can prepare is a codebase that runs on the new person's machine on their first day. Not day four after they have struggled through an out-of-date setup guide. Day one.
Think about what the first day starts. If a new engineer spends it chasing missing credentials, installing the wrong version of something, and following setup steps that were last accurate a year ago, you have taught them two things before they wrote a line of real code. You have taught them that the tooling is a mess, and you have lost the early energy and goodwill that a first day is supposed to build. Every hour spent on environment problems is an hour of wasted effort that produces nothing and quietly shows that this team is not well organised.
So invest in the dull part. A one-command setup, a container or a script that works, credentials ready and waiting, a setup doc that someone actually followed last week and confirmed is correct. This is unexciting work and it is easy to keep putting it off, because the people who already have a working environment never have the problem. But it is the difference between a new hire opening a real problem on the afternoon of day one and a new hire opening a support ticket about their laptop. Get this right and everything after it goes faster.
A small real task first, not a tour of the docs
The instinct is to put all the learning at the start. Give the new person a week of documents to read and a series of walkthrough meetings before they touch anything real. This feels responsible and it is one of the most common ways onboarding goes slow, because people forget what they read without doing. You cannot learn the structure of a system from a document when you have no problem to connect it to.
Reverse the order. In the first day or two, give the new engineer a small, real task that goes to production. Not a practice exercise you invented for them, and not a big feature that will take three weeks. Something contained and genuine: a bug fix, a small visible improvement, a piece of cleanup that matters. Size it so they can finish in a day or two. The goal is not the task itself. The goal is that they go through every step early, from writing the code to getting it reviewed to watching it deploy. Once someone has released one real change, the whole process stops being frightening, and every task after it is a variation on a thing they have already done. The reading still happens, but now it happens in context, guided by the questions the real task raises, which is the only way people actually remember it. This is the same reason we release products in small pieces rather than all at once at the end, an idea we explain in move fast without breaking the product.
A named buddy and written context
Two things help a new engineer through those first weeks: knowing who to ask, and being able to find answers on their own. Most onboarding leaves both to chance.
The buddy fixes the first one. Assign a single named person whose explicit job is to answer the new hire's questions, and make it clear that answering is part of their work, not an interruption. The biggest hidden problem in onboarding is not the hard technical questions. It is the small ones, the "who owns this," the "why is it done this way," the "is this supposed to look like this," that a new person will keep to themselves for an hour rather than risk looking foolish in a public channel. A buddy turns that one-hour silent struggle into a two-minute question, many times a week. The productivity difference is large and it costs you almost nothing.
Written context fixes the second one, and it is where a lot of teams fail because they rely on live walkthroughs instead. A walkthrough happens once, at the exact moment the new hire cannot yet absorb it, and then it is gone. Written context is different. Why the system is designed the way it is, what the main parts do and how they connect, where things are, which parts are easy to break, all of it written down, can be read, reread, and searched at the exact moment a question comes up in week two or week six. Verbal onboarding does not work for many people and is soon forgotten. You explain the same thing to every new hire and it is forgotten each time. Written context you build once and it serves everyone, including the person who wrote it when they forget their own reasoning six months later.
The first two weeks decide more than you think
Fast onboarding is worth the effort for the obvious reason, which is output. A strong hire who releases work in week one instead of week five gives you a month of real work back, per person, forever. But there is a second reason that matters just as much, and it is about whether the person stays at all.
The first two weeks quietly answer a question the new hire is asking themselves: did I make the right choice, and can I actually do this job here. An engineer who releases something real in week one gets a clear yes. They feel useful, they feel welcome, and they trust that the team knows how to run itself. An engineer who spends a month struggling with the environment, with no first task and no clear person to ask, gets a very different answer. They start wondering if they can do the work, when the truth is you never gave them a fair chance to. How someone feels about the whole role is shaped in those first days, long before they have the information to judge it properly.
None of this requires a big program or an expensive tool. A working environment on day one. A small real task in the first few days. A named buddy who treats questions as their job. Written context people can read on their own time. That is most of it. It respects the engineer's time, it gets your team the value of a strong hire far sooner, and it makes the person glad they came. Slow onboarding is a hidden cost. These four things are how you stop paying it. And they work well with judging people by what they actually accomplish, which we wrote about in measure engineers by outcomes, not output.
Onboarding changes when a codebase is largely generated, and the change is not obvious. New engineers traditionally learn a system by reading code and asking whoever wrote it. In a generated codebase the second half of that is missing: there is often nobody who remembers writing a given file, because nobody did.
What replaces it is the specification. If your specs are kept as documents that are updated as the system changes, that explain what each part of the system is supposed to do and why, onboarding is fine and arguably better, because intent is written down rather than held in one person's memory. If they are not, a new engineer is reading code with no way to find out why any of it is that way.
