Myths Teams Live By

Exposure to a mixed body of evidence made both sides even more convinced of the fundamental soundness of their original beliefs.’ Confirmation bias is profoundly human and it is appalling. When new information leads to an increase in ignorance, it is the opposite of learning, the death of wisdom. — Heretics: Adventures with the Enemies of Science, Will Storr.

“Human beings live in their myths. They only endure their realities”. — Robert Anton Wilson.

I’m listening to the book Heretics: Adventures with the Enemies of Science by Will Storr. It’s a fascinating book, looking at how seemingly intelligent people can hold bizarre and illogical beliefs that fly in the face of reason and what those extremes of belief tell us about all of us and our beliefs.

Essentially our brains are narrative engines, making sense of the world through stories where we are the hero of our own dramas. It should be unsurprising then that the same can be said for teams.

I’ve talked before about the use of language and narrative in software development. We work in an abstract knowledge based industry where everything from our rituals, to our processes, to the very code we write is all made up in our heads.

Let’s really unpack that last statement, almost everything you do every day in your work is a fiction. It has no reality outside of the collective story that your group is telling itself, we justify our decisions based on this story and we manage our actions through it.

If I was going to be really honest, our entire lives are fiction, we’re all living the story we tell ourselves in our heads. However I don’t want to freak people out too much, so let’s just stick to the office shall we?

This fiction has very real consequences, I remember talking to a couple of developers I used to work with about previous employers. One recounted how releases used to regularly stretch whole weekends, pizza fuelled chaos binges where software was released and fires valiantly fought. Another recounted how at a games company they worked at they and and the other developers used to keep sleeping bags under their desks.

What was interesting was that both told these stories with a hint of nostalgia not abject horror. Adversity and struggle bonds teams together to a common valiant cause, like a siren song it’s both destructive and beguiling. This is why the shared narrative can be dangerous as it can normalise situations that should really be considered extreme.

A healthy story on the other hand is a powerful positive feedback loop, a team that talks itself together not apart is adaptable and resilient, knowledge grows and people feel part of something that is worthwhile.

How do we know if we are working in this way? Well it probably is self evident if it’s bad, but I still think it’s worth considering, if we can’t see a way of measuring change how can we ever hope to make that change? I think the only way we can truly judge if the the story we are telling ourselves matches reality is by measuring the outputs of that narrative, and with our industry that has to be the end result of our actions: the software we produce.

However we have to careful here, notice I am talking about outcomes. Metrics can be dangerous if we don’t understand what behaviour they incentivise. The very act of measurement feeds the team story and changes it. This is why metrics are both necessary and a risk, metrics act as a vital check against a bad narrative but can equally be powerful incentive for it. How you judge a group defines how they value themselves.

For instance judge a team by number of points delivered then that will become the driver of behaviour. This may increase the number of features going out the door, but it also runs the high risk of incentivising over estimation or fast delivery undermined by constant rework and bug fixing, as developers seek to meet their perceived targets.

In the end the best metric for software is the quality. Is the system we are producing stable and reliable? Can I deploy it regularly, easily, safely, without fear and without extreme measures? And are the amount of bugs and rework low? Can I add new features without fear?

I know that I am not right about everything, and yet I am simultaneously convinced that I am. I believe these two things completely, and yet they are in catastrophic logical opposition to each other. — Heretics: Adventures with the Enemies of Science, Will Storr.

So what are some practical things we can do here?:

Firstly you need to know or discover the story is your team telling itself. Set aside any assumptions and really listen to the language that is being used around you as well as your own. How do you and your peers describe yourselves and most importantly how does it match with your actual experience and the it’s outcomes?

If you are hearing ‘everything is fine’ but your experience is ‘everything is on fire’ then that’s a clear pointer to a cognitive dissonance. However it can be more subtle, for instance if there’s a sense of resigned acceptance to things like failing builds or poor testing, or you’re constantly saying ‘we’ll fix that later’ that can indicate an area where a bad narrative has normalised something that is actually a problem, simply because no one sees it as a problem.

Another useful exercise is to define ‘team rules’ or ‘team values’, I spoke about this before in another article, I’ve found it is a good way to get people talking about what they believe should be happening and once agreed acts as yardstick to measure yourselves against. If you are saying as a group that you believe in one thing but never actually do it then it becomes clear quickly.

Some caveats. The rules apply to everyone including leaders, values are a conversation not a stick to beat a team with. They’re for highlighting gaps between word and action and instigating an open investigation, an exploration of why that gap exists and they have to be backed up with action. Talking about something is not a substitute for doing, the walk needs walking more than the talk needs talking.

Check your metrics. By what criteria are you measuring success? What effect is that having on the team and the way they act? Is it positive or negative? If negative can that be changed? Looking at some of the suggestions that have come out of the Dev-Ops reports is a good start. As I mentioned earlier we’re interested in outcomes not outputs and the Dev-Ops metrics focus on this. Using measurements like Lead Time, Deployment Frequency, Mean Time to Restore and Change Fail Percentage give you a clearer picture of what your results your current process is actually achieving. This can be then compared back to internal story you are telling yourselves to see how close to reality it is.

The last thing is to consider our own bullsh*t. It’s easy to point fingers and analyse the short comings of those around us while being blithely ignorant of our own and this is equally true of teams. The sign of a healthy team is not that mistakes are made but that it is self aware enough to correct itself.

Even if we are on a healthy team the Professor ‘Mad Eye’ Mooney’s maxim of ‘CONSTANT VIGALENCE!’ is required to make sure we don’t start talking ourselves in or out of things we shouldn’t.

To give an example we made some decisions recently on a team I’m helping run, the decisions were for good reasons and for expediencies sake, we all told ourselves the story that it would be fine and convinced ourselves it was true. However it was soon apparent that the outcome of those decisions were having a negative effect on quality. It was called out discussed and a strategy decided to course correct. This is the sign of a healthy team correcting itself.

The most important point with any of this is to move slowly, tread lightly and be kind. People do the wrong things for the right reasons all the time (and that includes me and you), and we all react strongly when we feel our beliefs are threatened. A mature team entrenched in a strongly held but destructive narrative can be hard to change even if it’s for their own good. Small changes that show benefit will allow people to adjust and not feel overwhelmed, hopefully opening the door to larger changes as confidence and experience grows.

And if all of this is out of your control? If the bad narrative comes from the organisation itself? If you feel disempowered or not in a position to make change then perhaps moving somewhere else is the only option. Change your company or change your company as the saying goes.