In this type of meeting the analysis always ends before it gets to the point of questioning the guy who was calling the shots that went in the foot. One of the

In this type of meeting the analysis always ends before it gets to the point of questioning the guy who was calling the shots that went in the foot. One of the things I really enjoy about 5 Whys done well is that it can be done asynchronously. You don't need to gather everyone into a room for a long drawn out retrospective, preach lofty best-practices that everyone knows, and come out of it with nothing actionable on a reasonable timeframe. Instead, someone who was close to the incident can draw up a quick email with the 5 whys, a tally of person-hours spent on the incident, and send it out quickly. Oftentimes the answers from the 5Ws /are/ obvious to engineers -- we need more monitoring! that wasn't tested well enough! we didn't have time to prepare for this problem! -- their power comes in formalizing cleanup of technical debt, and prioritizing it appropriately. Production problems don't get swept under a band-aid, new features get queued until the proportional investments are made. And, yes, if the 5 Whys has management buy-in, it does address why the problematic cron job was rushed into production in the first place.