This is a short talk outlining some of the ways that teams can react to
the mistakes they make and how blameless reviews help build trust within
teams and also enable them to learn from both their successes and their
mistakes.
Transcript
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.
The transcript above is from the version of the talk that I gave at
London Ruby User Group in
September 2015 which was recorded by
Skillsmatter.
Other versions of this talk
Further reading, watching and listening
Reactions
Great talk from @joelchippindale I think I'd like to be in his team. :)
Rob Borley
. . . . . . .
