engineering excellence

Building software that it is useful, correct, consistent, and fast—in such a way that minimizes the waste of time (i.e. human potential).

• Useful because useless software wastes engineers’ time (and others’), so engineers must understand the use for what they build.
• Correct because software that doesn’t work as it should wastes its users’ time, and engineers’ time fixing it.
• Consistent for a similar reason: when similar things don’t look or work the same, it leads to confusion that wastes the time of those using it.
• And fast because slow software wastes the time of those using and building it alike.

What it looks like

• challenges are opportunities. Excellence is a verb. It’s not about being perfect, but constantly improving, e.g. kaizen
• addressing technical debt at the right time
• adhering to good API design
• keeping it going through durable excellence

How to measure it

• Cycle time: how quickly can value be delivered?
  • Deploy frequency contributes to this and can be measured separately
• Onboarding and dev tooling setup: how quickly can new engineers start contributing?
• Error rates (especially user-facing, but not solely): how often does the software behave in surprising, time-wasting ways?
• Security audits: correct software is secure software, so how rare are audit violations?
• Morale! Excellent engineers are happy engineers.
• Uptime, and mean time-to-recover from unplanned outages: how well are we meeting our (reasonable, not 100%) goal, and how quickly are we learning from surprises to get there
• Defect rate vs. time-to-fix bugs
• “Near miss” rate: how often do we find out about a problem before it happens?
• Synthetic measures of things that are hard or too low-level to measure directly

Also see systems-thinker Jessica Kerr’s thoughts on measuring engineering teams.

Engineering Values

When I think of “strong” as a team I think of vision and discipline: a consistent, coherent vision/opinion/values for how we’d like our software to be built, and the discipline to pursue that vision even when it’s inconvenient. For example, a team that says “we don’t have dead code” and prioritizes removing obsolete code promptly. Or a team that says “We value one way to do things” and chooses to update/expand their own abstractions rather than introduce competing ones. Of course, values are aspirational and there will be edge cases where they can’t be easily applied, but having an opinion and sticking to it most of the time is what I have in mind.

Further Reading

• How we measure Backstage success at Spotify by Spotify’s “backstage” team focused on engineering effectiveness, with a particular focus on how they measure it.
• Will Larson on “Measuring an Engineering Organization”
• Jessica Kerr on Five Measurements You Should Make and Then Ignore (Plus One to Watch Intently)