Don't Accomplish Everything: Why Hitting Half Your Goals Might Mean You're Winning

Don't Accomplish Everything

TLDR: Kent Beck recounts his first performance review at Facebook where accomplishing only 3 out of 6 goals earned him an "exceeds expectations." The lesson: in exploratory environments, completing all your goals signals you either learned nothing or sandbagged — and both are worse than embracing surprise.

Summary:

Here is a story that should make every engineering manager uncomfortable. Kent Beck walks into his first performance review at Facebook, sweating because he only hit half his semester goals. His manager tells him he is right on track. If he had accomplished all six goals, that would have been considered underperformance. Let that sink in for a moment.

The framework behind this thinking is something Beck calls 3X — Explore, Expand, Extract. These are three fundamentally different modes of software product development that just happen to look similar on the surface because in all three you are shipping increments of value. But the goals and tradeoffs are completely different. Explore is searching for new super-linear value. Expand is scaling what you found. Extract is harvesting that value efficiently. The real confusion in our industry is that most people manage as if they are always in Extract mode — dependencies, roadmaps, KPIs, OKRs — because that is where most of us learned to manage. And for Extract, that is exactly right.

But here is what Beck is really getting at, and what I think a lot of teams are not confronting honestly: the entire industry has been forcibly relocated from "Extractistan" to "Exploristan." AI is rewriting the rules. The tools are changing. The economics are shifting. And yet most organizations are still running Extract playbooks — demanding 100% goal completion, enforcing rigid roadmaps, and penalizing the kind of opportunistic learning that early Facebook rewarded. If your team hits every single OKR this quarter, you should be asking yourself whether those goals were ambitious enough, or whether people just stopped exploring because the incentive structure punished it.

What Beck does not spend enough time on — and this is the hard part — is the transition. He mentions Explore-to-Expand and Expand-to-Extract transitions but glosses over how brutally difficult those shifts are for real teams. The "P50 goals" idea is elegant in theory: set goals you expect to hit about half the time, which incentivizes both discovery and effort. But in practice, most organizations have zero tolerance for this. Comp committees, board decks, investor updates — they all want predictability. The missing piece is how you build organizational trust to actually operate this way. That is the conversation architects and engineering leaders need to be having.

There is also a subtle point about dependencies that deserves more attention. Beck argues explorations should have as few dependencies as possible because they are small and extremely sensitive to delay, while extractions can and should have dependencies for economies of scale. This is a genuinely useful architectural heuristic. If you are structuring your teams and systems for exploration, coupling is your enemy. If you are extracting, coupling is your friend — within reason. Most organizations have both happening simultaneously and treat them identically, which is a recipe for frustration on all sides.

Key takeaways:

• Accomplishing 100% of goals in an exploratory phase signals either no learning or sandbagged targets — both are failures
• The 3X framework (Explore, Expand, Extract) describes three fundamentally different modes that look similar on the surface but require completely different management approaches
• "P50 goals" — goals you expect to hit roughly half the time — incentivize both discovery and genuine effort
• Explorations need minimal dependencies (sensitive to delay); extractions benefit from dependencies (economies of scale)
• Most of the software industry is being pushed from Extract back into Explore mode, but management practices have not caught up

Tradeoffs:

• P50 goals create space for learning but require deep organizational trust that most companies have not built — and Beck does not address how to build it
• Reducing dependencies accelerates exploration but sacrifices the coordination benefits that mature products need, making the transition between modes the real engineering challenge
• Rewarding partial goal completion can genuinely incentivize discovery, or it can become a cover for lack of accountability — the difference depends entirely on culture and leadership judgment

Don't Accomplish Everything