New Engineer Onboarding Checklist

IT creates the Okta / Google Workspace identity, then provisions GitHub org membership, AWS SSO, Slack, Jira / Linear, PagerDuty, Datadog, and 1Password through SCIM where possible. Confirm the GitHub team grants the right CODEOWNERS coverage for the engineer's pod — wrong team membership is the most common Day-1 access blocker.

Ship the MDM-enrolled laptop (Jamf / Kandji for macOS, Intune for Windows) with disk encryption, the team's standard browser profile, and the VPN client preinstalled. Include a printed Day-1 setup card so the engineer doesn't waste their first morning hunting for the wifi password.

The engineering manager covers the company mission, the engineering org's principles (e.g., blameless post-mortems, trunk-based development, you-build-it-you-run-it), and how these show up in day-to-day decisions. Ground it in a recent example, not a slide deck.

Run a 30-minute pod intro: who owns which services, who to ask about which subsystem, and where the standup / retro / planning ceremonies sit on the calendar. Schedule 1:1 coffees with each pod member across the first two weeks.

Walk through the engineer's pod-owned services in Backstage (or your equivalent service catalog): repo links, on-call ownership, SLOs, runbooks, and dependency graph. New hires often try to read the entire monorepo on Day 1 — the catalog is the right entry point.

Clone the primary repo, install language toolchains via asdf / mise, and run the bootstrap script. Confirm gitleaks / trufflehog pre-commit hooks fire on a deliberately committed dummy secret — this is the only way to know the secret-scanning gate actually works on this machine.

Install the team's recommended IDE extensions (ESLint, Prettier, Ruff, gopls, rust-analyzer — whichever the stack uses) and import the shared editor config. Format-on-save is non-negotiable; PRs that disagree with the formatter waste reviewer time.

Connect to the staging VPN, run aws sso login, then verify kubectl get pods -n <pod-namespace> against the staging cluster. Production access is granted later, only after the engineer completes the access-review acknowledgment.

Bring up the full local stack via docker compose up, run the seed script, and exercise the smoke-test user path against localhost. Local-stack failures on a new machine are usually Docker memory limits, port collisions with another running service, or stale env vars from a prior shell session.

The mentor picks a starter ticket from the pod's backlog tagged good-first-issue — small scope, well-bounded, touches the build / test / deploy loop without requiring deep domain context. Pair on the first commit; the engineer drives, the mentor narrates the codebase.

Open a PR following the team's PR template (description, test plan, risk, rollback note). Get the CODEOWNERS-required approval, watch CI go green, squash-merge to main, and confirm the canary deploys cleanly. Goal is one shipped change in the first week — small, real, and visible in the changelog.

Cover what the team looks for in review: PR size budget (target under 400 lines), test coverage on changed paths, observability for new code paths, backwards compatibility for API changes, and the migration-safety rules (no ALTER TABLE with default on hot tables, batched backfills only). "LGTM" without reading is the cultural failure to avoid.

Shadow the primary on-call for one full shift in PagerDuty's read-only mode. Observe how the on-call triages a page, navigates the runbook, drives an incident channel, and writes the handover note. The engineer joins the primary rotation only after a second shadow and explicit manager sign-off.

Structured 30-day check-in: PR throughput, review participation, on-call readiness, pod-fit signals from peers, and any blockers (access, environment, scope clarity). The engineer also rates onboarding from their side — gaps surface fastest at this checkpoint.

The engineering manager and the engineer agree on a written remediation plan: two or three specific behaviors to change or skills to build, weekly 1:1s, and a 60-day reassessment. Loop in HR if the plan touches performance-management territory.

By Day 60 the engineer should own a scoped project end to end: design doc, implementation, review coordination, deploy, and post-launch monitoring. Pick something with a clear customer-visible or operational outcome — first PRs prove they can ship; a project proves they can drive.