A 30/60/90 Ramp-Up Path for AWS SDK Engineers

A vague plan like "get up to speed" gives a new hire nothing to check progress against. A 30/60/90 plan gives both the new hire and their manager a shared, concrete definition of what "on track" looks like at each stage.

This page lays out a realistic path built on this site's own sections: CLI setup, sandbox access, and the SDK fundamentals, rather than generic corporate milestones that don't map to actual AWS SDK work.

Recipe

Structure the first 90 days around three stages: read-only competence, a first reviewed mutation, then ownership of a small integration.

• Day 30: credentials and CLI working, fundamentals read, comfortable making read-only SDK calls in the sandbox account.
• Day 60: first mutating call made under review, and a first small PR merged into a real (non-sandbox) integration.
• Day 90: owns a small service integration end to end, including its error handling, retries, and cleanup.

This progression matters more than the exact day counts. Moving from read-only to mutating to ownership, in that order, is what keeps risk proportional to experience at every stage.

Working Example

Here is what each stage looks like in practice, building directly on the earlier onboarding pages in this section.

Days 1-30: Foundation. The new hire completes everything in Team & Onboarding Basics: sandbox account access, CLI configuration, and the sdk-fundamentals / aws-cli-setup / iam-basics reading list. By day 30, they can run read-only calls confidently and explain, at a basic level, how a call gets signed and what IAM controls about it.

# --- Python (boto3) ---
import boto3
 
session = boto3.Session(profile_name="sandbox")
dynamodb = session.client("dynamodb")
tables = dynamodb.list_tables()  # day-30 level: read-only, low risk
print(tables["TableNames"])

// --- TypeScript (AWS SDK v3) ---
import { DynamoDBClient, ListTablesCommand } from "@aws-sdk/client-dynamodb";
 
const dynamodb = new DynamoDBClient({});
const tables = await dynamodb.send(new ListTablesCommand({})); // read-only
console.log(tables.TableNames);

Days 31-60: First mutation, first real PR. The new hire makes their first mutating call (creating or updating a small resource) in the sandbox account, under direct review from a teammate who checks the error handling and idempotency. Separately, they open and merge a first small PR against a real, non-sandbox integration - something narrow, like adding a field to an existing read path or fixing a small bug in an existing SDK call, not a new feature from scratch.

Days 61-90: Ownership. The new hire takes ownership of one small, well-bounded service integration: they understand its retry behavior, its cost profile, what it costs to run and why, and how its resources get cleaned up. "Ownership" here means they are the person the team asks about that integration, not that they built it alone from zero.

Deep Dive

The reason this plan orders things read-only, then mutation, then ownership, is that each stage naturally reduces one specific kind of risk before increasing exposure to the next.

Read-only calls carry no risk of unwanted side effects. This makes the first 30 days safe to move through at whatever pace the new hire learns, without the account, or anyone else's work, being at risk.

A first mutating call is where irreversible action first enters the picture: creating a resource that costs money, or updating one that other tests might depend on. Doing this under review, in the sandbox, catches the two things a new hire is statistically most likely to get wrong at this stage - unbounded loops that create more than intended, and missing cleanup that leaves cost or clutter behind.

Ownership at day 90 is deliberately scoped to one small integration rather than "the whole system," because ownership requires a level of context (this integration's specific failure modes, its typical request volume, who to page if it breaks) that cannot be handed over instantly. A small, well-bounded piece is something a 90-day engineer can genuinely hold end to end.

This maps directly onto the failure modes covered in sdk-rules: read-only calls avoid cost and reliability risk entirely; the first mutation stage is where cost-aware and error-handling habits get exercised for the first time; ownership is where security and cleanup responsibility land permanently.

Gotchas

• Skipping straight to mutating calls to "move faster." This is the most common way the plan breaks. A new hire who makes their first mutating call without review, before finishing the read-only stage, is the person most likely to leave orphaned resources or an unbounded loop running.
• Treating day counts as hard deadlines. Some engineers need more than 30 days on fundamentals, especially if AWS is new to them; others move through faster if they arrive with prior cloud experience. The stages matter more than the specific day counts.
• "Ownership" without a clear boundary. If day 90 ownership is left vague, a new hire can end up nominally responsible for something too large to actually understand. Scope it to one small integration explicitly.
• No named reviewer for the day 60 mutation. The review at this stage is what makes the risk acceptable. Skipping it defeats the purpose of doing the mutation in a sandbox at all.

Alternatives

• A single "shadow someone for a month" plan with no explicit milestones. Lower upfront design cost, but gives no way to measure whether onboarding is actually on track, and tends to produce inconsistent results across new hires.
• A fixed curriculum with a test at the end. Works for pure knowledge transfer, but AWS SDK competence is largely about safe hands-on practice, which a written test does not verify the way a reviewed mutating call does.
• Immediate full production access with close pairing. Can work for a very senior hire joining a small team, but removes the safety margin this plan is built around, and does not scale to onboarding multiple people at once.

FAQs

Related

• Onboarding an AWS SDK Specialist - the day-one foundation this plan builds on.
• Team & Onboarding Basics - the concrete first-week checklist behind the day-30 stage.
• Sandbox Accounts & Safe Experimentation - where the day-30 and day-60 work happens.
• Team & Onboarding Best Practices - a condensed checklist version of this plan.

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