Why Some Things Should Never Fully Ship
Dancing landscapes don't call for giving up — they call for an ongoing explore/exploit discipline most RevOps orgs never build, borrowed from metallurgy.
A few posts back, I said rugged landscapes are worth solving hard because the solution holds, and dancing landscapes aren’t, because whatever you optimize will likely be stale before you finish. That’s true, but it’s not the whole answer, because “don’t bother” isn’t actually the right response to a dancing landscape either. The right response is a specific, different kind of ongoing effort — and most RevOps orgs never build it, because it doesn’t look like finishing anything.
Page frames this as the explore/exploit trade-off, and the model he uses to explain it comes from an unlikely place: metallurgy.
Borrowing from how you harden metal
Annealing is how you strengthen glass or metal — heat it until the particles move freely, then cool it gradually so they lock into an aligned, stable structure instead of freezing into a disorganized mess. Cool it too fast, and you get something brittle and full of internal stress. Never cool it at all, and it never hardens into anything.
Translate “temperature” into a search strategy and you get simulated annealing: think of temperature as your probability of accepting a move that looks worse right now. High temperature means you’re willing to wander into configurations that seem like a step backward, because that’s the only way to discover there’s a taller peak somewhere you haven’t looked. As temperature drops, you get pickier, converging toward only accepting real improvements. At temperature zero, you’re pure exploitation — climbing straight uphill from wherever you landed.
Contrast that with a greedy algorithm, which only ever takes a step if it’s an immediate improvement. Greedy is fine on a Mount Fuji landscape — there’s only one peak, you can’t go wrong. On a rugged landscape it’s a trap, exactly the one I described with comp plan design a few posts back: stop exploring the moment the first tweak looks like progress, and you’re stuck on a mediocre structure, confident it’s good because you never looked further.
Rugged: cool the temperature all the way down
On a rugged landscape, the annealing strategy is the whole answer, and it has a clean endpoint. Explore hard early — genuinely test comp structures that look worse on paper, run alternate quota-setting logic you don’t expect to win, see what the search actually turns up. Then cool it down. Narrow in. Lock in the strongest structure you found and run it.
This is the version of RevOps work that has a real finish line. You explore, you converge, you exploit what you found, and unless something structural changes underneath it, that solution holds. The temperature genuinely goes to zero, and that’s correct.
Dancing: the temperature never fully cools
Pricing and packaging don’t work this way, and neither does lead scoring or account health scoring, for the same reason: something else in the system is adapting in response to whatever you build. Cool the temperature to zero on a dancing landscape, and you’re exploiting a peak that’s already started moving away from where you found it.
Page’s example for this is leafcutter ants — colonies that farm fungus, which attracts invasive bacteria, which the ants fight off with an antibiotic-producing bacteria they cultivate on their own bodies. The relationship never resolves into a fixed state. It’s permanent, active maintenance against a threat that’s also adapting. That’s what a dancing landscape actually demands: not a project with an end date, but a standing practice.
What that standing practice actually looks like
I outlined this once for a client mid-conversation and it’s held up well enough to repeat here in full:
Never let the temperature fully cool. Reserve a fixed share of pricing, packaging, or scoring-model changes as ongoing tests, not one-time rollouts. A couple of live experiments running permanently, not as a project that wraps.
Shrink the blast radius instead of shrinking the exploring. You can’t stop testing, so make each test cheap to run and cheap to reverse — try a new scoring weight on one segment before it goes global, the way a careful hiker takes smaller, more frequent steps instead of one big leap.
Put the retraining cadence on the calendar, not on someone’s judgment. A model with the adaptation dial too low goes stale quietly, the same failure mode from a couple posts back. Fix it with a fixed schedule — quarterly model refresh, scheduled comp-plan reviews — treated as a recurring line item, the same category as month-end close, not a project someone remembers to revisit eventually.
Treat a fully “solved” model as a warning, not a win. If behavior around a metric has stopped changing quarter over quarter, that’s rarely stability. It’s usually the Goodhart’s Law failure from a couple posts back finishing its work — everyone’s fully optimized to the target, and the target has quietly decoupled from the outcome it was supposed to represent. Rising performance on the metric with flat real results is the tell. When you see it, that’s the signal to change the metric itself, not just retune the weights.
Instrument for drift, not just performance. Since the peak is what’s moving, track how fast what’s winning is changing — which packaging tier is closing best this quarter versus last — not only whether the current config looks fine today. Drift shows up before the top-line numbers do, if you’re watching for it.
The org-design consequence
The practical implication is about staffing, more than process. A dancing-landscape motion needs an owner whose actual job description includes “keep testing this indefinitely” — not a project team that ships a version and moves to the next initiative. Staff pricing, packaging, or scoring like a rugged-landscape project — build it, ship it, done — and it will go stale exactly the way an untouched lead-scoring model does, no matter how good it was on day one.
Rugged problems deserve a finish line. Dancing ones deserve a person whose job never quite ends.
This is Part 5 of a series working through Scott Page’s Understanding Complexity (The Great Courses, 2009) applied to RevOps at scaling companies. Next up: emergence and networks — how order shows up bottom-up with nobody designing it that way, and why the most connected system you own is also the most fragile one.