When should you skip the spike and just build?

Kestrel Waste Systems runs residential collection routes for about forty towns. BinSense is its feature that predicts which bins will overflow before the truck arrives, so routes can adjust the same morning. Priya Wexler is the AI PM who has to decide, every quarter, which features actually need a full spike before they ship.

How to answer this, stage by stage

Nobody is scoring whether you know that spikes are good practice. They're scoring whether you can say, out loud, exactly when one is a waste of six weeks.

Let's learn

Here is what happens when a process built for one hard decision gets applied to every decision, hard or not.

Before BinSense, a driver reported a bin as full over the radio, and a dispatcher manually slotted an extra stop into the day's route, about ten minutes of dispatcher time each time it happened, a few times a week. With BinSense's core model, fill-level predictions come back automatically, and the harder question becomes what the system is allowed to do with them on its own.

The five letters, held up as one page. Reversibility is the step this question is really testing.

Here's the turn: the spike process at Kestrel was built after one bad launch that shipped with no validation at all. The fix that followed wasn't a rule about which decisions needed proof first. It was a blanket six-week spike for every feature touching a model, regardless of how easy that feature would be to undo if it went wrong.

At its worst, a reversible, low-stakes tweak sits in a six-week queue behind decisions that actually deserve that scrutiny, engineers get tired of waiting, and they start quietly building their own before-and-after checks outside the process entirely, with nobody reviewing those checks at all.

What I would leave alone: I wouldn't relax the full spike for the fleet-wide auto-reroute feature itself, since a bad version of that one strands real trucks on real streets with no fast way back.

The lesson: a spike is a tool for a specific kind of decision, the hard-to-undo, wide-blast-radius kind. Applied to every decision equally, it stops being caution and starts being a tax on the easy ones.

Now here is the same thing as a story

The short version above is what you'd say defending a lighter process in a planning review. Read this one for how the rule quietly hardened over four quarters with nobody deciding it on purpose.

Every dispatch shift at Kestrel starts the same way: a printed route sheet, a radio channel, and a coffee that's always gone cold by the second call.

The second step is where the same five weeks ran for every feature, no matter how easy it would be to undo.

Two years ago, a route-scoring feature shipped with no spike at all, misjudged traffic patterns badly for a week, and cost the depot real overtime before anyone rolled it back. After that, the rule became: every feature touching a model gets the full process, no exceptions.

Nobody decided, on any single day, to spike everything equally. It just never stopped being the default after the one time it was needed most.

By the third quarter, a genuinely small, cheap tweak, flagging any bin reported full by a driver three times running for a manual reroute, went into the same six-week queue as the fleet-wide auto-reroute model. It came out the other side unchanged, because there had never really been much to learn from spiking it in the first place.

Two doors. One swings back easily. One is bolted shut the moment the trucks are already moving.

By the fourth quarter, a senior engineer named Tobin Marsh had quietly built his own before-and-after comparison script that he ran on every small model tweak before it ever entered the formal process, just so he could tell, in an afternoon, whether six weeks of waiting was even worth proposing. Nobody reviewed his script. Nobody knew it existed except the engineers using it.

The two trivial features sat in the same corner. The one that actually needed the full spike sat alone, far from both of them.

The real question was never whether BinSense's model deserved scrutiny. It was whether every single decision touching that model deserved the same six weeks of it.

Four questions that were never written down anywhere the team could point to.

When the blanket rule was first adopted, someone said, "let's just require the full process for anything touching the model, so we never get burned like that again," and it sounded reasonable, since the one bad launch was still fresh in everyone's memory.

Rerun the same year with a written reversibility rule in place: the bin-flagging tweak and the threshold adjustment both ship behind a three-day canary instead of a six-week spike. The fleet-wide auto-reroute feature still gets the full process, since a bad version of it really does strand trucks with no fast way back. Nineteen weeks return to the roadmap, and Tobin's private script becomes an official, reviewed part of the canary step instead of a quiet workaround.

What I'd tell myself, hearing that an engineer had built his own validation process on the side: the rule was never wrong to exist. It was wrong to apply to everything the same way, once "never again" hardened into "always, regardless."

ORDER, the rule that finally noticed the differenceNot a script for skipping validation whenever it's inconvenient. ORDER is what tells you exactly which decisions actually earn the six weeks.

The recap, one line per letter: outcome is routes staying efficient without a stranded truck, reversibility is a bin flag reversing in minutes against a fleet reroute that doesn't, dependency is the core model needing validation before the reroute feature can, evidence is a three-day canary proving what a six-week spike eventually confirmed anyway, and rank is spiking the hard-to-undo feature first and canarying the rest.

And if you want to be sure it really works, try it somewhere elseSame five letters, an HVAC field-service company instead of a waste fleet. Different flip family entirely, the same missing rule.

Doreen Kessling runs product at Cinder & Vale HVAC Services, where one feature looks up a diagnostic code from a unit's error display, and a newer one predicts which units are likely to fail within the next two weeks so a technician gets dispatched early. Mapped onto ORDER: outcome is fewer emergency no-heat calls without wasting technician dispatches. Reversibility says the diagnostic lookup is trivially reversible, wrong once, corrected next time, no truck involved. The predictive-failure alert is not: once a truck rolls on a false alarm, that technician's whole morning is gone. Dependency says the lookup needs nothing else validated first. Evidence favors a small canary for the lookup and a real spike for the predictive alert. But the flip here is an abandonment one, not a workaround: after a few early false alarms wasted real truck rolls, technicians didn't build a private process, they just quietly stopped opening the predictive alert feed at all, with no complaint filed anywhere.

A different flip entirely: not a private workaround built in the shadows, but a feed that quietly stopped getting opened at all.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "skip the spike when it's cheap to reverse and small in blast radius, spike it when it isn't, that's the whole rule," and stop.
Cost: no time to build a formal reversibility rubric before the next feature ships. Say so honestly, and ask the one question, "how fast could we undo a wrong call here," before defaulting to either extreme.
The feature turns out to be lower stakes than assumed, for real: if a "risky-sounding" feature actually has a fast, cheap rollback built in, that's a legitimate reason to skip the full spike, not a shortcut being taken.

Where people run it wrong.
They treat "touches a model" as the trigger for a full spike, instead of reversibility and blast radius.
They apply one blanket process to every decision after getting burned once, instead of writing down what actually needs the extra scrutiny.
They let engineers build private, unreviewed shortcuts because the official process has stopped fitting most of the actual decisions.

How to use it live. The moment an interviewer asks when to skip a spike, ask yourself: how fast and how cheaply could we undo this if it's wrong, and how many people or routes would feel it in the meantime? Answer those two, and the rest of the call makes itself.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0