Tackling Sociotechnical complexity in the heart of your team

[00:00:00] Welcome or bonjour probably is the best way to say it. but that's as far as my French goes so um that will be it for the rest of the presentation. Um today we are going to talk about tackling social technical complexity in the heart of your team. And we have heard some stuff about the social part in software development already. Uh the keynote talked a little bit about culture, uh I've seen a talk from Jurgen who was uh going into uh how we're working together and today Kenny and I uh will be talking about social technical complexity only in this talk. Um and we always like to start with some story that is related to our topic but not really something that we actually are doing in our daily lives. So we are from the Netherlands, um and we have these people in our country. Uh and if you're not from the Netherlands, you don't recognize it, but these are the people who are taking care of our public green areas in our neighborhoods. And every time I'm working from home or I'm at home and I see these people, I always think to myself, wow, is this really the most effective way of doing stuff? Is this really the most effective way of organizing a team? As you can see, some are even uhm hindered to communicate at all with each other, they cannot communicate because they are wearing these these these headphones and they are not communicating at all. And what they're doing, they um, they come up in usually in teams of four and they all have their own discipline, they all have their own tool and that's what they will be doing for the rest of the day, so there's usually one people, one person who's shuffling and there's one people with a leaf blower and then there's always one person who just stands there. And he is hanging on his on his shovel and just overseeing everything, I guess. Uhm, but I'm always thinking, yeah, this this there should be a more effective way of doing stuff. Uhm but what we're missing here, I think, is that we are not seeing the bigger picture all of the time. Maybe it is the most effective way of working, maybe it isn't. But what I'm very often seeing is that we are getting in each other's way and these people are getting in each other's way because there's actually this example of one people, one person shuffling some leaves and then there comes one person with a leaf blower and then everything was all for nothing. Uhm so people are doing counterproductive stuff and this is not only happening in uh in this example, but we also see that in our uh in our daily lives.
[00:02:07] So when you reflect back and I'm a software developer, uh been developing for quite some time. Uhm, I started out and you get these refinements together where you decide on your model, you decide what you're going to do and then after the refinement, I will go here and Evelyn will go there and we're sitting at our laptop, right? Who recognizes this part? So the developers goes back to their own laptop and starts. Yeah. And then three days later we need to resync, right? Maybe two, three laters. If it's one day, perfect, but maybe sometimes it's three, maybe it's two weeks. We come back together, there will be a PR, right? And then the other person will review that code. Who recognizes that after a couple of days? Yeah, so we we sync up again and then it's like, oh, I didn't really expect this.
[00:03:01] Right? Who had that? That you were thinking that the other person was writing some form of code and then after three days like, huh? Yeah, alignment is really hard and we're in software, so we don't actually see it. But when you go uh to hardware stuff and thank you Nick for these uh nice pictures, you get stuff like this. And I know Nick showed one with the three uh toilets sitting next to each other, right? I love these pictures. But let's say this is your software, what are we going to do now? You're not going to rewrite everything, right? That takes days again. So what are we going to do? Well, let's build a small little bridge here, maybe a small little bridge there. Right? So that we can work around it because yeah, we spent so much time working on that code already. We spent three days. Yeah. It actually has a name, which I found out. Because I was in this situation all the time, right? I was happily coding and and then, ah, let's just metal a bit here and this is how technical dept usually comes in. And it actually has a name, it's the sunk cost fallacy. Why change now? We've already wasted so much money. So let's just waste a whole lot more money. Right? Recognize this part? Yeah. So uh that's the hard part and now I'm looking at low code platforms.
[00:04:24] And it's happening again. It's happening again. Problem, as application teams grow, delivery slows down, multiple developers compete to change the same code. And well, I have some experience now, so I would just say, have you tried speaking together? Pair programming, mob programming. Because I've been here, but now I see it happening again and why are we constantly looking in our tools to solve the problems we have? Why don't we solve it in another way? And and that's the thing, autonomy has become so compulsive, we need to remember we are still tribal creatures that require tribal safety, right?
[00:05:00] Definitely. Yeah.
[00:05:02] That's where I come in.
[00:05:03] Yeah. Yeah, I'm the social scientist of the two and uh the autonomy part and the the tribal creatures with the tribal safety, that's a very important thing actually. And the thing that we need to remember and that we very often forget is that we are not only investing in technology, mainly we are investing in people. And even though when we're talking about investments, we are mainly talking about investments in technology because that's the most easy part. But actually by investing in our people, we will get better results, we will get a more sustainable delivery process. Uhm because in the end, and this was also something that came up yesterday at the speaker speaker dinner, we are writing code for other human beings and not for computers. And that was a very interesting discussion that we were having there. Uhm but I strongly believe that almost every technical issue that we see, and it's very easy to see technical issues because they are there and we can grasp them and we like them because they are these shiny puzzles that we can solve and there is something that we can deal about it. And as soon as we we dive into the social part of things, as soon as we have to deal with interpersonal relationships and politics and actually talking to people, things get messy. We don't like that because it's it's less tangible, it's more abstract than that. So the thing is that I strongly believe that almost every technical issue is a consequence of organizational issues. So that the root cause of the technical problems is actually in the organizational problems, in the people problems. And still we are investing more of our time and effort and resources in technology. So that's kind of weird. Uhm so that's why uh the essence of today will be about social technical systems. We don't believe that we are operating and working in technical systems, we don't believe we're operating in purely social systems, but we are working in socio technical systems. And that is all about the uh their interaction and the relationship between technology and people. Uhm very often we um we neglect that, it's a very complex relationship, um but this is what we should be investing in. So we should start observing these social technical systems, treating them as social technical systems. Uhm and looking at multiple uh multiple perspectives and multiple aspects here. So that is what we uh what we want to talk about today.
[00:07:03] Yeah. So let give you a simple um simple example. DevOps, who's been working in DevOps companies, right? So I always make the joke of getting a posted, put it on the wall and just write DevOps and now we're DevOps. Right? Putting Dev and Ops together, uh, that's all there is. Because it's simple, just put them together and they will do DevOps, right? Really simple, basic example. It doesn't work that way because we have ranking. What I observed lately was uh business analysts also in the team, but they still own the team. They're still the highest in ranking, so if they decide that we don't do testing, there won't be testing.
[00:07:45] Right? So that's the first problem, we have ranking, we actually have ranking within teams that you need to be aware of. Secondly, I've been in this situation where I got an op sitting across from me, but I was still writing Jira tickets towards him. The Jira driven communication, right? Who's been in that situation? I've done it. Person was sitting next to opposite to me. Communication didn't really change. We were still using the same tools, things didn't change. And what we actually call that uh in system thinking is shifting the burden to the intervener. My burden was sometimes testing or sometimes ops. So I'm shifting the burden to another person. So I don't need to own it myself. Because it's simple, right? Autonomy. But actually what you lose is actually ownership of the whole case. Right? That's the first simple uhm example we have of when to observe social technical complexity and uh and systems. So the other one is a more familiar one is who's working in open spaces nowadays?
[00:08:50] Wow.
[00:08:51] Wow. Same here, I feel uh. So what happens is it should be improving your communication. That was the promise we get.
[00:09:03] But uhm this happened. It's the same as these workers actually at the start, right? We get headphones on. So I already tell you, communication is essential here because if we get in each other's way, oh, let's put a tool into that. Well, here you have another tool.
[00:09:20] But maybe just sit together and talk about the solution. And that's another part of it. And uh I by the way, hereby, I'll show you the next stage of this development. It's this. It's the next step. Yeah. Because we want to because really sometimes we need to isolate ourselves, right? If we're working on a problem, yes, we need to isolate, but it's context specific.
[00:09:43] Who would like this?
[00:09:46] Yeah, so these are uh simple examples.
[00:09:51] And it happens for a reason.
[00:09:52] Yeah. There's a reason for this and it's called cargo culting. I'm not sure if everyone's have has ever heard of it. Uhm but this is actually a great story that goes all the way back to World War two in the in the deep Pacific Ocean actually. Uhm there was a tribe there and all of a sudden they were just mining their own business, doing their own thing and all of a sudden there were these big metal birds appearing in the sky. Also known as airplanes for us, but they saw big metal birds. They've never seen them before and all of a sudden they were there. So at first they were kind of scared, but then these planes actually landed on their island. And they started giving them free stuff. Food, cargo, that's where the name comes from. Uhm and they were like, okay, we like these things. And then World War II ended and the planes left. And they were like, yeah, um okay, we liked these metal birds. Maybe we should copy them, maybe we should build exactly these things and maybe we will get more free stuff. They were actually thinking this would be probably, this would be our ancestors giving us some some some food and a better life. So what they started doing, they started building the building almost exact replicas of the things that they saw from wood. So they had no clue about the technology, they had no clue what these things actually were doing. But they were building these things from wood and just placing them on the island, including landing strips and then they just wait. Like, maybe we get more food. But um this is where the name Cargo Culting comes from. And there's also actually a thing that's called Cargo programming and that is the art of programming by coincidence. Just doing stuff, copying stuff because it worked for someone else, it should work for us as well.
[00:11:25] So just put Dev and Ops together.
[00:11:26] Exactly.
[00:11:27] They're DevOps.
[00:11:28] That's the that's the exact same thing. So, um, but obviously it doesn't work like that. So, um, this cargo culting thing is actually that's going on in our working lives and our office spaces as well. Uhm and this is uh another picture of the airplanes that they were building, but this is a more cool picture of a wooden uh replica of a of a spaceship, but this is the same thing that's going on there.
[00:11:51] So the idea here is that there are useful principles, universally useful principles in every approach, in every new kid on the block. I mean, Devops, Lean, Scrum, Agile, whatever new kid comes on, there will be useful principles that will be universally useful and you can take them. But by just copy pasting stuff, you won't get there, you have to be aware of what this will do to your culture, to the people who are working in it. So just copy pasting stuff for the sake of it or because it worked for Google, so it will work for us. That's not gonna happen. So we have to see which principles of each approach, each method, each each new kid on the block will work for us in which specific situations and then start using that.
[00:12:32] Sounds a bit social.
[00:12:34] Thank you. I take that as a compliment.
[00:12:36] Let's take a step back and uh talk talk a bit about what's culture. So uh we were here at uh and I've been here before at the meetup and uh during the lunch here, we were like walking in and we saw these bottles of wine and like, what's happening here? We're from the Netherlands, we don't drink wine during lunch. But that's what you do here, that's the culture here. If if you wouldn't get that, some of you wouldn't get that, you will, why are why are we stu, right? When you go to the Netherlands, we eat at 6 o'clock.
[00:13:07] So I came here during a meetup and at 8 o'clock, I'm getting hungry. Right? Because that's how we do things and that's culture if you wrap it up in just one sentence, the way we do things around here. And that's the essence where you need to look after when you start implementing or start taking these useful principles, right?
[00:13:27] Yeah.
[00:13:30] And that's where we get back to the open office space again. Uhm this was supposed to improve our communication structures. This was supposed to help us finding each other more easily, communicate more clearly, more interpersonal communication. Uhm but actually there is uh quite some research about these open office spaces and they don't improve communication structures. Um we also we already saw the examples. Uhm but there is also research that actually states that this is the most expensive way of working in an office. Uhm very often the argument is, yeah, but this is cheaper, we are throwing down walls and this will be cheaper. But actually people get more sick in this uh in this space of working, in these open office spaces, they are not happy, they are dissatisfied, not motivated, this is actually the most expensive way. So just because Google or Spotify is doing it is not a reason for us to do it. That's also the reason why I kind of hate these open office spaces, although we are working in in one. Uhm but this is the reason why you cannot just copy and paste stuff. You have to be aware of what it will do to your people. If in the end you're copying something and then all of your your employees are not motivated anymore and not happy anymore, then they won't build any great products anymore. So that's the essence here.
[00:14:39] And then we get to something that's called my precious, um which we know from the Lord of the Rings, but I hate Smegle, so um I choose this this this picture. Uhm and all of a sudden once we copied something and here come here uh the sun cost fallacy comes in again. Uhm we hold on to it because we will make this a success. Doesn't matter what it cost, doesn't matter how much we need to invest, even if we already invested way too much and it's not bringing us anything, we will make this a success. Anyone recognizes this?
[00:15:09] Yeah. So that's why we always say that you cannot, well, you can copy a model, but you cannot paste a model. Uhm and that is a very important lesson to remember, we feel.
[00:15:18] And I've literally heard that, don't don't mention this anymore because we know it's bad, but it's not good for the people to talk about it. Okay.
[00:15:26] Okay, yeah, well, let's not mention it then anymore. Uhm but these are all examples of this social technical complexity that we have to deal with. Uhm and if we are not handling the social technical complexity properly, if we are not trying to do something about it, if we're not trying to solve it, then it will result in losing the bigger picture, the sense, shared understanding, vision and mobilization.
[00:15:48] And by coincidence, these are the things that we really need if we want to improve, if we want to scale, if we want to innovate and if we want to get better at what we're doing. So, um, the social technical complexity is a result of multiple aspects. Uhm not surprisingly technical and social. Uhm so the the result of technical aspects, cognitive aspects, social aspects, but mainly the interrelation between these aspects. So what we want to do today is we want to talk about all these three aspects, we have some examples, see how we could uh how we could, yeah, deal with them and how we could solve this uh this complexity. Uh we're starting off with the technical aspect.
[00:16:23] Yeah.
[00:16:25] So um who here likes to do or knows TDD is good. Or wants to use the principle TDD. Right? Always?
[00:16:38] Well, that's there's the part again, that's the technical aspect. So when we get to decide in a team, let's go to a team, should we do TDD? How do you decide when to do it or not? Usually it just says, well, there's a book that says it's okay for me to do it. But we're actually not sure if it works. You can experiment, which I say, well, great, let's do it. But let's take a step back and uh look what Dave Snowden came up with called the Kinavan framework. Who knows the Kinaven framework?
[00:17:06] Wow, nice.
[00:17:07] Great. So this is the first part where so then I probably don't go into it a lot, but this is the first step to deciding do we need these technical aspects or not. Right? So let's start with the obvious here, which is the obvious over here at the bottom one. And the obvious is everything that's obvious to do. So for us it's uh changing a beer keg in the Netherlands, it's really obvious for us. It's just look at it, do it and then go on tapping. Because yeah, you like wine here more, we like beer in the Netherlands, only not Heineken by the way.
[00:17:44] Uh so that's obvious, right? Just do it. And waterfall actually pretty well works here. Because why not? We know what it is. Then we get to the complicated part. And the complicated part is actually, I always uh do it as a watch. A watch for me is complicated. But with enough knowledge, I can pick it apart and I can put it back together and it will work again. It's the same like your IKEA uh thing when you get a more complicated IKEA thing to build. You just sense, you analyze and then you build the thing. Right? It doesn't change. So that's complicated and stuff like Scrum and Agile start to work here pretty well. But then we can move over to the left side, which is the complex part, which we're very usually in. And it is with humans. Humans are usually or humans are always complex. They change their behavior. Every time the reaction would be different. Okay, so that's complex. Every time things change. So can you really say this will always work in a complex situation? No, because things change. So when things start getting more complex and complex, things like TDD won't work anymore. Because what test should I do if I don't know it's the domain of the unknown, unknowable. If I don't know, how can I write a test? So what we do is probe here more, so try experimenting more, see if stuff actually works. And then the lower part is when you organize a kids' party and throw in a lot of candy, it will be complete chaos. So when the alarm pops here, the fire alarm, the only thing, the only reasonable thing to do is act. Go out. Check what's going on, then respond. So it can be a fake uh alarm, but first, please move out. Because it's chaos. Right? So that's the framework and you can move from here to here, it's possible, not always, but can be possible. And there's also a there's also a small slip here. You can actually move from obvious to chaotic. With that beer keg, if I forget something, the beer keg will actually explode. So it will be total chaos. There's actually a company who went bankrupt in one day because they went from obvious to chaotic, they forgot to upgrade one server of the nine and it was an investment company, well, next day they were bankrupt. So as you can see, you can move from obvious to chaotic, but you cannot go back. So that's the thing, so if we try to make sense of where we are, we know for a first step in our team, what principles we can use.
[00:19:41] It's possible, not always, but it can be possible. And there's also there's also a small slip here. You can actually move from obvious to chaotic. With that beer keg, if I forget something, the beer keg will actually explode. So it will be total chaos. There's actually a company who went bankrupt in one day because they went from obvious to chaotic. They forgot to upgrade one server of the nine. And it was an investment company. Well, next day they were bankrupt. So, as you can see, you can move from obvious to chaotic, but you cannot go back. So that's the thing. So if we try to make sense of where we are, we know for a first step in our team what principles we can use. Right? You have all these universal principles. The book Accelerate talks a lot about research about them. If you know where you are, you can actually find out if it's good to work in it. So for instance, Agile really works in complex ways. Scrum between complex and complicated, Scrum will be better. Right? So just know and sense in your team where you are. And don't have my pressures, like, we're all going to do Scrum now. Well, have fun with that. Never works in a whole company because everyone is different in your company. And every team is different in your company, so just check where you are and decide which one of the frameworks I'm going to use.
[00:21:08] Make sense?
[00:21:11] So, great. So we're going to now jump into the meeting room and decide together how complex our environment is. So who still does meetings in this way?
[00:21:23] Oh, that's a lot less.
[00:21:24] Yeah, awesome. So what happens here and now I hope it starts.
[00:21:29] Nope, or not, then I will make it start.
[00:21:31] Yeah. So this is an interesting part, this woman has a problem, she needs to know the direction, right?
[00:21:38] Yeah. This is actually a Portuguese sketch. We have a Portuguese colleague and he showed us this example and we really like it. So, at this point, your first stakeholder is entering the scene. He has some ideas. Maybe we should go there, the direction, we should go in that direction. And this woman is actually, she wants to get somewhere, she's lost, she doesn't have a map. And this person is telling her you need to go straight up, straight up, then to the right, at the church to the left, and then you're there, it will be fine. Then the second stakeholder enters the situation. And he thinks, well, what you're saying, that's completely wrong, you have to go left here, the shorter way is this, the better way to do things is this. And she already gets a little bit more confused. But this is actually, it's it's a funny sketch, but this is what's what's happening when we have to deal with multiple stakeholders. This is not it, there will be more stakeholders entering this scene. There's the third one. Um, so but this is happening, and it's not getting any clearer or better for this person who actually asked for directions. So these are a lot of stakeholders battling over the best idea. I know my idea is best. No, my idea is best. I know better. Um,
[00:22:43] Who recognizes this in their meetings, the several stakeholders, yeah? I've been there.
[00:22:48] Maybe you should show her this video in your for in your next meeting and then we can all have a good laugh about that. So this is this is what's happening a lot and this goes on for a while, this video, but you get the essence, I'm figuring.
[00:23:02] And that has a lot to do with with the cognitive aspect of socio-technical complexity. Cognitive bias. Um, our brain is a really funny thing, and cognitive biases are impacting a lot about what we're doing. So, um, cognitive bias or heuristics are actually mental shortcuts that we use all the time to make sense of the world. Um, and there are whole studies about this, so, um, the shortest way to explain this is, um, well, probably you should read the book Thinking, Fast and Slow from Daniel Kahneman. Um, but we have two systems, we have a system one and we have a system two in our brain. And our system one is kind of our automatic pilot. It just knows how to do stuff. The reason that you didn't have to think about every single decision that you had to take in order to get here this morning is your system one. You know what you're doing, you have done it before. Not that complicated, not that complex, so you just know what to do. And that leaves you with some time to spend with your system two. What you can actually use for more rational decision-making is more deliberate, it's it's slower, and that will help you make rational decisions, thinking about stuff. So, in most cases, the heuristics and the biases that you are suffering from or actually not really suffering from because in most cases they help you make the best decisions of your life. Um, you can mostly rely on these heuristics because they help you make quick and effective decisions. But in some cases, it is actually better to address your system two actively. For example, the sunk cost fallacy that Kenny mentioned in the beginning. We hold on to stuff, and we will throw more money to the problem, we will throw more developers to the problem just because we already invested in it so much. Financially, emotionally, we we are involved in this thing and we're not letting it go. So, that's a problem. In that case, you might want to think rationally and use your system two in order to make the best rational decision in this case. So, there's not just one cognitive bias or heuristic. Um, this is, um, an index of mainly all the biases and heuristics that are there, so you can imagine that we're not going to talk about all of them today. Um, but this helps me in, uh, in getting some more sense about this. I like I said, I'm a social scientist, I study these things. Um, these I think these are really, really interesting. Um, and we will mention a few today in this, uh, in this talk, but there is actually, there's way more, uh, more available on that. But this cognitive bias Codex can give you an idea of where to start. And this is divided in four categories, so too much information, not enough meaning, need to act fast, and what should we remember? And there are all heuristics and biases related to these categories. And they will help you start understand what biases you are suffering from. So, if you are working in a in an organization, in a team, these biases are always affecting everything that you do. And if you are not able to recognize them, if you're not able to recognize the fact that you are being biased and that you are being affected by all these things that your brain is doing, then you might not make the best decisions. So, um, our advice is to mind these cognitive biases. And of course, it's not something that you just start doing because it's a very difficult thing to do. But just being aware of these things existing, that they are there and that they are affecting everything that you do, is a great starting point actually.
[00:26:10] There's a new one actually. So there's the IKEA effect. You know the IKEA effect? So just because you build it, it has more value than if someone else built it.
[00:26:19] Yeah.
[00:26:20] Uh they rebranded it to the IKubernetys effect. Just because I build the Kubernetes cluster myself, it's more valuable than.
[00:26:27] Yeah, that's that's also the thing. This is this is an endless list. There will be
[00:26:31] It's an endless list.
[00:26:31] These are just the ones at this point that are in, but it's an endless list and it's it's very interesting.
[00:26:37] Yeah.
[00:26:38] Yeah. So, um, this is actually another heuristic, the magical number seven plus or minus two. And that is everything to do with how many complexity we can handle. There is a limit in how many complexity we can process. Uh, we are processing a lot of information all the time. And these heuristics help us, but if we try to process more complexity than our brain can handle, there will be error, and it will be chaos, and that's not what we want.
[00:27:05] So, even though we know that there is this magical number seven plus or minus two, we try to get as much complexity into our brains and into our meetings and into our projects as possible. But that will go wrong eventually. And to illustrate this specific heuristics, I want to do a quick test. Um, no worries, you cannot fail or or pass. But it's about beans. So this is one bean, right? We all, we can all see one bean. So I'm going to show you a next picture and just think of yourself how many beans do I see in this picture?
[00:27:40] That was pretty easy, right?
[00:27:43] Okay, we're doing this again.
[00:27:46] How many beans?
[00:27:47] Oh my God. It's I'm seeing different answers.
[00:27:51] Between 9 and 11.
[00:27:53] Somewhere between 9 and 11. But it got harder, right? Okay, we have one more.
[00:28:00] How many beans did we see?
[00:28:02] 20.
[00:28:03] 20.
[00:28:04] Yeah. Even though there were more beans, it was easier to see it, right?
[00:28:08] So there's this funny thing about complexity. Um, even though we cannot handle that much complexity, but there are ways and tricks that we can use to deal with that complexity. And one of them is visualization. And visualization not only helps when it comes to counting beans, it actually is a very useful tool in, uh, in collaborating together.
[00:28:26] Yeah.
[00:28:27] Oh, oh, sorry.
[00:28:28] Go back.
[00:28:28] Go on back, sorry.
[00:28:29] So who knows this book, Visual Meetings?
[00:28:32] Great.
[00:28:33] Right? So when we think back of that conversation in the car where someone wants to know the way. Well, if you, if you would have have a map, it would be so much easier to guide you to the way you wanted to go. But they were just shouting like the meetings rooms I'm usually in, right? Around the corner. But if we just do visual meetings, so use graphic sticky notes, ideas, mapping to transform productivity. We can handle more complexity. Because we're actually sinking a lot better, we're making the implicit explicit here. And me coming from the domain driven design, uh, scene. Uh, I use a lot of these visual collaboration tools like event storming, domain storming, telling, example mapping, impact mapping, user story mapping, bounded context canvas, business model canvas, there's a lot. Right? But I use these in my toolkit that when I'm there and even just a few stickies or just writing already helps. And I would advise you to read that previous book. Because it already helps dealing with the complexity. Especially event storming is really cool. I got married last year, uh, I did my event storming with my future parents-in-law. Yeah, to plan. Everything went perfect because they were saying, well, you need a first dance and me and my wife like, no, we're not taking a first. Then we took off the posted in front of them and, no, we're not going to do it. And it helps because now we discussed it more clear, right? But it they helped me a lot because I never got married before and they did, so. We had a lot of information from them and it turned out perfect, the planning was perfect. I'm not really great at planning, but this really worked well. And I keep using these visual collaboration tools to make sense of the complexity we're dealing with.
[00:30:20] So and that's what we try to do, we create a shared sense of reality here.
[00:30:25] And that's the thing we want. Documentation is not creating a shared center of reality. Uh especially on a wiki, it's there to die.
[00:30:35] So whoever read a wiki page and say, oh, it's really clear now.
[00:30:39] Thought so, yeah. So Wiki is helpful for some parts if if it's really obvious for instance, if something is obvious, just write it down there. And it will stay obvious if it's complicated, it stays there. But when we're dealing with complexity, well, it will just be there, but it will already change the moment you put it on there. Right? So we need to create this shared sense of reality. We need to put these people together in a room doing these doing these event storming sessions.
[00:31:09] However, coming back to what I previously said, we have ranking in group, we have group dynamics. And so we dive into the social aspect of this talk. And the social aspect is what's happening now in this group dynamics. So what, what do you notice here?
[00:31:27] Anyone notice anything?
[00:31:30] Pointing at the bird. Yeah.
[00:31:31] This one, right? So, um, two cultural anthropologists in the Netherlands showed this to their audience. And he say, well, you always know this bird, right? There's always we know these people who are just a bit different or weird. We usually use the word weird. Who, who?
[00:31:50] Who's thinking of someone?
[00:31:52] Someone who's thinking of someone, who's thinking of themselves?
[00:31:55] Yeah.
[00:31:56] So then they showed this and in the Netherlands we call him Harry. Because they show it at a group and say, ah, that's Harry. Yeah, yeah, I know. This is Harry.
[00:32:05] Maybe it should be Henry in France.
[00:32:07] Yeah, maybe it's Henry, yeah. And and we all know this person. The thing is that there's a cognitive bias here at play again. And that's called the fundamental attribution error.
[00:32:17] Yeah. So, um, the reason that we are calling this hurry or Henri weird or crazy or it's the idiot or we have there's hurry again, that's how it goes because we find him a little bit annoying, but that has everything to do with how our brain works. Like I said, we are dealing with a lot of information, we are processing a lot of information. So if we would it's very useful that we use some stereotypes, so that we do not have to observe everything, process everything and then come to a conclusion about a certain person. Um, so the reason that we find hurry weird is this. And the fundamental attribution error basically says that if someone else is doing something bad or stupid, it's because they're an idiot. If I'm doing something stupid, there are a lot of situational aspects that made me do this. If so if Harry writes a bug, then it's like, yeah, Harry is stupid, he just doesn't know what he's doing. If I'm writing a bug, yeah, I was tired, I had a really long night last night, um, there were all there was all this noise around me. I just it was just a situation. So this fundamental attribution error is that we are over-emphasizing personal characteristics when it comes to the other person, and when it's about ourselves, we take into account all these situational aspects that we do not take into account when it's about another person. So, the solution here, and even though this is a great mechanism that can help us. But if we're working together with someone, if we start judging someone right away and we say, yeah, you're weird, that might harm us. Because Harry might have very interesting ideas. So what we could do to overcome this specific cognitive bias is get to know someone.
[00:33:48] It's as simple as that. And it's not just about getting to know his work or her work, it's about getting to know someone on a more personal level. If I know more about someone, if I know more about you, then I'm less likely to think you're an idiot. Because I will take into I will start taking into account situational factors, and that will help me formulate a less biased, more rational judgment about someone. So, if you're thinking of a hurry, then maybe you're not knowing this person well enough on a personal level. So that is something that you could do to overcome this bias in particular.
[00:34:18] Yeah. And the thing I like to use is stop meetings and do meetings as campfires and it's the same two anthropologists in the Netherlands saying that. Let's don't do this busy thing, but really start out as really connecting with each other beforehand. It can be done quickly, it can be done non quickly or later, depending on the group. But really need to start thinking rethinking the way we do meetings. First connect on a personal level. Because it really helps. And that's the thing I like to use is something called deep democracy, the Lewis method. Whoever heard of deep democracy, Lewis method?
[00:34:55] Great.
[00:34:56] So the thing is, this is why it's happening what they say. We have a group conscious, which is on the top of the iceberg, that's what everyone sees, right? Someone's wearing glasses, someone has light hair, someone has dark hair, these characteristics. Then we get to the group unconsciousness, that's sort of things you don't know about a person that makes them perhaps weird. But then at the whole bottom is actually the wisdom and potential of the whole group. What we usually do in a democracy is lose this wisdom and potential. Because we say, well, 50% or more of us decided to go that way, so we're just going that way.
[00:35:32] Uh but maybe they have some stuff that you can add to it. It's always hard to really make it fit together. But let's find a way if we can add these information. So usually when we voted, as I said, let's go right. But maybe says, yeah, well, I can go right, but can we add something to it? Can we use a motor instead of a bike or can we go by train instead of by plane? Right? We still go right, but I really need to do this and maybe it's a great idea. What this creates is more wisdom potential of the group. And more inclusion, and by inclusion you get more ownership of the entire group. Because if five of the six people go right, there will be some person not unhurt. Not getting heard about what this person wants, and that person won't take ownership.
[00:36:22] So the first thing I do in this workshop is something called a check-in. And a check-in is just, how are you today?
[00:36:30] How did you sleep? And sometimes you couple it to the workshop. So I say, well, how how are you getting into this workshop? Is there anything that's on your mind that is anything troubling you?
[00:36:41] So a good thing is I was with a colleague doing a workshop and we didn't do this. And the guy was standing in the corner like feeling a bit like this and doing a bit like that, not doing his take in the workshop and I got pretty annoyed with the person. I was like, why is this and here's the attribution error again, right? What happens, his tooth got a bit loose or chipped during the night?
[00:37:05] So no wonder he was standing there in the back. So if I would do a check-in and he told me that during his check-in, then I would change the way I was thinking about him. But there was a whole group there too. So now you empathize with someone and now you can actually say, oh, do you need anything, maybe it's not good to be here? But there's lots of these things. I haven't slept really well yesterday. Oh, maybe your energy is low instead of you're not really here.
[00:37:29] It's basically making these situational factors explicit so that you can, yeah.
[00:37:33] Exactly. So then we empathize and can work with each other. And uh, oh, it's got a bit cut off.
[00:37:39] I did it wrong.
[00:37:40] So what what happens is sometimes a conversation starts whirlpooling. Have you ever been in this situation? Oh, we discussed it three times already. Who's been in that situation?
[00:37:51] Who's been in that situation?
[00:37:52] Yeah, we call that whirlpooling. So that's the thing when people are not being heard. It's it's called whirlpooling. They're start to whirlpool, they start edging behavior. Maybe look at their phone. And when it happens three times, it's it's becoming a pattern. And I usually give a weather report. I just say to the group, oh, this is the third time we speak about it.
[00:38:13] And then see what happens. Just be quiet. It's it's three time I see this happening.
[00:38:18] Stay quiet. See what happens. The group will the group knows how to solve it. I just make him aware something is happening. Okay, so that that's the weather report. Because if you don't do it, people get into this sabotage line, they call it in deep democracy. And the sabotage line on the left part is more openly, on the right part is less openly. Well, I've it took me one hour 45 from Garden North here. Uh it's it's on there. Strike.
[00:38:47] Yeah? Because people are not feeling listened to. And and that's sometimes you want to slow down and really listen to people. During the check-in, people can say whatever they want without people reacting.
[00:39:04] If you do that, people already start to feeling heard more. And one trick I always use here and we've been using this now here too. Is at some point you get people who are a bit quiet, maybe more introvert, maybe not, but you they don't feel listened to. So what we do is I amplify and spread these things. Like we just did here. Do you recognize it? And I put up my hands and you put up your hands. We're not alone.
[00:39:33] That's a really easy trick you can start doing tomorrow if you see someone struggling to get listen to, just say, hey, this person said this, who's recognizing this? And just grab the group back. Take a moment and really listen to the person and spread this knowledge and amplify it. If you just start doing that tomorrow, you already see a whole different group dynamic. Which already works a lot better. And what you're actively doing here, and I need to credit Root Malan for this slide is expose your mental models to the open air. It's your perception. And if we just expose our mental models together and you visualize these mental models, we can discuss these mental models because it's perceptions.
[00:40:17] And then we can discuss it. Then we can see, okay, what's the best perception here? Because in the end, uh the human soul doesn't want to be advised or fixed or saved, it simply wants to be witnessed, to be seen, heard, and companion exactly as it is. And if you just in a team, if you already start focusing on this and start actively listening to people.
[00:40:37] Your technology will come. Alberto always says, software development is about learning, working code will be the side effect. Your Kubernetes cluster will be the side effect, only just listen to people.
[00:40:53] So this is done when it comes down to, right? Um, most of what we said today in this in this talk is about like trying to not judge right away. And even though that's our nature, even though that's how we are programmed, how we are wired, we like judging stuff because it helps us making sense of the world. But in some cases, it's very good to take a step back and sometimes literally take a step back and try not to judge right away. Try to find out what the situational factors are that are influencing what you're doing, how you're working as a team. Because once you start judging, you will stop listening and learning and that can really harm you, your project, your collaboration and everything that you are doing.
[00:41:32] So, um, to conclude, kind of conclude the talk, um, what we think that we might start doing when we want to tackle socio-technical complexity. Is we could start using the framework as a sense making device to aid decision making. If you know where you are, if you can figure out in which, uh, in which domain you are, it will be easier to make decisions. It will help you make more effective decisions, better decisions, less biased decisions, which is what we all want. Um, be aware of these cognitive biases. As you saw, there are plenty of them, so you won't start recognizing all of them. But just being aware of the fact that you are being affected by these heuristics and these biases will already help you and it will help you see patterns and that's the first step in getting there. Visualizing complexity. As you saw with the beans, it's way easier if you visualize complexity. Uh, event storming, uh, visual collaboration tools will really help you there. And mainly to maintain that shared understanding. Because that is eventually what will get you there. And have meetings as campfires to increase understanding and lower assumptions. This is all about overcoming that fundamental attribution error, getting to know each other, start working together more effectively. Um, so these three action points will also help you deal with everything, um, that is the result of this socio-technical complexity. You want that shared vision, you want that shared understanding, you want that shared sense of reality. Um, by doing these things, and these are just a few of the things that we can start doing, um, you will probably get closer to that goal. Um, so, yeah, we, uh, kind of this is kind of the conclusion of our talk. We, uh, of course, we are very happy to be here and we, uh, we thank the organization to, uh, to have us. Um, we, um, besides that we share a passion for social technical complexity, we also are crazy cat persons. Um, so we always conclude with a picture of our cats. Um, so I think we still have time for questions.
[00:43:22] I think so, yeah.
[00:43:23] If there is time. So feel free to, uh, to shoot.
[00:43:26] On this side. Thank you.
[00:43:30] Nice.
[00:43:38] You have to go all the way up.
[00:43:39] Yes.
[00:43:44] Hello. So you you mentioned a little bit about the weather report. Can you give me like some more examples of like how this has been useful and how you use it in the past?
[00:43:54] Uh yeah, I can give you one example, uh I was doing an audit at a company and they had a lot of problems with boundaries, whose task is what. So I was in their building and it doesn't even have to do with patterns of people behaviors. But in the building there was this doors like this all the way up and on every door there was a sign saying, um, please close the door because of draft.
[00:44:20] Because of draft. But the doors were always open. I was in the building three times, the door was always open. So at one meeting I was just saying, so whose job is it to close these doors? Yeah, it's summer now.
[00:44:36] And then I just wait. Yeah, but in the winter they're not also not closed. So that's all I did. I just gave back a factual observation like you have these things on the wall who are opened, nobody's closing them. And you see and it's what in deep democracy they say fractal patterns where a group will show a pattern. For instance, when some cup falls down and you see it happening three times, there's something in the group that and it can be as basic as that. Right? So then I just explain, well, I see this happening. It needs to be factual and it needs to be at the exact same time. Because if I do it after twice, the group will just say, oh, no, that's nothing and it will move on. Does that answer your question?
[00:45:20] Yeah.
[00:45:21] Yeah.
[00:45:30] And then you can stop running.
[00:45:32] Okay.
[00:45:33] Okay.
[00:45:34] I think that was it.
[00:45:35] Yeah. Thank you.
[00:45:36] Thank you. Thank you very much.

Transcript