Beyond Blame

"Beyond Blame - Learning From Failure and Success" by Dave Zwieback

Review by: Nick Holder – Platform Development Manager

This work appears to be taking the same approach as The Phoenix Project in creating a fictional narrative to illustrate a point, in this case, the focus is on how to learn from experiences to improve for the future.

Again the lead character is named Bill (as in the previous book – I don’t think there is meant to be a connection) and he is working at an organisation with a strong blame culture. The book starts with the aftermath of a network outage and in the name of “accountability” one of Bill’s staff takes the fall. 

With the help of some friends, Bill looks into whether there is a better way to handle these things.

The themes are again familiar to a DevOps audience but this book is very much focussed on learning ways to make sure accountability is not synonymous with blame. It encourages organisations to learn from their experiences by not engendering fear of blame in the employees, leading to better sharing and understanding of WHY things happened.

Again it has the key points summarised at the end for ease of reference but I did not feel as engaged in this book. The cast are not as well developed, maybe because the book is so short and there is no time to establish the characters.

The author has probably self-mockingly, said it is deliberately a quick read as he has trouble engaging with larger books (Food Fight Podcast, 2015)

As a primer to learning reviews, as opposed to Post-mortems, it is a useful read particularly when read alongside The Phoenix Project as part of learning how important the culture of a business is.

A good learning tool to introduce learning reviews and the dangers of blame culture but a bit light.

The Phoenix Project

The Phoenix Project, is a book well known in DevOps circles and is the de-facto must-read.

Review by: Nick Holder – Platform Development Manager

 If you’ve spent any time in an operational role, firefighting issues, you will find the situation instantly familiar: A company going through technological change and suffering from growing pains due to legacy decisions and practices.

The main character, Bill is being unexpectedly promoted and has a sudden responsibility for all IT in his organisation. The company has bet the future of the business on “The Phoenix Project” which is massively delayed and at serious risk of failing, possibly taking the company with it. Can Bill and his colleagues pull it together and deliver on that bet? Can they work out how to get all the parts of the company traveling in the same direction in time? Read and find out!

This story is a light-hearted way to introduce DevOps principles in a context that both techies and managers understand and have, in most cases, experienced. It is both an entertaining read and a cautionary tale rolled into one in such a way you forget that it has a wider message and get lost in the story, but when you reflect on it, you start seeing things in your own experiences that directly apply.

It has characters you sympathise with and you are invested into as they are so well established and familiar (you WILL start putting colleagues names on them) which will get you hooked. Along the way, you will see the effects of siloed working and siloed knowledge, technical debt and approaches to de-risk how you engage in technical work, but without realising you are sneakily being educated.

In case you didn’t get the key messages from the main text there is an appendix crystallising some of those key points. This can be useful if you want to try and promote DevOps working in your environment by providing a summary of why you may want to do this.

Massively engaging, fun (that may just be schadenfreude, though) and deceptively educational.