Lenny's PodcastUnpacking Amazon’s unique ways of working | Bill Carr (author of Working Backwards)
CHAPTERS
- 0:00 – 0:32
Cold open: Customer obsession and the core idea behind “working backwards”
Bill frames Amazon’s decision-making philosophy as an “article of faith”: if you serve customers exceptionally well, the business outcomes will follow. He explains why starting with the customer’s needs clarifies what work must be done to build the right solution.
- •Customer-first decisions as a foundational belief, not a provable theorem
- •Outputs (revenue, cash flow, share price) are expected to follow strong customer value
- •Working backwards identifies the engineering/cost/operational problems to solve
- •Customer benefit is the starting point for new products and features
- 0:32 – 4:32
Bill Carr’s background, the book, and what this episode will cover
Lenny introduces Bill Carr’s Amazon tenure and leadership roles (Books, Digital Media, Prime Video, Studios), plus his work after Amazon and as a consultant. He previews the episode’s deep dive into Amazon’s practices: working backwards, single-threaded leadership, metrics, disagree-and-commit, and hiring.
- •Bill’s 15-year Amazon journey and leadership scope
- •Working Backwards as a synthesis of Amazon’s mechanisms
- •Episode roadmap: org design, PR/FAQ, metrics, decision-making, hiring
- •Bill’s current consulting work helping companies implement these practices
- 4:32 – 9:55
Why Amazon generated so many “shareable” ways of working (and the key innovation window)
Lenny asks why Amazon contributed so many widely adopted mechanisms. Bill argues Amazon was as focused on process innovation as product innovation, and highlights a narrow period (2003–2007) when many foundational products and processes were created to handle growing complexity.
- •Amazon deliberately innovated on processes, not just products
- •Many mechanisms were created as Amazon scaled beyond “CEO in every meeting”
- •2003–2007 as the unusually dense period of process + product invention
- •Bezos’s scientific/experimental mindset applied to management mechanisms
- •Leadership principles reinforced by real processes, not posters
- 9:55 – 11:44
A process that didn’t work: Amazon’s abandoned “fitness function” metric
Bill shares an example of an Amazon mechanism that failed to spread because it wasn’t effective: a “fitness function” index combining weighted metrics into a single score. The lesson: compound metrics often hide causal insight and create confusion instead of clarity.
- •Fitness function = weighted rollup of multiple metrics into one index
- •Compound metrics obscure what actions drive outcomes
- •Better approach: manage key metrics independently with clear ownership
- •Practical warning: avoid “munging” signals into a meaningless single number
- 11:44 – 20:16
Single-threaded leadership: what it is and why Amazon leaned into it
Bill defines single-threaded leadership as a way to reduce resource contention and speed execution by creating dedicated, accountable teams. He contrasts this with heavily centralized planning processes that consume time and debate flawed assumptions.
- •Scale creates competing teams fighting for constrained resources (engineering/AI)
- •Amazon optimized for ownership, speed, and agility
- •Dedicated cross-functional teams with a single accountable leader
- •Shift from meeting-heavy coordination to clearer autonomy with strong reviews
- •Senior leadership “referees resourcing,” not daily roadmap arguments
- 20:16 – 22:06
Single-threaded teams vs. the GM/P&L model: where they overlap and differ
Lenny probes whether single-threaded leadership is just the GM model in different clothes. Bill explains how P&L ownership can be sliced too narrowly, and emphasizes the core design test: does the team control enough resources to truly own outcomes?
- •GM model often implies P&L ownership; can be subdivided too far
- •Key org-design question: does the team control what it needs to succeed?
- •Examples of sensible boundaries (e.g., Prime Video apps by device platform)
- •Over-fragmentation can create teams without real levers to manage results
- 22:06 – 25:23
Making single-threaded leadership work: prerequisites and functional countermeasures
Bill explains the practical enablers for autonomous teams, including decoupled software architectures and explicit “countermeasures” to preserve functional excellence. The core tradeoff: autonomy and speed can degrade craft development if you don’t build mechanisms to compensate.
- •Technical prerequisite: move from monoliths to service-based architectures/APIs
- •Org-structure has no free lunch; autonomy trades off with functional depth
- •Countermeasures: centralized functional standards (interviewing, promotions, reviews)
- •Functional leaders/experts contribute across teams via panels, reviews, mentorship
- •Leaders may manage outside their craft—systems must fill the coaching gap
- 25:23 – 32:45
“Have backbone; disagree and commit”: how it actually works (and how people misuse it)
Bill unpacks why disagree-and-commit is nuanced and frequently misunderstood. The “disagree” phase is about surfacing missing information and alternative viewpoints; “commit” happens after you feel heard and your reasoning has been understood and weighed.
- •Obligation to voice dissent to improve decision quality
- •Escalate if needed—but aim for understanding, not winning
- •Stop disagreeing once the leader demonstrates understanding and weighs tradeoffs
- •Real commitment isn’t passive-aggressive compliance; it’s informed alignment
- •Practical tactic: focus on the “kernel” of why the leader believes the direction matters
- 32:45 – 35:25
“Leaders are right, a lot”: judgment, data interpretation, and credibility
Bill explains that data rarely “makes” decisions; leaders interpret ambiguous signals and apply judgment. The principle emphasizes developing sound judgment through experience (including being wrong), which builds trust and followership over time.
- •Data can be framed to support multiple narratives; judgment is unavoidable
- •Being “right a lot” is earned through experience and learning from mistakes
- •Teams won’t follow leaders who repeatedly choose baffling directions
- •The wording matters: it’s “right a lot,” not “right always”
- 35:25 – 41:11
What “working backwards” means: start with customer needs, not constraints
Bill defines working backwards as beginning with durable customer problems and imagining solutions without immediately defaulting to internal constraints. Only after a clear customer benefit is articulated do teams work backwards to solve cost, engineering, legal, and operational challenges.
- •Two sources: customer-obsession principle + PR/FAQ product process
- •Work backwards from customer needs; don’t start from revenue targets
- •Constraints are addressed after the customer value is clear
- •Low-cost structure matters only if it’s used to improve customer value (e.g., lower prices)
- 41:11 – 54:35
PR/FAQ as Amazon’s innovation engine: press release, FAQs, and the product funnel
Bill describes how Amazon operationalized working backwards via the PR/FAQ: an internal “press release” that crisply defines the customer, problem, and solution, paired with FAQs. He details the concentric-circle review process, how many ideas die early, and why this creates a funnel (not a tunnel) that prevents teams from building poorly formed ideas.
- •PR/FAQ turns a concept into a scalable, repeatable product decision process
- •The core: customer definition + problem statement + solution statement (harder than it sounds)
- •Not a real press release: factual, data-rich, no hyperbole; headline/date provide clarity
- •Concentric-circle iteration: expand reviewers over time; many docs get killed early
- •Goal: create a product funnel where only the best ideas reach build stage
- •Separate processes: deciding what to build vs. executing delivery efficiently
- 54:35 – 1:04:23
Input vs. output metrics and the Amazon flywheel: avoiding short-term fire drills
Bill explains how Amazon shifted away from quarter-end revenue “panic tactics” toward improving controllable input metrics that drive long-term outcomes. He connects this to the flywheel model and offers a method for discovering good input metrics by instrumenting the end-to-end customer experience.
- •Output panic leads to last-minute promos/emails that rarely create durable growth
- •Good to Great helped Amazon codify its flywheel and focus on inputs
- •Inputs: selection, price, delivery speed, customer experience quality, cost structure
- •S-team goals skewed heavily toward input metrics vs. financial outputs
- •Finding good inputs: map the customer journey; measure speed/quality/ease at each step
- •Heuristics: controllable levers, customer-experience linkage, iterative validation (DMAIC)
- 1:04:23 – 1:10:16
When frameworks still fail: Fire Phone, disagreement signals, and why timing matters
Lenny asks how failures happen even with strong mechanisms like PR/FAQ. Bill emphasizes that tools don’t guarantee correct decisions, and argues Fire Phone likely started with a technology (3D effects) and then searched for a customer problem—an inversion of working backwards; he also notes that internal disagreement doesn’t reliably predict failure because many successes were heavily doubted too.
- •No mechanism provides certainty; they only improve decision quality
- •Fire Phone as “solution looking for a problem” (tech-first vs. customer-first)
- •Disagreements aren’t a reliable failure predictor (Kindle and Prime Video were doubted)
- •Some failures are timing/scale issues (e.g., early ad-like “Slots” lacked scale)
- •Calculated risk-taking as a prerequisite for big innovation
- 1:10:16 – 1:13:52
Building a real risk-taking culture: incentives, performance systems, and CEO engagement
Bill addresses why many companies say they tolerate failure but punish it in reviews and bonuses. He explains how Amazon’s compensation (stock-based, no performance bonuses) and input-oriented evaluation reduced fear of failure, and how direct CEO involvement helps protect innovative teams from organizational “crushing.”
- •Common failure: incentives penalize people for joining risky projects
- •Amazon: no performance bonuses; long-term stock alignment reduced short-term gaming
- •Performance evaluation emphasized what was built/contributed (inputs), not just outcomes
- •Innovation needs structural protection: fewer approvals, faster decisions, dedicated teams
- •CEO commitment can’t be delegated; senior sponsorship runs interference
- •Putting top leaders on new bets and keeping them close to the CEO (e.g., Jassy/Kessel examples)
- 1:13:52 – 1:20:41
The Bar Raiser hiring program: preventing quality decay during hypergrowth
Bill explains why Amazon created Bar Raisers: rapid hiring led to “new people hiring new people,” risking cultural and quality drift. The Bar Raiser is an independent interviewer who runs the debrief, enforces objective criteria (leadership principles + behavioral interviewing), and acts as a counterweight to a hiring manager’s urgency bias.
- •Origin: maintain standards when teams scale faster than culture can propagate
- •Independent Bar Raiser is not the hiring manager or recruiter
- •Bar Raiser runs the debrief; nominal veto power exists but is rarely used directly
- •Objective criteria: leadership principles; method: behavioral interviewing
- •Primary value: help hiring managers make better decisions and avoid urgency bias
- •Implementation advice: pilot in one org; select people with high standards and interviewing skill; train them
- 1:20:41 – 1:33:27
Adopting Amazon practices without “becoming Amazon”: rollout advice, consulting, and lightning round
Bill advises companies to adopt mechanisms selectively and thoughtfully, recognizing they’re profound changes requiring commitment and often CEO buy-in. He then shares how he and Colin engage as hands-on advisors, followed by a lightning round on books, media, products, interviewing, and personal mottos.
- •Don’t try to copy Amazon wholesale; adapt practices to your culture
- •Many changes require CEO sponsorship (product development, hiring)
- •Pilot some mechanisms locally (e.g., PR/FAQs) but expect a learning curve
- •Successful rollout needs discipline—half-trying usually fails
- •Bill’s advisory approach: assess current state, prioritize issues, coach in meetings
- •Lightning round highlights: key books, favorite shows/movies, interview question, and “slow is smooth, smooth is fast”
