I wrote an ebook series about creating better DevOps teams recently and had a lot of fun. I also learned a lot doing the research.
One thing that tickled me - there are some excellent buzzwords circulating around the world of business that you can use when it comes to talking about DevOps and software development. Grappled with the bus factor, Ikea effect, or ping-pong thinking recently? I hope not!
Today we’re going to zone in on the Ikea effect. It’s a powerful one and, if you’re an IT manager who is hoping to have a significant effect on the way his or her team thinks and acts, it’s something you should be aware of, so at the very least you can take advantage of it - or keep it at bay - when the time comes.
Like our DevOps thinking? The Cycloid quarterly newsletter is just as fun.
First of all, let’s make sure that we’re on the same page. The Ikea effect is a cognitive bias in which people (in the original study, consumers) place a higher value on things they have had a hand in creating. Many of you will have already heard of it and read the original story - researchers asked students to make their own Ikea furniture and then bid on it. After controlling and testing for different variables, they concluded that people are prepared to pay more for things they have created themselves.
A proviso - the effect didn’t hold up if the thing they had made was destroyed after making it or if they failed to make it - it only held true if they were successful in their endeavors.
There are several schools of thought about how this fits into the wider world and, specifically, the world of software development. In the first instance, it looks like a great match for DevOps and agile thinking - people make their own software and feel proud of it and, as a result, do the best they can to improve it and help it reach success.
However, as with most things, it’s not really that simple. We’re here today to give you a few things to look out for when considering the Ikea effect, point out the negative effect it could possibly have on your team, and show you how to produce the same pride in work - without lying solely on cognitive biases.
The first problem with the Ikea effect is not even the Ikea effect itself. It’s the fact that there are several other cognitive biases that are very similar, which could be confusing. Now, for many people, this doesn’t really matter - unless you’re actually interested in identifying one or the other. If you’re not, it doesn’t matter. If you are interested in these cognitive biases, however, watch out for these two. They’re very similar to the Ikea effect, and could easily be confused for it.
The endowment effect is a psychological bias that says people are more likely to value an object they own more highly than one they don’t. In tests, people who were given a chocolate bar were less likely to be willing to exchange it for a mug, but the people who were given the mug first were less likely to want to exchange it for the chocolate bar.
When you introduce a financial aspect to it, the bias becomes pretty clear - it causes individuals to value an owned object higher, sometimes irrationally, than its market value. That's why people insist on selling second-hand Ikea furniture for the same price as you could buy it in the store!
Although similar to the Ikea effect, the Ikea effect specifically requires people to have made the item, which makes it more relevant to the SDLC (software development life cycle).
This cognitive bias can look very like the Ikea effect, in that both are something that happens specifically when somebody puts physical effort into doing something. The difference is that the sunk cost fallacy happens when a person continues a behavior or endeavor as a result of previously invested resources (time, money, or effort). It’s related to loss aversion and status quo bias and we've all seen it exemplified by that person who keeps on going until the bitter end, despite all the good reasons to stop!
The sunk cost fallacy is something that can definitely be seen on development teams and should be avoided, but it’s still not the same thing as the Ikea effect. The main thing is that the sunk cost fallacy is an active type of loss aversion, whereas the Ikea effect is simply that - a consequence - and not an action in itself. Although the sunk cost fallacy and the Ikea effect are different, it's also true that they can compound each other. If you see one, keep an eye out for the other.
The Ikea effect in itself isn’t dangerous - in fact, it can be helpful, the emotional attachment encouraging pride and investment in a product. Where it gets “dangerous” is where it combines with other fallacies and effects, enhances natural human tendencies, compounds the effect, and makes undesirable behaviours even harder to correct.
The higher the value of the item in question, the more powerful the effect and it can lead people to get really dogmatic about software or fixes they have created. It can also make them short-sighted and resistant to change and improvement. When you know your software is the best, there's nothing you can learn from competitors and peers, right?!
These pressures may just be “effects” and “aversions”, but they are powerful cognitive biases that can exert a significant influence on human behavior. There's nothing you can really do to avoid them. Instead, knowing about them can help you understand your team's (or your) behavior more easily, and see when you might be needed to step in to shed a little more light on inadvertently poor decision making.
It's easy to see why you might think that DevOps protects teams from such biases, but it's not a slam-dunk issue. True, running a project or team along DevOps lines should put everyone in a great position to avoid such cognitive biases - open, communicative, and collaborative teams should have short feedback loops and great discussions, which would hopefully allow team members enough headspace to see and highlight such distorted thinking from afar.
Even so, DevOps is a spectrum, not a solution. Teams may strive to improve, adopting DevOps processes as they go, but no team can boast of 100% DevOps perfection. That simple fact means that there is always a sliver of room - and sometimes that sliver's bigger than others - for cognitive bias to slip in.
...without the Ikea effect (or, at the very least, without having to rely on it for the results you want.
We're glad you asked, because any steps you take to help your team feel more invested in the product are steps that will help your team feel better about themselves, each other, and their work - and that will benefit everyone, Ikea effect or not.
It's hard for people to care if they don't feel cared for. Sure, depending on the team, your language of love might look very different, but if you don't care about them, they won't care about you or, by extension, the company and product.
Still talking about the language of love, a much appreciated way of caring for your team is by making sure their accomplishments are seen and appreciated by the powers that be. It's easy for a combination of job role and personality to get in the way of recognition, so if you can give your people an extra public boost, it will speak volumes to your appreciation of them.
Trust breeds excellent teams, and excellent teams make great products. Create trust in your team by walking the walk and talking the talk, and endeavor to be trustworthy and transparent in all your dealings with them. It's not a quick fix, but over time it will make your team much more cohesive.
Things are changing, but it's still common to see very heterogeneous tech teams. Creating diverse teams where everyone feels confident of bringing their whole self to the office works on two levels - if you're a member of a tech team and living your best life by bringing your whole self to the office, you'll be happy and productive. And, even if you're not so big on self-expression, you'll likely learn a few new things from those who are - diverse perspectives can be real eye-openers!
Finally, rather than being a tip in and of itself, we want to reiterate the basic fact here. People care when they feel cared for. A cohesive, collaborative and respected tech team will far outperform one that's not. They will also likely care about the product, perhaps even if only because it is their tech team's product. Either way, they'll care about their work, move mountains to improve the product, and likely embrace DevOps thinking with both hands, since it encourages and supports the behaviour that makes them so happy in the first place.
There you have it. The bottom line on the Ikea factor and DevOps? It's neither good nor bad, but could be having an impact on your team. Stay aware to recognize it and build strong, communicative, and collaborative tech teams to give people the space and clarity to see distorted thinking from afar.
Even if the Ikea factor never darkens your door, your team will be the better for it.
