In my job, I use a number of collaboration tools. From email and instant messaging to browser-based collaboration platforms, they help me get information, generate information, and share information. My ambition is that the vast majority of questions any of my colleagues may have about the peculiarities of our customer-facing systems. Our documentation systems are open – at least to reading – by default. This way, anyone can look up information on any system.
Recently, this usage of our systems has grown with regards to major incident management. Whenever a major incident is called, a temporary Slack channel for that incident is set up. When these channels are created, several channels (including the support channels) are notified, and anyone can then join the channel and see the discussion. I usually do just that. I find it interesting to see what issues the organisation is dealing with, and being up to date on major incidents is very useful to me in my role as change coordinator.
Also recently, I’ve been noticing a trend. Where the discussions in these channels were initially relatively sparse and terse, they have grown increasingly verbose. I speculate that we are getting used to being open about what we’re seeing, and increasingly happy to speak up about theories that might be worth following up on. Put another way; we are feeling safe in offering speculation, in speaking up about what has been done, and in sharing information knowing that it will be used to solve the issue – not to place blame.
Blame-less post mortems are much ridiculed by parts of the IT industry. My experience is that when we go into a post-incident review with a mind to place blame, we will never learn. And so, we must choose: Do we want to learn, in order to avoid repeating the error some other day, or do we want to find someone to blame? I have no doubt which option I would choose, ten times out of ten.