Engineer Onboarding Checklist

A setup guide that has not been followed end to end recently is a setup guide that no longer works. Someone should run it on a clean machine before each new engineer arrives, or better, maintain a scripted or containerised setup so the environment is reproducible rather than reconstructed.

Have the new engineer follow the documentation and fix it as they go. They are the only person who can see what is missing, and that first contribution is genuinely useful to everyone who follows.

Access requests raised on the first day become blockers on the third. Repositories, the version control organisation, the build pipeline and the non production environments should be provisioned before arrival, based on the role rather than by copying another engineer's permissions.

Production access is a separate decision with its own timeline. Granting it automatically at hire is a common default that undermines every later access review.

The first merged change exercises the entire path: writing code, running tests, opening a review, responding to comments, merging and deploying. Doing that on something trivial teaches the process without the risk, and it tells you where the pipeline is broken.

Keep a small backlog of suitable first tasks so nobody has to invent one under time pressure. Documentation fixes, small test additions and low risk bugs all work, provided they touch the real repository and go through the real process.

An engineer who understands only the service they were hired to work on will make locally reasonable decisions with system wide consequences. Walk through how the pieces fit together, where the data lives, what talks to what, and which parts are known to be fragile.

Include the history. Knowing why something is the way it is, including which parts are deliberate and which are accepted debt, prevents both misplaced respect for a workaround and misplaced confidence in rewriting one.

Every team has unwritten review conventions covering how large a change should be, how much detail a description needs, what warrants a blocking comment and how quickly reviews are expected. A new engineer learns these by getting them wrong in public, which is a slow and uncomfortable way to learn.

Write them down as a short team agreement. It also gives the team something to point at rather than repeating the same review comments to every new joiner.

Putting a new engineer on the rota before they know the system is a risk to the system and unfair to the engineer. Treat on-call as a capability with prerequisites: familiarity with the alerts, the runbooks, the escalation path and at least one incident observed from the inside.

Shadow rotations work well. The new engineer joins the rota as a secondary alongside an experienced responder, sees real alerts, and takes primary only after that.

Engineers touch credentials, customer data and production systems, so their onboarding needs more than the general awareness training. Cover how secrets are managed, what may and may not be logged, and the rules for handling customer data in development and testing.

Be explicit about the boundaries. Using production data in a local environment is a common shortcut that a new engineer will assume is acceptable unless someone tells them otherwise.