I‘ve been wrestling with the topic of hierarchies quite a while, wrote several drafts for blog posts and deleted all of them. Now I figured that maybe the issue was that I was trying to write one grand blog post, where I would express all my thoughts on hierarchies. But the topic feels too big for me, and there are still so many things I haven‘t managed to wrap my head around. So I decided to slice the topic into smaller chunks and start publishing whatever might be good enough already. So here‘s the first part of a series of posts that are to come later.
In the good old days, I used to train karate a lot. And I remember one day a read a newspaper or something and spotted an ad, which caught my attention. It read something like this:
"Karate is a great martial art and can be a very useful means for self defense. At the same time, the way it is practiced is very hierarchical. In our courses, we will teach you karate in a non-hierarchical, participatory way."
Back then I just shook my head and didn‘t think about it too much. But recently I remembered the ad and found it quite interesting. The authors obviously thought hierarchy is inherently evil and needs to be avoided at all cost. An assumption I don‘t agree with - neither in general, nor specifically when it comes to karate.
I believe hierarchy in itself, like most organisational structures, is neither good nor evil. It can be more or less appropriate or helpful in a given context. It will come with certain costs and certain benefits. And it can used in a more or less helpful way.
Let‘s look at hierarchy in karate. Yes, it‘s true, the hierarchy is very obvious in the dojo: we have a master and we have a group of students. They are not treated as equals during the training sessions. And then there‘re the different levels of expertise, which are indicated by the color of the students‘ belts*. In the beginning and at the end of every training session, the group lines up in a standardised formation: The master on the one side, the students on the other. And the higher a student‘s belt, the farther to the right this person stands. So just by looking at the line-up, you can clearly see the hierarchy. During the training sessions, the hierarchy will also be reflected in the way people behave. The master tells the students what to do, and they do it. They don‘t question what the master says. There‘s no debate and no participatory decision making. And since a lot of the exercises are done in pairs or small groups, and the master cannot be present in all groups at the same time, the student with the highest belt becomes the proxy master in his/her absence. The same is true, if the master cannot show up for a training session: The student with the highest belt will lead the training session, no questions asked (unless it‘s a group of children and/or absolut beginners).
If you just look at the things I have just described and if you are suspicious of hierarchies, then it‘s understandable why this might be a turn-off. But this is only one part of the picture, and by only looking at this, you would be missing at least two other, critical aspects.
1) Practicing karate means practicing dangerous techniques. Discipline, strict rules and hierarchies are means to make the practice safe. One of the main assumption here is that the person, who‘s highest up in the hierarchy knows best how to guarantee safety and will do her/his best to keep everyone safe. Based on my experience this works quite well, in more than 2,000 hours of training, I have been injured once, and I have witnessed maybe one dozen other injuries.
2) You cannot understand the aspect of hierarchy in karate, without looking at the whole system. One other widely important aspect of karate is respect. Looking at hierarchy in Karate in isolation, without connecting it to respect, will show you a completely flawed picture. Respect is deeply engrained in every karate session. Every training session starts and ends with a ceremony, where people bow, in oder to show respect. Respect towards their master, their peers and the art of karate. Every kata, every sparring situation, any kind of excercise really starts and ends with a bow. This is a recurring gesture, which signals respect and means: "I respect you, I see you as a partner (not as an opponent), I want to learn with and from you, and I will do my best to keep you safe."
Why is respect so important, when looking at hierarchy? Because it guarantees that a master will never misuse his/her authority. Respect is based on reciprocity: It‘s required that students show their respect to the master, and the students can be sure the master respects them as well and will always act in their best interest.
Of course I know that a karate dojo is very different from a business organisation. I am not advocating for using the karate system in our work environment. So what can we learn from all this, when it comes to hierarchies in a business context? When I reflected on this, I took away two general insights:
1) Hierarchy is not inherently good or evil. It serves a purpose, and we should evaluate the usefulness of hierarchy based on how effective it is in serving this purpose (and what the costs are).
2) It can be too simplistic to look at hierarchies in isolation. We need to view it as a part of a bigger system and look at the other elemenst of that system as well as the interactions between the elements.
* Technically this is not 100% correct, it‘s the kju ranks, which indicate the level of expertise, not the belt color (you could have two people with brown belts and different kju ranks). But since the mapping is almost 1:1 and for the sake of simplicity, I use belt colors in this post.
Recently I have been doing quite some reading on remote work. In one of the books I was reading, the author suggested adopting ROWE to make remote work easier. I had heard about ROWE 10 years ago but then almost forgotten about it. It sparked some thoughts and after brief conversations with Henning and Stefan, I feel these thoughts are worth sharing.
What is ROWE?
ROWE is, of course, an acronym. It's short for "Results-only Work Environment". I am not going into details or the history of the concept - this blog post by Steve Nguyen gives a good overview.
The basic idea of ROWE is pretty simple: Results are all that counts. It does not matter when people work; it does not matter where people work; it does not matter how people work - as long as they deliver the desired results.
It‘s easy to understand why this concept is appealing to Agile folks: It gives a lot of autonomy (back) to the employees and frees them from micor-management and stupid policies. To my understanding ROWE was developed as an alternative approach to being paid and evaluated simply by how much time someone spends in the office. That surely makes a lot of sense. And it explains why ROWE got quite some traction in government agencies and big, old-school corporations.
Problems with ROWE
We all want great results. So what‘s not to like? Reading through some articles, the main areas of criticism seem to be that a) It‘s very hard to create a shared understanding of the desired results and how to measure them; and b) contrary to proponents‘ claims, ROWE does not always reduce working long hours. Some studies indicate it can have the opposite effect and actually harm work-life balance even more than traditional work environments (see "the Risks and Obstacles of ROWE" in Nguyen‘s post for sources).
These concerns sound legit to me, but in this blog post I want to stress a different concern, that is probably as serious as the ones already mentioned. I use ROWE as an example, but the critique holds true for any kind of hands-off management that focuses entirely on results/targets. My main concern is:
ROWE totally ignores methods and therefore makes organizational learning very hard (if not impossible).
Imagine you are running ROWE in a small company. You as a CEO are quite happy with the results. Your clients are also happy, and you earn a lot of money. Now you want to grow the business and hire a bunch of new people. How do you onboard them? Sure, you can agree on desired results with them and hope for the best. But chances are that at a certain point you will not be happy with the results anymore. What do you do now (other than fire people, because they are "under-performers"? How do you train people, if you have no understanding which methods work in which situations and which don‘t? How do you make sure co-workers will learn from each other, if there is no structured conversation about methods? Learning and scaling the business becomes incredibly hard in this situation. And for employees who struggle with their work (for whatever reason) it becomes very frustrating, because there will likely be no structured mentoring.
And it gets worse. Deming advised managers always to ask "By what method?" whenever someone bragged about their achievements. He stressed the importance of a solid method you can learn, teach and iterate on. If you don‘t do this and purely look at results, you are rewarding luck and unethical behavior.
Conclusion
Yes, we want to keep methods as lightweight as possible. But let‘s not throw out the baby with the bath water and abandon them all together. Without solid and explicit methods there will be no organisational learning, and personal development of the employees will be sub-optimal. ROWE might sound appealing at first glance, because it emphasizes individual autonomy, but it does exactly that: neglecting the methods that can (repeatedly) lead to great results.
I know Erikand Håkan for almost ten years now, and they both have an impressive track record of Lean and Agile. Not only do they deeply understanding the concepts, but they also are true practitioners and have driven substantial change in various big organizations. Since I have moved to Stockholm in 2017, we get to meet and talk more regularly. In several of these conversations we touched the pros and cons of the SAFe Framework. We agreed that we would need a longer discussion to properly discuss the topic, so I invited them, and we recorded our conversation, which went on for over an hour. When we had drinks later that evening, Håkan said that he felt like he was been roasted (of course in a very friendly, a very Swedish way). Although this was not our intention, we all agreed that it would be a great concept:-) So I give you the first part of our Lean-Agile Roast on SAFe. You can check out part two of this Lean-Agile Roast on Erik's blog and part three on Håkan‘s blog. If you prefer to listen to the whole conversation, you can download the audio file here.
SAFe: A big bowl of candy? (Image credit: Wikipedia)
Arne: Welcome, Håkan and Erik to our little conversation about SAFe. I'm happy to have you here. I would like to start with a question for Håkan. A lot of people from the Lean/Agile community are kind of suspicious about SAFe and you have just become a certified SAFe trainer. How come?
Håkan: Yeah that's right. I was moving to a big Swedish insurance company and they had taken some initial steps in that direction. And from a personal point of view a lot of the principles and the values that are stated in SAFe are something that I totally agree with. So therefore I didn't have any problem to actually explore being a trainer and help train people around us, because I think if you train them with a focus on principles and values then the method would follow as you learn more and more.
Arne: I believe this has been about six months. What have been your experiences so far?
Håkan: I'm really impressed by the depth of the material. I might not agree with all the details but there's a lot of intellectual property that is really useful to get started. And also there is what is called the implementation roadmap. In there it's described how to actually do the implementation, which has been very helpful to hold people back and not just throw themselves into the implementation without learning first.
Arne: Erik you have been more on the other side of the spectrum, when it comes to SAFe. What are your concerns?
Erik: Well, I think way back SAFe and I got off to a bad start. It wasn't even called SAFe at the time. This was in 2010/2011 and I was a big fan of Don Reinertsen, the author of Principles Of Product Development Flow. He recommended us at the start of our Lean/Agile transformation journey to read Leffingwell's book Agile Software Requirements. So I started reading it, but I couldn't finish it! And that very seldomly happens for me that I can't finish a book. It was not to my liking, not to my taste. So we got off to a bad start and we took a different path to scaling. Our ways of working with large scale Scrum systems was inspired by the Lean community and by Kanban -- we were always trying to learn and to get inspiration from several sources. I found the book a bit dogmatic and it felt like a bag of goodies: a lot of good stuff but no consistency, no real depth. And it was hard to get to the essence, that was my initial impression. But bear in mind: I see a lot of skilled people who know the principles, and they work with the SAFe framework and they get it to work really well. So if you know what you're doing, if you're a practitioner and you know the principles I guess you can make any framework work. Because then you start from the needs and you start from from your context, and then you tune and tweak the framework to suit those needs.
Arne: When I prepared this conversation I remembered that Schiller once reviewed a book and wrote: “This book contains many new things and many good things. Unfortunately the new things are not good and the good things are not new.” And I was thinking you could say the same thing about SAFe: It contains many new things and many good things. But the new things are not good. And the good things are not new. Does that make any sense to you both?
Erik: I think that's a very interesting summary. I have to admit that I haven't dived into all the details or taken any training. So I've looked at it from the outside. Still, I've seen a number of companies, that were on their journey and talked to people, who were part of that journey. Your description seems fairly, consistent with what I hear. Håkan, I would like to hear your view on that since you're in this now.
Håkan Yes I think there's not a lot of new stuff in there.
Arne: Is there valuable stuff in there?
Håkan: You could say it's a framework that embraces everything that has seemed to work at some point. Which could be a problem. But it also actually puts it together in a way that it should work together, if you actually are using the principles and the values. From my point of view there is nothing that is really, really new and SAFe is just a way to communicate the ideas to an audience that is not necessarily knowledgeable about this area. If I go to the CEO of my company, they might not even know the concepts of Lean and Agile, but you can talk to them around this material in a way that they understand what it could potentially look like in the future.
Arne: Why do you think SAFe is so successful.
Erik: I would say it's very neatly packaged. It comes in a box and it's very easy to explain to upper management. And it solves a real need. It fulfills a real need to deliver faster and that's a legitimate need. I really think it is. In that sense it helps a lot of companies that would otherwise struggle quite a bit.
Håkan: And I think one of the biggest values that it brings is that it is great in communicating the ideas. So there's lot of good stuff and it's well presented, so you can just use it and you don't have to reinvent the wheel. You can take the ideas and build on it. And that's been a great support in many situations, where you might not yourself have developed the training material around a certain area. There's a lot of help from that framework itself.
Arne: We had a conversation this morning at the Stockholm Lean Coffee, where we discussed the idea that maybe the main purpose of SAFe is just to help organizations deliver big projects or programs. And this it does really well. So if you look at it this way it's a really good tool. But a lot of people are assuming that what it should be doing is also enabling an organization to develop their own ways of working. And this is probably not what SAFe is intended to do. Would you agree with that?
Håkan: You could say something similar about Scrum, right? So from my point of view Scrum has one rule that rules them all, which is inspect and adapt. So I'm someone, who would say I'm a very proud Scrum-But. And I think that's the same idea about SAFe. There are built-in mechanisms to actually adjust and make changes. You can change the core values and principles as well, as long as you are actually doing what is in that rule which rules them all. You should always inspect and adapt. I don't see a problem in that sense.
Erik: But isn't there a risk, since the SAFe is such a big framework, that this fundamental rule gets lost, because you see all the other good stuff? And then you might miss out on the fundamental thing, which is to inspect and adapt, the improvements, the continuous learning. All those things. Because you're so busy just understanding and grasping the framework that is so big.
Håkan: Sure. But then there's a lot of material that prescribes the kind of meetings and so on in a similar way as the Scrum framework would do. One important part of that is that you should measure things - that you should evaluate at the end of the Program Increment (PI). And you should look at the bigger picture and optimize the bigger picture and not the individual parts. So if you actually are following a lot of the material that is described, you are at least on a path of that learning. But of course you can get lost just like you can get lost in just doing Scrum by the book and not applying inspect and adapt.
Arne: Would you say that the one rule that rules them all is the same in SAFe: inspect and adapt?
Håkan: Yes I would.
Erik: Would the C-suite also formulate it that way? If you would ask that question to upper management, what would they answer? Why would they use SAFe? Is it because of inspect and adapt, or is it for some other reason?
Håkan: No, no, no. They want business results. And I guess that's the same thing if you would implement Kanban or XP or whatever. They are not particularly interested in the method itself. But they want the actual business results and I think that's a very similar thing with SAFe. You need to deemphasize the idea of the SAFe framework itself, it's the business results that we are after. And it's clearly stated what they expect the business results would be by implementing SAFe.
Arne: Another aspect we discussed this morning was that a typical manager, who is not the owner or the founder of a company is usually not incentivized to think ten years ahead or even five years ahead. So the incentive is to deliver stuff. And this is where SAFe could be helpful. But the incentive is in most cases not: in five years from now or in ten years from now I want this to be a real learning organization. And this is maybe a little bit tricky, because on the one hand we would like organizations to be more like learning organizations, on the other hand it seems very hard, because why would it be in the interest of a manager to invest in the future and then everyone else would say: "Oh this is a weird person. What is (s)he doing?" I think you have maybe similar thoughts, Erik?
Erik: Yeah. That's a really really tricky. I mean being a middle manager myself and having been in that situation: How do you progress without being seen as a UFO or sort of alien? And if you're too alien you might get shut down. So of course you want the sustainability to be there for the company for the long term. And you also want to deliver results, and that is a very tricky trade-off. You want to do both, and I think ultimately it will come down to learning some new patterns and un-learning some old patterns and re-learning. And different frameworks and different philosophies can emphasize that more or LeSS - pun intended. So I think that's my take.
Arne: There is a lot of stuff in SAFe. And if you look at the poster it can be a little bit overwhelming. My friend Henning likes to make this joke: He shows the SAFe poster to people and then asks them: " Where's Waldo? Where's the customer?" Because there's a tiny spot, I think on the bottom left or something, where you can find the customer. At least it's not very prominent. And so I guess there's also a risk that you lose the customer out of sight, because there's so much process and so many roles and artifacts. Is that something you've seen?
Håkan: If you follow the implementation roadmap of SAfe (which has some great tools in it by the way), one of the things that you do before you get started is to do a value stream analysis. You then identify how you set up your organization and your Agile Release Trains. What we have found with the work that I've done so far is that this type of work has not been done that much before. So by going through that and actually looking from that lens we actually put more emphasis on the customer and ask what customer value is, before you get into defining the Release Train and the delivery organization. So I actually found it to be a little bit opposite. That this helps upfront with thinking about these things in an organization. So from my point of view it really has helped to take that perspective even more. And then on the portfolio level the suggestion is to use prioritization and scheduling based on Don Reinertsen‘s principles around cost of delay, which also put the customer in the focus. So there's a lot of mechanisms in there which are leaning towards a very high customer focus. So I actually found it to be helping to put those things in the front seat, instead of something that you can potentially introduce to the organization later on.
Arne: I can can totally understand why it's tempting for a manager to implement SAFe. If I try to put myself in this person's shoes, where I'm managing an old school company and I see that we have to change, that we need to become more agile. Now I see that there's this framework called SAFe, and it has a lot of interesting stuff and has this implementation handbook and everything. So that sounds great, and I would probably want to buy it. Erik, what would you do in this situation if you would be this manager, but you didn't want to implement SAFe? How would you start such a journey?
Erik: I'm thinking about acting your way into a new way of thinking, acting your way into a new mindset. We were struggling quite a bit with this in the beginning of the journey in the part in Ericsson where I worked. We had two thousand people at ten different locations in our product development unit. And we were thinking about the whole transformation approach and asking ourselves: Should we do that like an implementation project with a plan and a roadmap and all the steps predefined? We were going back and forth and ultimately we thought that if we want to change our way of working, then we should change our way of changing first. So we didn't come up with a big project plan. We had a one pager showing the rough direction where we were going. We had a few principles and we started moving. So I think that the whole approach to change is pretty important: As a manager in the organization, do you start with yourself and then do the whole transformation approach differently? Or do you do it the traditional way, where you have the risk that you will continue to do things the way you've always done them? Then you don't get into the inspect and adapt and improvements loop. That's my fear. My respect goes to all skilled people, who know the practices, who are practitioners and who know the principles. They are of course aware of this and will tune and tweak things. My fear would be that it's too easy to start with the classic way of driving change: to have all the big plans upfront and then start executing to implement the new new framework. Many organizations, if not most of them, have done that several times and they get bored or fed up with it. And then this becomes the new fad and there will be no real change, because the managers will not change their way of acting. And then they will not change their way of thinking and then you're back to square one after some time -- that will be my fear. So what would I do? I would do something similar to what we did, in addition to everything I said. Having a group of people, who are formal or informal leaders and let them work together as a cross-functional team, meeting regularly to inspect and adapt. Visualize what they do, lead by example and then act. Act your way into new thinking and have full transparency for all the other teams and all the people in the organization to see what you're doing. Also have working sprints or whatever iterations you have, to walk the talk.
Arne: And with with all your skepticism about SAFe do you see any good parts?
It was a couple of months ago, when I first came across this image, showing a big group of wolves traveling in the snow.
Source: this youtube video (although it appears to be a still from BBC´s "Frozen Planet" from 2011)
The picture comes with a description about the structure of the group: The weakest individuals in the front, followed by the strongest ones to protect the group from an attack from the side. In the very back we are supposed to see the leader of the group, who makes sure no wolf is left behind and the whole group travels in the right direction.
Since then I came across countless versions of this picture&story, packaged as a lesson in leadership. The take away usually comes as some variation of: "Great leaders are servant leaders."
When I first saw this picture, my initial reaction was:
Wow, this is so powerful! I am totally going to share this with all my followers!
Luckily, I did not do this immediately, but looked at the comments first. And (what a surprise!) it turns out the description is complete nonsense. Whatever we see on this picture, it is not what the author wants us to believe. So my second reaction to this picture was:
Oh crap, this is fake! I am glad I checked before I distributed this even further.
A couple of days ago, I saw this picture again, and this time I had a different thought, which now makes much more sense to me:
Why on earth should human leaders be able to learn something from a group of wolves?
I mean, seriously, am I the only one who thinks this is ridiculous? Even if the description was correct: so what? It might be an interesting fact for everyone, who is interested in wildlife. But what makes us think we could transfer insights from this to our daily work? Last time I checked, we all were humans working in corporations, not wolves roaming Alaska. These two scenarios can hardly be more different. I guess nobody would use wolves as role models, when it comes to diet ("Rotten carcasses are good for you!") or other behaviors ("Wolves teach us that we should always sleep naked in the snow!")
But there is something about this specific leadership narrative that makes it so appealing to (some of) us: We want to believe that it is true! Or, to be more specific: Those of us, who believe in a certain school of leadership, want this story to be true - because it reaffirms our belief. This certainly applies to me. Now that I reflected on this, I realized that I wanted this story to be true so badly, that all my rational safe-guards were bypassed within the blink of an eye.
The reason I am posting this is because I believe this is a great example of how powerful biases (in this case: confirmation bias) can be - and how sneaky. In this example I was not only biased to (almost) share a fake story on the internet, but also to neglect the obvious differences between wolves and humans. And then there is of course the echo chamber problem: Even if the story would be true, and I had shared it, then only people within my filter bubble had seen it. These people mostly share my believes, so chances are that they would have liked the story very much and shared it once more. But would that really help our course of advocating servant leadership? I doubt it. At least I have a very hard time imagining someone with a very different view on leadership seeing this picture and thinking: "Wow, this is how wolves are leading. I will totally change the way I lead people in my organization!"
This post is part of a series on cognitive biases. You might also be interested in my thoughts on groupthink and the survivor bias.
_____
"People have no trouble turning any information into a coherent narrative." Jason Dana
Zener Cards
J.B. Rhine, the founder of parapsychology, was convinced that ESP (extrasensory perception, ie receiving information with the bare mind, instead of the known senses) exists. In the 1930s and 1940s he conducted hundreds of experiments to prove his claim. Amongst other things Rhine invented a card deck called Zener Cards. A deck comprised of 25 cards with one of five different symbols on each card. The "sender" (often Rhine) looked at a card, while the "receiver" (a person potentially capable of ESP) had to guess the symbol on the respective card. If people would just randomly guess, they would get an average of five correct answers. When a person scored way above five, Rhine saw this as prove for ESP. Over time, Rhine thought he had found people, who were extraordinary good at ESP, because they consistently scored above five.
Millions of people believed Rhine‘s research, he sold lots of books and got funding after funding. However, later it turned out that his methods and his data were completely screwed. Rhine was so desperate to prove his claim, that he went through his data over and over again, until he finally found what he was looking for. For instance, when a promising "receiver" seemed not to perform well enough in a series of tests, Rhine found what he called "forward displacement". This means that the "receiver" did guess the correct answer, but his/her guesses were "displaced", so that he/she did not guess the actual card, but the upcoming one. Another obscure phenomenon Rhine discovered was what he called the "decline effect". When a receiver started promising, but then failed to continue his/her correct guesses, he/she must have been fatigued or bored (and therefor the results must be discarded). Probably the most absurd claim Rhine made was that whenever people scored above average, they clearly were capable of ESP; and when they scored below average, this too was proof for ESP, because they used their ESP skills to embarrass Rhine!
J. B. Rhine with one of his "receivers", Hubert Pearce. Source: Wikipedia
I‘ve learned about Rhine and the Zener Cards from reading the great book Standard Deviations by Gary Smith. The story is a striking, yet extreme example of confirmation bias, "the tendency to search for, interpret, favour, and recall information in a way that confirms one's preexisting beliefs or hypotheses" (Wikipedia). One interesting thing about Rhine is that there‘s no strong evidence that he intentionally cheated. He thought his methods were totally valid. And he was without any doubt a smart man.
You‘ve probably seen lists of dozens of cognitive biases. While it turns out that some of them are so context-dependent that it‘s questionable how useful they really are (and others could not be replicated in subsequent experiments), it appears to me that there‘s no real doubt that confirmation bias exists and that it seriously impacts our behaviour and decision making. We are all affected by confirmation bias, even if we think we would be better able to deal with it than others. For a vivid and astonishing example (there‘s a magician involved!), watch this video. You will get to know choice blindness, which is very close to confirmation bias IMO.
Why are we affected by confirmation bias?
It‘s not entirely clear why confirmation bias (and similar effects) seem to be hardwired into our brains, but there are some explanations that make sense to me:
In this article Jonah Lehrer links confirmation bias (and similar phenomena) to our ability to persuade others, which is a critical skill for humans as social beings. In that sense there‘s a lot value in our brain finding more and more arguments for our point, so that the rest of the group follows or supports us: "the function of reasoning is rooted in communication, in the act of trying to persuade other people that what we believe is true."
David McRaney suggests that confirmation bias might has offered an adaptive advantage to humans as a species He gives the example of a caveman being out in the woods. He has a hunch that there are cheetahs out there, which is obviously dangerous to him. He therefore looks for clues that confirm his hunch. In cases like this it‘s generally much better to go with confirming information, instead of looking for disconfirming information. Or as McRaney puts it: "It‘s better to be wrong than to be dead." (You Are Not So Smart Podcast, episode 103)
Sarah Gimbel and Jonas Kaplan from the University of California point out that relatedness is extremely valuable for humans. Whenever we change an important belief, we put this relatedness to our peer group at risk. So although it might make sense to change a belief from a rational, individual‘s perspective, it might be to costly from a group perspective. Gimbel and Kaplan also explain that important beliefs can become part of our identify, and threatening this beliefs triggers very similar reactions in our brains than eg meeting a bear in the woods.
Kaplan adds two more interesting views on this: Firstly, mental models need some level of stability to be useful in the real world. Therefore we need to balance the influence of new information with this need for stability. Secondly, new information ist not stored independently in our brains. We don‘t simply add another piece of information, but instead we connect it to other information we already have. So changing one piece of information could cause a "chain reaction" and might not be worth the effort. (Listen to this excellent episode 093 of the You Are Not So Smart Podcast with Gimbel and Kaplan.)
Whether or not these theories can be backed up by more research in the future, there‘s strong evidence that humans have a hard time dealing with cognitive dissonance: When our beliefs don‘t match our behaviours, we tend to become psychologically uncomfortable. Therefore we strive for internal consistency, either by changing our behaviour or by justifying it (or avoiding situations in which this inconsistency becomes evident). Changing our behaviour seems extra hard, one reason being that when we do change it, we‘ve created another inconsistency, because our current behaviour deviates from our past behaviour. Therefore oftentimes we justify our behaviour by looking for more and more confirming data and neglecting disconfirming data. Confirmation is not a big problem with minor or relatively unimportant beliefs, but it really kicks in with "cherished beliefs", those beliefs that are linked to our core identity (for many people religion or politics).
It gets weirder: in this blog post David McRaney writes about a study from 1979, which suggests that "even in your memories you fall prey to confirmation bias, recalling those things which support your beliefs, forgetting those things which debunk them."
The internet does not really make things better. As Justin Owings points out in this blog post: "Thanks to Google, we can instantly seek out support for the most bizarre idea imaginable. If our initial search fails to turn up the results we want, we don’t give it a second thought, rather we just try out a different query and search again. [...] People have always been prone to confirmation bias, but the Internet amplifies the phenomenon since we need not look far to confirm our particular bias. It’s always a click away.” That‘s also the reason why it‘s almost impossible to win an argument online - the other party will always find websites which support their opinion.
What can we do about it?
The research on confirmation bias is not new, and most people have heard about at least some of it. Yet I am amazed by how little we talk about the impact of confirmation bias (as well as other biases) in our community. One reason for this might be a phenomenon called Bias blindness, which means that we underestimate the effect that biases have on us compared to others.
If only a small part of the research about confirmation bias is valid, we are wasting tons of money by making flawed decisions in any part of our organization: Should we hire this person? What product should we develop next? Should we invest in a new market? etc.
So what to do about it? Obviously I don‘t have the silver bullet and research shows that it‘s incredibly hard to overcome or even dampen cognitive bias. But I really think we should talk more about these things and share ideas. Here are some of my thoughts on how to fight confirmation bias, please share yours in the comments section):
Whenever we hear someone (our ourselves) say things like: "I knew it! Here‘s yet more evidence that XY is correct!", we should be cautious and try to look out for confirmation bias.
I think it‘s important to institutionalise a process in which we come up with criteria for success and failure (or better: confirming or disconfirming data) in advance, i.e. before we start with a project, initiative, etc. "How will we know we are successful?", "What are signs of failure?", "At what point will we re-evaluate what we‘re doing or stop it all together?" are good questions to discuss (I believe this is called Preregistration in the scientific community). What happens instead (and I am guilty of doing this many times) is this: We are very enthusiastic about a thing and really want it to succeed. So we start a project and invest time and money. After a while the data shows that the desired effect does not occur. But instead of questioning what we are doing, we start looking for other "great" effects we can observe: "Yes, sales did not go up after implementing this feature, but look how much this blogger liked it! So let‘s do more of it." In this case we not only deal with confirmation bias, but most likely also with the sunk cost fallacy.
Writing things down often helps. By grabbing a piece of paper and writing down our assumptions, we can create a commitment, which makes it harder to justify contradicting actions afterwards. The story goes that Warren Buffett admired Charles Darwin‘s approach to confirmation bias: "Charles Darwin used to say that whenever he ran into something that contradicted a conclusion he cherished, he was obliged to write the new finding down within 30 minutes. Otherwise his mind would work to reject the discordant information, much as the body rejects transplants. Man's natural inclination is to cling to his beliefs, particularly if they are reinforced by recent experience--a flaw in our makeup that bears on what happens during secular bull markets and extended periods of stagnation." (source)
Have someone take the role of devil‘s advocate is always a good idea, especially with big decisions. In addition, it‘s often beneficial to invite known critics to voice their opinion. Warren Buffett, again, is known for inviting his critic Doug Kass to challenge his investment plans (source).
On a related note David Rock points out in this webinar that it‘s a good idea to fight bias as a team. Rarely all members of a team need to be involved in actually making a decision. So some of them can focus on observing how the decision is being made, share their observations and trigger a discussion about the biases at work.
It‘s good to keep in mind that often people are not as rational as we think (or wish for). If we wonder why someone is insisting on his/her opinion, despite all the evidence against his/her point, chances are that we won‘t convince this person by adding more arguments. In fact, this could result in this person insisting even more on his/her option. This is called the backfire effect.
If someone seems to behave irrational, we should not assume he/she is an idiot. It‘s almost always a good idea to take a break and let heated discussions cool down. From what I understand the prefrontal cortex plays an important role in what we call rational behaviour. Unfortunately, this part of the brain is easily tired. So give it time to "recharge", before making important decisions.
Taber and Lodge have found evidence for what they call the "Attitude strength effect": Subjects voicing stronger attitudes will be more prone to confirmation bias. (for a summary of the study see this PDF document.) One conclusion from this might be that we should not expect someone to change his/her opinion, when this very person has just talked about this very opinion with utter conviction. In this case it might be a better idea to take a break and continue the conversation in a smaller group.
The way most people (me included) search for information seems to be problematic. When we do research, we often use a search engine to find what we are looking for, or so we think. But knowing a little bit about confirmation bias, I tend to believe that we are rather typing in what we already believe and/or what want to be true. I remember searching for phrases like "Kanban success stories" or "Lean cycle time reduction". And of course I will find what I was looking for. But what if I would search for phrases like "Kanban does not work" or "Lean is is fad"? Wouldn‘t I find completely different results? I now try to make it a habit to search for disconfirming results on Google. But what can I say? It‘s hard...
We all know the term filter bubble and some of its implications. We might call social media a big confirmation bias machine. The first problem is that we are only connected with people who are mostly like us, meaning they probably share most of our cherished beliefs. So I don‘t even get to hear disconfirming data. The next problem is that I get rewarded, whenever we post something that confirms our group‘s beliefs. For this we will be instantly rewarded in the form of likes, retweets and positive comments. So our beliefs are being re-affirmed and strengthened all the time. If we want to change this, we might want to consider following/friending people on social media, who are different from us and have very different opinions/beliefs. I‘ve done that, and it‘s interesting but it can also be very exhausting.
These are some ideas I have about mitigating confirmation bias. I will soon publish another blog post on debiasing strategies in general.
If you want to dig deeper, you might want to learn about biases that are closely connected to confirmation bias. Here‘s a list I‘ve compiled:
P.S. Of course the belief that confirmation bias exists is also affected by confirmation bias. I‘ve at least done some googling and searched for phrases like "confirmation bias is not real", "confirmation bias is overrated" etc. I did not find any useful information.
Over the course of the past years I‘ve become more and more interested in cognitive biases, how they affect our work and what could be done to mitigate them. A couple of months ago I‘ve published my thoughts on groupthink. Today I want to share some thoughts about survivor bias. I believe it‘s hard to exaggerate the effect of this bias, but at the same time it seems to be relatively unknown in our community.
Never give up!
For whatever reason Facebook decides to show me these "motivational" pictures with "deep" messages every now and then. Yesterday I saw this gem:
Seems like good advice. It must be good advice to never give up, if this was the secret sauce for Coca-Cola‘s success, right? Of course it‘s not! It‘s pure survivor bias. Just as well you could ask a millionaire what her recipe for success was and then she would reply: "Quit your job, sell your house and your car, go to the casino and bet everything on number 12! That‘s exactly how I got rich." Of course that‘s bad advice, but unfortunately this is exactly how many business books and other guidebooks work.
We‘ll come back to this later, but first let‘s hear about a story from World War II.
Abraham Wald
The Hungarian statistician Abraham Wald was part of a group of geniuses, who helped the US win World War II with weapons of mathematics. The group was called "Applied Mathematics Panel", and there‘s a wonderful article on this group, written by David McRaney. One task the group was assigned to was to figure out how to improve the armor of allied bombers. It was clear they needed extra protection (too many were destroyed in combat), but it was unclear were exactly to put the additional armor, and protecting the whole plane would make it too heavy. So commanders examined the planes that returned from battle and looked at the bullet holes. It was easy to spot patterns (one obvious one was along the wings), so they concluded to add extra armor at exactly these places. Fortunately, Wald was involved in solving this problem, and his clear thinking probably saved hundreds of lives. He concluded, that the exact opposite of this had to be done: improve the armor at the places where no bullet holes could be spotted. His reasoning went like this: The planes we get to see here all have survived the battle, so they have done pretty okay. But all the planes who did not return from combat would have needed extra protection, because they had been hit at all the places we don‘t see at our planes here.
Survivor Bias
Wald‘s story perfectly explains what survivor bias is:
The logical error of concentrating on the people or things that made it past some selection process and overlooking those that did not, typically because of their lack of visibility. (Wikipedia)
It would be easy to smile at this story from World War II and just carry on. But survivor bias has serious implications for almost all areas of our professional and personal lifes. Here are some examples:
Ever heard someone say this: "The quality of XY nowadays is so crappy. I have a really great 20-year old XY, but they don‘t make these anymore"? I‘ve certainly said something like this many times. However, chances are that this statement is not true. In fact, the quality of many things has drastically improved over the last decades. They‘ve made a lot of crappy items in the past as well, but they all have disappeared, so that only the (few) good ones have survived. Or, if you look at it the other way around: They build good ones and crappy ones today, but we haven‘t figured out yet, which ones are the good ones.
We tend to believe that the cities of eg the Renaissance must have been really beautiful, and all the art of this time was extraordinary. This must be the case, because all the buildings and all the art from the Renaissance we get to see is very beautiful. But of cause we never get to see all the ugly buildings, paintings, songs etc., because they were torn down, cast away, not passed on and not talked about in history books.
Social media is a big survivor bias machine. Whenever I browse through my Facebook stream, I get the impression that all my friends have spectacular lifes, while mine is nothing but boring. Wherever I look: Happy people with a drink in their hands (one with an umbrella!), travelling the world, chilling at the beach in wonderful weather. At least two survivor biases at work here: 1) People only take pictures when the skies are blue and the wine is plenty. 2) People tend to only post spectacular stuff. They rarely post pictures of them being bored on a cloudy day. In the case of social media, events "survive" the processes of photography and social media posting only if they are interesting and colorful.
I do not understand a lot about mutual funds, but I stumbled on this paper, whose authors claim that "[a]lmost all prior mutual funds studies suffer from survivorship bias".
Ever heard of this anecdote? When cats fall from a balcony, they have a bigger chance to survive, when they fall from a greater hight! The data for this conclusion was drawn from the observation that cats that were brought to the vet had greater injuries if they had fallen from 1-6 stories, compared to cats who had fallen from higher than six stories. One explanation given was that whenever cats fall from a greater hight, they have enough time to spread their legs and use their body as some kind of parachute. Sounds amazing, but perhaps the more reasonable explanation for this phenomenon is this: Cats who fall from higher than six stories are rarely taken to the vet, because they did not survive the crash or, if they do, their owners don‘t find them or do not have any hope for cure.
These are just some examples from very different areas, and the list could go on and on. What all these stories have in common is that the conclusions we draw from the data are backward looking: We look at a set of visible data and conclude what must have happened in the past. That seems reasonable, but as Gary Smith claims in his book Standard Deviations: "When we chose a sample today and look backwards, we only see the survivors" and that those studies often suffer from survivor bias. From a scientific standpoint we should have done the following to conduct serious, forward looking research: Take 100 random cats, for each one toss a coin, throw half of them from the 3rd story and the other half from the 8th story and then see which group has the greater injuries. No, I am in no way proposing actually doing this, but you get my point:-)
Great Companies
Now what has all this to do with the Lean/Kanban community? I think one serious implication is best illustrated by Jim Collins‘ best-selling book "Good to Great". Collins compares eleven "great" companies and then finds a set of seven characteristics all these companies share. His conclusion is that he has found the recipe for success and if you use this recipe, your business will be successful as well. Gary Smith points out that Collins‘ approach is pure survivor bias, because it‘s backward looking. Collins only looks at companies that still existed at the time of the writing of his book. So we have no way of telling how many other companies did the exact same thing but went bankrupt anyway. Smith also points out that the eleven "great" companies do not perform that great anymore: Between 2001 and 2012, these companies combined did worse than the overall stock market.
Now if even Collins‘s work (who worked as a Stanford professor) is affected by survivor bias, we can be sure that many, many other articles and books are as well. So we should be very careful, whenever we read something about "the 10 things that all successful managers/teams/organizations do" or the like. Plenty of these writings exist in our community, as well. I am not suggesting that these stories are useless. I find many inspiring ideas in them, many worth trying and adapting. I just disagree with the (implicit or explicit) conclusion that we, too will become successful by doing the same thing.
This is a translated and modified version of my article "Wie bei Kanban die Post abgeht", which was published online at Projektmagazin in February 2015. If you prefer German, you can find the original German article here.
_____________________
Once I was with a company, that had freshly started using Kanban. Peter, the CEO was happy with what they already had achieved and proudly presented their board to me. Indeed I was impressed with how far they had come in such a short time without having much external expert support! The board roughly looked like this:
Sipping our coffee, we had a chat about Kanban in general and their board in particular. After a while I asked about the problem with queues in the post office. My conversation partner looked in me in disbelief, so I started from the beginning.
"When I was a kid", I said "every post office was organized in a way that each counter had its own queue. If you had a package to ship, you had to decide for one of the queues and line up - of course it always was the wrong choice, because it turned out that all other queues were serviced much faster. Today, post offices are organized differently. Usually, you‘ll only find one central queue for all counters. Only shortly before its your turn, you‘ll be directed to the next available clerk. Why is this? This system offers at least three major advantages:
Predictability improves significantly. In the old system, it happened quite frequently that I had lined up in a specific queue only to discover later, that the person in fron of me had a very complicated issue he wanted to discuss with the clerk. Bad luck! The same thing happened, if my queue was served by a trainee, who (of course) was way slower than his/her colleagues. Certainly these things happen in the new system, as well. But here trainees and complicated requests have different ramifications, because the delays are split amongst all the customers, so to say. This is called "using pooling to buffer variability". Needless to say that this improved predictability and unified wait times lead to higher customer satisfaction.
The new system is way more reliable. Imagine one of the clerks needs to leave his/her counter, because he/she is needed elsewhere. In the old system, this had caused severe disturbance, because the queue now had to be distributed amongst the other queues. But by what mechanism? Should the customers just line up at all the other queues? And wouldn‘t that be unfair, because they had already waited in the disintegrated queue? In the new system, it‘s still annoying, when a counter is being closed. But the impact for the overall system is rather low. Nobody has to be redirected. The wait time for all customers gets a little bit longer, but nobody feels treated unfairly, because the additional wait time will be evenly distributed amongst all customers.
The new system is less stressful for the clerks. In the old system, every clerk had to serve each of his/her customers, before he/she could close the counter and leave work. Everyone had "own" customers and should have felt responsible for them individually. In the new system, all the clerks work as a team and share responsibility for all the customers. If someone is having a rough day (or difficult customers), his/her team mates will compensate for this automatically."
Keeping an eye on the queue as a whole
During my little monolog, Peter had been nodding a lot, so ha seemed to agree with all this. After I had finished, he directed his gaze to the board again and started thinking out loud: "In our context, the tickets on our board are the customers in the post office, each with different requests. Our team members are the clerks, who deal with the requests. A finished ticket is the equivalent of a served customer (hopefully a happy one!) At the moment we assign people to tickets right from the beginning, everyone has his/her own queue and is responsible for dealing with it. This means we are working in the old post office system. When I think about it, I have witnessed all the disadvantages you have just described. So for us, too, one joint queue should be a much better solution. But for this our board had to look differently."
He grabbed a marker, went to a nearby flip chart and started to sketch a modified version of the board.
For the columns "To Do", "Next" and "Done", the swim lanes had disappeared. They now only existed for the activity columns "Dev", "Test" and "Deploy". It seemed like a small change, but I think it was a big step in the right direction towards more flexibility, collaboration and knowledge sharing.
Holes in the input queue
I then nudged Peter a little bit more and asked: "What about holes in the "Next" column?" Again, he seemed to be puzzled, so I elaborated: "I guess, that the tickets in the "Next" column are prioritized by some sort of mechanism that makes sure the tickets with the highest value (or best value-cost-ratio) are on top of the queue and the less valuable ones are at the bottom, right?" Peter nodded, so I went on: "Now what happens when, let‘s say Stefan is done developing a ticket and wants to pull the next one from the "Next" column? Of course, he should pull the one at the top of the queue." I grabbed a marker and wrote "1" on the top ticket, "2" on the next one and so on. "Unfortunately, I am pretty sure that in many cases that will not happen. And the cause for this is specialization. That‘s probably the reason why you have the swim lanes in the first place. So if ticket 1 requires a specific skill, which Stefan does not master, he will leave the ticket where it is and pull ticket 2 instead. Now after a while Inken wants to pull a new ticket. But again, she‘s lacking the required skill for ticket 1. She doesn‘t feel comfortable pulling ticket 3, either, so she pulls ticket 4. Does this scenario sound realistic?" Peter nodded his head thoughtfully. He knew where I was getting at and changed his sketch of the board again. At this point it looked like this:
Before I could go on, Peter started speaking, and he said the exact same thing I was about to say: "This is a disaster! From a business perspective, these "holes" are an absolut no-go, because they mean we are delaying the most important tasks/projects, while we are working on less important ones. We cannot have this!" While he paused, I explained, what I had seen many times before: "Yes, I agree. But here comes the catch: If you want to make sure the most important tickets are always being worked on, the company has to invest in this new way of working. And depending on the degree of specialization, the technology you use, your code base etc. it might be a quite high investment. The board helps, because if designed appropriately, it will show you how far you‘ve come at any time. But of course, the sole visualization will not be enough. You will probably have to train your staff and collaboratively develop policies that make sure you gradually improve." "Of course, I understand", Peter said (and he looked a little bit depressed). "I will start working on this tomorrow. Do you have any other advice on how the board can support us in this effort?"
Some more ideas for improvement
I paused for a moment and thought about this. Then I replied: "In my experience it‘s mostly unfavorable to have swim lanes (or columns for that matter) named after specific people, because it tends to perpetuate the current division of work. It might be a good idea to have the specialization written at your swim lanes instead. The specialization might be a technology, a project, a product etc. And if you decide to do so, it might be a good idea to have avatars for each team member to indicate who‘s working on which item. The advantage of avatars compared to swim lanes is that they are more fluid. It‘s easier to move avatars from one item to another. And probably even more important in your case: you can easily have two or even three avatars on the same ticket. And that‘s exactly what you want: several people working on the same task, so that the specialist knowledge can spread." Again, Peter started to change the layout of the board, and now it looked like this:
I finished my thoughts by throwing a couple of more ideas at Peter: "In order to make more explicit, what you want to achieve, you could introduce a policy that goes like this: In every column there have to be at least two different avatars at any time. You could easily track your improvements by counting the number of tickets on which two or more people have collaborated. It might also make sense to limit the number of avatars per person, to encourage collaboration across specializations...But I feel we get carried away. So before going any further, I think you should gather your team and explain to them what you want to achieve and why. I am sure they have plenty of ideas how to get there themselves!"
Reflecting
One of the biggest benefits of Kanban is that it focuses on queues. Through the board we can gain visibility of the queues. And by limiting work in progress, we actively manage queues and thereby improve flow. Managing queues is a powerful, yet relatively simple way to decrease lead time dramatically. Of course the board can only show us improvement opportunities, if we are willing to look at them and if we know where to look. So the board should be designed in a way that it shows queues immediately. Ideally, this visualization is accompanied by metrics, which show the impact of (often growing) queues over time.
In my experience it‘s always a good idea to have a closer look at the division of queues and ask questions like: How many different queues do we see? Why are they separated? What would be the advantages and disadvantages of merging several queues into one major one? How high would the investment be?
I am not saying it‘s always a good idea to have one common queue (the modern post office system). It‘s mainly a tradeoff decision, which should be answered considering different factors like risk, short-term costs, customer and employee satisfaction etc. In fact, many post offices still do have a separate queue for banking issues. This probably makes sense, because it would be very costly to train every clerk in banking tasks.
Another interesting point is to look at this problem at different levels. In this post I‘ve discussed the issue of having individual specialists, whose work is divided by separate queues. Merging these queues might cause more collaboration and spreading knowledge. The same logic applies at a team or even department level. For instance, in product development it‘s worth asking: Do our development teams work on separate queues or do they pull items from a common queue? And again: What are the advantages and disadvantages? What would it take to change this? At which cost? And then at an even higher level: How do the queues look like for our departments and business units? Would it make sense to have a common queue here, as well (at least for some kind of work)? To get a better understanding of these different levels, I find the concept of Kanban Flight Levels as developed by Klaus Leopold very useful.
What are your experiences with separate vs. common queues (and the post office)? Please leave a comment!
