Dave Anderson spent over 12 years at Amazon as a software development manager (SDM) and director of engineering before retiring early. He offers a candid look at how Amazon works differently from other large tech companies, from its leveling system and hiring process to on-call culture, performance management, and frugality. Many of the traits that make Amazon unusual—extreme ownership, decentralized teams, and relentless operational discipline—also explain why former Amazon engineers tend to thrive at startups and other companies.
Amazon’s career levels for engineers and managers
Amazon’s engineering levels start at L4 (entry-level, typically new college graduates) and go up to L10 (Distinguished Engineer or VP).
L4: Entry-level engineer; expected to need guidance and oversight.
L5: Mid-level engineer who can work independently on decent-sized projects; also the rare “junior” SDM level.
L6: Senior software engineer or SDM managing a “two-pizza team” (small, autonomous team); this is where many engineering careers plateau.
L7: Principal engineer (leading across multiple teams) or senior SDM (first level managing managers).
L8: Senior principal engineer or director.
L10: Distinguished engineer or VP; the pinnacle for most individual contributors and managers.
There is no L9 at Amazon—the senior director level was never formally created.
The numbering starts at L4 for historical reasons; L3 exists only in niche roles like QA testers or fulfillment center workers.
How promotions work
Promotions are driven by detailed written documents (six-pagers) that map specific criteria for each level.
L4→L5 is relatively straightforward: demonstrate you can complete projects independently over ~1.5–2 years.
L5→L6 is a significant jump requiring a multi-page narrative showing repeated work at the next level, endorsed by several peers or senior engineers.
L6→L7 (principal) is extremely difficult, involving years of documented large-scale project leadership and technical assessments from existing principals who have incentives to say no.
Each level up becomes exponentially harder.
Managers face structural pressure to grow their team size because having many direct reports creates an expectation of promotion (e.g., “this person has 55 reports but is only L6—they must be promoted”).
The hiring process and the bar raiser
Amazon’s interview process is similar to other big tech companies: phone screen followed by a loop of ~5 interviewers.
For engineers: typically two coding interviews, a design or architecture interview (for senior roles), and at least one leadership-principle behavioral interview.
One interviewer is a bar raiser—a trained, experienced interviewer from outside the hiring team who can veto a hire but cannot unilaterally approve one. Both the hiring manager and bar raiser must say yes.
After interviews, all feedback is written up in detailed notes (question, candidate’s answer, interviewer’s interpretation, and hire/no-hire vote).
The bar raiser leads a debrief meeting where everyone reads the written feedback, shares their current thinking, and pressure-tests both directions.
The bar raiser’s role is to ensure fair discussion, prevent fixation on minor issues, and correct misinterpretations from less experienced interviewers.
Bar raisers typically have 100–600+ interviews under their belt and undergo an apprenticeship (observing and being observed) before leading loops independently.
Tooling and technology stack
Amazon’s stack varies widely by team—there is no single mandated toolset.
Many teams build on AWS, but some use homegrown web hosting platforms or other internal tools.
Mobile teams use standard Apple/Google development tools.
Teams have significant freedom to choose their programming languages, deployment methods, and monitoring tools—sometimes leading to odd choices (e.g., a critical service written in Lisp that later had to be rewritten when the original engineers left).
On-call culture and operational ownership
At Amazon, engineers who write the code also own its production support—including deployment decisions, database sharding, and emergency response.
Most teams run a weekly on-call rotation; a typical engineer might get paged ~2 times per week during their rotation.
The philosophy: the pain of bad software should land on the people responsible for fixing it, creating strong incentives to build reliable systems and fix root causes quickly rather than applying band-aids.
Outages are classified by severity (sev 1–5):
Sev 5: negligible, no action needed.
Sev 3: a problem to fix eventually.
Sev 2 and Sev 1: emergencies that trigger immediate response and escalate up the leadership chain.
Sev 1 can involve VPs and SVPs joining calls, especially at AWS scale, where Amazon’s monitoring is sometimes better than backbone providers’ and Amazon can direct external partners to specific failure points.
Well-run teams treat on-call pain as a signal to stop feature work and fix underlying problems; poorly run teams suffer chronic multi-times-per-night pages, which is considered a management failure.
The upside: engineers develop deep operational skills (debugging live systems, coordinating with customers and third parties, making rapid decisions under pressure) that are highly valued at startups and other companies.
Frugality as a core value
Amazon’s frugality is extreme and sometimes frustrating for engineers (e.g., single small monitors, vending machines that generate profit rather than being free).
The rationale: Amazon employs over a million fulfillment center workers with very thin margins, and the company avoids offering corporate perks that would be legally or financially difficult to extend to FC workers.
The broader principle: unless there’s a strong reason to spend money, don’t. Engineers sometimes had to write six-pagers justifying hardware upgrades with productivity data.
Compared to companies like Meta (where free food and experimental projects are common), Amazon’s discipline reduces waste but can feel stingy.
Performance management: the URA target and PIPs
Amazon has a long-standing practice of expecting roughly 6–10% of employees to be rated as underperformers (“unregulated attrition” or URA target).
This cascades through large organizations: directors and senior managers must identify a certain number of people for coaching or performance improvement plans (PIPs).
For most individual contributors, this is not a daily concern—people focused on doing good work and getting promoted rarely think they’re in the bottom 10%.
It becomes scary when someone moves to a new team or gets a new manager who doesn’t rate them highly; that’s when PIPs happen.
The rating is called “least effective,” not “ineffective”—it’s a relative comparison. Someone can be a competent engineer but still be the slowest or most error-prone on their team.
Ideally, managers give ongoing feedback throughout the year so the rating isn’t a surprise.
Problems arise when a manager has been positive all year and suddenly initiates a PIP, or when a new manager doesn’t understand the employee’s track record.
Compared to Netflix’s “keeper test” (would you fight to keep this person?), Amazon’s approach is more explicitly comparative and continuous.
Other companies (Meta, Stripe) have started adopting similar performance-based layoff practices, suggesting Amazon’s model is becoming more common.
Advice for engineers receiving negative performance feedback
If you start hearing any performance criticism from your management chain, consider transferring teams immediately—before being flagged as non-transferable in the system.
Internal transfers are easier than external job searches and let you rebuild your reputation with a new manager.
Many engineers who were struggling on one team have thrived after moving to another, and vice versa.
Your relationship with your manager is critical at Amazon: they control your rating, compensation, and promotion prospects. If you don’t get along, fix it or move.
Good managers often bring trusted team members when they move to new organizations. If you’ve had a strong manager in the past, reaching out can open doors.
Why former Amazon engineers succeed at startups and other companies
Amazon’s decentralized, high-ownership culture means engineers operate like they’re in a small startup:
Teams choose their own tools, languages, processes, and deployment strategies.
Engineers make product decisions, set up their own monitoring, and own the full stack from code to production.
There’s no reliance on internal-only tools that don’t exist outside Amazon (unlike Google or Meta); many teams use AWS, which is widely available externally.
The combination of operational rigor, frugality, autonomy, and customer obsession produces engineers who are adaptable, resourceful, and comfortable with ambiguity—traits that translate well to startups, scale-ups, and other large tech companies.
The downside of decentralization: some teams are poorly managed with no higher-level intervention, leading to pockets of high turnover and bad experiences. Amazon’s overall attrition stats are fine, but individual teams can be terrible.
Dave’s path to early retirement
Dave discovered the financial independence (FI) movement in his early 30s and began planning his exit.
He tracked expenses, studied withdrawal rates and index funds, and built a spreadsheet projecting when he’d have enough to stop working.
Amazon’s strong compensation (including stock appreciation) and a high savings rate (he and his wife, also an Amazon engineer, eventually saved ~85% of their income) accelerated the timeline.
He reached his safety margin around the time he was promoted to director.
After leaving Amazon, he briefly worked at Bezos Academy (a nonprofit) and did some coaching, but found his calling through writing.
A popular LinkedIn article he wrote about Amazon’s leadership principles led him to start the Scarlet Ink newsletter (scarleting.com).
The newsletter grew quickly, eventually generating more income than his expenses—allowing him to stop considering traditional employment.
He now writes one article per week on topics he finds interesting, without pressure to chase trends, which he believes makes the work better.
Resources he recommends for learning about financial independence: Mr. Money Mustache (blog), The Mad Fientist, and a book he lists on his website.
