I like this idea and this framing of it. A way I've put it in the past is that a postmortem is only really useful if you thought that you were already doing everything you could to prevent an issue of this type. In 95% of incidents I've experienced in my career, this is just not the case. There was a known lack of testing, the deadlines were too tight and we decided to push through and take shortcuts to launch anyway, there was known tech debt where everyone on the team was scared of this code but it was too much work to address it so it kept getting put off, etc.<p>Often every person on the team could rattle off 5 major problems off the top of their head. That's it, that's your postmortem right there, let's go and prioritize solving these underlying problems. But engineering orgs get obsessed with establishing a sacred heavy-handed process around postmortems. There must be a reviewer, and a chairperson, and a standardized form that takes an hour or two to fill out, and several rounds of revisions. This gives you a nice shiny metric to point to where you can say that 100% of incidents were followed up with a postmortem. If any big picture questions come up during the postmortem, well that's not the kind of thing you can just make a jira ticket for, i.e. "don't make the deadline so short next time". So we'll move right past that one and then make one or two actionable jira tickets like adding another view to the metrics dashboard which overfits on this particular issue while doing nothing to address the underlying problems, and then get back to work taking shortcuts and building up more tech debt on a whole new set of features.<p>A premortem may end up with the same sort of perverse incentives, but it's an interesting thing to try. If it's something the org commits to actually putting aside time for ahead of every deadline, I could even see it potentially helping a little bit to address some of the underlying problems.
Rather than ask "what could go wrong?" the standard technique of premortems[1] is to imagine an specific thing went wrong and then brainstorm root causes. Our brains are much more creative when working backwards this way.<p>I've done premortems for the launches of new features where we imagine some symptom ("user apparently saves data, but it doesn't commit") and then have the team try to hypothesize causes for it. You can generate the symptoms either by thinking of common failure modes or having people on the team privately come up with their own cause-symptom pairs.<p>Another important thing to do is use the exercise to discuss what tools/dashboards/techniques you would use to diagnose and repair these issues. his can help you find gaps in your monitoring, logging, and diagnostic capabilities.<p>[1] <a href="https://hbr.org/2007/09/performing-a-project-premortem" rel="nofollow">https://hbr.org/2007/09/performing-a-project-premortem</a>
<i>Before deploying new code, ask yourself and at least one other person “If this is going to cause a major issue, what would it be?”</i><p>I love a premortem, but this isn't quite how I do them. I prefer to start long before a deploy, before a feature hits sprint planning. By asking my team "What could go wrong if we start this?" we often uncover some of the unknowns that can derail our engineering effort. It's particularly important to get the quality assurance team involved that early too, by getting them to think about how they'll test the feature - QA should be about implementing processes to assure quality after all.
Page seems to not load CSS for me. Anyone else seeing that happening?<p>Edit: Here’s a snapshot of the page with seemingly no CSS loaded, same as I was seeing <a href="https://archive.ph/qe2IW" rel="nofollow">https://archive.ph/qe2IW</a>