New Developer Onboarding: A Checklist for the First 30 Days

The new hire should not spend their first morning filing tickets. Complete these a few days ahead:

• Laptop ordered, configured with disk encryption and device management, and shipped or waiting.
• Accounts requested: email, chat, source control, ticketing, cloud console access appropriate to the role, and the password manager. Enforce multi-factor authentication from the first login.
• Access requested with least privilege. Start with read access and the environments they need, and add more as tasks demand.
• A buddy assigned, someone other than the manager, with time set aside.
• A starter task chosen: small, real, well-scoped and unblocked.
• A first-day schedule sent, with names and times for introductions.

Keep a single onboarding ticket template with each item and an owner. The person doing it the twentieth time shouldn't rely on memory.

Aim for a merged change by the end of week one. A practical sequence:

1. Day one: welcome, tour of how the team works, laptop and accounts verified. The person should sign in to everything before lunch.
2. Day one or two: set up the local environment following the written guide. Have the buddy pair on it, and fix the guide wherever it's wrong. The new hire sees the gaps that experienced engineers no longer notice.
3. Day two or three: read the architecture overview and the service catalog entries for the systems they'll touch, so they know who owns what.
4. Day three to five: take the starter task through the full path: branch, review, CI, deploy to a test environment and merge.

Deployment to production can come later, but the person should watch one release and understand how rollback works. Keep that step short and safe: watch, don't push.

Move from guided to independent:

• Week two: a slightly larger task in the same area. Pair with an engineer on a code review, both giving and receiving one.
• Week three: join the on-call shadow rotation, if you have one, and read recent incident reviews. Meet people on adjacent teams.
• Week four: own a small feature or fix end to end, including monitoring and a note in the changelog.
• End of the first month: a structured conversation about expectations, what confused them and what to fix in onboarding.

Set clear expectations for each week in writing, so the new developer isn't guessing what good looks like. Also assign reading that's short and specific, such as three design docs and two incident reviews, rather than a link to a wiki with hundreds of pages.

Onboarding is when access gets granted casually and never revisited. Build good habits from the start:

• Grant access by role and record who approved it. Avoid copying an existing engineer's permissions wholesale.
• Use single sign-on where possible, so offboarding is one action.
• Never share credentials in chat. New hires get their own accounts and secrets from the password manager or secrets store.
• Share your AI coding tool rules and data handling expectations in week one.
• Set a 30-day access review: what did they use, and what can be removed?

The same checklist, run in reverse, is your offboarding process. Keep them together.

Measure a few things and review them each quarter:

• Time from start date to first merged pull request.
• Time to a working local environment, and the number of questions asked in the first week.
• New hire survey score at 30 days on clarity and support.
• Number of onboarding steps that were blocked by missing access.

An internal portal such as Backstage or Port can host the catalog, docs and setup guides in one place, and the portal comparison covers when that's worth adopting. Before that, a well-maintained page and a buddy go a long way. Every new hire is a free test of your documentation, so treat what they report as bug reports and fix them the same week.