Onboarding is usually designed as a tour: architecture diagrams, an overview of the domain, a walkthrough of the systems. It feels thorough and it is largely wasted, because none of it attaches to anything the person has done yet. What produces a productive engineer quickly is the opposite - a small, real change shipped early, and the context arriving as it becomes needed.
The first blocker is environment setup, and it is worth measuring honestly. If it takes a new joiner two days to run the system locally, that is two days lost per hire plus the time of whoever helps them. A single documented command that produces a working environment is the highest-return investment in onboarding there is, and the test of it is that a new person can run it unaided. Every failure they hit is a documentation bug to fix while it is still visible - after a month, nobody can see these problems any more.
Then have them ship something on day one or two. Not a toy - a real change, small and low-risk, that goes to production. It exercises the entire path: environment, tests, review, pipeline, deployment, verification. It teaches more about how the team works than any document, and it converts someone from a guest into a contributor, which matters more than it sounds.
Assign one named person as their first point of contact for the first fortnight, explicitly, with the expectation that interruptions are the job rather than a distraction from it. New engineers systematically under-ask, out of a reasonable fear of looking slow, and spend hours on things a colleague would answer in a minute. Naming someone makes asking cheap.
Give them the why rather than the what. The code says what it does; it does not say that this queue exists because a supplier once sent forty thousand duplicate records, or that this validation is deliberately lenient because a large customer's data is malformed. That context lives in people's heads and gets lost. If you keep architecture decision records, this is where they earn their cost - a new engineer reading a year of decisions absorbs the reasoning in an afternoon.
Finally, treat the new person as an audit. For their first month they can see everything that is confusing, undocumented or absurd, because they have not yet normalised it. Ask them at week four what surprised them and what wasted their time, and act on it - the list is accurate, it is free, and it will never be available from that person again.
