What does onboarding look like for a new engineer joining your team?

Aim for a real change in production in week one and genuine ownership by the end of the first month. Give them a buddy who is not you, setup documentation they repair as they use it, a starter task with a clear definition of done, and written expectations at thirty, sixty and ninety days. Introduce context in layers: product first, then architecture, then history.

The target is a real change in production in the first week, however small, because until somebody has been through the whole pipeline once they do not really work here yet. To make that possible I keep a small backlog of genuine starter tasks, not busywork, scoped so they touch the build, review and deploy path. Every new person gets a buddy who is not me, whose explicit job is answering the questions people feel stupid asking their manager. Setup documentation is owned by whoever joined most recently, so it gets repaired every time instead of rotting for a year. On context, I do product before architecture, because a system diagram means nothing until you know what customers do with it, and I save the why did we build it this way stories for week three. I write down what I expect at thirty, sixty and ninety days and share it on day one, then actually review it with them, because a plan nobody revisits is decoration.