How to Onboard a New Engineer to Your AI Platform Team

Your new hire's first Slack message is usually "which of these 40 permissions do I actually need?" That's the real onboarding tax on AI platform teams: the platform touches GPU quotas, model endpoints, vector stores, and production traffic, so nobody wants to hand out broad access on day one, but nobody's written down what narrow access should look like either. Most teams either lock the new engineer out for three weeks or grant them prod admin out of impatience. Both are wrong. Here's a path that gets a new engineer productive fast without making them (or you) the incident of the month.

This is about ramping up a new hire on your own team, not handing a finished system to a customer. If you're looking for that, the site already covers customer-facing handover separately; this is the internal version, for someone who's about to become one of the people who carries the pager.

Build the paved path before they accept the offer

Write the access request down as a repeatable artifact, not a memory. A scoped IAM role with an expiry beats a Slack thread where someone eyeballs what permissions "feel right."

# Create a time-bound onboarding role, not a permanent one
aws iam create-role \
  --role-name onboarding-<new-hire-username> \
  --assume-role-policy-document file://trust-policy.json \
  --max-session-duration 3600

aws iam put-role-policy \
  --role-name onboarding-<new-hire-username> \
  --policy-name onboarding-read-only \
  --policy-document file://onboarding-readonly-policy.json

onboarding-readonly-policy.json should grant read on dashboards, logs, model registry entries and cost reports, and nothing else. Set a calendar reminder to review the role at 30 days; don't let "temporary" access become permanent by default.

Day one: read access to everything, write access to nothing

Give them a self-guided tour they can run without pinging anyone: the observability dashboard for the platform's SLOs, the runbook index, the on-call schedule, and the architecture diagram for how a request flows from a client app to a model endpoint and back. Keep this as a checked-in file so it doesn't rot.

# onboarding/week-one-checklist.yml
checklist:
  - task: "Read the platform SLO dashboard, note current error budget"
    owner: new_hire
  - task: "Walk the request path: gateway -> router -> model endpoint -> cache"
    owner: new_hire
  - task: "Find last quarter's worst incident in the postmortem log"
    owner: new_hire
  - task: "Pair session: trace one real request end to end with a buddy"
    owner: buddy

The pairing session on day one matters more than the reading. Watching someone trace a live request teaches the mental model faster than any diagram.

Week one: give them a real ticket, not a toy project

Skip the sandbox side project. Pick a small, low-blast-radius ticket from the actual backlog: a new golden path template variant, a missing alert threshold, a stale runbook section. It has to ship to production, reviewed like anyone else's work, so they learn the real deploy path, not a simulated one.

A good first ticket has three properties: it touches one service, it has an existing test suite to lean on, and a rollback that doesn't require anyone to page you at 2am if it goes wrong.

Shadow on-call before running it solo

Don't put a new engineer on the pager rotation until they've shadowed at least one full on-call shift, ideally one with a real page in it. Have them read the alert, form a hypothesis, and check it against the primary responder before any action is taken. This is where the platform's actual failure modes, GPU node preemption, rate limit exhaustion, a stale embedding index, become real instead of theoretical.

Give them a piece of the platform to own

By week three or four, hand over a bounded area: one service, one dashboard, one on-call escalation path. Ownership, not just tickets, is what turns a new hire into a team member. Write it down in the team's ownership map so it's not tribal knowledge.

Gotchas

• Don't skip the access review at 30 days. Onboarding roles quietly becoming permanent admin roles is how platform teams end up with an access audit nobody wants to run.
• Don't let the first ticket be a toy. If it never touches production, the new engineer never learns your actual deploy and rollback process.
• Don't put someone on solo on-call after a single shadow shift if that shift was quiet. Wait for one with a real page, or pair them on a second shift.
• Don't assume the runbooks are current. Have the new hire flag anything that didn't match reality; it's the best signal you have that documentation has drifted.

A platform team that onboards well ships a second reliable engineer, not just a second set of hands, and that's what actually shortens your on-call rotation.