Team & Onboarding Best Practices

This is the index for the Team & Onboarding section. It condenses the four pages above into one checklist you can hand to a manager or team lead.

Each item below is a one-line rule that links to the full page behind it. Use it the day a new AWS SDK specialist joins, and again at each 30/60/90 milestone.

How to Use This List

• Read top to bottom before a new hire's first day, then re-check the relevant group at each ramp-up milestone.
• Groups run in the order a new hire moves through them: access first, then setup, then reading, then the ramp-up plan itself.
• Every rule here holds identically for boto3 and the AWS SDK for JavaScript v3.
• If you only do two things from this list, do the sandbox-first access group and the small-first-PR item.

A - Access & Accounts

• Grant sandbox access first, never production. Route day-one access through a scoped IAM Identity Center role in a sandbox account, not a long-lived key.
• Use the org's existing multi-account structure. A sandbox is another member account under the same AWS Organizations setup already used for dev/staging/prod, not a new pattern.
• Set a budget alarm on the sandbox. Catch a runaway loop or misunderstood pricing model within an hour, not at the end of the month.
• Verify no trust path back to production. A sandbox role that can assume anything in a production account is not actually isolated.

Full detail: Sandbox Accounts & Safe Experimentation.

B - Local Setup & Verification

• Configure a named profile for the sandbox identity. Keep it separate from any other profile on the machine so commands never accidentally target the wrong account.
• Verify credentials before writing any code. Run aws sts get-caller-identity and confirm the account id matches the sandbox, not a guess based on a successful aws configure.
• Confirm both SDKs if the team uses both. Check that boto3 and the AWS SDK for JavaScript v3 resolve the same profile without duplicated or hardcoded credentials.
• Prove the whole chain with one read-only call. A successful GetCallerIdentity through the SDK, not just the CLI, is the real day-one milestone.

Full detail: Team & Onboarding Basics.

C - First-Week Reading

• Read sdk-fundamentals first. Understand what an SDK call actually does - a signed, billed, network request - before writing one.
• Read aws-cli-setup next. Understand the shared credential chain the CLI and both SDKs read from.
• Read iam-basics third. Understand how IAM controls what any given call is allowed to do.
• Skip generic tutorials in favor of this site's own sections. They already match this team's account structure and conventions.

Full detail: Onboarding an AWS SDK Specialist.

D - The 30/60/90 Ramp-Up

• Day 30: read-only competence. Credentials working, fundamentals read, comfortable making read-only calls in the sandbox.
• Day 60: first mutation under review, first small real PR. A reviewed mutating call in the sandbox, plus a small, narrow PR merged into a real integration.
• Day 90: ownership of one small integration. Understands its error handling, cost profile, and cleanup well enough to be the person the team asks.
• Adjust day counts, keep the stage order. Read-only before mutating, mutating before ownership, regardless of how fast or slow any individual moves.

Full detail: A 30/60/90 Ramp-Up Path for AWS SDK Engineers.

E - Where to Start

• If you are a manager preparing for a new hire's first day, start with Group A.
• If you are the new hire, start with Onboarding an AWS SDK Specialist for the why, then Team & Onboarding Basics for the concrete steps.
• If you are checking progress at a milestone, use Group D as the rubric.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Y29kZWd1aWRlcy5pb3xjZ2lvMTE1MHwyMDI2MDc=