The Parking Brake

Facebook ran four key-value stores in production at the same time, on purpose. Kent Beck’s 3X model explains why that was correct, and why the instinct to clean it up early is a phase mistake most engineering organisations make without noticing.

While Kent Beck was at Facebook, the company ran four key-value stores in production. At scale. At the same time. Roughly the same API on each one.

Any platform review would call that waste, and would be wrong. Beck’s reading, given in a Software Engineering Daily interview on 28 August 2019, is that the duplication is what made the exploration possible.

“If all those teams were told, ‘No, you have to wait for the corporate standard key value store to come out,’ the explorations wouldn’t have happened, the expansions wouldn’t have happened and you wouldn’t even get to the extract stage.”

The cleanup was a real project with a real return, and it came later. Put four engineers on going from four stores to three, save two thousand servers, then three to two, then two to one, and you end up with one good key-value store and a product that got built while you were deciding. On the instinct to standardise first, Beck is blunt.

“You’re just putting a parking brake on your product and your company.”

That story is the whole of his 3X model in one artefact. The four stores were not a mistake that got fixed. They were correct for the phase the work was in, and the consolidation was correct for the phase it moved to. Do either one at the wrong moment and you lose.

What Beck actually said, and when

3X debuted in a Facebook note called “The Product Development Triathlon” on 19 July 2016, after five years inside Facebook. Beck’s own count, five years, is how long it took him to see the pattern. He had joined in 2011 as the author of the book on test-driven development, found a huge platform running on very little unit testing, offered a TDD class at his first company hackathon and got zero signups. The classes either side of his, advanced Excel and Argentine tango, both filled with waiting lists. He decided to forget everything he knew about software engineering and relearn it.

The model says an idea passes through three phases and each one is a different game. In Explore the opponent is indifference, and you beat it by running many cheap uncorrelated experiments. In Expand the opponent is scale, and the work is clearing whichever resource is about to run out. Extract fights inefficiency, turning growth into the profit that funds the next round of exploration.

In July 2026 Beck restated it as Canon 3X, part of a series where he sets out his ideas “as plainly & unambiguously as possible, no analogies, no persuasion, just the facts”. That version gives each phase a risk, a goal, a strategy, a set of tactics and an exit condition, and one sentence carries everything else.

“Applying the approach from one phase to an idea in another phase kills ideas.”

He names nine things that have to change with the phase. Finance, team size, project management, personnel, technology, risk management, implementation, marketing, sales. Two of those nine, personnel and risk management, he names and never fills in.

Why nobody notices the mismatch

What makes this a real problem rather than a tidy diagram is that from the outside, all three phases look the same.

“What’s confusing about software product development is that all 3 phases look similar—we are shipping increments of value frequently & reliably—even though the goals & tradeoffs are starkly different.”

Same standups, same board, same demo cadence, same two-week rhythm. Nothing visible in the process tells you which game is being played, which means a mismatch produces no alarm. Beck’s own list of what gets misapplied is specific. Teams apply Extract-phase management practices, KPIs, tight schedules and inter-team dependencies, to Explore work where the value is in learning.

And the drift has a direction. He generalises it past Facebook explicitly, calling the balance between exploring and extracting “a universal”.

“Once you’ve gone through that curve once, the natural tendency of everybody is to treat all projects, like extract projects.”

He gives the mechanism in a 2019 essay. Large companies stretch the time from idea to measured feedback “as social structures become more complex, tolerance for risk declines, and extract thinking comes to dominate the culture”, and the delay feeds itself. Fewer experiments produce fewer successes, which puts more pressure on each experiment, which produces fewer experiments. Nothing pulls an organisation back toward Explore on its own. Somebody senior has to hold it open.

What actually changes

Four switches carry most of the practical weight, and all four are in Beck’s own words.

Dependencies. In Explore, “as few as possible”, because an exploration is “small but extremely sensitive to delay”. His Explore tactic is “tiny teams, no dependencies, quickly discard failures”. In Extract they “can & should have dependencies because you’re shooting for economies of scale”. Same dependency, opposite verdict.

Goals. At Facebook, exploration ran on P50 goals, where you were expected to hit about half of what you set. Hitting everything means you either learned nothing or sandbagged. Missing things in Extract is a different matter, because other teams are depending on you.

Speed. Explore speed is “How long from idea to measured feedback?” and how many experiments you run per week. Expand speed is “How quickly do people and money flow towards emerging bottlenecks?” Extract speed is “How long do profitable projects take?” Three different numbers, and tracking the wrong one hides the problem you have.

Testing. This is the most misquoted part of 3X, usually flattened into “skip tests while exploring”. Beck’s actual position from the talk is narrower. “Should you write tests? It depends. Do you have anything to lose? No? Only write the tests that help you experiment quicker.” That is a cost-of-feedback argument, and it comes from the person who wrote the TDD book. Anne-Marie Charrett, working the same question as a quality coach in November 2022, puts TDD and vertical slicing squarely inside Explore.

What the model does not carry

Worth being blunt, because 3X almost always gets presented without any of this.

There is no evidence behind it. No study, no sample, no control. It is one person’s reading of one very unusual company, plus ten years of conference iteration. That does not make it wrong, and it does mean it cannot settle an argument on its own.

There is no numeric threshold on any transition. Beck’s exit conditions are “one experiment works way better than others”, “cause and effect of growth become predictable”, and “no further return on investment”. The widely repeated “10-100x signal” for product-market fit is not his. It traces to a Substack post by Pandith Jantakahalli in May 2022 and has been circulating under Beck’s name ever since. Every OKR figure attached to 3X in the product-leadership blogs is somebody’s illustration.

And Beck’s two answers on when to leave Expand do not agree with each other. In April 2020 he wrote that “Expand->Extract is usually a business decision”, with a parenthesis worth keeping, “(Professional CEOs have a perverse incentive to transition too soon.)” In Canon 3X, six years later, all three exits are stated as observed conditions with no decision language anywhere. So the neat asymmetry that gets taught alongside 3X, where you detect one transition and call the other, has the author on both sides of it.

One more thing goes missing between the 2019 interview and the 2026 canon. Beck named a fourth failure mode and then dropped it.

“When you get to extract, there’s a big downside and you have to stop only looking at possible improvements and metrics, or however you’re going to measure success. You have to start paying attention to the downsides of your actions in a way that you don’t when you’re little and scrappy you got nothing to lose.”

He was talking about Facebook. Impact culture rewards upside, the upsides keep shrinking, the downsides keep growing, and he would bet the culture cannot be unwound. Canon 3X contains no discussion of incentives, rewards or promotion at all. An organisation can therefore sit in Extract while its reward system still pays out for upside-chasing, and the canonical version of the model has nothing to say about that.

The 2026 turn

All of which matters more this year than last. Beck told Charles Humble at LeadDev in February 2026:

“Programming hasn’t really advanced since Smalltalk-80. The workflows, tools and languages that we use are all small tweaks to a foundation that was laid down in the late 1970s and early 1980s. So the act of programming has lived in extract for 45 years and we’re used to that.”

“Then the genie of generative AI coding assistants escaped from the bottle, and all of those certainties have been thrown out of the window.”

If he is right, the tooling, review depth, estimate discipline and definitions of done that a mature engineering organisation spent fifteen years perfecting were all tuned for a phase the work has left. And the discomfort senior engineers report is exactly what the model predicts when Extract discipline meets Explore work.

Hold one tension. In May 2025 Beck wrote that AI coding tools are “great for exploration, not so much for expansion & extraction”. Nine months later he argued that AI moved the whole discipline into exploration. Both can be true, but only if you keep the levels apart. AI is good at one phase, and AI changed which phase the industry is in. The May 2025 capability claim is also the line most likely to have expired, because it was written against May 2025 models.

Four ways to use it

Ignore it and run one operating model. Cheapest, and consistent across the organisation. The cost is that you keep applying the same review depth, dependency tolerance and goal discipline to a two-week probe and to a customer-facing platform. Rational if almost all your work genuinely sits in one phase.

Vocabulary only. Adopt the three words so that “which game are we playing here” becomes a question anyone can ask in a planning meeting. No process change, no artefacts, costs an hour. The risk is that the label becomes cover for whatever someone wanted to do anyway, most often skipping tests.

Vocabulary plus an operating switch. Label each significant initiative with a phase and let that label move the four switches above. Someone has to own the label and re-check it, and you need a rule for who decides when a team disagrees, which Beck does not supply.

The full portfolio and staffing model. Add Wardley’s pioneers, settlers and town planners, sort people by phase affinity, fund Explore out of Extract. Highest ceiling. It also builds a status ladder between the people who explore and the people who extract, and turns movement between them into a career event rather than a rotation.

Recommendation

Take the vocabulary now, and add the operating switch for AI work only.

The vocabulary costs almost nothing and fixes the specific problem Beck identifies, which is that phases are invisible from outside so nobody notices the mismatch. Getting a team to say out loud “this is an Explore piece” is most of the value on offer.

The operating switch earns its overhead where the phase is genuinely contested, and in 2026 that is the AI work. Four changes are enough. Goals move to P50 and get read as learning. Dependencies get capped. Tests get written where they speed up the next experiment. Speed gets measured as time from idea to measured feedback rather than as throughput.

Skip the sorting exercise. Beck names personnel as a dimension that must change per phase and never fills the row in, so anyone selling you a phase-based staffing model is filling that gap with their own material. The half worth stealing is a permission structure. At Facebook the leading expert on a profitable Extract project could hear about a scaling fire, assign themselves to it, and expect their manager to backfill without a fight. Beck is honest that this costs real managerial complexity, and that “not many organizations are willing to pay the price”.

What would change this. If a phase label starts working as a way to dodge review rather than a way to choose review, drop back to vocabulary only. And if the AI work turns out to be predictable and repeatable, then it is not Explore and the switch was wrong.

The caveat Beck puts on his own advice

Canon 3X closes with the portfolio move, running Extract products that fund a basket of Explore projects and dropping everything when one of them hits Expand. Then he marks his own homework in a parenthesis.

“(Simple to say and apparently nearly impossible to execute.)”

A parenthesis like that is the honest version, and it is why the useful thing here is a question rather than a framework. Which game is this work in? Most process arguments turn out to be two people optimising for different phases with neither of them saying so. The question costs nothing, and it dissolves a category of disagreement that otherwise runs for months.

Four key-value stores in production, at scale, on purpose. Standardising them early would have stopped the exploration that made the standard worth having.

Sources

• Kent Beck, “Facebook Engineering Process”, Software Engineering Daily ep. SEDFB 15, 28 August 2019. Verbatim transcript. Four key-value stores, parking brake, payoff shapes, drift toward Extract, the Extract downside, KPIs in Explore.
• Kent Beck, “The Product Development Triathlon”, Facebook note, 19 July 2016. The debut of 3X.
• Kent Beck, “Canon 3X: Explore/Expand/Extract”, 30 July 2026. Risk, goal, strategy, tactics and exit per phase; the nine dimensions; the kills-ideas rule; the closing parenthesis.
• Kent Beck, “Fast/Slow in 3X: Explore/Expand/Extract”, 22 October 2019. Speed per phase, the drift mechanism.
• Kent Beck, “Expand to Extract and Back”, 5 April 2020. Expand to Extract as a business decision, the CEO incentive parenthesis.
• Kent Beck, “Don’t Accomplish Everything”, 23 February 2026. P50 goals, the phases-look-similar quote, dependencies by phase.
• Kent Beck on Bluesky, 20 November 2024. “The market tells you. Like this. You can’t force it.”
• Kent Beck, “Augmented Coding is Good For Exploration”, 7 May 2025.
• Charles Humble, “Nobody knows what programming will look like in two years”, LeadDev, 18 February 2026. The Smalltalk-80 and forty-five-years quotes.
• Anne-Marie Charrett, “Kent Beck’s 3X and Quality: a quality coach perspective”, 6 November 2022. TDD and vertical slicing inside Explore.
• Pandith Jantakahalli, “#125 Kent Beck’s 3x Model”, 9 May 2022. Origin of the “10-100x” figure.
• Kent Beck, YOW! talk, recorded 2018 and 2019, via Laszlo Sragner’s timestamped notes. The testing line.