Technical quality: is the codebase getting cheaper or more expensive to change?

Technical quality: is the codebase getting cheaper or more expensive to change?

Chapter 6. Quality is invisible until it isn't. These surface the rot before it becomes a system everyone's afraid to touch.

7. Defect escape rate. Of the bugs that exist, how many were caught before customers hit them versus after? A high escape rate means your customers are doing your testing for you, which is the most expensive way to find a defect and the worst for trust. Drive this down and reliability and reputation move with it.

8. Rework / tech-debt ratio. What share of effort goes to redoing or repairing past work rather than building new things? Some rework is normal. A ratio that climbs quarter over quarter is the sound of a codebase rotting, the early warning before change gets slow and brittle. This is the number that explains why a team that shipped fast last year is crawling this year, and it's the one founders almost never get shown.

Roadmap & business alignment: did the work matter?

Chapter 7. The two most commercial numbers on the page, and the ones closest to your job.

9. Percent of delivered work tied to a business outcome. For each shipped task, can someone name the goal it serves: a revenue lever, a retention risk, a cost saved, a customer commitment? Work that can't be traced to an outcome is work you paid for on faith. Pendo found that 80% of features are rarely or never used (Pendo 2019). This is the number that keeps your team off that list.

10. Roadmap commitment accuracy. When you tell the board, or a customer, that something lands by a date, how often does it? Predictability (number two) is about the cycle in front of you; this is about the promises you make further out. It's the difference between a roadmap you can stake your reputation on and a wish list that quietly slips.

The dashboard

Here's the whole thing on one page. Read it the way you'd read a P&L: not every number every day, but the shape, and which line is moving the wrong way.

Four of these (1, 5, 6, and lead time's close cousin) are DORA metrics, which means you're not grading on a curve you invented. The rest are the operational reality a founder needs and rarely gets handed.

You don't need to act on all ten constantly. Glance at the page weekly, watch for a line drifting red, and ask about that one. That's the whole discipline. The scorecard turns "I think engineering is going okay" into something you can defend to a board.

There's a catch, and it's the bridge to the rest of this part of the book. A founder can read all ten of these. That was always the easy half. The hard half is having someone whose job is to move them, week after week, and to answer for the line that's gone the wrong way.

You can read the scorecard. The real question is who owns it: who do you build, hire, or subscribe to make these ten numbers their problem?