Debug your thinking

🔗Transcription

00:03 Laila Bougria

... on? Can everyone hear me? Yes, there we go. Welcome, everyone. Thank you for being here. I know this was a really tricky slot. I'm looking at the lineup, I'm like, "Okay." I'm so grateful to everyone who's here. So my name is Laila. How are you finding the conference? Good?

00:20 Audience

Oh, yeah.

00:21 Laila Bougria

Yeah? Is this the first conference you went to this year? Mostly yeses, cool. That's a good way to start the year. I'm actually a little bit annoyed at this year, because I'm actually celebrating a milestone birthday this year. One of those pretty round numbers. I'm basically approaching the age where people put a single sparkler on your cake, because one a year, that's way too cumbersome. And at this point, it's a fire hazard, so we're not going to do that. And thinking about that makes me feel like, okay, it's time for a midlife crisis, don't you agree?

00:55 Laila Bougria

So apart from all of the expensive shoes, and bags, and all that, it's also really been a time of reflection, of really sort of thinking back of my life, of my career. And thinking back of all of the things that went well, the things that didn't go so well. But more importantly, all of the things that I've learned throughout that process, throughout all of these experiences, all of these projects I've worked on. And that is exactly what I want to be sharing with you here today, some of those deeper insights that I've gained over the years. All of you, welcome.

01:32 Laila Bougria

So to do that, I'm going to have to take you back to one of the first ever projects that I worked on. And it was really early stages, you can sort of think of it as proof of concept stage, still trying to convince the customer that we're really the right company to go with. So what we did is we quickly cobbled together a couple of working use cases to showcase that we were really the right team to take this on. And we didn't spend much time thinking about architecture or technology choices. We were like, "We need something to showcase this customer quickly. We don't want to spend too much time thinking about the details right now."

02:09 Laila Bougria

So at some point we went into a meeting with the customer, also a sales representative there, the project manager, and we basically showed what we had and showed all of those use cases. And the demo gods were with us. Everything went perfectly well, we were really happy. And this prospect was like, "Oh, my God, yes, I'm signing. When can I start using this? This already looks great." I remember locking eyes with a sales representative before he turned around and says, "well, as you can see, this is already operable. Give us a couple of weeks to figure out the details and then she should be able to use this in production." Yeah, customer, really happy. Me, lightning bolts shooting from my eyes, like, really? Seriously?

02:55 Laila Bougria

You could pretty much guess what happened, right? We were basically building feature upon feature on a foundation that was never meant to support the scale at which it was being used. And the thing is it was really hard for us to get additional budget to start fixing all of these issues, because in the customer's eyes, everything worked, it's looking great, what's the problem? Of course, that's only true until it didn't, and things started to fall apart, and we basically really struggled keeping this project running.

03:27 Laila Bougria

Now, at the time, I had no idea how to handle a situation like that. So this ended up sort of dying out basically. And I was like, "Oh, my God, how did this happen? How did I get here?" And more importantly, "How do I never ever get here again?" Now, at the time, I really attributed this failure, if you will, to the fact that we didn't really think through all of our technical choices. We should have really thought about our architecture upfront. We should have really thought about which frameworks we're going to use, how we're going to design things, before even getting to that demo meeting. So what did I do? Well, I continued educating myself in all of the state-of-the-art technology, or what was state-of-the-art at the time. And I really believed that if I was more aware of all the frameworks of all the technologies out there, that next time, I would be way better equipped to make better choices.

04:25 Laila Bougria

And life goes on, so at some point, the next project came along and it was super fun. It was greenfield, so we could basically start from scratch and apply all of those things that I had been learning, right? So what did I do? Well, I basically treated it like a kid walking into a candy store with a Platinum American Express card and basically chose all the latest and greatest technologies. Scalability? It's going to scale this time, I promise you that. And think of all the patterns that I learned about, unit testing, integration testing, acceptance testing, performance testing, all of the testings. And thinking about security from the get-go, all of these things. And it was really beautifully designed. It was something that as a team, we were really, really proud of. So you might ask yourself, did that then make us successful? No, because what happened is we ran out of budget. The thing is that we spent so much effort gold plating, and thinking of all of the details, and getting everything right that we never even got to deliver a first functioning version to our users before they pulled the plug on us.

05:37 Laila Bougria

And that was a really hard one for me to take in. I'm like, "How did I get here again? Seriously, how did this happen?" And I was really, really frustrated, because I was like, "Come on, I spent so much time studying all these best practices, avoiding all of these anti-patterns." And I've done all of that only to realize that I wasn't considering all the variables that were at play. So I felt that sting of disappointment for a while, right? Now, luckily not all the projects I worked on throughout my career have been this dramatic. I've been lucky enough to work on a lot of successful projects. But when I sort of think back and I look back to all of those systems and projects that I've been a part of, every one of them, I can remember specific types of friction that we tended to run into again and again and weren't able to solve.

06:28 Laila Bougria

And what happened is that over the years, that thought process of, "Never do this again," and, "Oh, my God, definitely never do that again," and, "Maybe we want to repeat this," that basically swung a couple of times back and forth. And what I learned over the years is that actually, a couple of things that didn't work well in a specific context ended up working exceptionally well in different contexts. And every time I learned that, I took those learnings to the next project and to the next customer. And then over the years, that sort of thought process started to stabilize a little bit in the middle. And with that sort of stabilizing cradle, also came an eye-opening realization that there is no such thing as the right architecture. There's also no such thing as the perfect blend of frameworks to use. Also, no such thing as a perfect programming language.

07:26 Laila Bougria

Success also was not dependent on the team structure or composition alone, also didn't have to do with the size of the organization or which project methodology we were using. It was something deeper and actually something that in most situations, wasn't even paid a lot of attention to. It was about the decisions that we made, how we made those decisions, how much attention and intention that we spent when we were making impactful decisions in those projects that we were working on. Now, all of us make decisions on a daily basis. It doesn't really matter whether you're early on in your career or whether you're a tech lead that's making decisions about large-scale applications. All of us make decisions that end up impacting the projects, the systems that we work on, in one way or another, with varying degrees of impact.

08:21 Laila Bougria

So with that in mind, ask yourself, over the last few weeks when you were at work, what decisions did you make and how impactful were those decisions that you make? In what way do they affect the system that you're building? What were the negative effects that were associated with that decisions? Because there are always some, you just have to be aware of which ones.

08:48 Laila Bougria

Also, would it work in the long term or was it more of a quick fix type of situation? And what problem were you solving? Did you understand that problem well enough? Is it a problem that needed to be solved right now or did you consider maybe even postponing working on that? What options did you consider? Did you even consider multiple options before you dove in? What assumptions did you make about the specific context that you found yourself in? And did you ensure that you weren't overly biased towards your preferred solution? Could you easily explain to someone else, why your solution was the right one to pursue in your specific context? And did you take some time to actually validate that thought process with others before going in and implementing that? In short, how are you debugging your thoughts?

09:56 Laila Bougria

Now, if this is how you feel right now, no worries. If you would've bombarded me with all of these questions in the past, I would also be like, "I don't know." But actually over the last few years, I've been learning a lot and actively practicing critical thinking a lot, basically pulling apart my own thoughts to improve my own decision making in everything that I do at my work. And that is exactly what I want to be sharing here with you today, right?

10:28 Laila Bougria

I didn't choose this title just because it's a nice play of words and we're sort of engineers, generally speaking. But the reason that I chose this title specifically is because I truly believe that many of the activities that we need to do to basically pull apart our own thoughts aligns a lot with how we debug our systems. Because when we run into a problem, what do we do? We take some time to try to understand what is going on? In which situations does this occur? We'll take a look at observability signals, tracing, and metrics, and logs, and all of that, to get a sense of where is this friction located in the system and why is this happening?

11:12 Laila Bougria

From there on, we'll start debugging parts of the application and see, okay, what sort of string of methods is being called? In what order? What data is coming through? We start to place breakpoints everywhere. And then when we hit those breakpoints, we usually take a look at what data came in? What is the state of these variables? We'll start to inspect them and take some time to validate, does that actually carry the value that I expect it to? And I've understood that our thought process would benefit a lot from the same type of activities that we do when we debug systems. Now, you might be thinking, "That's great, Laila, but there's no such thing as a mental debugger." But the thing is that we can build one. With multiple techniques and practices, we can build one that allows us to sort of pick apart our own thoughts that way.

12:05 Laila Bougria

But before doing that, how are you not seeing other slides? This is odd, I'm moving forward. Okay. But anyway, so to basically understand how to build that mental debugger, we need to also understand the traps that we tend to fall into, and the most common one is our beloved solution mode. Because what usually happens is that someone walks up to you and says, "Well, I have this problem and I really need you to solve this for me." And what do we do? We immediately jump in, right? And that's logical, because that's why we're there, right? We're there to solve the problems that people bring to us. So it's not only that we are biased towards solution mode, it's even worse than that. We're incentivized towards solution mode, because when someone comes to us, they want it done by yesterday, because this is an issue for them, right?

12:59 Laila Bougria

But the thing is that if we immediately jump in and we don't take enough time to think about what is being presented to us, we could come up with the wrong solution to that problem. Or even worse, we could be solving the wrong problem to begin with. And that's why it's so important for us to take a moment and slow down, think about what is being brought to us? What are people telling us? Is it actually a problem that they're presenting to us or is it more like points of friction that they're experiencing? Maybe it's symptoms of a sort of more deeply rooted issue, right? Maybe it's even just an observation.

13:43 Laila Bougria

But what most commonly happens is people don't bring us problems, people bring us solutions. "I need a big red button over there. Can you please add this additional field on that page or get me a report of that data?" So it's really important to sort of slow down and get a sense of what are they actually trying to solve? And try to understand, what is the underlying problem that we want to be solving? And there's one magical question that can help you answer it, why? [different language translations for the question, "why?"]. It doesn't really matter in which language that you choose to ask this question, as long as you do so repeatedly. Now, what I'm referring to is the five whys techniques, which was introduced by Toyota, in which we're just going to ask why, or even why not, a couple of times so that we can get to the root cause of this problem that's being presented to us.

14:44 Laila Bougria

Now, I'm aware that there are a lot more root cause analysis techniques out there, but the reason that I'm bringing up this specific one is because at this point, when someone walks up to us, we don't want to go into full analysis just yet. We just want to get to an initial framing of the problem and this is a really useful technique to get to that, and then we can elaborate on that further. So together with this question, you are also going to need a very, very, very important tool, a pencil. Or okay, a keyboard if you prefer. Because writing down that problem statement is basically going to force us to slow down, to think a little bit about what is being presented to us. Even if you just take five minutes, that's already a great start. But what you will usually find is once you start doing this, is that five minutes is not enough, because it's actually hard to write down a problem statement. Why? Well, because writing is nature's way of letting you know how sloppy your thinking is.

15:51 Laila Bougria

Because what's happening now is we need to basically transform all of those chaotic streams of thoughts that are going on in our brain to something that is concise and specific, to something that anyone is able to understand. And that requires a very clear understanding of what is really going on here. But once you do that, it can actually bring you a lot of benefits, because once you have that written down, you can take it to your peers, and discuss that problem, and start from a common ground, and avoid a bunch of communication issues that are happening along the way. But also, you can go back to your stakeholders and validate, "Hey, wait a second, is this actually the problem that you want us to solve?" Which can avoid us many misunderstandings down the road?

16:39 Laila Bougria

So here are a few key points for you to remember. You basically want to take some time to write down that problem statement. Just a single paragraph, doesn't have to be a novel, okay? And also, you want to stay away from any solution proposals. You don't want to go into solutions just yet. You want to focus only on the problem, also because we don't want to a bias towards specific solutions yet. And also we want to avoid coming up with problems for solutions that we fell in love with as well. Also, avoid any technical terms when you're trying to frame a problem. Because usually when you use technical terms to describe a problem, you're still thinking in terms of solutions. What is the underlying problem that you're trying to tackle? Usually that doesn't require any technology at all. And finally, make that measurable. What do I mean by that? Well, in order for anyone to be able to understand the problem, that problem statement should be able to sort of answer, what needs to be true in order for this problem to be solved?

17:48 Laila Bougria

And when we have that initial problem statement, we also want to take a moment and ask ourselves, "Is this actually the right problem to solve?" Let's consider a well-known use case called the elevator problem. So imagine that you're a building manager and you're getting complaints about the elevator that is way too slow, like, "It's stopping at every floor, I'm late to my meetings." People are really frustrated. So what happened is the problem is framed as the elevator is too slow. And this is a good problem statement, right? It's concise, it's specific, it's understandable by anyone. It's not mentioning any specific solutions. But there's one big problem with how this is currently framed, because it's narrowing down and actually almost self-imposing the applicable solution space. The elevator is too slow, so we need to make it?

18:40 Audience

Faster.

18:41 Laila Bougria

Faster, right? Now, when this problem statement was presented to a group of people to solve, the options that they came up with was, "Maybe we should reconsider the prioritization algorithm of the elevator," or, "Maybe we can upgrade the motor?" Or, "You know what? How long have we had this elevator? Can't we just replace it altogether?" Which is the equivalent of a system rewrite. Now, what happened in this use case is that they basically reframed the problem to the wait time is annoying. And that completely changed the perspective and therefore people came up with wildly different solution proposals. Actually, the way that they ended up solving this issue is by installing mirrors in the elevator, because now people were presented something incredibly fascinating to look at, themselves, right? And people stopped complaining. So you can argue that this was a well enough solution to the problem that they're facing, even though it didn't alter the speed of the elevator.

19:47 Laila Bougria

Now, what basically happened in this sort of use case is what is called reframing, and I think we should do a whole lot more of it, starting with our own role in this industry. Because years and years ago when people would ask me, Laila, what is it that you do for a living? I would say, "Oh, I'm a coder. I'm a software engineer. I build complex systems." Now almost two decades into my career and I think that's the worst possible way anyone could introduce themselves as. Not only because of how others view us, but how we view ourselves, because it's putting us in the wrong frame of mind. We are not here to write code, we are not even here to build complex systems. We are here to solve business problems.

20:37 Laila Bougria

And yes, usually that does entail the means of technology in one way or another. But if we are presented with a problem that doesn't require a technical solution at all, then why wouldn't we? It's actually our responsibility as technical experts to be able to identify and point out when we're presented with problems that don't require a technical solution, no matter how much fun it would be to build.

21:03 Laila Bougria

So I really believe that if we reframe what we're supposed to do, what our goal is as engineers, as architects, as all of that, can really help us also reframe problems. So when you're looking at a problem statement, ask yourself a couple of questions, starting with is this statement true? Is the elevator actually slow? How fast are elevators generally speaking? Also, who is affected by this and in which way? If you want to really understand the problem, you need to understand who is affected by it, you need to know your stakeholders?

21:42 Laila Bougria

Also, is there a solution bias hidden away in the problem? Now, this is not the same as the solution proposals that I talked about before, right? This is more a solution bias, like in the elevator is too slow, which is biasing us towards making it faster. That is the bias. Still framed as a problem, but it's sort of pushing you towards a specific direction. Also, ask yourself, what happened before this sort of problem surfaced? Did something happen? Was maintenance done to the elevator? Or maybe there's a new company that sort of moved into the building, they're having lunch at the same time as all the rest of the companies and that's what's causing the queuing in the elevator.

22:26 Laila Bougria

Also, ask yourself, are there any hidden influences when you zoom out? Could it be that all of these complaints that are happening about the elevator are basically a hidden strategy to force the building manager to lower the monthly rent? Asking all of these questions can then also give you some information to see whether you can find a better problem to solve. So with this elevator problem, I think we can really show how just with a different perspective, just a different way of looking at things, of thinking about things, we can have a huge impact on the solutions that we come up with. And this is before we started thinking about solutions, right? Why it's also so important to take some intentional time to think this through. Now, this is also something that you can do as a continuous exercise. It's not something that you do at the beginning and then you forget about. Because as our understanding of the problem evolves, as we start to analyze and as we start to look into multiple solutions, we might be able to find different angles to then reframe the problem at a later point as well.

23:34 Laila Bougria

So okay, now we've slowed down. We've taken a moment, thought about the problems, seen if there are better problems to solve, if it can be reframed, and at some point we need to start looking at solutions, right? But that's when we start to face a huge amount of different problems. First of all, our bias towards speed. "Let's just get this over with. I was doing something really fun before this came up," or, "I want to get this done so I can start working on something that's really fun," right? And that then tends to go hand in hand with our bias towards using what we already know, technologies that we already know and trust. "Oh, but this is like SQL Server, we've been using that for years, it's trusted technology. We already have the infrastructure and we have all the knowledge in-house, so we're just going to use that," which are all valid points. But if you're using SQL Server mainly to store JSON, then is it the right tool for the right job?

24:38 Laila Bougria

Sometimes it's also a problem that we face from a different angle, right? The reason that we come to conferences is to learn about all these new frameworks, all these new technologies, and all these new practices. And we go home, and we're super excited, and we go back to our projects, and we're like, "Let's just implement this, because wouldn't it be cool? Everyone and their mother is using this," right? But is it a good idea for your specific context, for the system that you're running into, for your team? Because another problem that we just tend to ignore entirely is how is this going to affect our team? How is this going to affect our velocity? We just assume that everyone will learn everything. But first of all, is there sufficient documentation about this new framework? Whatever it is that you want to use. Is it comprehensible to everyone that is on the team? What is your plan to actually get everyone on board with using this? How are you going to introduce this into a system? Especially if it's very large.

25:47 Laila Bougria

And finally, another trap that we tend to fall into is that we keep reinventing the wheel. We keep basically coming up with solutions for problems that have already been solved, because how hard could it be? And then we find that it's actually not as easy as we thought and it's completely derailing us from our goal, which is solving the business problems, right? That's why it's so important for us to think outside the box when we're trying to look into solutions. Now, I used to really hate this statement, because when someone says, "Laila, think outside the box," I'm like, "Okay, what do you mean? How do I do that? Where is my box? How do I even know where the boundaries of my box are?" But let me tell you a secret, every one of us in this room has at least at one point or another, been perfectly capable to think outside the box. Because the best example of out-of-box thinkers that I can think of is children and I'm going to prove that to you with a real life story.

26:54 Laila Bougria

Now, I have a daughter called Nora, and a couple of years ago, I think she must have been four years or something at the time, she had a couple of friends over and they were having lunch. So I made them small charcuterie sandwiches. And at some point, one of the girls sort of opens up the sandwiches like, "What is this?" And Nora says, "Oh, that's chicken meat." And this whole conversation on meats start and they start talking about the meats that they usually eat in their sandwiches. And Nora's like, "Oh, I eat chicken meat." And the other one's like, "Oh, I eat pork meat." And the other one, "Oh, I eat cow meat."

27:29 Laila Bougria

And at some point, one of the girls looks up and says, "So what about people meat? That is also meat, right?" I just stood there in shock, like, "What did you just say?" It took me a moment to sort of put myself together before I said, "No, no, no. This is not something that we do. This is immoral, this is illegal, this we don't go there." But if you take a couple of steps back from that statement, that is true out of the box thinking for you. It's about considering options that are counterintuitive, that are uncomfortable, that maybe you've been told to never consider, that may shock others, and then genuinely asking yourself, is this a valid option? And that is what children naturally do, right? There is no box limiting their thinking. They think completely free.

28:26 Laila Bougria

But as we grow up and as we are basically taught by our parents, by our schools, by our teacher, that box is slowly created. We're taught about nature's law, society's rules, right? And also throughout our education, how to do certain things and how to not do certain things, best practices, anti-patterns, ring a bell? And basically that box is slowly created.

28:52 Laila Bougria

Now, in case it's not entirely clear, I'm not incentivizing anyone to do anything that is immoral or illegal, okay? The reason that I chose this specific example is because I wanted to provoke that feeling of shock, of resistance, and of deep discomfort. Because you will recognize that same feeling in professional settings when other people are bringing up options that are outside of your box, because not all boxes are created equally. And it's really important that when you feel that way, and when people come up with a thing like that and you're like, "Oh, my God, that is a horrible idea," that you try to sort of stop yourself in that moment and say, "Okay, wait a second. That is an interesting thought. Can you please walk me through your thought process of how you got there?" It's basically about approaching these types of statements with curiosity rather than judgment, and sort of see where that takes you.

29:56 Laila Bougria

And in order to do that, it starts with something beyond any skills. It starts with safety, because in order to basically come up with these non-obvious options with stuff that people don't usually bring up, to basically go where we haven't gone before, we're going to have to break the rules here and there. And that means that you need to know in your gut, that whatever option you come up with is not going to piss anyone off, is not going to make anyone think that you're stupid, and is not going to negatively affect your career or your reputation. And the reality is that that still requires a values and culture shift in many organizations. That's why it's so important for all of us to create that safety in the workplace. It doesn't matter whether you're earlier in your career, or you're a coach, or a team lead, but probably even more so if you find yourself in one of those influential leadership positions, so when someone comes up with an idea, that you're like, "Whoa, that is crazy, try to approach it from a different angle."

31:02 Laila Bougria

Because if we want to unleash that creativity that is happening outside the box, we want a lot of curiosity and an open mind when we are inside the box, right? In academic terms, when I'm talking about inside and outside the box, I'm really referring to convergent and divergent thinking, right? Where convergent thinking is, in this analogy, happening inside the box and divergent thinking is a lot more creative, and exploratory, and happening outside the box. And we want to do a little bit of both.

31:33 Laila Bougria

So in order to do that, one of the most powerful techniques that I've found is actually collaboration, right? And I'm not only talking about collaborating with your colleagues, your peers, doing PR reviews, and maybe pairing together, but really about inviting people with a completely different perspective. People who've gone through a different education than you have, maybe people who are working in different departments. All of those people think very differently than we do. And inviting their perspectives can be really eye-opening when we start listening to their ideas. Even for the problems that you're solving that you're like, "Yeah, but this is a technical problem." It's not easy for me to invite someone who has a completely different education while I still believe that there's value in trying to explain that to them. But one of the things that you can also consider is maybe including the people who will end up supporting this application in production.

32:32 Laila Bougria

Or maybe the graphic designer that's kept on Figma Island, right? Or how about the internet started week? All of those people think differently than us, they have a very different perspective. And if they feel safe and invited, they will start thinking about various types of options that we don't naturally come up with.

32:55 Laila Bougria

Now, one of the sort of activities that you can then engage in to sort of start unlocking these ideas, there are many, brainstorming, brainwriting, mind mapping, reverse brainstorming. There are many, even more than what's listed here, many activities that you can try to sort of unlock these ideas. But what is most important to understand is what we're trying to achieve. Because when you have an idea, you don't just have a single idea. You actually have multiple connected ideas that are happening in the brain, but they're still sort of hidden away in the unconscious mind. And these techniques can basically help us surface those to the conscious mind, and then we can start talking about this and seeing where that basically brings us.

33:40 Laila Bougria

Now, I know this picture looks all serene, and happy, and all of that, but the reality of going through a process like this is that it's incredibly messy and chaotic. And you're going all over the place and sometimes completely diverging from the problem that you set out to solve in the beginning. And that's normal, it's important to trust this process, and to basically go through that, and trust that it's going to work. But of course, we also want to manage the chaos a little bit. So maybe time-box these sessions. Or another thing that you could do is invite a facilitator, someone who is not there to necessarily collaborate and brainstorm options with you, but who is rather there to sort of point out, like, "You're 20 minutes in talking about something that does not seem to be connected to the problem that we're trying to solve," and then we can sort of manage that chaos a little bit.

34:35 Laila Bougria

So that brings us many different options. Now we have several options that we can consider to solve one specific problem, but that then opens up a big different challenge, that of our biases. And the thing is that biases have a really bad reputation, right? But if you start to think and read up on how the brain works, a bias is a feature, it is not a bug. We have biases because they're basically performance optimizations that allow us to make swift decisions when we need to. And that can be really useful if you're in traffic, and someone before you does something crazy, and you need to quickly decide what you're going to do. But in our context, when we're solving business problems, we don't necessarily need that performance optimization, because we have intentional time to think about what we're trying to do here.

35:33 Laila Bougria

Now, there are over a hundred cognitive biases documented, but what I want to do is sort of call out the top three that I have found are mostly going to affect the decision making in our work. And I'm going to do that by sharing another anecdote from my own career. So at some point, I joined this project, and I was on there for a while, and it was a mess. We were dealing with a big ball of mud. And the reason we had that big ball of mud is because at some point, a bunch of people started to leave this project and then we started to hire new folks. And those new folks, they started to introduce a bunch of new frameworks, and architectural styles, and I don't know what, and that increased the complexity of the system, and now we have this big ball of mud.

36:17 Laila Bougria

But what I just did is what is called the false causality bias, because I just called out multiple events in a sequence as evidence that one event caused the next, right? There was a lot of turnover, we hired new folks, they introduced new coding styles, now everything is getting more complex and because of that, we have the big ball of mud. But now, I'm assuming that all of these events are basically connected with each other. And is that true? I should be asking a lot more questions, like, was there a decent onboarding process for all of these people? Did they have some documentations and guidelines available telling them, "These are the coding styles that you're going to use, these are the frameworks that you're going to use"? Did someone take the time to explain to them how the system works? How it's supposed to work? Was there any documentation? Did they have access to business experts? Without really considering all of these options more widely, false causality is at play.

37:22 Laila Bougria

But hey, we were there, we continued, and we were like, "Okay, we need to deal with this big ball of mud. How are we going to go forward?" And at some point, I remember joining a meeting and we were sort of discussing the points of friction that we're facing and sort of thinking about what are ways we can sort of tackle to resolve this? And at some point, the software architect that was responsible for this project walks up, comes to the front, and says, "You know what, team? I've been really spending the last months looking at the friction that we're running into, trying to observe the problems that are arising. And I've been looking at the code, I've been listening to your problems. And honestly, there's no way back. We need a full rewrite. And with all of the knowledge that we have now, we are in the perfect position to actually pull that off."

38:12 Laila Bougria

But what's happening here is the authority bias, also known as the HiPPO effect, the highest paid person's opinion. Because the thing is that there's now someone standing up and saying, "We need a rewrite," and that person has a lot more authority than we do, has a higher paycheck than we do. And they also have a lot of significant experience both inside and outside of this project. And because of all of those factors, we just naturally assume that they must definitely be right. And it becomes really hard to start questioning that. And that's why it's so important for leaders, specifically coaches, senior members on a team, to take that into considerations when they make statements like that. And choose to even refrain from sharing their own opinions until the rest of the team has had a chance to basically share how they're thinking about this, to engage in that trade-off analysis and learn from each other. And if you start doing that, even as a leader, you will also learn, because remember, these people are maybe thinking very differently than you are. So surfacing that is a learning experience on both ends.

39:28 Laila Bougria

Okay. So at that point, we're like, "There's no way back. We need to fully rewrite this. There's nothing else that we can do." So at some point, we start engaging with management and talking to them. And we're like, "Yeah, we've spending weeks on this. There's no other way forward than rewriting the whole system." And they're like, "What? Are you crazy? It took us more than five years to get to the state that we're in now, and now you're telling me you have to start over?" So they're basically challenging us as a team and saying, "Can you bring me proof that this is actually a good idea?" We're like, "Sure, we can bring you proof." And we go back to our computers and start Googling use cases, and blog posts, and articles about a lot of companies that have gone through a system rewrite and how successful they were. And how their velocity improved, how much better they are able to keep up with market demand after going through that exercise. And we come up with this long list and we presented it to management, and they're like, "Okay, seems legit."

40:42 Laila Bougria

But what happened here is the confirmation bias. Because the thing is that we strongly believe that we need a system rewrite, and we start looking at all of the articles out there, and we find use case upon use case that is confirming that belief, right? But the thing is that we don't do this on purpose. It's not that we're all evil minds and we have this secret scheme to say, "No, we want to rewrite and we're going to make it go our way." Again, this is something that happens unconsciously, that is how the brain works. If you truly believe something, it becomes incredibly easy to find data points that further support your beliefs. And it becomes incredibly hard to actually identify and find those data points that go against those beliefs, because again, that is uncomfortable. It's completely messing with our state of mind, and it feels like we need to rewind, and that's not a fun thing to do.

41:47 Laila Bougria

But it's really important for us to basically actively find opposing evidence. Can we find articles, use cases, and I don't know what else, that is basically telling us the opposite of what we think? And also, when we look at all of these use cases that are brought by, oh, this rewrite was successful, and all of that, is our context the same? Is it the same line of business? That company, did they have the same financial means as us? Is it the same team size? Did they have a stable domain? Do we have a stable domain? We can't just look at something as abstract as a system rewrite and then assume because it's working for them, it must be working for us, without considering our specific context and also theirs when they wrote that article. Because if it doesn't mention the context that they were in, that is probably not a good data point for you.

42:49 Laila Bougria

Now, I'm wondering, who could recognize themselves as part of this story at one point or another? And that shows how our biases affect us on a daily basis as we go through this. So if you've been listening closely to this story, there is one word that came up multiple times and that word is assumption. An assumption is basically a statement that we believe to be true to the point that we're not going to question it. It's like breathing air, "I'm not going to validate that, that doesn't make sense." But this is exactly where we want to place those breakpoints. This is where we want to go and inspect, is this actually true? Go to someone and ask, why do I believe this? Is there any data point that supports this? Is this true in this specific context? It might have been true in some project in the past, is it true today? In short, don't assume, validate. Take a moment to find the right people to ask. Find the right data points that can further validate whether you're thinking in the right direction.

43:57 Laila Bougria

Now, to catch all these biases that are occurring, that is a really hard thing to do, because again, it's happening unconsciously, right? It's happening in the brain. It's not that we choose to have these biases. But there are multiple techniques that can help us catch these and be aware of them. Now, the first technique that I'm going to bring up is probably going to be unexpected, and that is mindfulness. Who practices mindfulness in any shape or form? Okay. A couple of hands. Feels like mindfulness, "Oh, my God, that's a fad." You can be honest, it's fine. So guess what? I'm wondering, who in the room likes to build LEGO? Okay. Many hands. Guess what? Lego is a mindful exercise. There's proof. I'm not just stating this, this is from the LEGO website. They have a whole page dedicated to mindfulness. They even co-authored a book on the topic. Sorry?

44:58 Audience

It's a confirmation bias.

45:04 Laila Bougria

Even brushing your teeth can be a mindful exercise. But you might be asking yourself, wait a second, mindfulness is supposed to be a technique to handle stress, to cope with anxiety, maybe even help with depression. What does that have to do with biases? How are those things connected? But if you start to think about what mindfulness really is, it is not much more than basically engaging in activities that allow you to be present in the moment. And when you are present in the moment, you have this ability to basically observe the thoughts that are coming up in your brain. And when you think about it that way, it's actually the perfect tool to be able to catch those biases, because when a thought pops up, you can be like, "That's interesting. Why do I think that? What is driving that thought process?" And start to question yourself. Now, I hope I've made you at least a little bit curious about mindfulness and how it can help us solve problems and catch our own biases in our thought process. But if you're still like, "Nah," then don't worry, there's other techniques for you.

46:10 Laila Bougria

And the next one I want to talk about is our devil's advocate. That person that we all know that we perceive at at least a little bit annoying, because they keep asking all of these difficult questions that are derailing us from what we want to do. Who has a devil's advocate on their team? Who is the devil's advocate on your team? Okay. That's good. Now, I think there's actually value in purposefully assigning a devil's advocate on your team in a specific problem case. Now, it's not the idea that they're going to be part of that problem-solving process, but rather take on the position of a devil's advocate as an outsider and start observing the thought process that is going on in the group. Basically to catch that group thing that is happening and the biases that may be driving possibly faulty decision making, right? Their goal is not necessarily to come up with solutions, not to make your life difficult either, but rather to surface those biases that may be occurring.

47:17 Laila Bougria

And the thing is that if you purposefully assign a devil's advocate, it also means that you can rotate this role. It doesn't have to be the same person every time, right? You can start to rotate this role even with people who are not natural devil's advocates, they can start to engage in that process. And by doing that, everyone basically gets better at pulling apart those thoughts. And if you start getting good at doing that with others, it also means that you are getting better with doing that with yourself as well. You start to have more of that inner reflection.

47:54 Laila Bougria

And then I have a final technique that I want to talk about and that is a wider request for feedback. Now, what we're going to do here is basically invite people who were not involved in that process at all. They haven't been looking with us at the problem, at solutions, at nothing. And we're just going to present to them, "Hey, this is the proposal that we want to move forward with." And then basically invite them to basically review that. And because they're so far away from all of the details, they are better able to catch maybe those biases that are going on.

48:29 Laila Bougria

But you might be thinking, "Seriously, Laila? Do you know how hard it is to get a meeting with five people, let alone with 15 or 20 people?" That's impossible, right? I know, I agree with you. And that's why the mighty pen can help you again, because if you write down your decision making process and say, "This is the problem we're facing, this is the context that we find ourselves in, these are the assumptions that we are making and this is how we validated them. These are all of the possible solutions that we considered, these are all the risks associated, and this is our proposed solution."

49:09 Laila Bougria

If you then present it to anyone, you write that down, you're scaling that process. You can send that document to anyone. You could even publish it on the internet if you want. And because you are going so wide, it also means that you don't necessarily need everyone to review and to give you feedback. You can start making use of a deadline and say, "Okay, whoever has commented within that timeframe, great. Whoever didn't get to it, that's fine. We had such a wide group that whoever has answered within that timeframe is good enough for us to help." Now, these are called RFCs, Request for Comments, who's heard of those before? Anyone that uses them actively for their decision making. Okay. Couple of hands, great. Actually also have a dedicated talk on how to build an RFC, what components go into that, so be on the lookout for resources at the end.

50:03 Laila Bougria

I still want to share why I think this is so useful, because again, we're forcing ourselves to slow down a little, write all of those things down. We keep convincing ourselves that we're going to remember all the details and then we don't. But if we've made a decision a year and a half ago and we can go back to that document, we can see how it has evolved. We can search it, we can verify what was our context at the time? What were the assumptions that we were making? How valuable would that be when things go wrong? And you can pinpoint, what it is that went wrong?

50:38 Laila Bougria

Now, there's a couple of things that I really want you to take away as I'm nearing the end of this talk that I really don't want you to forget, so I'm going to recap a couple of these for you. The first one is that we really want to be conscious and slow down. And I really understand how incredibly scary that this sounds in a fast-moving industry, where all of those quick results and those successes are basically celebrated, they're rewarded. If you come up with a solution quickly and everyone's happy, everyone's like, oh, pat on the back, well done.

51:15 Laila Bougria

But if you start to observe at scale, how much time we waste, how much time we lose because we jump in too quickly, because we haven't really taken the time to understand what is going on, to understand who is affected in what way, and what are the best solutions to look at this, then you start to see how much there is to lose in actually jumping in quickly. Does anyone recognize that feeling? So it's really important to slow down and to say, "Okay, no, I'm going to take time for this and then hit the ground running once I figured a couple of things out."

51:56 Laila Bougria

Next, write it down. I know this is boring, I get that. I get that we would rather be coding or rather be doing something else, but there is so much value, it's going to bring you an unprecedented clarity about anything you're working on. Because you can think that you have things figured out in your brain, but once you start writing things down, it's usually where you start questioning yourself all the time and you start to find the gaps in your own thoughts. You start to find that. And even in a group setting, right? Because like I said, we want to collaborate on this as well.

52:33 Laila Bougria

And when you have a decision-making thought process that is written down, you also have something that multiple people have aligned on and there are less communication issues that are possible, because all of those people align on the words that are written down there. There's a lot of value in that, especially in a time where there's also a lot of internationalization and people speak different languages, and all of those things also affect us. And by writing things down, you can also scale those processes. Remember that people can read two to three times faster than they can listen and sort of process information that is being told to them, okay?

53:15 Laila Bougria

And finally, collaborate. Now, if I'm being honest, it's only over the last couple of years when I've really started to collaborate in the sense of problems with people that have different educations, completely different perspectives, that think really differently than me. And honestly, the way that I have grown through doing that is a growth that I hadn't even thought it was possible, because they think so differently. They have a different view of the world, that I'm learning so much, I'm widening all of my perspectives. And this is true for everyone, right? They're also learning from our perspectives. So having that rotation sort of built in, inviting people who think differently than you can be extremely powerful. Now, we've really entered sort of a new age, right? There's AI everywhere. How many of you have seen an AI talk already at the conference?

54:13 Audience

Yes.

54:15 Laila Bougria

We have basically ChatGPTs or Copilots wherever we turn around. In the browser, in your IDE, on your mobile phone. You can't get away from them. And these tools are incredibly powerful, right? A tool like Copilot is able to generate code more quickly than we're able to fill in the prompt to ask for the code that we're actually looking for. And these tools are basically in their infancy, we just started. So who's to say that in years, and years, and years from now, code doesn't become a commodity? We don't know that, right? But that actually adds more importance to our ability to debug our thoughts, to pull our thoughts apart so that we can make well-balanced decisions when looking at the output of these tools to decide, is this something that we want to incorporate? How is this going to affect our project? How is this going to affect our team? And we need a lot more of these skills.

55:15 Laila Bougria

Even now, if you look at the global job market, the most sought after skills are complex problem solving, creativity, and critical thinking. And I think that's only going to become more and more important. So as you're here at the conference, fill your toolbox, learn about all of these new frameworks, all of these new technologies, these architectural styles, the best practices. But when you go back to your project, slow down, think about is this actually what I need? What is my context? The person that was speaking at that conference, what context were they saying that this is useful in? How does this affect my team? Write things down, validate it with others, and collaborate with other people. Share that knowledge so that when it's your time to implement all of those things, you can make the right decision.

56:10 Laila Bougria

And that brings me to the end. Now, as always, I've gathered a sort of list of references for you. I didn't just invent all of the things that I'm saying, it's backed up by a lot of knowledge by a lot of incredibly talented people. So if you want to read more, I have a lot more information there. There's also a link to my talk on how to do RFCs. If you have any questions, I'm happy to take them. If you don't want to do that now, then hold me when you see me walking throughout the conference, come say hi. I would love to talk to you. And you can always connect and ask me questions later as well. Thank you for listening.