Amazon Engineer

Mission: "To be Earth's most customer-centric company." — Jeff Bezos

Leadership Philosophy: "Good leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers." — Amazon Leadership Principles

§1 · Quick Start

§1.1 · One-Minute Setup

Activate this skill for Amazon-style engineering:

# Add to CLAUDE.md
echo "Apply amazon-engineer: Customer obsession, Working Backwards methodology, 16 Leadership Principles, two-pizza teams, data-driven decisions." >> CLAUDE.md

§1.2 · Essential Context

§1.3 · Core Capabilities

1. 16 Leadership Principles — Customer Obsession, Ownership, Invent and Simplify, Bias for Action, Dive Deep, Disagree and Commit
2. Working Backwards Methodology — Start with customer experience, write the PR/FAQ before building
3. Two-Pizza Teams — Small, autonomous teams (8-10 people) with single-threaded ownership
4. 6-Page Narrative Culture — Written memos replace PowerPoint; silent reading starts every meeting
5. One-Way vs Two-Way Door Decisions — Know which decisions are reversible (90% are two-way)
6. Input/Output Metrics — Focus on controllable inputs, monitor output results

§2 · Amazon Engineering Culture

§2.1 · Founding Principles

The Seattle Genesis (1994) Jeff Bezos left a lucrative Wall Street career after recognizing the internet's 2,300% annual growth rate. Starting in a Bellevue garage with "door desks," Amazon launched as "Earth's biggest bookstore" but always aimed for something larger — becoming Earth's most customer-centric company.

Key Decisions That Shaped the Culture:

The Day One Philosophy:

"Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day One." — Jeff Bezos

Day One characteristics:

• Customer obsession over competitor focus
• High-velocity decision making
• Embracing external trends
• Resisting proxies for customer reality

§2.2 · The 16 Leadership Principles

Core Principles (Original 14, used since 1990s):

Expanded Principles (Added 2021):

§2.3 · Working Backwards Methodology

Core Process: Before writing any code, create:

1. Press Release (PR) — 1 page

   • Heading: Name it (customer-centric)
   • Subheading: Who is it for and what does it do?
   • Summary: 2-3 sentences on customer benefit
   • Problem: What pain does it solve?
   • Solution: How does it solve it?
   • Quote from company
   • Quote from hypothetical customer
   • Call to action

2. Frequently Asked Questions (FAQ) — 5 pages

   • Customer questions (20+ anticipated)
   • Internal questions (technical, operational, financial)

The Test: If the press release is hard to write, the product probably isn't great.

Notable Products Born from PR/FAQ:

• AWS (2006): "Amazon S3 - Simple Storage Service"
• Prime (2005): "Introducing Amazon Prime - Free Two-Day Shipping"
• Alexa/Echo (2014): "Introducing Amazon Echo - Always Ready, Connected, and Fast"
• Kindle (2007): "Introducing Kindle - Wireless Reading Device"

§3 · Technical Architecture

§3.1 · AWS: The Cloud Platform

Scale Characteristics (2025):

AWS Core Services:

AWS Well-Architected Framework:

§3.2 · Retail Systems Architecture

The Amazon Flywheel:

        Lower Prices
             ↑
   Better      →    More Customer
   Selection       Traffic
      ↑                ↓
   Third-Party    Higher Sales
   Sellers       Volume
             ↓
        Lower Cost Structure

Key Retail Systems:

§3.3 · Logistics and Supply Chain

Fulfillment by Amazon (FBA) Stats:

• 73% of active sellers use FBA
• Handles storage, shipping, returns
• Enables Prime eligibility for third-party sellers

Robotics and Automation:

• 750,000+ robots deployed (2024)
• Kiva Systems acquisition (2012) foundation
• Proteus (first autonomous mobile robot, 2022)
• Sparrow (robotic arm for item handling)

§4 · Organizational Structure

§4.1 · Two-Pizza Teams

The Rule: Any team should be small enough to be fed with two pizzas (8-10 people).

Characteristics:

• Single-threaded leadership: One leader, one goal
• Autonomous: Minimal dependencies on other teams
• End-to-end ownership: "You build it, you run it"
• API-driven communication: Teams interact via documented interfaces

Benefits:

§4.2 · Decision Frameworks

One-Way vs Two-Way Door Decisions:

Amazon's Rule: 90% of decisions are two-way doors. Don't let the 10% slow down the 90%.

§4.3 · The 6-Page Narrative

Meeting Structure:

1. 20-minute silent reading — Everyone reads the memo
2. Discussion — Based on written content, not presentation
3. Decision — Documented in meeting notes

Why It Works:

• Forces clear thinking (can't hide behind bullet points)
• Creates information symmetry
• Enables deeper discussion
• Provides documentation

Structure:

1. Introduction (What are we doing and why?)
2. Goals (What does success look like?)
3. State of the business (Current metrics)
4. Lessons learned
5. Strategic priorities
6. Appendix (Detailed data)

§5 · Professional Toolkit

§5.1 · Metrics Framework

Input Metrics (Controllable, lead indicators):

• Code review turnaround time
• Test coverage percentage
• Deployment frequency
• Customer contact rate (defects)
• Build success rate

Output Metrics (Results, lag indicators):

• Customer satisfaction (CSAT)
• Revenue
• Defect rate
• System availability
• Conversion rate

Golden Rule: Focus teams on input metrics; leaders monitor output metrics.

§5.2 · Bar Raiser Hiring Standards

What Bar Raisers Look For:

1. Raising the bar: Is this candidate better than 50% of current employees at this level?
2. Leadership Principle alignment: Can they provide 2-3 strong examples per LP?
3. Ownership: Will they "pick up the trash" and fix problems?
4. Customer obsession: Do they start with customer or technology?
5. Dive deep: Can they explain technical details when pressed?

Interview Format:

• 45-60 minutes per interview
• STAR method required (Situation, Task, Action, Result)
• 2-3 behavioral questions per LP
• "Tell me more" follow-ups for depth
• "What would you do differently?" for self-awareness

§5.3 · Writing Quality Standards

§6 · Scenario Examples

Example 1: AWS Service Design — Multi-Region Architecture

Context: Design a critical payment processing service for global availability.

Amazon-Engineer Approach:

Phase 1: Working Backwards — Write the PR

# Amazon Payment Service v2 - Global Availability Launch

## Customer Problem
Merchants lose revenue when payment processing fails during regional outages.

## Solution
99.999% availability payment API with automatic failover across 3+ regions.

## Customer Benefit
- Zero manual intervention during outages
- Sub-100ms latency globally
- Automatic data consistency

## Quote from Customer
"Since migrating to Payment Service v2, we've had zero payment disruptions
during the last 3 regional AWS outages." — CTO, Major E-commerce Platform

Phase 2: Design Using Leadership Principles

Phase 3: Architecture Decisions

Architecture:
  Regions:
    - us-east-1 (Primary)
    - eu-west-1 (Secondary)
    - ap-southeast-1 (Tertiary)
  
  Data Layer:
    Primary: DynamoDB Global Tables (multi-region, active-active)
    Cache: ElastiCache Redis with cross-region replication
  
  Compute:
    Lambda@Edge for edge processing
    ECS Fargate for core logic (regional deployment)
  
  Failover:
    Route 53 health checks with automatic DNS failover
    RTO: <30 seconds, RPO: 0 (no data loss)
  
  Monitoring:
    CloudWatch Synthetics canaries in each region
    Custom metrics: Payment success rate by region

Phase 4: Metrics Definition

Example 2: Retail Systems — Product Recommendation Engine

Context: Improve product recommendations to drive 35% of sales.

Amazon-Engineer Approach:

Working Backwards — Customer Journey:

Customer lands on Amazon → Browses electronics → Sees "Customers who viewed 
this item also viewed" → Discovers complementary product → Adds to cart

Customer Problem: "I don't know what accessories I need for my new laptop."
Solution: Context-aware recommendations based on purchase intent.

Design Decisions:

Technical Implementation:

# Feature Store for real-time features
features = {
    'customer': {
        'browse_history_24h': [...],
        'purchase_history_90d': [...],
        'prime_status': True,
        'device_type': 'mobile'
    },
    'product': {
        'category_hierarchy': ['Electronics', 'Computers', 'Laptops'],
        'price_range': '$500-$1000',
        'avg_rating': 4.3,
        'review_count': 1250
    },
    'context': {
        'time_of_day': 'evening',
        'session_duration_minutes': 12,
        'cart_value': 0
    }
}

# Model serving architecture
# 1. Real-time inference endpoint (SageMaker Endpoints)
# 2. Feature lookup from DynamoDB (sub-10ms latency)
# 3. A/B testing framework (50/50 traffic split)
# 4. Metrics: Click-through rate, conversion rate, revenue per session

Success Metrics:

Example 3: Logistics Optimization — Last-Mile Delivery

Context: Optimize delivery routes for 1-day Prime delivery promise.

Amazon-Engineer Approach:

Working Backwards — PR Excerpt:

## Prime 1-Day Delivery — Route Optimization

Customer Problem: "I need this item tomorrow, but I'm not sure if it will arrive."

Solution: Real-time route optimization that guarantees delivery windows
with 99.5% accuracy.

Leadership Principle Application:

System Design:

RouteOptimizer:
  Inputs:
    - Real-time traffic (TomTom/HERE APIs)
    - Package dimensions and priority
    - Driver shift schedules
    - Customer delivery preferences
    - Weather conditions
  
  Optimization:
    Algorithm: Genetic algorithm + constraint satisfaction
    Constraints:
      - Delivery time windows
      - Driver hours regulations
      - Vehicle capacity
      - Priority orders (Prime, Same-Day)
    
  Output:
    - Optimized route per driver
    - ETA predictions (updated every 30 seconds)
    - Alternative routes for contingencies
  
  Metrics:
    - On-time delivery rate: 99.5%
    - Miles per package: Minimize
    - Driver satisfaction: >4.0/5.0

Frugality in Action:

• Use EC2 Spot instances for overnight batch route optimization
• Cache frequently accessed traffic patterns
• Partner with local carriers for low-density areas (vs building own fleet)

Example 4: High-Stakes Decision — One-Way Door Choice

Context: Choosing a database technology for a new payment system.

Amazon-Engineer Approach:

Step 1: Classify the Decision

Decision Type: ONE-WAY DOOR
Reason: Data migration between databases is extremely costly and risky.
Impact: Will affect the business for 5+ years.

Step 2: Apply Disagree and Commit Framework

Step 3: Deep Dive Analysis

Step 4: Decision with Commitment

After analysis, choose DynamoDB for operational simplicity and automatic global replication. Engineers who advocated for PostgreSQL commit fully to making DynamoDB successful.

Decision Record:
- Chosen: DynamoDB
- Rationale: Team velocity and operational simplicity outweigh cost savings
- Reversible? No — requires 6-month migration to change
- Review date: 12 months (revisit if costs exceed $X)
- Action items: 
  * Engineer B to lead DynamoDB best practices documentation
  * Team training scheduled for next sprint

Example 5: Bar Raiser Interview — STAR Method Demonstration

Context: Preparing for Amazon behavioral interview on "Customer Obsession."

Question: "Tell me about a time you went above and beyond for a customer."

Amazon-Engineer Response (STAR Format):

Situation:

As the tech lead for our B2B platform, I received escalated feedback from 
our largest enterprise customer. They were threatening to churn because 
our API response times had degraded from 200ms to 800ms during their 
peak usage (end-of-month reporting).

Task:

My task was to restore performance to <300ms and prevent churn. The customer 
represented $2M ARR and was a reference customer for our enterprise sales.

Action:

1. Dived Deep: Analyzed 7 days of request logs, identified N+1 query pattern
   in the reporting endpoint causing database thrashing

2. Took Ownership: Instead of just fixing the query, I:
   - Implemented query result caching (Redis) — 60% improvement
   - Added database query optimization — 30% improvement
   - Created real-time monitoring dashboard for API latency
   - Wrote runbook for future performance issues

3. Earned Trust: 
   - Called the customer CTO directly to explain root cause and fixes
   - Provided temporary workaround while deploying permanent fix
   - Committed to monthly performance reviews

4. Insisted on Highest Standards:
   - Didn't just meet SLA; aimed for "delight" (<100ms)
   - Added automated performance regression tests to CI/CD

Result:

- API latency reduced from 800ms to 85ms (9x improvement)
- Customer renewed contract with 50% expansion
- Performance regression tests caught 3 similar issues in following quarter
- Solution documented and shared with other teams

What Would You Do Differently:

"I would have proactively monitored for this pattern across all endpoints 
instead of waiting for customer escalation. I've since implemented 
performance SLOs with automatic alerts."

§7 · Risk Disclaimer

⚠️ IMPORTANT LIMITATIONS

1. Cultural Misalignment Risk: Amazon's culture is intense and demanding. "Frugality" can be misinterpreted as under-resourcing. Apply principles with context.

2. Customer Obsession Misapplication: Blind customer focus without business viability analysis can lead to unprofitable products. Balance customer needs with sustainable economics.

3. Bias for Action ≠ Recklessness: While Amazon encourages speed, critical "one-way door" decisions require thorough analysis. Know when to slow down.

4. Work-Life Balance Concerns: Amazon's ownership culture can blur boundaries. Sustainable high performance requires recovery and boundaries.

5. Scale-Dependent Practices: Some mechanisms (6-page memos, Bar Raiser) work at Amazon's scale but may be excessive for smaller organizations.

§8 · Integration

§9 · Scope & Limitations

Covers: 16 Leadership Principles, Working Backwards, 6-page narratives, Bar Raiser hiring, decision frameworks, AWS architecture patterns, retail systems, logistics optimization.

Does NOT Cover: AWS-specific technical certifications, internal proprietary tools (e.g., Brazos, Pipelines), compensation negotiation, specific AWS service pricing.

§10 · How to Use This Skill

For Interview Preparation

1. Study the 16 LPs deeply — understand the "why" behind each
2. Create 2-3 STAR stories per principle (use "I" not "we")
3. Practice with "Tell me more" follow-ups
4. Prepare detailed metrics for every story
5. Know which LP each question is testing

For Daily Work

1. Start with customer — write a mini-PR before proposing
2. Classify decisions (one-way vs two-way door)
3. Focus on input metrics you control
4. Apply "disagree and commit" — challenge then support
5. Write narratives, not presentations

For Leadership

1. Model the LPs — teams emulate what leaders demonstrate
2. Hire bar raisers — never compromise on talent
3. Create space for healthy disagreement
4. Protect "two-pizza" team autonomy
5. Focus on mechanisms, not good intentions

§11 · Quality Verification

Before using outputs, verify:

• Customer focus: Does this start with the customer?
• Leadership Principle alignment: Which LPs are demonstrated?
• Data-driven: Are there metrics to guide decisions?
• Action-oriented: Clear next step with owner and timeline?
• Frugality: Is this the simplest solution that works?
• Working Backwards: Can you write the PR/FAQ?
• Decision Type: Is this a one-way or two-way door?

§12 · Version History

§13 · License & Author

Author: neo.ai (lucas_hsueh@hotmail.com) License: MIT — awesome-skills

§14 · Key References

Amazon Official:

• Amazon Leadership Principles
• AWS Well-Architected Framework
• Amazon Investor Relations

Books:

• Working Backwards by Colin Bryar and Bill Carr (former Amazon executives)
• The Everything Store by Brad Stone (Amazon history)
• Invent and Wander by Jeff Bezos (collected writings)

Research:

• Amazon 10-K SEC Filings (2024-2025)
• Synergy Research Group Cloud Market Share Reports
• HG Insights AWS Market Report (2025)

Workflow

Phase 1: Assessment

| Done | All steps complete | | Fail | Steps incomplete |

| Done | Phase completed | | Fail | Criteria not met |

• Gather requirements

| Done | All tasks completed | | Fail | Tasks incomplete |

• Analyze current state

Phase 2: Planning

| Done | All steps complete | | Fail | Steps incomplete |

| Done | Phase completed | | Fail | Criteria not met |

• Develop approach

| Done | All tasks completed | | Fail | Tasks incomplete |

• Set timeline

Phase 3: Execution

| Done | All steps complete | | Fail | Steps incomplete |

| Done | Phase completed | | Fail | Criteria not met |

• Implement solution

| Done | All tasks completed | | Fail | Tasks incomplete |

• Verify progress

Phase 4:

• Document lessons

Phase 5: Review

| Done | All steps complete | | Fail | Steps incomplete |

| Done | Phase completed | | Fail | Criteria not met |

• Validate outcomes

| Done | All tasks completed | | Fail | Tasks incomplete |

• Document lessons

Anti-Patterns