Leveraging Our “Brains” in Software Development

We're kicking off 2021 with a new interview series: GOTO Unscripted, with our first round of interviews recorded back when we could still meet in person. GOTO Unscripted takes our conference speakers off the big stage and brings them behind the scenes for an intimate conversation on topics they know best.

Our brains empower us to run complicated software development programs, but can also be the thing that prevents us from achieving the best possible results due to several psychological biases. Fahran Wallace, senior consultant at OpenCredo, and Benjamin Mitchell, director of engineering at Kevel, discuss those psychological biases at work, how we can tackle them and how we can wire the brain to overcome them. 

Intro

Preben Thorø: Okay. My name is Preben Thorø. I am part of the program committees for our GOTO Conferences.

Part of making software is understanding each other as human beings because, at the end of the day, it's human beings writing software, most often for human beings. So the human factor in things is very important to what we do.

With me today I have Fahran Wallace and Benjamin Mitchell. I will just let the two of you give a brief introduction on your focus here.

Fahran Wallace: Sure. Hi, I'm Fahran Wallace. I'm a consultant at a company called OpenCredo based out of London. I really enjoy consultancy because it lets you keep doing hands-on programming, but also you get really interesting human situations. I find those quite fun.

Benjamin Mitchell:  I'm Benjamin l Mitchell. I'm a partner in a software consultancy in London called Equal Experts (now at Kevel), and I work with teams of teams doing agile and pragmatic approaches to delivering software.

Psychological biases at work

Preben Thorø: One thing I know that is very close to your hearts, that is the bias that we apply to the decisions we make at work. What are these psychological biases that we deal with in working situations?

Fahran Wallace: The brain is a spectacular machine, a spectacular computer, but it's not necessarily been designed to program, and not necessarily designed to work with other people in a technical capacity. And so, you often find that there are lots of individual biases and biases that combine together in a team to occasionally have a detrimental effect on a project as a whole. For example, people can be quite optimistic about how long it's gonna take to get something done in the software world. That's a fairly common one.

There are things like you're much more likely to believe or be persuaded by someone who you think well of, even this idea, it turns out, they don't know a huge amount about. There's a whole host of these different biases that can turn up. Spotting them is really hard when you're in the midst of trying to get something done.

Benjamin Mitchell: I'm really passionate about understanding the biases. I think it's amazing to hear about how our brain can be tricked and then using approaches in a team, or the way we deliver the software, that tries to take them into account so that we don't have to be perfect. Because I think there's too much evolutionary wiring that we're operating against.

But doing things like frequently looking at releasing software to customers, so that we can measure so that we make sure that the amount of time where we're wrong is as small as possible. Or doing things like pair programming, where we're asking someone that is outside of our head, who's more likely to see the biases that we're bringing impacting what we're doing working together.

So, a lot of my focus is how do we take these biases into account and design ways of acknowledging them, rather than trying to become more perfect by overcoming them, and then build them into the team's practices and the way that we build the software so that we're less impacted by them.

Preben Thorø: So accepting them, is the way to overcome.

Benjamin Mitchell: Yes. For me, I went to see Daniel Kahneman talk about his book "Thinking, Fast and Slow." And he's the guy that invented them, and he's pretty clear that he can't overcome them. So I think it's a fairly futile direction to head in, to think, "If I'm aware of my biases, I can be cleverer than them."

I like his humility in the face of the bias to think, "I'm not going to spot when I'm being influenced by a bias, but then I can do things like… you can probably see what I'm blind to, and if I can create a safe space for you to tell me, 'I think this could be a recency fallacy,' or I'm being swayed by someone's power," then we can be more effective together. But the right direction isn't to attack 'em head-on.

Recommended talks GOTO 2018 • Your Brain on Software Development • Fahran Wallace

Are our brains wired for software development?

Preben Thorø: You briefly touched on this in your introduction. Are our brains actually suited for software development?

Fahran Wallace: Well, they seem to get the job done. I don't know. The brain is the culmination of many, many millennia of various things happening to it on an evolutionary scale. The human brain is pretty well optimized for being flexible, as far as I can tell. They seem to cope well with a variety of situations and they adapt fairly well to those situations.

So in the sense that the human brain can learn anything, that you can even get software done, I think, inevitably, we are carrying around the rest of the stuff with us. We are prone to getting angry, especially when our ideas are being questioned, and we're prone to other little quirks that make us more reactive. If we understand that we're being reactive, and we know that's sort of in our natures, then we can feel the reaction and then go, "Okay, yeah, that was an emotional reaction to someone criticizing me. Let's now process that and then think about what I'm gonna do about it and if, actually, the reason I'm feeling an emotional response is because I was actually wrong." It's quite often that we are wrong

Preben Thorø: Is that a cultural thing?

Fahran Wallace: A cultural thing?

Preben Thorø: Yes.

Fahran Wallace: I think different teams have different levels of openness. Also, different people get on in different ways. If you've got very opinionated people all working together and they all have a different view of how to do stuff, they're going to have to find a way to work together or, if necessary, just go do something different if it's not gonna work.

Preben Thorø: Especially in a global world, I guess.

Fahran Wallace: Yes.

Passion vs the “know it all” attitude

Preben Thorø: Talking about biasing our decisions, that's very much about that I have a feeling that what you're saying is wrong as compared to my opinion about how the world looks like. What is the difference between being just passionate about things and me being that irritating guy that just knows better?

Benjamin Mitchell: I think it's important to look at how we see this playing out. So, what I'm so excited about working with teams is that approaches like agile and others bring in roles like delivery leadership or scrum master. So there's a role for someone to help the team work effectively together as humans.

If I saw someone who is very passionate, we want that. I talked about how we want to have all of the ideas out on the table so that we have the best selection to be with. I think the issue often comes when someone believes in the value of their idea, but someone sees it differently. So what do we do from that point? And what I like is sort of two directions in software development.

One, where we're doing a very sort of test-driven culture. There's a great mechanism built into that. "Let's write the test that would show us what the right way forward would be, and then we can partner together on doing this," which I also think is a good human negotiating point of view.

The other thing is if someone is really passionate and they disagree with others, you might see them stopping effective behaviors like they're not asking for inputs from others or they might be doing some behaviors that shut others down or make it less likely for them to talk. So trying to facilitate the group or get the team to facilitate and say, "It's fantastic that you're so passionate about it. We really want that help. I also notice that others in the group haven't said how they see it. I was wondering whether anyone saw it differently." So, using facilitation behaviors in order to balance across the team and encourage an environment where everyone feels psychologically safe to contribute and say they see things differently.

Fahran Wallace: Yes, that's a really important one actually, getting the quiet people to speak because otherwise, if they're not on board with the process, they're gonna feel left out of it and just not want to contribute to it. And then they might feel resentful, or, I don't know, not wanting to contribute to the team anymore.

Benjamin Mitchell: Yes, absolutely.

Recommended talks GOTO 2018 • Secrets of Effective Communication You Can Learn (from my Failures!) • Benjamin Mitchell

Fahran Wallace: Yes.

Benjamin Mitchell: That's why I'm so excited, having come from a psychology background into software development, to see things like team-based approaches with built-in feedback mechanisms. You've got the unit tests, you got the daily standups, you've got the retrospectives. I think it's a really effective way of saying, "Hey, we do have these brains, and we might be stretching their capabilities and doing more abstract work than we've done through evolution, but we've got these mechanisms built in to work with other humans to get this job done, that we're not just looking at superheroes in front of a computer translating requirements into abstract syntax. But it's more of a team-based approach with a focus, too, on users and user needs pulling through effective software."

It is really fantastic to be involved in an industry that sees that need for a balance of approaches.

Tackling “hierarchy”

Preben Thorø: When we talk about bias and me knowing better, it's not far from that to "I should respect this guy because he resides somewhere higher in the hierarchy than I do." Should we fight that? I mean, at the end of the day, hierarchy, I guess, is what has brought evolution so far.

Benjamin Mitchell: I certainly have friends who are psychologists who raise dogs, and they have a very alpha hierarchy, and it's definitely groups that we see in animals. So, I'm clear that that has to be part of who we are.

In terms of fighting it, I think the issue, for me, would be, “Are you getting the results that you want?” And so if there's a tendency for people not to question senior people, and ask them to explain their reasoning, you might be fine in that scenario, or it might produce problems.

If there are problems, then I think there are some useful things we can do to create a culture where, through the leaders' own behavior like inviting others to question their reasoning, or to say, if you don't hear it, that we could encourage a different culture that balances those things out if that's important for the situation that you're in.

Recommended talks GOTO 2018 GOTO 2018 • Politics &; Hierarchy: How We Create It & How to Stop • Benjamin Mitchell

Fahran Wallace: Yes. I think respect in both directions is really important. But there's different levels of respect. There is a form of respect that can happen whilst questioning their decisions politely. And hopefully, they're responsive to that sort of polite questioning.

If there is not the respect either way, you're just sort of getting requirements dropped on your head or implementations dropped on your head, then finding ways to sort of gently get them to explain their reasoning gets very important, I think.

Benjamin Mitchell: Yes.

Can we fight biases from the start of a project?

Preben Thorø: It's so easy to talk about this and how we could deal with it right now because we're not in such a situation. We know when we kick off a project that, at some point, this project will bump into one of these situations. Why don't we always start project day 1 by talking about this?

Benjamin Mitchell: I think we do sometimes. Like, for example, teams I've worked with will use futurespectives. So, we'll do an exercise where we say, "Let's acknowledge now the work we're going to do together, the product we're going to deliver, and let's assume it went well, what stories can we tell each other around what went well and why?"

Then, to cover the bias that people sometimes don't want to appear negative or don't want to appear critical, I've done it with teams, we play it the other direction. So we say, "Let's imagine for a moment that it's gone terribly. It's a catastrophe. What do we think we'd see that made it catastrophic, and what do we think would've contributed to the catastrophe?"

That's an example of designing a thing where we're trying to overcome people's tendency to appear supportive and positive. But we also need to think through what might go wrong and make it discussable, so that that negative futurespective allows people to safely raise concerns, and then to talk it through in a way that's not personalized so it's more likely to be respectful and an effective conversation.

Preben Thorø: Should we even identify personas upfront when we kick off a project, like, "Oh, I know I'm going to have a problem, trouble with this person in the project group."

Fahran Wallace: That's a pretty brutal way of kicking off.

Benjamin Mitchell: Yes, it is. We'll paint this target on your back just so we're all aligned.

Yes, I think, the challenge with that is if we label another person as the problem and we predict we're going to have the problem, it might become a self-fulfilling prophecy, which is I think, one of our sort of cognitive biases, that we pattern match towards our expectations.

Back to the hierarchy, if a leader demonstrates behavior that can be effective, that makes it easier for others.

I've worked with groups where I'll say, "Sometimes, you can have a conversation but be too caught up in a point-to-point conversation at a standup and other people will be frustrated but won't wanna say because it might be critical. And so, we'll put in protocols like, "If you think someone is talking too long or just involving one other person and not the group, raise your hand." And because we don't want that to be an autocratic decision, you need two hands to be raised before it happens.

Just briefly, what I've found in my own experience is the first two times I introduced this to a team and we decided we'd go with it, it was me that demonstrated ineffective behavior by talking too long to one person. Not only did I not spot people putting up their hands, people had to yell out that they had their hands up because I was completely in an argumentative tunnel with these other people.

So I think showing it through our own behavior is a useful way.

Fahran Wallace: Yes. I'm trying to imagine the situation where, in the initial project kickoff, you sort of say, " Hey, I know I don't get on with you, but we're gonna work together on this." I feel like...

Preben Thorø: Or it might not be that outspoken. It might just be that I have a feeling that, "I'm not going to work very well along with you." So I might prepare myself for what will come at some point.

Fahran Wallace: Okay. All right. 

I feel, if your communication is sort of that open and, I guess, healthy with people, that you're willing to, on the first day, go at it, I don't know. I feel like maybe everyone would get through, but it might be messy. I'm not really sure.

When to give up a difficult relationship at work?

Preben Thorø: Do we know when to give up a difficult relationship at work?

Fahran Wallace: Know when to give up...

Benjamin Mitchell: You never have to get on with someone at work, that would be my open.

Fahran Wallace: Yes

Benjamin Mitchell: It's up to each person as a grownup to decide where they are. There might be some impacts of that decision. If you think it's an unworkable situation from someone else, clearly, that would impact a team. So, there might need to be some discussion about what happens around that.

One bias I've seen is that, often, people jump to the conclusion that they can't work together before they've spoken effectively about what scenarios specifically contribute to these feelings. And we often jump to conclusions.

I once fled a team because I felt criticized by somebody else because they flared their nostril at me, which had this massive personal impact on me. I stormed out of the building because I was so upset. That person had no idea that they were flaring their nostril at me. It was a complete overreaction on my side.

Recommended talks GOTO 2017 • Top 7 Agile Tips I learnt as a Product Manager • Benjamin Mitchell

So, being able to overcome the tendency to jump to conclusions, particularly around other people's motives, like, "This guy is judging me and he thinks I'm ineffective," by being able to talk about it. It certainly served me well, and that's what I focus on with teams, trying to create scenarios where it's safe to have those conversations before it gets to the point that you think, "I just can't work with this person."

Fahran Wallace: Good job, you went back and found out what was going on. Otherwise, you'd have just thought this guy was your enemy forever.

Benjamin Mitchell: Yes, we became friends after having the conversation. So, we both learned.

Preben Thorø: That pretty much answers the next question I had in mind because that was if you have any examples of that you were actually able to change bias significantly.

Benjamin Mitchell: Yes, I am very humble to the fact that I can make small productive steps forward, and I continue to make the same mistakes over and over again.

It's building up that ability to ask others to help, like in the two hands scenario. It's why I like working with teams so much because, I think, if you can build quality relationships with other people, it gives you a lot of opportunities for them to help you out. But it needs to feel safe. I think, before we have relationships, it can be much harder. 

I don't know that I've made huge strides other than continuing to invest in working together with others with strong relationships in order to have that increased safety.

Fahran Wallace: That's really nice.

I'm thinking of a recent time when I sort of went into a client who was doing things in a particular way that they'd done for a long period of time. One of the nice things about coming into someone else's team and having a look around is you get this external perspective on how they're working. And you can quite quickly sort of see what patterns they have fallen into.

You can't necessarily openly say things to try and change that, but, you can help with behaviors and sort of suggesting ideas that can help them solve certain patterns and find gentle ways of introducing new techniques and tools that they haven't got direct experience with, but you can sell those tools to them based on the problems they're having.

So, coming at it sort of straight on sometimes doesn't work. But sort of helping them see it from their perspective, as you were saying in your talk, helping understand their problems allows you to sort of change their behaviors for the better.

Problems in software projects/teams

Preben Thorø: Assuming they are the problem.

Fahran Wallace: I've been in enough software delivery situations now where I have sort of looked around and realized things aren't perfect. Things are never perfect in software. There's always tech debt and there's always things you want to change but you don't have time to.

Then you sort of come in and see someone else's situation, and they've got loads of tech debt, and things aren't as they would want. Normally, they're not dumb. Nothing is willful. It's just how things are, and they've sort of run out of energy to change it. So, if you can find some ways of giving them new energy to change how they're doing stuff and help them, then they're gonna really enjoy the experience of change, hopefully.

Benjamin Mitchell: I like that phrase, "The finger of blame usually points back at us." So, if you're confident that someone else is the problem, it's nearly always that you're doing something to contribute to that scenario and its continuation.

Some of the things I've done is, if I'm struggling with someone, I'll write down the dialogue that I'm having with them to try to understand how I'm contributing. But it's remarkable how hard the brain, my brain, at least, finds this. Because I've even written down dialogue like that and taken it into a study group to get input from other people. And I've thought, "They're gonna find nothing that can help me here because I'm working with someone who's a very bad person."

It's always been remarkable. I sort of go, "Guys, there's nothing. There's nothing. It's as good as it can be." They're looking at me going, "You know when you said you were listening here, I don't see any question, actually, in anything that you've written. Can you tell me more about how you were listening."

If you've said that somebody else is the problem, it's probably good input that there's some material that you could look at with the help of others to find out how you might be contributing.

Preben Thorø: True. Most often, it takes two parties to build a conflict.

Benjamin Mitchell: It does. It depends where you wanna go because, sometimes, it's just not worth the investment to improve that situation. And if you don't want to, I wouldn't. I wouldn't invest. I'd be realistic about it.

What I've found is that there are ways of improving the scenario through my own behavior. Like with the nostril-flaring fellow, being able to say earlier, "I think you have a different point of view than I do, and I'm worried that you're critical of something that's going on. Can I just check? Is that what's going on?" would have saved me fleeing the building.

But I needed practice at asking questions and being comfortable when someone else had a very different, maybe even a critical view of me.

Preben Thorø: I think that's a very constructive way to end this conversation. Thank you so much, both of you.

Benjamin Mitchell: Thank you.

Fahran Wallace: Thanks very much.

About the interviewees 

Fahran Wallace is a Senior Consultant at OpenCredo. She’s been programming professionally for 7 years, starting with application development, and growing to explore other facets of delivery, including architecture and tech leading. Her current focus is Data Engineering. Building things, and hearing how others approached problems, are her two favourite ways to learn.

Benjamin Mitchell has over 20 years’ experience delivering online applications, in diverse sectors – including government, media (BBC.com), investment banking, insurance and software products. A highly-rated international speaker, he is passionate about helping software product development teams and leaders build the right products in the right ways. Benjamin is proud to be a director of engineering at Kevel.