Onboarding Engineers 
What the First 90 Days Should Actually Produce 

Most engineering organisations put months of effort into hiring and then hand the person they hired a laptop, a wiki link, and a Slack invite. The result is predictable and expensive: a senior engineer who cost six months of searching spends their first three weeks trying to get the test suite to pass locally, learns the architecture by breaking things, and reaches full productivity somewhere around month four — or does not, and leaves in month seven, at which point you have paid for the search twice and delivered nothing from it. Ramp time is one of the largest numbers in engineering economics and one of the very few that almost nobody measures.

What ramp actually costs

The arithmetic is worth doing once because it changes how much effort onboarding deserves. A senior engineer in New York costs roughly $270-340K fully loaded, or £150-200K in London, so every month of reduced productivity is on the order of $22-28K — and the full cost picture is worse than the salary line suggests. A typical senior hire reaches meaningful output in two to four months, which means the difference between a well-run onboarding and an improvised one is commonly six to eight weeks of one person's output, or something like $35-55K per hire. That is before the second-order costs: every question a new engineer has to ask costs an existing engineer's attention too, so a badly onboarded hire temporarily reduces the productivity of the team they joined. And it is before the retention effect, which is the largest term of all — the first month is when people form their view of whether an organisation is competent, and early attrition among senior hires is overwhelmingly a first-90-days phenomenon rather than a compensation one. Against that, a week of preparation and a maintained onboarding path is an unusually good return, and it is the same investment every subsequent hire benefits from.

Day one to end of week one: ship something

The single most useful goal for the first week is a merged, deployed change in production, however small — a copy fix, a log line, a test. It is not about the value of the change; it is about proving that the entire path works and that the new engineer has personally walked it. Getting there forces you to confront the things that actually block people: accounts and access that take days to arrive because three different people have to approve them, a local environment setup that has not been run from scratch in a year and no longer works, a test suite with four flaky tests that everyone else knows to ignore, and a deploy process that lives in one person's head. Each of those is invisible to the existing team and completely blocking to a new one. The practical test is to have the most recent hire set up the environment on a clean machine and fix the instructions as they go, every time you hire — the documentation is only ever correct immediately after someone has used it. Have the access requests submitted before the start date, pair the first commit with someone rather than leaving it as a solo scavenger hunt, and treat a first week spent fighting tooling as a defect in your system rather than a rite of passage.

The documentation that actually matters

• A one-page architecture overview: the four or five main components, what each is responsible for, and how a request flows through them. Diagrams age badly, so keep it coarse enough to stay true for a year.
• Why the system is the way it is. Architecture decision records, even brief ones, prevent the recurring cost of a new engineer proposing something that was tried and abandoned for a reason nobody remembers to mention.
• How to run, test, and debug locally — verified against a clean machine, not written from memory.
• The deploy path and how to roll back, including who to tell and what to watch afterwards.
• A map of the domain vocabulary. Every mature product has words that mean something specific internally, and the gap between the industry meaning and yours is where new engineers make confident mistakes.
• Who owns what, and who to ask about what. In a forty-person company this is more useful than any diagram.
• Deliberately, nothing else. A wiki with four hundred pages of which thirty are current is worse than seven pages that are true, because it teaches people that documentation cannot be trusted.

Weeks two to six: ownership, not tickets

The common pattern after the first week is a queue of small unrelated bugs, on the theory that they expose the codebase gradually. It is a defensible start and a poor month, because it teaches the shape of the code without ever teaching the shape of the product, and it never requires the engineer to make a decision. A better structure is to give one small but complete piece of work by the end of week two — a feature with a real user at the end of it, scoped to a couple of weeks, that the new engineer owns from design through deploy to watching it in production. Small enough that failure is cheap, real enough that they have to talk to a designer or a customer-facing colleague, and end-to-end so they encounter the whole system rather than one layer of it. The senior version of this deserves emphasis: senior hires under-perform in onboarding mainly when they are given work that does not require judgement, because judgement is what you hired and it is unexercised. By week six a healthy ramp looks like an engineer reviewing other people's pull requests, asking questions that reveal context rather than confusion, and having shipped something they can point at.

The structure around them

Two roles do most of the work here, and they are different. An onboarding buddy is the person whose job is to answer the questions that feel too small to ask — where does this get deployed, is this test always red, who is the person in that channel — and having a designated one removes the social cost of asking, which is the actual barrier. The manager relationship is separate and should be dense at the start: weekly one-to-ones from week one, with explicit expectation-setting about what the first month, quarter, and half-year should look like. Say those expectations out loud, because senior hires in particular arrive with their own assumptions about how fast they should be contributing and will usually set a harsher bar than you would. Add a written thirty-sixty-ninety plan with a small number of concrete outcomes and review it on schedule rather than letting it become a document that was written once. And schedule the feedback in both directions early: a candid check-in at week two and week six catches the mismatch that would otherwise surface at month five, when it is much more expensive to fix and often terminal.

Measuring it, and the remote case

Onboarding is easy to improve because it is easy to measure once you decide to. Time to first merged commit, time to first production deploy, time to first on-call shift, and time to first solo-owned feature are four numbers you can extract from systems you already have, and tracking them across hires turns a vague feeling into a trend. Pair them with a short survey at day thirty and day ninety asking what was hardest and what was missing, and act on the answers within the same quarter, because the next hire is the one who benefits. It is also worth watching whether ramp correlates with anything structural — teams with faster delivery cycles generally onboard faster too, since the same fast feedback loops that help experienced engineers help new ones more. Distributed teams need explicit versions of everything that happens by accident in an office: the incidental context absorbed by overhearing conversations has to become written decisions and recorded discussions, and the informal availability of a colleague has to become a scheduled block of pairing time in the first fortnight. The most effective single practice for remote onboarding is deliberate pairing — several hours a week for the first month, on real work — because it transfers the tacit knowledge that documentation cannot hold.

How Infiniti Tech Partners fits in

We are on both sides of this problem often enough to have a practical view of it. Our own engineers join client codebases regularly, which means we run a compressed version of this process constantly and have learned which parts genuinely matter — the clean-machine setup check, the small end-to-end first piece of work, and the map of who owns what have far more effect than the volume of documentation, which is usually the thing teams add first. The other side is that we frequently work alongside teams who are hiring, and the handover we do at the end of an engagement is an onboarding problem wearing a different hat: the measure of whether it worked is whether your engineers can change the system confidently without us in the room, which is exactly the test that matters for a new hire. If you are about to bring several engineers on at once, or you have just discovered that your last three hires all took four months to become productive, a short review of the path they walked usually finds two or three fixable blockages that are costing more than they look.