TL;DR notes from articles I read today.
Three types of risk: making decisions in the face of uncertainty
- Fatal risks can kill a company, so you need to be extra careful to watch for them as your company grows and ages. It is easy to get complacent but there is no recovery from such decisions gone wrong.
- Painful risks have lower but significant repercussions: missing a key goal or losing key people. But you can recover from them.
- Embarrassment risks have no significant impact beyond just what the name states. You just need to acknowledge the mistake, change course and move on.
- Another way to think about risk is Jeff Bezos categorization of decision making into Type 1 (irreversible, so spend time on them) and Type 2 (reversible, as with painful and embarrassing risks, so make the decision quickly and move on).
Full post here, 4 mins read
Four magic numbers for measuring software delivery
- Lead time to validate, design, implement and ship a new valuable thing. Consider two types of lead time: (a) feature lead time: the time to move an item from high-level requirements to feature release and (b) deployment lead time: the time from merging to master to the component being in production.
- Deployment frequency, understood as number of times per developer per day you ship to production. Your deployment frequency may ebb and flow, from 5-10 on a busy day to none the rest of the week. Establish a baseline over 4 weeks: say, 1 production deployment per day on average.
- Change failure percentage, ie, the proportion of red deployments, bugs, alerts, etc. Defining change failure rate as bugs per production deployment over a given period, aim for about 10% or less with medium or high-priority of customer impact.
- Mean time to recovery/resolution. For mean time to resolution, aim for less than a working week.
- Considering feature lead time as a key performance indicator can help you break features up and deliver faster. This might also decrease lead time per deployment.
- Convert generic support tickets into bugs with customer impact implications so they can be tracked better. Make bugs more visible can also make bottlenecks in the resolution process more apparent.
- Count red production deployments and production alerts as a change failure.
Full post here, 9 mins read
Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().
Top comments (0)