12-QUESTION SCORECARD · FREE · NO SIGN-UP

Stabilise, rewrite or pause? Check whether you have the evidence to decide.

This measures one thing: whether you currently know enough to decide. It doesn’t pick the answer for you. Answer alone, then send the link to your most senior engineer to answer blind. Where you disagree is more useful than either score.

Your answers stay in your browser. Nothing is sent unless you choose to share or email them.

A colleague has already answered. Answer on your own first: their answers stay hidden until you’ve done all twelve, then you’ll see where you disagree.

Answer Yes, No or Don’t know, about the system as it is today — not as it will be after the work you’re planning.

Part 1 — Do you know what’s actually wrong?

1. Can you name three specific failures that made you consider this, with dates?

Three incidents, when each happened, what each cost. Fewer than three, or three without dates, is a No.

2. Do you know which part of the system those failures came from?

Naming the service, the module or the query is a Yes. “The backend” or “the legacy code” is a No.

3. Have you measured the thing you’re complaining about?

Latency, error rate, build time, time to onboard an engineer — a number with a date attached.

4. Do you know whether it’s getting worse, better, or holding steady?

One measurement is a snapshot; two taken months apart show a direction. They justify different decisions.
Part 2 — Do you know what it would take?

5. Has anyone on the team shipped a rewrite of comparable scope before?

Not a rewrite in general: this scope, this domain, with the business running on top of it throughout.

6. In the last six months, have you hit undocumented behaviour that changed a decision?

One named instance is a Yes. The question is whether you’ve started finding it or haven’t looked yet.

7. Can you name what you’d stop doing to fund this?

Engineering time is fixed, so something gets displaced whether or not it’s been named. “We’ll do both” counts as a No.

8. Is there a point where you’d abandon the work and keep the old system?

Name the date or the signal. Without one, this is a one-way door.
Part 3 — Do you know what happens if you’re wrong?

9. If this takes twice as long as planned, what breaks first — and where is that written?

A constraint you can point to in a document is a Yes; one you can only describe in this meeting is a No.

10. Have you identified a way to ship this incrementally — or written down why you can’t?

Either one counts as Yes; not having looked is the No.

11. Do you know which customers are exposed during the transition?

“All of them” counts as a Yes only if you’ve written down why it can’t be segmented.

12. Does anyone on the commercial side know this is being considered?

Sales and support inherit the transition. Still an engineering-only conversation counts as a No.

0 of 12 answered

—Yes
—Gaps (No + Don’t know) — the number to act on

Waiting for answers

The reading appears once all twelve are in.

The disagreement test

Have your most senior engineer answer separately, without seeing yours. Where you disagree is more useful than either score.

Available once you’ve answered all twelve.

What this can’t tell you: what the code actually looks like, whether the test coverage is real or decorative, whether the schema can migrate incrementally. Twelve out of twelve with a wrong read on the schema is still a wrong decision — just a well-argued one.

Scope the decision (20 min) Email me your answers

I reply within 2 business days.

Reading it

Read the lowest part first, and treat the bands as rough groupings rather than a calibrated scale — they come from how these questions cluster, not from a dataset. A single question either way is noise. A part where you scored 1 or 0 is not. What the count is good for is comparing your sheet against your senior engineer’s, not scoring the system against other companies.

  • Few gaps: the evidence is there, either to decide or to commission a second opinion before committing capital.
  • Gaps spread evenly across parts: part of the picture, and usually the comfortable part. The lowest-scoring section is the argument that gets lost later.
  • Most gaps in one part: that part is where the decision is exposed, regardless of the total.
  • Gaps almost everywhere: worth measuring before paying anyone, including me.

If you want the second half

The scorecard measures whether the evidence exists. The 3-Day Technical Risk Review looks at what the evidence points to: one primary codebase, $3,500 fixed, excl. VAT. You get a decision memo, a prioritised risk register with evidence and a 30-day stabilisation plan.

Scope the decision Prefer the PDF?