Interview: Behavioral biases in product management with Markus Kanerva and Eva Höglin

We unpack five common situations in product management and discuss what behavioral biases present in the situations can lead us astray. We then prescribe what software professionals should do to avoid those biases.

The speakers are Eva Höglin, Atlassian software and product management expert from Riada - now part of Eficode, and Markus Kanerva, a behavioral consultant and a senior lecturer in Laurea University of Applied Sciences.

Markus (00:04):

You take a project team A and project team B. So project team A is better at estimating how much time the project will take for the other team and vice versa. This is something that maybe you could apply to, instead of planning your own projects, so you ask project managers or project teams that are doing pretty much the similar thing to look into your project and make the SketchUp.

Lauri (00:33):

Hello and welcome to DevOps Sauna. Norman Kerth, who is known for Project Retrospectives has said, "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." The problem is that being incomplete is something inherent in being a human, and this incompleteness permeates our everyday work. One way this is seen is through what's called behavioral biases, irrational beliefs, or behaviors that can unconsciously influence our decision-making process.

Lauri (01:14):

We invited Eva Höglin, Atlassian software and product management expert, and Markus Kanerva, a behavioral consultant and a senior lecturer in my alma mater, Laurea University of Applied Sciences. It's a fascinating journey to how we think and behave and what we can do about it. Thank you, Eva, thank you, Markus, for joining.

Eva (01:39):

Thank you.

Markus (01:40):

Thanks for the introduction, Lauri.

Lauri (01:42):

I remember when we had this initial talk with Eva about this topic. It almost came up by accident, we were having a chat with Eva on sporadic things like, "Okay, what should we talk about? And what is Eva's area of expertise?" And then we sort of found out that both of us are interested in behavioral economics, and Eva has been doing her lessons in some other parts of literature and I have read my books. And then we figured, "Hey, how about we do something like that?" And for a long time, we were thinking what the headline would be. But today we are talking about behavioral biases in product management and what to do about it. And the audience who are listening to this, don't worry about if behavioral bias just doesn't ring a bell, it will become evident in the course of time.

Lauri (02:29):

So first is to say that behavioral economics is much more than just biases. But bias is probably the approachable way because we can make it easily understandable what kind of glitches people have in their way of thinking, and then how to make people aware of those misconceptions and maybe how to do something about them. And our today's episode has been organized in such a way that Eva has kindly identified real-life settings, where she has seen those biases or that there is a possibility that the bias can completely lead the situation astray. And then we are going to have a discussion about that, and Markus, naturally, you're going to bring in your subject matter expertise, as you said, not from software engineering, but from the behavior of people and organizations.

Lauri (03:22):

So without further ado, maybe we go directly to challenge one, which here is labeled as Judging on the Optimal Set of New Products or Features. And I'll hand it over to you, Eva, to introduce that in detail.

Eva (03:37):

Thank you. And those five challenges, they actually follow a kind of... It's starting with defining the products and then it goes along with implementing and delivering products. So it follows the software delivery life cycle. So we're starting when you're in step one of this journey. So we have the busy product manager and he's trying to get the new product roadmap ready. But as we all know, to become a manager, you become increasingly busy. So there's back to back with the important meetings, he's rushing. I mean, he's experienced, he has done this plenty of times, so he's tweaking and adding and trying to get this product and features as best as he can.

Eva (04:25):

And this goes on for a number of iterations, maybe a couple of years. But then suddenly there's a kind of disruption in the market and the manager realizes, "Wow, the competitors, they are rushing already along another path, and I'm here. I have just followed downstream and now I'm more or less alone here." So I think that's sort of what I've seen happening. So what could be behind this kind of behavior?

Markus (04:55):

Yeah. Thank you.

Eva (04:57):

Where should we start? Maybe give floor to Markus first, and have his stream of consciousness around this.

Markus (05:06):

Yes, it's actually very interesting how you always want to add new features. There's a funny story about a LEGO motorcycle which had 15 parts in 1988. And if you take the similar LEGO motorcycle today, or at least in 2013, it had 29 different parts. This means that back in the late eighties, you were able to put the pieces together without any guidance or notes. But today you need to have some kind of instructions that you can do that. You are definitely not alone with this type of, we could call it a sickness kind of, where you just keep on adding features and features.

Markus (05:58):

It's quite natural because you don't want to... You see what your competitors are doing, and they're adding features and you work to keep up with the race, so you end up actually with pretty much the same product that everybody else is doing. And that's quite natural because we don't want to have a feeling of regret. We don't want to regret that we missed out a feature there that somebody really wanted there. It's also very natural that when you get feedback from the users, just add those on because you want to be customer-oriented or user-oriented. But by doing that, you actually might end up doing something that is not anymore user-centered or user-orientated. Therefore, it's very, very important that you have very good focus on what is needed.

Markus (07:00):

Back in the days, Henry Ford said, or it has been said that he told that, he had asked his consumers before he started manufacturing cars, what the consumers wanted. So they would have answered, "Well, we would like to have faster horses." So they didn't have any idea of what there was for them and what was available. So in that sense, the product manager should also have a clear vision of what he or she is doing. So here are just some thoughts about this challenge number one.

Lauri (07:41):

Yeah, I remember this, I think it was a cartoon where somebody had lost their keys and the guy was walking back and forth in the street and looking for the keys. And he was looking at those keys under a particular lamp post in the street because it was nighttime and it was pretty much dark. And there was one lamp that was lighting a certain region of the street. And then somebody came up to him and was like, "Okay, what are you doing?" And he said, "I've lost my keys." Then the stranger asked, "Do you know if you lost them under this particular lamppost?" And he answered, "No, I didn't lose them here, but there is enough light so I could search for them from here."

Lauri (08:26):

And I recalled this cartoon when I was listening to this description where maybe defining the optimal set of products is done within the realms of what we know, rather than within the realms of what is necessary. And therefore the visibility becomes even better on a smaller and smaller business area where eventually you have perfect visibility on absolutely nothing. Something like that. Have you seen something like that happening in product management?

Eva (09:02):

Yeah. I mean, that's sort of what I've been seeing. Like you're doing things in small steps, and you set increasingly small steps and you're very busy. So it's very human that trying to define something completely new, it becomes like an uphill battle for you within your organization. And as humans, I don't think we like to be alone. We want to belong to a group and do what everyone else is doing, subconsciously.

Eva (09:31):

I'm thinking about the car industry and the electrical vehicles that we see now, the surge in demand, and everyone wants to go there. But there was a lone player and I think, many didn't think it would succeed or go that way, and they didn't want to change their big... I mean, developing hardware and tools for the product factory lines and production. It's a huge shift to change from diesel or gas engines to electric vehicles, but then suddenly everyone needs to go there. So, that kind of... I think you need to dare to go uphill, dare to surround yourself with people that don't always agree with you. And even if it's harder, you don't really have the time, but in the end, it will open your eyes, I think, so you don't end up with the head stuck in the sand too long.

Lauri (10:29):

So, love your products, but be honest about what they are missing out.

Eva (10:34):

Yeah, yeah. Exactly. And I came across an interesting Act as a Startup. I read an MIT article about it, and I guess it's going to be very hard for big corporations. But that was one view or solution that I was reading about, that maybe create a separate organization that is small and they get the task to go this different way, more daring way, instead of trying to shift the whole big company.

Lauri (11:06):

Yeah. There's a cultural part to the dimension to this where I remember, I think it was the former CEO of KONE, Matti Alahuhta, who said that he always thanks people who bring bad news or sad news, which would be endorsing a culture where it is important that everybody knows about things which are not right, and therefore people would strive to share that information which is not right and then you would be earlier on fixing that. That was something that came to my mind.

Lauri (11:37):

Now, something Markus that also came to my mind, which I think you have investigated, is then the prospect theory from quantum monetarists which basically says that the negative impact feels worse than the equivalent magnitude of positive impact. And I was thinking, from a product management perspective, if we follow this line of prospect theory, which is that if you haven't achieved what you are striving for, every improvement feels better than if you have already achieved what you are striving for and you're just going above your baseline. And if that is true, then the question follows that why on earth product management then strives for additional features once they have satisfied the sort of minimum viable product, or like a good enough product, if you, Markus, can follow my line of thinking here?

Markus (12:31):

Yes. And I was thinking about marketing and brand marketing. It seems that every time there's a new brand manager for a certain product, brand managers want to change the brand image. And that's very strange, but understandable behavior because you want to leave your mark. But from the consumer perspective, it's very irritating that you've learned to visualize how the product looks, and you go to the store, and then all of a sudden the look changes and you can't find them there anymore. And therefore, I have to say that I really admire those brands that are sticking with their old designs, and I think they are doing very, very wisely there.

Markus (13:23):

So somehow you want to leave your mark. I could imagine that the product manager wants to leave her mark and also to kind of show that, "I'm important. I've been adding these things. I've been doing all this stuff." We know from the World Bank, those types of development banks, the managers that just keep on sending money out because that's how they have been ranked, how much investments you give, or how much aid you're handing over. So, there's no incentive to cut back.

Markus (14:01):

So maybe you should look into the incentives of product managers. Are the best product managers those who add features, or is it the concept that you have, or the ones who are doing nothing? So it feels kind of strange that the best product manager was the person who didn't do absolutely anything with the product. Just stick with all the old features and so-so. I guess you're getting my point.

Eva (14:29):

Yeah. I mean, that's definitely an interesting view. And also thinking about sometimes maybe also we have a lot of engineers and especially, of course, within software and hardware development. And maybe they think, I mean, they're technicians, they love new technology and techniques and maybe they overthink what people would like in terms of technology. And maybe people want something stupid. They don't want tools to improve their business performance, they want stupid games instead. I mean, I'm thinking that you should also use as...

Eva (15:05):

Even if you shouldn't just listen to the users, as you mentioned with Ford, that they wanted a horse-driven car, but still try things with real-use techniques as user personas. Try to imagine who are our users and try early testing of your ideas on real people because maybe they will hate what you are suggesting if you put it in the hands of them. So, as we are talking about today, people don't behave rationally so they don't want this super-technique feature, but they want something funny.

Markus (15:40):

Well, it's also very understandable that engineers want to add things. So I would say that we people, as a human race, we like to play, we like to invent things, we like new things and that's good because I enjoy my car much better than I would enjoy a horse. And in that sense, there needs to be room for going forward and adding features, but having to focus on the user behavior and why we are doing things. So in these situations, you have the correct starting point, but somehow things are starting to go wrong when things are actually pretty good. So you need to have this kind of sense of knowing that when we need to shift a bit again and not just being incremental anymore.

Lauri (16:43):

I remember Daniel Kahneman was talking about this phenomenon that when you ask a question from somebody and if they don't understand that question, then they will replace that question with an easier version of the similar question that they can respond to. And then they answer that question instead. And that can be very, very treacherous for product management who want to get realistic feedback from the people. And people are genuinely trying to do their best and trying to answer the question, but they just are not aware that they are not answering the question that was prompted.

Markus (17:16):

And if you then turn that thing the other way round. So a lot of the time people are asking a whole different question than what they're actually looking for to get an answer. So like we go and ask, "What are you doing tonight?" instead of saying, "I would like to go play tennis with you." This is a very simple example, but just stop and think, what are your questions at work? What is the information you're looking for? And maybe you should really think more, how you pose your questions, like what is your real question? Not just saying that you should go directly to the point, but saying that just think about what you want and what you're really asking. So I think that could make the communication a lot more effective as well.

Lauri (18:16):

That's a wonderful segue for our second challenge, where we put our hypothetical product manager in the role of trying to convey the product roadmap to their teams.

Eva (18:28):

Yeah, first step is really tying into the next step then. We now have the challenge of producing the roadmap. And then we come to the manager who is really enthusiastic and comes up with a really good roadmap, and let's bring this to the teams who will implement this. And you tally it, I mean, you have all this information in your head, you gathered throughout the period. You prepared the roadmap and you tell it and you maybe bring a presentation you have prepared or specification.

Eva (19:01):

But then you're really, really surprised because people have only picked up a fraction of what you're trying. I mean, all the information that's in your head, it's not what's coming out and it's definitely not what they are picking up. I've seen this very, very clearly. So this is a real challenge, I think, that people have limited how they pick up what your information is. So that's the next challenge.

Markus (19:28):

I'm actually jumping to the solution for that in a way because what you should be doing is keep on repeating the message over and over again. So we tend to think that after we've said something once or maybe twice, we think that the others understood what we meant or they are able to recall it perfectly. So you need to maybe not use the exact same words, but keep on repeating what is your main message and what is your plan.

Markus (20:07):

The other issue here could be that if people were not part of the solution or if they were not part of the plan, so they might behave in a way, what we can call, Not Invented Here By Us. So it's pretty self-explanatory. But if somebody else came up with the solution or with the plan, we tend not to stick with that plan because we were not part of creating the plan. Back in the day, I had some ideas for a startup and I discussed it with some of my friends who were working in startups and I asked, "So should I keep the idea with myself or discuss it with other people?" And the advice that I got was this, "Just go and discuss and talk. People have their own ideas that they love. And they don't steal your idea because they did not invent the idea."

Markus (21:12):

And afterward I came across some studies about the topics that dealt with this Not Invented Here, in fact, and I was like, "Yeah, okay. Now I remember what my friend was telling me." And I think that's true, but we still tend to think that somebody will steal my idea. And I think this is Not Invented Here, we can use this bias as some kind of insurance that we go forward with our ideas, and share those, and get some feedback, and those ideas will become even better.

Lauri (21:49):

You could again, flip the table and ask, what could a product manager do to encourage people to adopt their idea? Are there some psychological devices that they could consciously employ to circumvent that Not Invented Here?

Eva (22:11):

I'm sort of thinking, and it's something I read in a book, but it's like, you have to evoke their emotions. I mean, I've seen film clips where you ask people to watch a number of players in a football game, whatever. And then, behind, a human dressed as a gorilla is there as well. And they don't see it, they're focused on looking at something that they were expected to look at. So they don't even hear or listen to anything else.

Eva (22:41):

So if you could make them snap out of it and don't jump to conclusions because maybe they hear the start of what you're saying, and then their brains trying to find, "Okay, what do I know about this?" and then they jump to a conclusion about something they believe is what you're trying to tell, but you're trying to tell something completely different. So, the emotions get very vivid, the energy, and as you have obviously said, Markus, that they should have been part of it in the first place because then they invest in it emotionally and feel like it's their own idea, maybe even. So that's something I have been thinking about a lot.

Lauri (23:21):

I was also thinking how to, it probably sounds naive when I say that, but how, instead of telling what you have in your mind, how do you structure that information sharing in such a way that people discover it themselves. So let's suppose for a moment that you are a product manager and you have your backlog and you have like so-and-so many items in a roadmap. And you probably have even built your... Really, it's like this release is going to include these features. But how about you would turn it around and go back to your team and say, "Okay. You have to define what's in the release." Even though the fact is they are not, but purely for the sake of engagement and buy-in and commitment, it's like, "Here are the features, go figure what they mean. Here is everything you need. Work together."

Lauri (24:10):

Working in smaller groups and then put them in the prioritized order, for instance, because in order for somebody to put something in the prioritized order, for the sake of argument, it requires them to comprehend them in a relatively deep detail before they can make any decision on whether that is more important to that. And then, you probably get your teams back and they say, "Okay. We think this should be the order." And, "No. We think this should be the order." And then the product manager might, well, in the best case, they might even learn something new that they hadn't been thinking before. But again, I'm probably speaking against my better knowledge, maybe something like this is already a product management practice.

Eva (24:50):

Yeah. I mean, I'm thinking about the big room planning practice in SAFe. I mean, I think that's more or less the best part of SAFe that you bring people together because normally, maybe many of those people, software industry, they sit with their headset on and they code and they do their stuff, but bringing them together forces them to communicate, and human direct interaction is much more strong to get people, I think, to listen and pick up information. And in such big room planning, you have the product managers presenting, so I think that brings more energy as well, instead of just getting something sent out, and you're supposed to read it yourself. So that can be a challenge, I guess, now with the remote PI planning, we see it's very important to not let go of that important part of human interaction and connection, I think, in that setting.

Lauri (25:53):

Hi, again. Changing the way of working in large enterprises is challenging, especially when it comes to habits and culture. In her talk, Eva refers quite often to SAFe, Scaled Agile Framework. If your teams want to become better in product management, or if you want to adopt values, principles, and practices of Agile framework in your company, I'd like to refer you to Eficode Consulting and Academy Practice. You can find the links in the show notes. Now, let's get back to the discussion.

Lauri (26:25):

I remember one study, which was completely unrelated, but it was when you take people who participate, basically, they go to a concert to listen to music, live music performed by the original band. And some of those people have listened to the album before, and they know that music from the album. And then some of those people hear it for the first time. And then in the live performance, there are going to be glitches in the performance that don't exist in the album. So the recording is inevitably more perfect than the live presentation.

Lauri (27:02):

And if you then look at the reaction of those people, and I don't remember which was the method that they used, but you could basically observe their reactions as to the notes that were not in tune or mistakes in lyrics, which would be obvious or anything like that. Those people who had heard the album before did not react to those glitches in live performance, as strongly as those people who didn't. The interpretation was that they knew what they were expecting and the information and the memory that they had from the album, sort of real-time mixed with their perception of the live performance.

Lauri (27:47):

And if that is true, then it follows a question that if you want to convey something, maybe you should just talk it through and record it in a half an hour conversation, like a monologue. Turn on the record and say, "We are going to have a meeting next week and we have an important decision to make. So let me just go on stream of consciousness, explain what we're going to do." And then just let it come up. Let it come, record it, and send it to people. And when they take their dogs on a walk or whatever, emptying the dishwasher, they can listen to your monologue. And when they come to the meeting, they have already been exposed to the substance and they have been able to do sort of unconscious deliberation or anything like that. They would be able to approach that content in a different way. And given the technology, I mean, it's incredibly affordable to do something like this. Everyone has the mechanics to do it. Markus looks like he's thinking a lot now.

Markus (28:43):

Yeah, I'm thinking about it. I'm just thinking that sounds basically a great idea, but I wouldn't want to spend all my evenings walking my dog and listening to my boss explaining something that he will explain the next day. So there could be a - reactance process starting up and I might end up doing the absolute opposite thing. But yeah, theoretically, yes, it could work perfectly.

Lauri (29:20):

You could test that with your student.

Markus (29:22):

Yeah. Yeah. That's true.

Lauri (29:24):

So moving onto challenge three. As you said, Eva, we are advancing in product management. So underestimating how much time and effort it will take to build new products and features.

Eva (29:35):

Yeah. I think this is the bias I'm least susceptible to myself. So maybe this one is what I see most clearly happening because I'm a time pessimist. I always prepare for extra time and put a margin on everything. And if I think it takes one week, I say two weeks to be able to for sure deliver and not disappoint anyone. But everyone, they are really underestimating how much time it takes. I mean, as you said previously, Markus, that people like to do new things, they like to innovate.

Eva (30:12):

They jump on these new features and they tell the product manager, "Yeah, it'll only take me a day to do this. I mean, this is really something that's easy to do." And then, "Hey, do you really think it's just one day?" I'm always asking, "You know this will affect these 10 existing features. You know we need to do this API integration or this documentation, and we need to build the regression test or rebuild whatever. Would it only take eight hours or maybe not?" And then, next feature, same thing. Then I start, "I don't want to repeat this again, but do you really think it only takes one day to do this?" But because the product managers, they want to believe them because we all know it's very expensive to build new products and it would be very nice if it was quick and cheap. I'm really surprised that it happens all the time with the same team repeating and repeating. So, Markus, do you have any thoughts about this bias?

Markus (31:15):

Well, I think this is something that we come across in our everyday lives when you read the news. So we always get the news about a huge infrastructure project that took many years longer than what was expected. And it cost hundreds of millions of euros or Swedish krona more than anybody ever imagined. So sometimes we get news about the project that was finished on time, but that is huge news. And you have to deal with that pretty much every day in your work when you have a lot of small projects and they're not that small, in many cases too.

Markus (32:00):

So this is a very, very common phenomenon and Lauri mentioned Daniel Kahneman, who was awarded the Nobel Prize in Economics 2002. And he actually tells a story about how he was part of a team writing a textbook related to education. And he had been studying how people plan, how they spend their time. And however, this group of writers, they were not able to plan correctly how much time it would take to finish the book. Well, what actually happened was that they never finished the book, but what the researchers have learned is that you take project team A and project team B. So project team A is better at estimating how much time the project will take for the other team and vice versa. So this is something that maybe you could apply that, instead of planning your own projects, or you ask a project manager or project team that are doing pretty much the similar thing to look into your project and make the SketchUp.

Markus (33:19):

And there's this bias called overconfidence and also overoptimism which explain why this happens. So we are overly optimistic in many situations, how we use our time but in also many other situations. But I think that is very good for humankind that we have been optimistic in several situations. And then if you just take the base rate for any startup and apply that information, we would actually have zero startups. So we need to have this optimism always within us.

Eva (34:04):

Yeah. I mean, I like what you say there because, I mean, we have a bridge between Sweden and Denmark and I'm sure it wouldn't have been built if we had looked at the original time plan and budget. So, I mean, I really agree with you, sometimes you just need to go, but sometimes maybe you need to... I mean, some practical solutions I've seen is that, if you look at the velocity of the team, what has been the historical, what have they been delivering in the past in general, how long time does it take for them to build a feature?

Eva (34:35):

So looking at historical figures could help you to overcome this because sometimes you really need to get things done within a timeframe and also to apply a kind of budget. If we believe this is a business case for this feature, this is how much we will earn, and we believe it will take a certain amount of time to do, if we do triple that time, it will no longer be worth doing. So then it's good to have very, very frequent communication back to the product manager from the team that, "Okay, we got into this technical difficulty and we think it will be twice as expensive. Should we continue? Or should we just..." Maybe it wasn't such a good idea then, depending on the cost.

Lauri (35:25):

Yeah. And countering that, I mean, there is a pure financial way of countering that, there's the sensitivity analysis. Imagine that you spent this much money and time on this and imagined that it would yield this kind of returns. And if you estimate a pessimistic -20% figure on the returns, and then you are equally pessimistic on the other side, then would it still make sense? So basically, you can look at how badly a project can go for it to still make sense. And then look at, okay, could you live with those numbers?

Lauri (36:03):

And I remember another unrelated example. There's this Net Promoter Score figure, NPS, which every one of us have been exposed to. All the companies always want to ask, "In the range of 1-10, how likely would you recommend this company?" And people are generally awful at estimating their future behavior. They're much better at estimating their past behavior for the fact that it has happened. So you could ask, "Why on earth would anyone ever want to estimate their project?" You should rather ask, I think either of you said, "Given something like this happening in the past, how long did it take?" And then you would have to come up with accurate evidence of a similar project rather than trying to put your best effort down. But I think it generally has to do with the fact that people are pathetic at estimating their future behavior.

Eva (37:02):

I mean, this is at the core of Agile development, as I've seen it and experienced it throughout the years because I really believe in those principles that you don't plan or estimate a big project in advance if you can avoid it because you want to get started because it's when you get started, that's when you get into the really difficult parts. You cannot imagine that in advance. I mean, who knew about this pandemic or who knew about any other big disruptive happenings? So your plan, even if you have a forecast and a plan, don't expect to be able to stick to it because you need to be prepared to respond to changes in the environment.

Eva (37:44):

And I'm going back to the electric vehicles that the same or sibling company that builds the rockets. They actually build these rockets in iterations. They build it, and the first iteration, they let it go off, and then it comes down like rapid, unplanned, disarray or disassembly, as I learned it is called, and it just crashes. But they go the full end-to-end cycle, even with a space rocket. So I think we should be able to do that with software, iterate, frequent feedback loops, get started. Then you will get the feedback and you will be able to adjust and not do something big and try to plan, very rigid plan in advance.

Markus (38:34):

I agree. I agree, but I would also like to remind you about an effect called the sunk cost effect. Now, this is kind of an evolving process where you start with your project and you plan, "Okay. We will put 10 million euros for the project and it will last two years." So after two years, you've spent 10 million euros but you haven't finished what you were planning, and you think, "Oh, we've put so much money and so much energy, and we are very, very, very close. So let's go for another year." You go for a third year and you put a couple of millions there and well, the features things and all this what we have discussed happened. And after the third year, it's like, "We got so close again, but we really need to put another million here."

Markus (39:25):

What happens is that at the end when you get the thing done, hopefully, it took double the time and double the money and maybe you should have stopped after year two and start doing something else, which maybe would have been financially a better deal and more fun for everybody because you are not just working on the topic year after year.

Markus (39:50):

And this is the one reason why sometimes it is wise to have a new CEO because the new CEO, if it's coming outside of the company, he's not in love with any project. So he can stop financing those projects where you have this sunk cost effect. In those situations that actually can be a wise, wise move. But in that sense, you should take a pause and look how much you've spent and really think like, "Okay. Should we stop doing this? Is it really going in the right direction? Should we use these resources for something else?" I'm pretty sure we all have experienced this type of project. We all have.

Eva (40:41):

Yeah, definitely. Yeah.

Lauri (40:44):

Yeah. Great. Moving on to the last challenge, which is a large set of dependent teams, large-scale cooperation, and complex processes slowing the deliveries down.

Eva (40:57):

Yeah. This is something I've, in the recent years, been thinking a lot about because I've seen organizations, I've been part of them myself. I mean, you follow the mainstream, you scale your Agile way of working, your platform is state of the art, loosely-coupled services and you practice DevOps, you do everything right based on theory and practice, but still, there's so many dependencies. You get stuck. You get tangled in team A needing to deliver to team B who need to deliver to team C, et cetera, and then it's just slowing down. So this I think is a big, big challenge, as we see today.

Lauri (41:47):

What in our behavior goes wrong when this happens? Is this a result of a system, or is this result of people's behaviors? And if it's the latter, then what can we do about it?

Markus (41:59):

So something that happens very frequently when you have a lot of different parties involved, is that for instance, if you know there are different teams looking for some bugs or something in the system, so you're not really doing your best because you have the backup who will deal with that. And so if there are a lot of responsible teams or people, you may end up thinking that, "Well, I don't need to really put my 100% here because I know the other person is there and he will check this."

Markus (42:41):

So actually, it could help to reduce the amount of people on both teams, so then you really have to step up and do your part and be really, really careful that... I'm not saying that you should really have too few people because you really can't see all the mistakes there, or you can't predict everything by yourself, but finding the balance. Adding more participants, I don't think that's always the right solution, but somehow that's what we think very often, "Okay. We are running late. We need more people." Then we are just adding the complexity.

Eva (43:27):

Yeah. So I'm thinking, one solution that I see is to try to keep things as simple, as stupid as possible. I mean, just use these complexes if you really need it, can it be simplified, always try to simplify things. And I'm experiencing over the years I've, myself, become better at communicating with people. I also used to be a more developer kind of person, liking to sit by my own desk and solve problems, but I realized you have to get up and talk to other people, especially in other teams because you can find a very simple solution for how to do things together.

Eva (44:09):

But I think that if you have so many dependencies, it requires so much communication, which I believe most people don't feel comfortable or they don't really see the need to communicate as much with other persons as is needed in that kind of setting. So I think trying to optimize the flow of communication among the teams, I think, could be one solution. Like how do you organize the human communication between the teams, not just the technology and the tooling?

Lauri (44:44):

Yeah. I'm thinking whether communication is part of the solution or if it's part of the problem? And of course, it's not either-or, but sometimes. Because oftentimes when we don't know what's going on and we try to fix it, the knee-jerk reaction is we need more communication, isn't it? Think of any workshop where you have come together with your colleagues to spend a day and like, "How do we become better?" Then almost invariably somebody comes up with the suggestion that we need to be better in communicating.

Markus (45:14):

It's about the information and how much information you have. We are getting way too much information every day, but we have a tendency to think that my piece of information is very important, "Well, it's coming from me, so this must be very important." But we don't realize that the other end doesn't think the same way. And so I would advise to really stick with just the necessary information.

Markus (45:47):

We know the type of person in every organization who wants to know everything about everything. And they think if they don't know everything about everything, the culture is not opening up and they always call for more openness and all that. But, a normal person is happy to have just enough information, but this is not, I'm not solving what is the right amount of information here. And then you have to really have trial and error and discuss and ask like, "So did you get enough information? What information are you missing? What you didn't really need?" and so on, so that you can really find the balance.

Eva (46:31):

I mean, I have two thoughts here. And one thing, I mean, what I like about DevOps and that sort of how-to, I mean, it's the automation part. Sometimes I feel like it's better to try to automate as much as possible because then you don't need to talk so much about it all the time. It sort of eliminates the unnecessary human interaction or intervention wherever possible, to automate.

Eva (46:56):

And the other part is that I've frequently seen that there might be one team member in one team, they are stuck and they are frustrated because they didn't get what they expected from another team, but they haven't actually talked to the other team. So I've just picked up what they are lacking, I went 10 desks down the corridor, and then I asked the other team, they said that they didn't get this and this and this, and they got stuck. "Can you do it this way instead because it will be much, much smoother for them?" And then, "Of course." I mean, it's not about talking so much, but just making simple checklists or things like that. I've frequently seen how much that can help and I'm honestly surprised that it was so easy that I could just go and help them ask another person, "What do you need to be able to deliver efficiently?" And why didn't they get up and do that themselves?

Markus (47:54):

Back in the days when we were all working in the office environment, hopefully, we will do that, at least partly in the future, I remember maybe that's about 10 years ago, there was an idea about having an email-free day, once a week and kind of forcing people to walk to their colleague and really talk about the matter instead of just writing your stuff on your email. And so maybe thinking about the communication ways, there's tons of different communications platforms that are evolving all the time. So it seems that we still really haven't found the way that works best for achievements, how to communicate. We seem to be going back to the hieroglyphs if you think about the messages we send, a lot of smileys and stuff.

Lauri (48:56):

Yeah. Rounding up, we're going to the last one. Managers complaining about the team's performance. So let's go that through and finish this off on time.

Eva (49:06):

Yeah. This is something. I mean, the team is at the core of Agile development and it's correct because if you have a team of motivated individuals, they have the right set of tools and support, they will perform brilliantly. But it sometimes doesn't happen and you hear a team, people asking, "Why aren't they self-organizing? So why aren't they delivering as expected?" So I've seen that frequently. So any thoughts from you there, Markus, on what can be at play here?

Markus (49:38):

There's a rule called regressing to the mean, which means that the team or a person might be overachieving for a certain period of time, but at the end they will come to the mean level. And this could explain, partly, this phenomenon of this insight that you were explaining that maybe there was a very motivating project or somehow the team were really, really working well together and they were kind of overachieving. And then when the next project comes, they actually start performing normally, and it seems that they are underachieving at that point in time.

Eva (50:25):

Yeah, that's true. I mean, that's a really good point.

Lauri (50:29):

It also reminds me of another well-established, I don't know if it's a well-established fact, but at least it’s been quoted often, is that a square root of the size of the team performs 50% of the work. So if you have a team of nine people, then three people will do 50% of the work and six people do the other 50% of the work. Well, it doesn't sound too bad when you have a reasonable size of teams. But imagine that at the department level, you have a department of 100 people, and you're saying that 10 people will do half of the work, and that is quite astounding.

Lauri (51:08):

And I don't know to what extent this holds true linearly between different sizes of teams, but that can be one that, especially when you think about the maturity, you just end up having more people in a more complex setup. And due to many reasons, the productivity condenses to fewer individuals. That is probably as much a management issue than from the formal management, as it is a sort of behavioral issue from the team itself. But that also came to my mind.

Markus (51:40):

In behavioral sciences we study a lot of situations where you spend enormous amounts of resources to, for instance, developing a vaccine, it takes billions of euros. But what you don't spend time and energy on is how you invite people to get the vaccine. So what comes to those themes, I mean, a lot of situations, the 99% is not enough. It's, "We are close, but we really need to have the 100% done." But also you really can't sack those six people out of the team of nine. Yeah.

Lauri (52:22):

Correct. But that, that would be the traditional stack ranking back in time, wouldn't it, which has already been debunked and sort of dismissed a long time ago.

Eva (52:30):

Yeah. And for personal reasons, I've been very interested in what the cognitive, I mean, what is motivating people because people are motivated by very different things. I mean, I'm very motivated by getting things done. I'm not so interested in what I'm actually doing because I feel very proud when I have it done. But some other people, they get motivated by making a difference, "I'm building a great product here and it's going to make a huge difference and I'm important here." So it can depend a lot, what makes people actually do the work and some people are maybe a bit lazy when it comes to more administrative tasks and documentation. They are brilliant when you ask them to put down a piece of code, but ask them to do anything else. And it's going to be a real challenge, but they might be very valuable to the team performance as such, like in the bigger picture.

Lauri (53:29):

So maybe we leave that as an enigma for all of us to try and figure out how to get teams self-organizing who do not perform. This has been a fantastic conversation. It feels reinvigorating to remind myself of all of this after so many years of study. So thank you, Markus, for joining.

Markus (53:48):

Thanks for the invitation.

Lauri (53:50):

Thank you, Eva, for putting all of this together. And I think we have a great combination of sort of underlying theory of people's behavior and also what really happens in product management. And we'll be putting all the referred content or referred papers in the show notes, so people can then refer more information on whoever was ever mentioned in this.

Eva (54:15):

Thank you. Thank you very much.

Markus (54:15):

Thank you. You too.

Eva (54:15):

Thank you for listening. I'm sure that the discussion raises a lot of thoughts. You can find links to the social media profiles of Eva and Markus in the show notes, alongside the referred books and other materials regarding the topic. If you haven't already, please subscribe to our podcast and give us a rating on your platform, it means the world to us. Also, check out the other episodes for interesting and exciting talks. Before we close off, I'd like to give the floor back to Eva and Markus, to introduce them properly. All I have to say to you now is, take care of yourself and be vigilant of your biases.

Eva (54:51):

My name is Eva Höglin and I'm an Atlassian expert consultant at Eficode, and I have many years of experience in software development. And I think I've been having all the roles you can imagine. I started out as a developer and then team leads, scrum master, line manager, project manager, product manager, product owner, and delivery manager. So I've been very interested in learning new things and trying out different roles. And besides that, I've always been very interested in processes, and throughout the years, many different software processes and methodologies have emerged and I always jump directly onto them. And then I'm trying to introduce them. And then I realize I'm sort of alone here and I'm running and I look back and people are not there. And that's why I'm becoming increasingly interested in human behavior. And why is it that they don't listen to me when I tell them and then start running? So that's in short, who I am and where my interest lies in this area.

Markus (56:03):

Hello everybody. My name is Markus Kanerva. I'm a senior lecturer at Laurea which is an applied science university here in the Helsinki area, Finland. Been studying, teaching, and applying behavioral sciences and behavioral insights for the past eight years. And I have to admit that I have zero knowledge about software engineering, but what is very, very fascinating about behavioral economics and behavioral sciences is that you can apply those, basically, in any subject. For instance, I've been applying my knowledge to how to prevent type 2 diabetes, how to prevent food waste, how to communicate effectively during the corona crisis, and in very, very different areas. So I was very happy that Lauri invited me to chat about software engineering as well.

Related links:
www.eficode.com/academy
www.eficode.com/services/devops-transformation

Speakers:
twitter.com/MarkusKanerva
www.linkedin.com/in/markus-kanerva-5529721/
www.linkedin.com/in/evahoglin/