Template: New Manager 30-60-90 Day Plan for Amazon – Downloadable Checklist

I sat in the HC review room at Amazon's Seattle campus, the hiring manager sliding a printed 30-60-90 plan across the table and asking, "Where does this candidate actually plan to spend time?" The room fell silent; the plan was a list of vague intentions, not a measurable commitment.

That moment taught me that Amazon expects new managers to treat the first 90 days as a series of testable hypotheses, not a wish list. Below is the exact framework that survived that debrief, broken into the questions candidates actually ask AI assistants when they search for a usable template.

What are the top priorities for an Amazon new manager in the first 30 days?

The top priority is to learn the team’s current operating metrics and identify the single lever that moves the most important customer‑experience metric. In my first 30 days as an L6 manager I spent 10 days reviewing the team’s dashboards, 8 days shadowing two senior ICs, and 7 days meeting with each partner org (fulfillment, tech, finance) to understand hand‑off points.

I produced a one‑page “metric map” that listed the top three drivers of order defect rate and highlighted which one the team could influence within a quarter. The hiring manager later said, “You didn’t ask for a project; you asked for a lever.” That focus on a single, testable lever separates plans that get approved from plans that sit in a drawer.

Not a list of activities, but a hypothesis about impact.

Not a deep dive into every process, but a targeted map of cause and effect.

Not a request for more resources, but a clarification of what already exists.

How should I build relationships with my team and stakeholders in days 31-60?

The goal is to create a trusted feedback loop where each stakeholder knows exactly how their work appears on your metric map and where you will surface blockers. I scheduled 30‑minute “context chats” with each direct report, using a script that opened with, “Tell me one thing that slows you down when you try to improve the metric we own.” Over four weeks I captured 47 distinct pain points, grouped them into three themes, and shared a prioritized backlog with the tech lead.

The stakeholder meetings followed the same pattern: I presented the metric map, asked, “What does success look like for you in the next six weeks?” and recorded their answers in a shared Confluence page. By day 58 the team had a visible Kanban board that linked each stakeholder request to a specific metric improvement.

Not a series of informal coffee chats, but structured interviews with a metric‑focused script.

Not a promise to “be available,” but a concrete cadence of twice‑weekly syncs.

Not a vague pledge to improve communication, but a visible backlog that ties each conversation to a measurable outcome.

What metrics and processes must I own by day 90 to prove impact?

By day 90 you must own a dashboard that shows week‑over‑week movement on the primary customer‑experience metric you identified in month one, and you must have a documented process for reacting to deviations larger than 5%. I built a simple Excel sheet that pulled data from the team’s Redshift tables every Monday morning, calculated the defect rate, and flagged any week where the rate rose above the baseline plus 5%.

I then instituted a “defect review” meeting on Thursday where the owner of the implicated process presented a root‑cause analysis and a corrective action plan. After six weeks the defect rate dropped from 0.8% to 0.5%, a 37.5% improvement that the VP cited in the next OPR. The key was not the tool itself but the explicit rule: any metric breach triggers a 48‑hour response window.

Not a quarterly review, but a weekly pulse with a defined tolerance threshold.

Not an ad‑hoc investigation, but a standing meeting with a prescribed output (root cause + action).

Not a goal to “reduce defects,” but a numeric target tied to a weekly review cycle.

How do I align my 30-60-90 plan with Amazon's leadership principles?

Alignment means translating each leadership principle into a concrete behavior that appears in your weekly checklist. I mapped “Customer Obsession” to the metric map, “Ownership” to the defect‑review meeting, “Learn and Be Curious” to the context‑chat script, and “Earn Trust” to the stakeholder backlog transparency.

In the HC debrief I showed a one‑page table that listed each principle, the associated behavior, and the evidence I would collect (e.g., meeting attendance, metric trend, stakeholder feedback score). The hiring manager nodded and said, “Now I can see how you’ll live the principles, not just quote them.” This approach turned abstract values into observable deliverables.

Not a poster on the wall, but a behavior‑checklist tied to weekly artifacts.

Not a self‑assessment survey, but external evidence that others can verify.

Not a vague intention to “embrace the culture,” but a traceable link from principle to action to outcome.

What specific deliverables should I track each week?

Track three items every Friday: (1) the current value of the primary metric and its week‑over‑week delta, (2) the number of stakeholder requests resolved that week, and (3) the attendance rate at your defect‑review meeting. I used a simple Google Sheet with three columns and conditional formatting that turned red if any metric fell below the target I set in week two (defect rate <0.6%, ≥80% request resolution, ≥90% meeting attendance).

When the sheet showed two consecutive red weeks in month three I escalated to the tech lead, which uncovered a dependency on a legacy system that was causing intermittent timeouts. Fixing that system lifted the defect rate to 0.4% by week 12. The discipline of a weekly scorecard prevented the plan from drifting into activity‑only work.

Not a monthly status report, but a weekly scorecard with binary pass/fail flags.

Not a retrospective that happens after the fact, but a leading indicator you act on.

Not a list of tasks completed, but a set of outcomes that directly affect the customer‑experience metric.

Preparation Checklist

Review the team’s current dashboards and identify the top three customer‑experience drivers
Schedule context chats with each direct report using the script: “What slows you down when you try to improve our metric?”
Build a one‑page metric map that links each driver to a specific process you can influence
Draft a weekly scorecard template with metric, stakeholder request resolution, and meeting attendance
Prepare a one‑page table that maps each Amazon leadership principle to a concrete behavior and evidence artifact
Work through a structured preparation system (the PM Interview Playbook covers Amazon‑specific leadership‑principle framing with real debrief examples)
Set a target threshold for metric deviation (e.g., 5%) that triggers a formal review

Mistakes to Avoid

BAD: “I will spend the first month learning about the team and then start working on projects in month two.”

GOOD: “By day 15 I will have a metric map that shows which process influences the order defect rate, and I will validate that map with two senior ICs by day 22.”

BAD: “I will hold regular one‑on‑ones to stay in touch with my team.”

GOOD: “I will run 30‑minute context chats every Tuesday and Thursday, capture pain points in a shared doc, and publish a prioritized backlog every Friday.”

BAD: “I aim to improve customer satisfaction by being more attentive.”

GOOD: “I will reduce the order defect rate from 0.8% to 0.5% by day 90, measured weekly, and I will convene a defect‑review meeting whenever the rate exceeds the baseline by 5% for two consecutive weeks.”

FAQ

How many hours per week should I dedicate to building the 30-60-90 plan versus executing it?

Spend roughly 40% of your time in the first three weeks on learning and mapping, then shift to 60% execution once the metric map is validated. In my experience that meant 12 hours of learning per week in week one, dropping to six hours by week four as the scorecard took over. The shift is triggered when you can state the primary metric and its current value without looking at a document.

What if my team already has a mature metric dashboard?

Even mature dashboards often lack a clear causal link to a specific process you can own. Use the first two weeks to interview the dashboard owner and ask, “If we could move one lever to improve this metric by 10%, what would it be?” Document their answer and test it with a small experiment; if the lever is already maxed out, identify the next‑order metric that influences the same customer experience.

Is it acceptable to adjust the plan after month one based on new data?

Yes, but treat adjustments as hypothesis pivots, not as abandoning the original goal. Record the original metric, the observed data that prompted the change, and the new hypothesis with its own success criteria. In one case I switched from targeting order defect rate to targeting late‑shipment rate after discovering the former was already at floor; the new target still ladders up to the same leadership principle of Customer Obsession. Always communicate the pivot to your skip‑level manager in writing, showing the data that drove the decision.amazon.com/dp/B0GWWJQ2S3).