Dig deep enough on the corporate website for many software-based companies and you’ll find seemingly innocuous little documents called “post-mortems,” in which some technically-oriented employee explains in detail the nature of a recent downtime or failure. These explanations serve various purposes, depending on who’s reading — some are simply interested in the product, and want to be aware of its status; others want to know why something they depend on wasn’t working, and whether it will continue working reliably in the future. A third, and most critical group or readers, consists of other technical people who take from the post-mortem a sliver of knowledge to bring to their own operations.
A post-mortem could elaborate on a method of thinking about software development, or a very nuanced flaw in a particular piece of software — a “bug,” as the common phrase goes. They’re generally made in the interest of disclosing information rather than burying it away for fear of bad press, and they’re generally beneficial to the community. It spurs interest at the very least, and informs others in the best of situations.
For example, Dropbox — the fairly popular service for synchronizing files across computers and sharing them with others — just underwent a 48-hour downtime/slowdown, and then released a post-mortem explaining what went wrong, how they fixed it and even teased the future release of a tool that would help others from getting into a similar bind.
Manufacturing has no real equivalent, and I wonder if that isn’t a problem, or, at least, an opportunity. The industry is tight-lipped about internal operations, and most plant managers would be more apt to thinking that a major production disruption would be something to silenced as much as possible, told only to a few key business partners and perhaps the vendor of the malfunctioning equipment. They certainly wouldn’t get right on writing up a blog post about it. But what if they did? What if they thought others could find value in what went wrong?