Root cause analysis is a great thinking tool for uncovering failures in your processes that lead to team failures. When practiced, you repeatedly ask “Why?”, focusing on the decisions that lead to a negative outcome without blaming the individuals involved. My team uses root cause analysis whenever a major customer impacting event occurs to determine how we can improve our process. A lot of great ideas that are now central to our team have come out of these sessions, including the concept of ‘blocking’ tests in our build pipeline.
Root cause analysis ensures you avoid learning the wrong lessons from failure. However, it’s just as important to not learn the wrong lessons from success! Just as we don’t want to treat only the the surface problems when a failure occurs, we want to make sure that we don’t attribute our successes only to the most obvious factors. In the wake of a team victory it’s important to be just as demanding in your analysis so that the right lessons and processes get carried forward.
When digging into success, it’s important to focus on extrinstic factors (processes and facts about the environment) rather than intrinstic factors (things about ourselves that make us special). In popular culture a major ‘hook’ for our heroes is who are they: good people, born as a child of the prophecy, forced into circumstances that test them and which they ultimately triumph over (e.g. Luke Skywalker, most religious figures, most video game protagonists). The concept of the Hero’s Journey is built so much into the stories that we tell that it’s dangerously tempting to project it onto the stories that we tell about ourselves. While this creates a compelling personal narrative, attributing success to intrinstic forces is a dead-end towards generalizing success in the future.
In analyzing success, you can also find contributions that may have otherwise missed in the focus on the here and now. My team recently just turned on SSL for all our MySQL connections, a crucial step required for completing a major roadmap item. The work to enable and validate SSL was nontrivial, involving multiple weeks of testing and attempting a few different strategies. However, this work wouldn’t have been possible without work done months earlier to document our setup, building team competancy around our MySQL configurations, and automating this infrastructure with Chef. By breaking apart an overall team success, you can identify and recognize individual contributions that led up to it.
Once you’ve determined the root causes of your success, you can carry these things forward. One of the first takeaways I’ve gotten from reading management books is that people don’t change: you have to put them into situations that utilize their strengths as opposed to trying to fundamentally change who they are. (Management books are interesting and will eventually be a blog post themselves.) These processes and extrinsic factors that have enabled the team are what you want to learn from success.