I’m Joel Chippindale and I am here to talk about blameless reviews. There is no Ruby in this talk but the longer that I work in software development the more I think that all the hard problems are about communication and learning so hopefully it will be of interest.

I work at FutureLearn, a social learning platform, which offers free open online courses from leading academic institutions from around the world. This means we spend a lot of time thinking about how people learn on our platform but also how people learn within our company and I am going to talk about one of the ways that we learn within our teams.

I should start by saying that most of us in this room are very lucky because most of us have interesting jobs. On a regular basis we ask ourselves and are asked by others to do things we have never done before and every time we do that we have got an opportunity to learn, an opportunity to make our jobs interesting. But this has an inevitable side effect.

If we are doing things that we have never done before on a regular basis then we will make mistakes.

We make mistakes at FutureLearn, from very acute events like truncating a table on our production database by accident to longer term things like a project that has gone on for months without delivering the value that was envisaged. But I don’t think it is interesting to think about whether we make mistakes because mistakes are inevitable.

It is more interesting to think about how we react to mistakes.

How do your teams react to mistakes?

I am going to talk about two very natural ways you might react to mistakes and then I am going to talk about blameless reviews and why they are a better reaction.

The first very natural way to respond to a mistake is…

…to find out who is responsible and give them a good telling off. This is natural because of what social psychologists would call…

…the fundamental attribution error. Some of you will have heard of this but for those of you who haven’t…

…this is that it is very easy to view your own mistakes as a product of the circumstances you were in, the pressures you were under, the information you had available to you at the time and other people’s mistakes as a product of their incompetence. It does feel very natural but it is not very effective. The people you told off, or who were told off in your team were probably already trying their hardest not to make mistakes.

What does your team learn from this experience? You work with intelligent people…

…and being told off is an unpleasant experience and so they learn to avoid getting caught making a mistake. You have employed very smart people and so they are going to be good at avoiding getting caught. Given they are already trying hard not to make mistakes there are two strategies they might take to achieve this.

The first is to stop taking risks. To stop doing those things that they don’t already know how to do and that’s a disaster for you and for them. At that point people stop learning and you are not able to achieve the things that you need.

A second strategy they might try is to hide their actions. Systems involving computers and people are already complex when it comes to working out what is going wrong and if you have members of your team who are actively hiding what they are doing then you have just made it much harder to work out what is going on.

If that doesn’t work then what is a another strategy that we might take in our teams when dealing with mistakes.

Pretend we haven’t made any mistakes. Now this seems odd, of course we wouldn’t pretend we haven’t made any mistakes but again this is really natural. We ‘know’ that people who are feeling confident, who are feeling upbeat and optimistic perform better and that’s what you want for your teams so why dwell on that thing that didn’t quite work as well as was originally planned.

But there is a problem with this approach. What does your team learn if we all pretend that mistakes haven’t been made?

Nothing. You are doomed to repeat the same mistakes again and again.

Surely there is a better way.

I came here to talk about blameless reviews and you may already be running blameless reviews. You may not call them blameless reviews. You may call them project retrospectives, or incident post-mortems. The name isn’t really important but the fact that they are blameless is and that is why I have referred to them as blameless reviews.

It’s so important that Norm Kerth, in his book “Project retrospectives: A handbook for team reviews”, called this the prime directive of project retrospectives.

I am going to read this out to you because I think you should all know it,

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available and the situation at hand.

This is effectively an antidote to the fundamental attribution error. What it is asking you to do is to assume that everyone did their best and that is almost certainly a reasonable assumption in your team. If you can start with this assumption then you are in a position to run a blameless review.

How do you do that? Involve everyone who played a significant part in the incident or project. That may include people who did things but also key stakeholders.

You need to bring them together to come to a shared understanding of what happened. This is really important, you are all going to come to this with different partial understandings of what went on, what decisions were made, what information was available. You need to be curious at this point to find out what has gone on. This will start to build trust.

Once you understand what has happened, then you can decide what changes you need to make to improve in future. Here you need a short list of actions or changes that you want to make. If you arrive at a list of 25 changes then you are effectively saying to one another you won’t do anything. You want 1, or 2, or 3 things to change.

If you do this, then what does your team learn?

How to improve and trust one another. What’s not to like? It’s not just me who says this so I thought I would end on a quote.

This is Ed Catmull who is the President of Pixar and, in his book “Creativity, Inc.”, he says,

There are two parts to any failure:

There is the event itself, with all it’s attendant disappointment, confusion, and shame, and then there is our reaction to it. It is this second part that we control.

Do we become introspective, or do we bury our heads in the sand?

Do we make it safe for others to acknowledge and learn from problems, or do we shut down discussion by looking for people to blame?

That, in essence, sums up what I want to say in this talk.

Thank you for listening.