Build the scorecard you would use to present a model recommendation to leadership.

Ashgrove Metrics sells an observability dashboard to engineering teams, and it recently added an AI feature that reads an incident's logs and drafts a root-cause summary. Freya Danthorpe is the senior PM who has to decide, every time a new model is worth considering, what leadership actually needs to see before they approve it.

How to answer this, stage by stage

Nobody is scoring whether your slide looks polished. They're scoring whether the same five things get checked no matter who builds it or how rushed the quarter is.

Let's learn

Picture the meeting before anyone had agreed on a single row this scorecard should have.

Before any fixed format, Freya built the whole model-comparison case herself every quarter: pulled sample incidents, timed responses, priced out calls, and built a new slide deck from scratch, about two full days of work each time.

Once she started delegating it to Priya Anand, a newer analyst on her team, a quarter's comparison came back in about four hours of Priya's time, and Freya's own review dropped fast: three hours the first quarter, forty five minutes the second, and by the third quarter she forwarded the deck to leadership without opening it at all.

The five letters, held up as one page. Anchor is the row that has to survive contact with a real quarter.

Here's the turn: the real problem was never that Priya's work got worse. It was that "compare the models" and "build the leadership deck" had been merged into one loose task with no fixed shape, so each quarter's deck quietly measured different things, and nobody was checking whether they still matched.

At its worst, a model gets recommended and approved with no one checking whether it can even meet the feature's own speed requirement, and the gap surfaces only after the feature is already live.

What I would leave alone: I wouldn't force every internal, low-stakes experiment through the same five-row process, since a quick internal test with no leadership approval attached doesn't need the same weight as a production recommendation.

The lesson: a scorecard is not a nicer slide deck. It is the one artifact that lets someone else do this job as well as you did, without you checking their work line by line.

Now here is the same thing as a story

The short version above is what you'd say walking someone through the artifact. Read this one for what it felt like the week a new hire's question exposed how thin the process had gotten.

Freya could look at a rough model comparison and tell within a minute which row was doing real work and which was padding.

When she first handed the quarterly comparison to Priya, it felt like a clean win: Priya was sharp, thorough, and the first deck came back better organized than anything Freya had built solo. Freya read every slide carefully, checked the numbers herself, and signed off with confidence.

Five steps, and the fifth one is where the whole process quietly resets itself every quarter.

By the second quarter, Freya was busier, and she skimmed Priya's deck in forty five minutes instead of building her own confidence in it from scratch. The numbers looked reasonable. She signed off.

By the third quarter, a deadline was tight. Freya forwarded Priya's deck straight to leadership, unread, trusting that the same good instincts from quarter one were still guiding it.

The actual design decision, close enough to argue with: five fixed rows, never a fresh invention.

A newly hired analyst, reading through the last four quarters' decks to get up to speed, asked Freya a plain question: "why does this quarter's deck skip latency completely? Last quarter had a whole slide on it." Freya didn't have a good answer, because she hadn't read the deck closely enough to know it was missing.

Whether the card has a latency row at all decides how badly a wrong pick surfaces, and when.

The model that quarter's deck had recommended, chosen without a latency row, answered incident summaries in 3.4 seconds against an 800 millisecond target for the live chat feature it was meant to power. Nobody found out until the feature had already shipped and engineers started complaining that the assistant felt sluggish.

Freya reclaimed the whole process herself after that, back to two full days a quarter, plus time spent explaining to Priya what had gone wrong, which came out to more total work than either extreme on its own.

The real question was never whether Priya was careful enough. It was whether the process gave her, or anyone, a fixed shape to fill in, so a missing row would be obvious the moment it was empty instead of invisible inside a slide that looked complete.

Five named parts. A card missing any one of them is visibly incomplete, not just thin.

When the delegation was first set up, someone said, "Priya's sharp, she'll figure out what to include," and it sounded reasonable, since Priya really was sharp. Nobody had written down what "include" actually meant.

Rerun the same quarter with the Model Fit Card in place: Priya fills in all five rows in about four hours, the latency row flags the 3.4 second model before it ever reaches a slide, and Freya reviews the finished card in twenty minutes, checking that the rows are real, not rebuilding the case herself.

What I'd tell myself, hearing that new hire's plain question land: a scorecard with no fixed rows isn't a lighter process. It's the same process, minus the one thing that made it trustworthy enough to hand to someone else.

SPARK, the artifact that makes delegation survive a busy quarterNot a script for never trusting a junior analyst again. SPARK is what tells you exactly which five things they need in front of them.

The recap, one line per letter: situation is the ad hoc Slack thread and fresh slide deck built each quarter, payoff is trusting any analyst's completed card the same way, anchor is the five fixed rows in a fixed order, risk is the owner and re-review date that catch a wrong call, and keep out is the single weighted score and the low-stakes exemption Ashgrove deliberately isn't building.

And if you want to be sure it really works, try it somewhere elseSame five letters, a veterinary imaging tool instead of an observability dashboard. The rows barely change.

Odalys Ferraro runs product at Ashmere Veterinary Group, deciding which model reads x-ray images to flag likely fractures for a vet to confirm. Mapped onto SPARK: situation is a vet manually reviewing every x-ray with no assistance, about six minutes each. Payoff is trusting a flagged image enough to review it first, without re-checking every calm image the model already cleared. Anchor: the same five rows, task fit against a set of real, vet-confirmed x-rays, cost per scan at the clinic's real monthly volume, latency against the time a vet is willing to wait mid-exam, the failure mode of a missed fracture and its guardrail, a named clinical owner and a re-review date tied to each new model version. Risk: a missed fracture is dangerous, so the anchor needs a conservative default, an uncertain image still gets flagged for review rather than cleared silently. Keep out: no single combined risk score hiding which specific row is driving a recommendation.

Different industry, same rhythm: the card gets reused, not reinvented, every time a new version comes up.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "five fixed rows, task fit, cost, latency, failure mode, owner, every time," and stop.
Cost: no budget for a dedicated analyst to build the card every quarter. Say so honestly, and cut the card down to three rows before cutting the discipline of filling it in consistently.
The model got better, for real: if a new model claims a lower cost and the same quality, that's still worth a fresh card, since a cheaper model with a worse failure mode is not automatically the better recommendation.

Where people run it wrong.
They build a beautiful one-off deck for the first recommendation and never standardize it, so no two quarters can be compared.
They collapse everything into a single weighted score, hiding the actual judgment call from the people approving it.
They let review depth quietly shrink each quarter without ever noticing, since nothing marks the moment it happened.

How to use it live. The moment an interviewer asks you to build a scorecard, ask yourself: what five things would I need to see, in writing, before I'd stake my own name on this recommendation? Name those five, in a fixed order, and the rest of the artifact follows on its own.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0