From retrospective to prospective

After a system breakdown that impacts your users, reputation, and revenue, engineers write a retrospective summarizing the missteps, mishaps, and necessary changes to reduce the likelihood of recurrence.

It's a great idea and you should do it. Google used to conduct so-called blameless retrospectives, which focus on the system rather than the individual. After all, individuals generally operate within the constraints, rules, and incentives of the system. Change the system, behaviors follow.

I recommend more frequent reflections – not only those triggered by significant failures but also regular, perhaps weekly or daily, reflections. In the spirit of continual improvement – kaizen. The tighter and higher-quality the feedback loop, the faster one's improvement. Importantly, both are within your control.

At the end of each week or day, take a moment to reflect: “What went well today?” Make a note. This approach is also beneficial after significant events, such as a crucial one-on-one conversation or a high-stakes presentation.

§

In addition, try prospective analyses. Based on the day's or week's events, reassess your perspectives, form new opinions, and decide on subsequent actions. Collect these over time, then retrospect: “Were your past guesses or hypotheses correct? What factors contributed to more accurate predictions? Were there dead ends you could have seen if you had asked better questions?” This allows for "second derivative improvements", i.e. enhancing the rate of improvement itself.