#147 - Collaborative Software Design: How to Facilitate Domain Modeling Decisions - Evelyn Van Kelle & Gien Verschatse

[00:02:19] Episode Introduction

Henry Suryawirawan: Hello again, to all of you my listeners. Welcome back to the Tech Lead Journal podcast, the podcast where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. If this is your first time listening, please subscribe on your favorite podcast app. You can also subscribe to Tech Lead Journal contents on various social media on LinkedIn, Twitter, and Instagram. And for video contents, you can also subscribe on YouTube and TikTok. If you have been enjoying Tech Lead Journal contents and would like to contribute, support my work by either buying me a coffee at techleadjournal.dev/tip or becoming a patron at techleadjournal.dev/patron.

My guests for today’s episode are Evelyn van Kelle and Gien Verschatse. Evelyn and Gien are the co-authors of “Collaborative Software Design: How to Facilitate Domain Modeling Decisions”. In this episode, we discussed collaborative software design and why we need it in software development. Evelyn and Gien started by explaining the Cynefin framework in software development and the importance of having heuristics for making quick decisions. We then dived deep into discussing what collaborative modeling is, how to get people involved to collaborate, and the important role of the facilitator. We also talked about the socio-technical aspects and skills required in collaborative modeling, in particular understanding the influence of cognitive bias and ranking. Towards the end, we discussed when we should do a collaborative modeling exercise, how to structure it, and tips for doing it remotely.

I hope you enjoy listening to this episode and understand why collaborative modeling exercises can be the key difference for you to build better software. From my experience, it is extremely crucial to bring all the relevant people into a discussion and get everybody on the same picture about the solution to build and clarity on the expectations from multiple stakeholders. And if you think someone else will benefit from this episode, please help share it with your colleagues, your friends, and communities, and leave a five-star rating and review on Apple Podcasts and Spotify. It will help me a lot in getting more people discover and listen to this podcast. And I really, really appreciate it. Let’s go to my conversation with Evelyn and Gien after quick words from our sponsor.

[00:06:34] Introduction

Henry Suryawirawan: Hey, everyone. Welcome to another new episode of the Tech Lead Journal podcast. Today, I have two guests with me, co-authors of the book titled “Collaborative Software Design: How to Facilitate Domain Modeling Decisions”. So Evelyn and Gien are with me today. So happy to have both of you here.

Gien Verschatse: Happy to be here.

[00:06:53] Career Journey

Henry Suryawirawan: So maybe let’s start by hearing more about your story, right? Any highlights or turning points you have in your career.

Gien Verschatse: Yeah, I’ll start. So I’m a software developer. I did that for about 17 years. And then I moved to consulting for Aardling. That’s been great as well. If I had to give some advice to anyone listening, it’s like I kind of rushed to my first job. I was kind of happy to have one. But that first job really sort of, you know, sets the pace for everything else as well. So I wish I had taken a bit more time there, cause I was still young and living with my parents and things like that. So that was okay. So, you know, take the time to get that first job. A writer get a new job right. If you have the liberty to do that, that would be my advice there.

Evelyn Van Kelle: All right. So yeah, Evelyn. I am, well, basically, I sometimes describe myself as a social scientist who got lost in IT. I kind of accidentally ended up here. So I studied humans. I studied how they work, how they think, how they behave. I spent a lot of time studying behavioral science, cognitive bias, cognitive psychology, that sort of stuff. And then during my master’s thesis, I ended up at a very technical company. And that’s where I really fell in love with the IT, let’s say. At this point I’m a consultant, and I kind of have a, well, two things that I’m focusing on. So sometimes it’s more of a focus on the strategic software delivery part. And sometimes it’s really focused on the behavioral change part. And I really love that balance. So I really, I’m a big fan of all of these social dynamics that are flying around, especially when we’re doing collaborative modeling, but we’ll get to that in this conversation as well. So yeah, my advice or my most important lesson that I’ve learned, I would say as well, it doesn’t really matter where you think you will end up. It can go either way and it can very positively surprise you. I mean, I never thought I would end up here and let alone writing a book with these brilliant two other authors, that are way more technical than I am. But it works and, uh, and I’m liking it. So, yeah, let yourself be surprised every now and then. I think that’s the main thing there.

Henry Suryawirawan: Thanks for sharing the story, right? So it’s very interesting. So one is from software engineering background. One is from social scientist. There’s another co-author from the book, actually, Kenny, right?

Gien Verschatse: Yeah, I think he has the same background with me, like, in software development primarily.

Evelyn Van Kelle: Yeah, and he’s a real expert as well on Domain-Driven Design. That’s really his passion there. And, yeah, so I think Gien and Kenny are a bit similar, but we’re all sharing the same interest in the social part. So I think it’s a good balance.

[00:09:28] Collaborative Software Design

Henry Suryawirawan: Yeah. So I think for the audience here, you can already tell, right, what kind of session that we are going to have here. We’ll be talking a lot about collaborative decisions about software design. So I think the first thing in software development, right? Why do you think this kind of collaborative modeling is very useful and what kind of problems it tries to solve?

Gien Verschatse: So part of a job of being a software developer is to actually understand the problem that you’re trying to solve via software. You know, that’s what we do. And that is very difficult. And I think that it sort of has a long history of trial and error. I have in my career, a long history of trial and error. I had interviews. I had just written requirements. And, you know, whatever I built, it wasn’t quite right. So for me, you know, I felt like there has to be a better way to do this. So I came across, you know, Domain-Driven Design, and in there, collaborative modeling is this really big thing.

Which they state that, you know, take your stakeholders, mostly your domain experts, go sit in a room with them and visualize their problems and really focus on trying to understand their problems first. And then make sure that everyone on your team actually has that shared understanding.

I think that’s, you know, key to collaborative modeling and that’s what it’s trying to solve. That if I say, oh, it’s a lovely day. We all think maybe something different. It was like, Oh, she’s sarcastic. And so interpretations or how we see the world messes up how we understand it and collaborative modeling tries to help with that by visualizing it right in front of us so that we’re all on the same page with regards to the problem. And then with regards to how to design that solution.

Evelyn Van Kelle: Yeah. And one of the key points there is the domain experts that you’re mentioning. I mean, it’s you putting every domain experts together in a room because you want them to create that shared reality. Let’s say you want to create that shared image or version of what you’re doing. But it also means that you cannot just talk about in a language that is understandable for just one part of the group.

You have to tell a story, let’s say. So by visualizing it, it really helps in getting all of these stakeholders and domain experts like on the same page about what you’re doing more in a narrative way, let’s say. And that’s I think, where collaborative modeling is really unique. And the visualization part is extremely powerful in that sense.

Henry Suryawirawan: Yeah, one thing I pick up, I was a software developer a lot as well in the past. So I think the key thing that I pick up here is a shared understanding, right? Putting people together to actually come up with the same understanding. So I think maybe many of us here would have seen a cartoon, right, where you have three people drawing the same thing, but ended up with the different things. So I think the same thing in software engineering, right? So we have this perceptions if requirements, especially is passed down from someone to the others, right? So it may not end up with the same expectations.

[00:12:24] Complicated vs Complex Problems

Henry Suryawirawan: So maybe let’s start from there, right? Because I think still traditionally, some people think that building software, it’s a very easy thing. You just write what you want. Some people, even randomly, you can outsource, right? They will be able to produce what exactly what you want. So tell us why this is a danger. And in your book, you touch on about complicated versus complex domain. So maybe if you can relate a little bit about that, that will be great.

Gien Verschatse: All right. I think like my first job, which I spoke about, it was in a tank station, right? So where you go with your car and you fill them up with gas. A gas station, I think is a better name in English. And it didn’t look that difficult, right? People go. And then a machine collects all the transactions and then you have to work through those transactions and you, you know, have to link them to a customer, and someone has to be able to create that customer. And so it seemed very simple in the beginning. But we failed to deliver what the people actually needed there, because, you know, they get phone calls, they get all that sort of thing.

So whenever you say that, hey, something looks simple, it’s probably because you’re not digging deep enough. I think if a problem is worth creating software for, then by default you just can’t say anymore that it’s simple, because they need assistance for it in some way with software. And some problems are complicated and you need to really dig and understand how they work. And some problems are complex. And with complex, in this case, we mean that we’re not quite sure how it is supposed to work, right. We were sort of going on unexplored territory. And collaborative modeling is very good at, how I see it, is bringing that complex into complicated.

Like, we experiment. We try things. It’s very cheap because most of the time, you know, we’re doing it with post-its or some cards laying on the table. And we’re trying to figure out how does this could and should work, and how it should change. So I think that’s, you know, why often the simple complex complicated and chaos model gets added to collaborative modeling to show that, you know, when something is complex, you sort of need to get it to complicated, because you need to create software for it.

Evelyn Van Kelle: I think that actually might be a heuristic, right? If you, as soon as you start to think that something is pretty easy or simple, then that’s probably your cue that you should dig deeper and that you should put a bit more time into understand what you’re doing. I mean, you hear it a lot right in groups and in companies and in teams, like, yeah, everyone will understand this or everyone is on the same page about this. That’s your cue that something is probably going on underneath there that you should dig into.

[00:15:07] Heuristics

Henry Suryawirawan: Yeah. You mentioned this keyword “heuristic”, right? So first of all, thank you, Gien, for explaining that complex and complicated. And simple, most likely, I think in software, anything that is simple is suspicious, right? So which Evelyn brought up as a heuristics, right? You mentioned about this keyword, which you mentioned quite a lot in your book. So maybe explain a little bit for people here, what do you mean by heuristics and how can we use that in software development?

Evelyn Van Kelle: Yeah, so, in general, I think like the most simple explanation or the way that we use heuristics are they are kind of rules of thumb, right? Simple rules that you use to make a decision or to move forward. And basically, you can collect a lot of them based on your experience. So based on the stuff that you’ve done a few times, or you’ve been in a collaborative modeling session, and you think, hey, I’ve come across this specific situation now 10 times, and I’ve noticed that when this happens, I will do this because that will help.

So it’s kind of a rule of thumb for yourself to see like, okay, this happens. Well, I will do this and then we can move forward. So you don’t have to really extensively and deliberately think about every next step that you’re taking. So they really help you in keeping some flow and some progress and some movement in your session and you can use them on a lot of different versions.

I mean, we name a couple of different types of heuristics. So you can use them in your design, let’s say, but you can also use them just when you are facilitating a group and you think, hey, this happens within the group, then that means that I should probably do this to get them unstuck. If you don’t see any stickies moving, for example, in the group, then that might be assigned to you. Hey, I’m not seeing any stickies moving. I will start doing it myself and hopefully people then will follow me. So it’s kind of a simple rule that helps you in choosing what your next step is.

Gien Verschatse: Yes. If the audience wants to dig a bit deeper into that, Billy Vaughn Koen has a book where he also talks about mostly design heuristics. And he, you know, says that there are these guidelines to solve problems. They’re fallible. It’s not guaranteed you’ll get the right or a good solution out of them. They’re fallible, but they will help you push you to a solution when you need to. Because software design, there isn’t one right design, you know, so that’s why writing software just isn’t easy. There’s no right solution. There are a lot of good solutions. And we need to, you know, try to figure out what works and what doesn’t work. And these rules just help you find ways to design that as well.

Henry Suryawirawan: Yeah. So thanks for mentioning there’s no perfect, you know, design, architecture. So it’s all contextual, right? It’s based on your maybe team members, your situations, right? The complexity that you’re dealing with. And I think when you mentioned about heuristics and when you explained that, right? I think to me, in my mind, first is, it sounds like IFTTT, right? If this, then that. But in some software development world, right? People refers to it as design pattern. So any kind of specifics why you choose heuristics versus design patterns or patterns that we normally use in software engineering?

Gien Verschatse: For me, they are two very different things. So design pattern is, you know, you use that in your solution, in your code. Design heuristics give you an idea of how it could be. Like, for example, one design heuristic that I often use is that If you have to communicate to an external system, put it in a separate boundary. I’ll not always do that, but it helps you to sort of see that, okay, you know, if I have to communicate with this external system, I have to make sure that that is isolated and that that external system doesn’t boil into the rest of my software system. So I’ll just isolate that and I’ll create a clear communication language for everyone to talk to that interface that I made for that external system. As in, you know, design patterns is then, okay, I’m going to implement this like that because it’s easier in the code. So for me, they’re two very different things. A bit on architecture. And design in your code. And so, that’s sort of how I see it.

[00:19:03] Collaborating Modeling

Henry Suryawirawan: Right. Thanks for explaining that. So maybe let’s go to the actual thing that you explain in the book, right? Collaborative modeling. Maybe if you can describe what exactly collaborative modeling, if there’s a definition for it, right? And who should be the participants? And what kind of things can be solved by doing that?

Evelyn Van Kelle: So collaborative modeling, for us, what it means, or for me, I’m kind of used to speaking for the three of us at this point, but I will, uh, I’ll speak for myself. So, collaborative modeling for me is really like, you get the relevant people into a room to solve a problem, or at least to get on the same page about a problem. You’re not usually typically solving it in one session or by doing this, but at least, you are getting on the same page about what it is that you’re solving and getting some directions for that solution.

So, the key here is, indeed, like you asked, who do you invite? Who needs to be there? Gien mentioned the domain experts, right, in the beginning. So, yeah, there’s not really a set list on these roles should be there. But basically, it’s everyone who is relevant to that specific part or that specific topic that you are doing the collaborative modeling session on. So that means that you can be in a room with people ranging from all different departments, teams. Yeah, it can be a very wide range, which also brings the complexity in, right? Because that means that you will have software engineers, you have people from the leadership team, you have UX designers, you will have product management, you have sales, marketing, legal, finance, whatever. You can have everyone who is related and relevant to that topic.

And that makes it complex, because they all have different understanding of what you’re doing. They all have different interpretations, different assumptions. They bring in different interest, let’s say, I mean, for one person, this can be very important and there’s a high stake. And for others, it’s like, yeah, but that doesn’t really matter to me. So why should we focus on that? So it also brings the complexity in by inviting all these domain experts. But you do need them because you want to be on the same page about what it is that you’re actually solving.

Henry Suryawirawan: So if I understand correctly, right? So you want to get people who are relevant to solve the problem in the room. It could be from multiple departments, right? As long as they are relevant to solve the problems, which could bring complexity, like what you said, right? Because different interests, different perspectives, different ways of solving the problems.

[00:21:20] Inviting People to Collaborate

Henry Suryawirawan: But before we go into, how to bridge all of them together, right? So first, inviting all of them. So I understand sometimes some people don’t want to be involved in a big meeting, right? So how can you influence people, invite them to participate in this meeting? Or first of all, also explain why it’s beneficial for them to join.

Gien Verschatse: Yeah. I think I have always tackled that with a genuine curiosity on what these people are doing. Because, you know, very often, the sort of the conversations they have before with the software development teams might not have gone that great. Or via email and now you’re pushing for a change and, you know, whenever you want to change, people are a bit reluctant to do that. But I feel that if they’re a bit unconvinced, then, well, you know, don’t invite them to the big bang meeting immediately, but go over there and ask a few, you know, genuine questions. Do a bit of your homework.

If your domain expert is in finance, then, you know, research a bit on finance and say like, look, I was reading this and I don’t quite understand the difference between, for example, a savings and a debit account. Can you give me a bit more information on that? And if you show a genuine interest and you create a relationship with that person. And when you have a relationship and there is trust there, then you can ask them to do experimental things like, will you join me in a collaborative modeling session with other domain experts, so that I can, you know, do the best job I can.

I think the second thing, and that we often forget that is, for them, this is extra work. Because their main jobs, most of the time is something completely different. And talking to software developers is, you know, an extra add on for them. So understand that the burden that that brings, you know, they have different priorities than you do.

Evelyn Van Kelle: Yeah, it’s basically like there needs to be a positive consequence for them to join. Otherwise, well, it, may happen once, but they definitely won’t come back. So it’s really helpful to find out like, what would they, and then not as a group, but more on an individual level, what would they get out of it? What’s in it for them, let’s say. If you can find out that, and that you do that, indeed like Gien said, having those conversations, showing interest, really wanting to understand what’s going on. And if you know, like, what could be positive consequences or outcomes for them in that session, then you can also leverage that, right? Like, hey, this is what we also want to do within this session.

And for some people, it’s really on the content. Like they have a very big problem that they are working on and they are stuck. For some people, it’s really like, hey, I don’t want to be left out, which is also a very good positive consequence in that sense. So it can be anything, right? So find out what it is for those individuals and then leverage from that. That’s very helpful.

Gien Verschatse: Yeah. And start small. And as you said, like, and I made this mistake a few times, right? It took a while to learn myself, but you’re sort of trying to understand this whole picture, and that’s where you start off with. While what you should do is create a very small circle that, you know, you talk to your domain experts or some other people like your users. And with the information, you improve your model and you improve your code. And then, you know, you improve their experience. And then, you know, you push that to production and you can very quickly show them. So don’t start with a big bang that then will take, you know, half a year before they see any improvement. Show them how powerful it can be and then slowly go for the, the bigger redesigns that you need their help with.

[00:24:55] The Facilitator Role

Henry Suryawirawan: Right. So, yeah, definitely don’t always start big, right? So it will be chaotic. First of all, right, like Evelyn said, there are a lot of complexities when you involve too many people at once. And hence you need this facilitator, right? So that will be my next question. So how should we find a good facilitator for this kind of collaborative modeling? Because the job is not easy, definitely, especially the bigger the size of the audience. Maybe if you can describe what makes a good facilitator for this kind of collaborative modeling?

Evelyn Van Kelle: Yeah, no, it’s definitely not an easy job. It is a very fun job, at least, from my perspective. It’s very fun to do, you learn a lot from it. But indeed, like you said, you can have everything perfectly arranged and prepared and you have an idea of what you’re going to do and from a more technical perspective, everything is fine. But then the humans come in and yeah, everything can go wrong or be chaotic, let’s say. And then a facilitator’s job is not really to, he’s not responsible, he or she is not really responsible for the outcome, right? Like what the outcome of such a session is. But they are more responsible for facilitating or guiding the group towards something. And that can also be very frustrating because as a facilitator, you usually have an opinion and you also have perspectives. I mean, you are just a human, just as the rest of that chaotic group.

But as a facilitator, it’s very important to at least act neutral, right? You cannot really be neutral, but you can act neutral. I mean, no one is ever neutral because whenever I enter a room full of people and they are doing collaborative modeling, I have an opinion about the way that they’re doing stuff. About the outcome, about the process, about the people in itself. And so you will have an opinion, you will have a perspective on how things should be. But your job there is to act in a neutral way. Because as a facilitator, there’s also a very important role or function that you have there to make everything, well, at least that everyone is able to say what they wanna say. Everything needs to be said, right? So minority opinions or minority perspectives should also be shared in such a session.

And as a facilitator, if you are not neutral or you’re not acting neutral, then it can be very unsafe for whoever has a different or alternative opinion or perspective to share that. So as a facilitator, it’s your role to make it safe enough for everyone to speak up if they want to. And I think that’s a very important role of the facilitator.

Gien Verschatse: Yeah, I would say like, you know, good social skills, which can be developed. Like I had, I think somewhere, like 15 years ago, I did not have great social skills. I was very rude and I wondered why people were offended. But you know, I educated myself. I developed those social skills as much as I developed my technical skills. And you may have noticed, I don’t refer to them as soft skills, because they kind of seem easy. And for me the social skills were also always, you know, the hard thing to learn about software development. So yeah, anyone interested in developing their social skills can be a facilitator. I think if you look at the roles that are usually inside software teams, I think if we’re talking about collaborative modeling to design, then an architect or a team lead or a technical lead is a very good person to take that responsibility upon themselves to lead these sessions.

Evelyn Van Kelle: Yeah, and then one very important thing there, that whenever you take on such a role, I mean, especially if you’re going to do collaborative modeling then with your team, you cannot facilitate and participate at the same time. So then you have to be very clear on which role you are taking on at that point, because it will be even harder to stay neutral whenever you also have a stake in the game, right? So you also have an interest there. So be very specific about which role it then is that you are taking on. Are you the architect now or are you the facilitator? Because that implies different behavior in a way.

Gien Verschatse: I don’t know about Kenny. I don’t know about you, Evelyn, but I have made that mistake. Like I, I stepped this facilitator role. And I stayed neutral, right? It was about making sure everyone had space to express how they saw the design and how they think should be developed. But I was a software developer on the team, so I had a stake in it. So I could not always express my own opinions or I refuse to do that because I wanted to, you know, keep that neutrality. And that can lead to a lot of internal conflict. So the best thing to do then is to just, you know, say like, hey, I’m talking as an architect right now, or I’m talking as your team lead and here is my opinion. And to, you know, not prevent yourself from expressing it, or you’re going to make it a bit worse for yourself to do this.

Henry Suryawirawan: Thanks for sharing all these personal experience, right? So I think most of the teams in the software world, I would say they don’t have the luxury to work with like a professional facilitator. Most of them are just, you know, improvising from their original role, right? Be it an architect, maybe tech lead or maybe senior leaders or whatever that is. So thanks for sharing some of these heuristics, right? Maybe if I capture some of them, like you are not responsible for outcome, you’re responsible to guide the conversation, so that they can have a direction. And you should not facilitate and participate at the same time. If you want to do that, you have to switch. Maybe explicitly say, yeah, you are behaving as a facilitator or as a participant, right? So thanks for sharing that.

[00:30:10] Socio Technical Skills

Henry Suryawirawan: So one interesting thing that you mentioned also is about social skills, right? And I know this term is being coined a lot in software development about socio technical skills. So maybe explain a little bit briefly about socio technical skills and why collaborative modeling is actually perfect for solving socio technical skills in software development.

Evelyn Van Kelle: Yeah, as Gien already said, we don’t refer to them as soft skills, because I get really triggered and irritated whenever that’s being mentioned. Because that also implies that there are hard skills and they like have this connotation that they kind of like higher in rank, let’s say. The whole thing for us is like, collaborative modeling is a socio technical happening, right? I mean, yes, there is a very important and strong technical component to it, of course. But it’s also done by humans and they have to collaborate and they will have to work together and actively try to understand each other again on the same page. So that’s a balance there. I mean, if you only focus on the technical side, then you won’t get anywhere.

Because every technical decision that you make will have social implications or consequences. Let’s say whenever you choose a certain boundary, let’s say, you’re in your event storming session or your collaborative modeling session. That will imply some social consequences. It means that maybe other people will have to work together in a team or someone will disagree with that decision on that boundary and they will go into resistant mode and then conflict arises and then you have to deal with that. It’s really a balance. And it also goes the other way around, right? Like so for some social happenings or social decisions that you’re making in terms of team composition or your office layout or whatever, or the way that you work will also have an impact on your technical outcomes. So, it’s a two way street.

And I think there’s not enough focus on that balance and how you do that. And I think that’s where we want to focus on as well, because you have to deal with the socio dynamics as well. And it’s the hard part. And it’s not always a fun part, because humans can really mess everything up. But you have to understand, or at least, observe what’s going on in a group of people. I mean, when they come together, there will be conflict, there will be polarities there. Cognitive bias is flying around that impacts your decisions. There will be ranking. I mean, there’s always some sort of a hierarchy in the group, and that will impact how we discuss things and how we make decisions and how we eventually end up with our software architecture. So balancing that very actively and consciously, that’s something that we are, um, yeah, huge fans of. I think that’s, if I can put it that way.

Gien Verschatse: Sure. I mean, we’re enough fans to write an entire book about it for a year and a half. So…

Evelyn Van Kelle: Yeah, true. So we can say that probably. Yes.

Henry Suryawirawan: So yeah, I think as long as we still require human, right, it will be a socio technical kind of a problem, right? So maybe one day AI could perfectly write perfect software, maybe we don’t have the socio technical anymore, but until then, right? We need humans to collaborate with each other, right?

[00:33:10] Cognitive Bias

Henry Suryawirawan: So you mentioned a couple of things that are pretty interesting in the human dynamics, right? There will be conflicts, like you said. There’ll be cognitive biases. So maybe let’s start with the cognitive bias, because I think this is really, really important, because everyone has different kind of a bias. So tell us why bias is very important to probably first be aware of. And second is to probably identify before we make certain decisions in software design.

Evelyn Van Kelle: And I remember that you also asked before, like, why is this all socio technical thing related to the collaborative modeling part? Well, the short answer there is, of course, there are lots of people in a room when you do collaborative modeling. And it implies, by default, it implies, like, you have to work together. So as soon as you put people in a room, these socio dynamics will fly around. And you have to deal with that, in a way. And with socio dynamics, we also mean that the biases that you mentioned, sorry. And these biases are like, yeah, I really like them. And that’s because, well, some people see them as some sort of a negative thing.

But actually, in almost every situation, they help us. They are kind of like mental shortcuts that we use to help us make quick and effective decisions. And when you put it like that, I mean, like, who doesn’t like that, right? I mean, that’s what we want. And they are based on experiences that we have. I mean, they help us to make these decisions in a quick and effective way, because we’ve experienced a lot of it in our past time, let’s say. So they are really useful.

The only thing is that they can also hinder us in a way, and especially when we do collaborative modeling, then, well, they can hinder the process, let’s say. So for example, when you, um, I’m not sure if you if you’ve heard of it, but the anchoring effect is a very important cognitive bias that’s present in a lot of collaborative modeling sessions. And it basically means that we rely on anchors. So an anchor is, for example, we ask a question in a group, and someone talks first, and by that, is dropping an anchor.

So it also works in negotiation. So whenever you start, so you lay out the first bit, let’s say that that’s the anchor. And we as humans, we have this tendency to move towards that anchor. So whenever Gien and I would have a conflict or a discussion, for example, when will this book finally be ready? Maybe the publisher is asking us this question or our friends is asking us this question. And I would want to say like, yeah, I think in May 2024, let’s say, and Gien is saying is December 2023. And then I’m like, ooh, okay, there’s a big difference. But if Gien talks first, and she drops that anchor of December 2023, I will move towards that anchor. And maybe I’ll say, yeah, so maybe January or February 2024, then so we move towards the anchor that’s being dropped.

So in a collaborative modeling session, the person who starts talking first, the person who puts the first stickies on the wall, that person is dropping an anchor. And the rest of the group will move towards that anchor. So, for example, that’s also why we leave a lot of room for individual contribution when we do collaborative modeling, because we wanna sort out that anchoring effect, let’s say. So we wanna let people have room and space and time to at least share their individual contributions without being anchored or biased by the other people in the room. And this is just one example, but there are like, there’s a whole codec on biases that influence the collaborative modeling session. So, at least being aware of a few of them of some important ones, will really help you in making conscious decisions on how you do it, how you do that collaborative modeling part.

Gien Verschatse: Yeah. And to go further, like, so it affects the socio of the socio technical, but it also affects the technical. Like if you have loss aversion, you know, people have loss aversion, they’re afraid to lose things. You know, the more time you invest into something, the more loss aversion you have. So when we’re putting all that effort into a design and into our code, we get emotionally attached to it and we create loss aversion. And then, you know, when a new feature hits the deck, you’re sort of like, oh, I’m, I’m just, you know, going to adapt what I have just a bit, sort of make sure it still fits in there, because, you know, you now have an attachment to that model that you made. But maybe there are so much better designs available if you let go of that loss aversion and just, you know, see, okay, how can we actually deal with this new information that we just got and how can we change our models and evolve it? So, you know, impacts technical as much as it impacts the social as well.

Henry Suryawirawan: Yeah. Thanks for mentioning these two biases, right? So for people, maybe now you realize why certain things are done, for example, in a collaborative design, mostly like people write in sticky notes first before they put all of them on the wall, right? So this is to remove the anchor bias as much as possible. So loss aversion, definitely, for software engineers. We, sometimes, the creator, right, is very much attached to their design, right? So, and we’ll defend maybe with their life before someone else change it.

Gien Verschatse: Yes.

Evelyn Van Kelle: Yeah, but that’s true. I mean, we’re laughing, but it’s definitely true. Yeah.

Gien Verschatse: We’re all laughing because we have done that before ourselves. It creates empathy. If you can see that person, if you don’t think about cognitive biases, if you know nothing about them, you’re like, oh, this person is just being actually difficult. You know, my solution is so much better. Why doesn’t they want to see that? And then you’re, you know, it can just say, oh, you know, he’s having loss aversion. It’s normal. it’s what people do. You know, he’s attached to his solution. How can I deal with that? And it’s a different perspective towards that person as well at that moment.

Henry Suryawirawan: Yeah, so I think knowing about all these biases, I learned as well in the past, right? So knowing all these biases first is to create awareness, right? That you are actually in this kind of bias. So I think that’s really important as well.

[00:38:51] The Influence of Ranking

Henry Suryawirawan: So another important aspect, maybe apart from bias you mentioned earlier, Evelyn, is about ranking, right. So this is the human aspect that can give you like power dynamics that can give you a different kind of a bias, right? So tell us more about this ranking, because you dedicate one chapter to discuss about this ranking.

Gien Verschatse: Yes, we did.

Evelyn Van Kelle: Yeah, well, because it’s an important subject, right? So ranking happens everywhere in groups. And it kind of helps you to determine your own position compared to the others in a group. And it’s not a bad thing. Again, just like cognitive bias. It’s absolutely not a bad thing. It really helps you in making sense of your environment without having to process every bit of information that’s coming your way very actively. So it’s really helpful. You enter a room, and based on the others, the things that you’re seeing, your own position, you’d feel like, okay, so I’m relatively here compared to the others.

Some things are very obvious. I mean, there’s explicit ranking like your position in the organizational charts, your role. Like there are some things that are very, very obvious. But there is also more like the implicit part, which is really more about like age or gender or like there’s a difference there, your informal level of power. I mean, I can be very high up in the formal hierarchy of an organization. But there are always people that have this level of informal power. And whenever I say that, you probably think about someone like, yeah, okay, he’s not that high up on the ladder or she. But there’s a lot of informal power with that person. A lot of people just follow that person based on some magical hidden implicit ranking powers. And those people are there. And so deciding where you are relatively to the rest of the group, it really helps. And you do that unconsciously a lot.

But whenever you do collaborative modeling, for example, ranking also determines who starts to speak first, or who is sharing opinions, or who’s staying more quiet, or who’s taking the lead in some stuff. For example, who’s taking the lead in trying, starting to move stickies around, for example. And that goes unconsciously, but usually you see people higher in rank, starting to speak first, for example. And that then relates to the anchoring bias that we just mentioned. Because if you are higher in ranking and you are dropping an anchor, then it will be way harder for people to share a minority perspective.

So being aware of your rank and the ranking of others in that room can really help you in balancing that, let’s say. And that’s really important, because eventually you wanna have everyone be able to speak up and share their thoughts and share their perspective, because everyone has something to add. Everyone has wisdom to add to the collaborative modeling exercise that you’re doing and you don’t want ranking to hinder people sharing their perspective and their wisdom.

So as a facilitator, there’s also a role there to share that rank. So if you know that there will be, for example, someone who’s very high in rank and he or she has this tendency to start talking first, to be very dominant, to be very active and present and loud, let’s say, then you could have a conversation with this person before and what is it that you want to get out of this session? And then if the answer is, yeah, I want everyone to add their wisdom and perspective to what we’re doing, then my advice would be okay, so you’re higher in rank, then I would advise you to not start talking first. To ask questions to people instead of making statements, to keep yourself a bit more on the background instead of standing in front of the brown paper all the time.

So being aware of the rank, where you are and where others are, that really helps you in sharing it with the rest of the group, and, eventually, having everyone sharing what they wanna share in that session.

Gien Verschatse: I have plenty of examples about ranking. I’ll give one. I had a team lead and then in that moment, like I didn’t know the terminology ranking. And then, I didn’t know that yet. So it was quite a few years ago. And they were the team lead and that they felt I’m just, you know, similar role in the team. I’m part of the team. But we also had two or three people who had a lot of difficulty going against authority. So this person would always speak first, their opinions, in the sense that, hey, I’m just, you know, another person expressing my opinion. And then a lot of people, because of their background, their culture, we’re afraid to go against that team lead or to express a different opinion. So that person influenced whatever happened in the code base a lot more than they ever realized. And when I tried to discuss this, saying that I see these people react and they’re scared to speak up. And when we speak privately, they have a completely different opinion, but they’re scared to tell you. This person just didn’t understand that.

And again, I didn’t know about ranking. And if I had known, and if I could have explained like, hey, this is your rank as team lead, and it’s so much higher than everyone else and these are the social consequences of having that, that conversation would have gone a lot better, I think. Because that was just my intuition. And then I had actual scientific terminology, at least, to talk about. So that’s why we added it to the book as well, because, you know, knowledge is power. And being able to have that discussion then, if you know the terminology about, hey, you have a lot of implicit ranking, you have a lot of explicit ranking, be careful for just this and this, because science has shown that these are the effects.

Evelyn Van Kelle: And your example is again also a perfect illustration of how like this social dynamic also influences the technical part, right? Because if you are high in rank and there is no room for others to share their perspective, for example, then it’s very likely that your decisions will be included or implemented in your architecture or your design. And you will miss a lot of wisdom and knowledge and expertise. So that’s also like how it goes the other way around.

Gien Verschatse: Yeah. And they don’t have to live with the consequences, right. If someone has a very high ranking, they often are not coding and doing all that software development anymore. So they set the course and they do not have to live with the consequences of setting that course.

Henry Suryawirawan: Thanks for the plug. I can hear some maybe from past experience where you can have frustration because of that. But I think there’s a few things also that I want to add on, right? So sometimes this ranking is also implicit, because of the culture in some countries, right? They tend to give the leaders the first chance to speak, or maybe some leaders are being called first, right? So, sir, can you give your opinion? Something like that. And also the other thing when you mentioned about some people who have this magical power somehow, right? So ranking doesn’t always mean hierarchies in the social context, right? It could mean someone who have influence. And in your book, you mentioned maybe some kind of like a diva programmer or maybe people who are loud, right? So I think these are some of the examples.

Gien Verschatse: Yeah, the rock stars. People who have worked a very long time in that company often have implicit a very high ranking and they do have an enormous amount of knowledge, which is why they get that implicit ranking in the first place. But it might be a burden. Even for those people having that ranking, might be a burden. And, you know, sort of limit ideas and solutions.

Evelyn Van Kelle: Yeah. And I think like also why we added this chapter, why we spent a whole chapter on it, like, usually, architects also are pretty high up in rank, right? And we feel that they also are like the people who could be in a facilitator role. Or at least, should focus on this whole socio technical thinking. So then at least knowing what ranking is and how it affects like the group or the team or the people that they’re working with. And also being aware of their own rank and how they can share it with others. We feel that’s a very important skill to or at least a very important knowledge to have for these people.

Henry Suryawirawan: Yeah, again, we come back to awareness, right? First is to be aware there’s this term in the social context, right? We can use the term now to explain to people. So another example of maybe ranking that I can see from my past is the people who have worked with some kind of systems for the longest time, right? So they know the ins and outs. Sometimes you just refer to the person and just follow. So I think be aware of these such things, right? So not everything is always about hierarchies.

[00:47:00] Collaborative Modelling Structure

Henry Suryawirawan: So I think the other question that I would like to ask is actually, okay, we have the facilitator, we have the participants, how to put the structure? Because sometimes for some facilitators, right, you can’t just leave them to run it the way they like. So, maybe there are some tips from you, best practices, what kind of structure we should put. And I know that this kind of collaborative modeling, right, there are some people who also advocate certain things, things like event storming, or maybe lean inception. And also Domain-Driven Design have a few ways as well, right? So maybe from your experience, what kind of best practice you would advise us?

Gien Verschatse: For the process of collaborative modeling session, we did give people who never done facilitating before. We sort of gave them a structure that they can use there. You know, we talk about, you have the prep, you have the check in, then you have the actual collaborative modeling, you have to check out, and you sort of have to communicating and documenting to stakeholders not present there. And for each of these stages, we offer advice on how to do it. And I think that’s a good beginning, if you’re starting from nothing at the least. So make sure you’re well prepared. Don’t go in there and thinking, oh, I’ll make this work. Because that’s not really how, that does not end well if I may share my experience there. And a check in and a checkout, I think are very important as well. So Evelyn, you can hop in if you’re done thinking.

Evelyn Van Kelle: No, yeah, I was indeed thinking about, like, the scheme or the visual that we created on that preparation, but then I was like, yeah, it’s not here, so then we have to, we have to explain. But you explained it very well, so I’m again, impressed. But yeah, I think in terms of structure, if you’ve never done it before, then this general structure really helps.

But like Gien mentioned that doing a check in and a check out, that’s a very important part that not always is there in sessions. And it’s a very important part because it can help you like, getting some stuff up already, like knowing what’s going on in a group. Maybe there are some, stuff happening in the background that is going to affect your session or the outcome or whatever. And by doing a check in, it’s a way to connect with the people in the room. It’s a way to connect with the topic. It’s a way to set the stage, let’s say for that day. So even a very simple, but very powerful question to ask at a check in at the beginning would be, okay, so why do you want to be here? And why don’t you want to be here?

And especially by that second question, you will get a lot of information from people in that room. And you can choose to let people write it down on stickies or to express it or to, well, there are lots of forms and ways to do a check in. But I think that’s a very important part that is not always done in these sessions, but it’s very useful. And so if you’re looking for structure apart from the preparation and who to invite and the documentation and communicating part, check in and check out is really something that we would always do in sessions like this. And it helps.

Gien Verschatse: Yeah. Very small. Like when I’m consulting and, you know, I’ve been with the client for quite a while. It’s like, this is what we discussed last time. Do we need to get back to any of that? And that’s just a check in. Like, do you have any, you know, feelings about what we did last time we were talking? And then the wrap up is like, okay, we discussed this, this, and this. So it doesn’t have to be long. The better you know someone, the shorter you can actually make it more comfortable to group is.

Henry Suryawirawan: Right. So I think also well prepared, right? So preparation is the key, right? So don’t wing it probably. Especially when you invite a large group of people, right? So maybe if you are within the same, you know, team, maybe in a way you can be flexible. But if you have different interests of people joining the session, I think the key is to be well prepared. Maybe send the documents up front, right, what you will be discussing about and maybe setting the outcome as well. Like, what do you expect to resolve out of the session?

Gien Verschatse: Yeah. We have a template for how to prep for such a session. And one of the things is, you know, like you have to have an agenda and you need to communicate the outcome. Giving, you know, if it’s the first time, maybe even saying why you invited these specific sets of people in relation to the outcome that you wish to achieve. I’ve always hated meetings where there is just no preparation. Even if you’re not doing collaborative modelling, but just general. Cause it makes the meeting so slow and so boring. And that’s sort of how I got into decision making as well, to like, oh, it has to be a better way to do all this. Cause I don’t want to do this type of meetings for the rest of my life.

Evelyn Van Kelle: You don’t? That’s weird.

Gien Verschatse: No. I’m like, Ooh. I know, I know. But yeah.

[00:51:38] When to Do Collaborative Modeling

Henry Suryawirawan: The other question I would say, so maybe, doing this collaborative modeling is quite expensive, right? Because we involve a lot of people, we need to prepare and all that. How frequent or when should we do this collaborative modeling? Is it like for every big feature only? Or is it like any kind of a small feature can also use this kind of modeling? So maybe from your experience, what would be your advice?

Evelyn Van Kelle: So it also depends on which form of collaborative modeling you’re using, right? I mean, you have forms like big picture event storming where indeed you invite a lot of people and it’s relatively expensive, yes. But you also have other tools like example mapping or impact mapping or Wardley mapping or context mapping, or just to name a few; which don’t require the same big group of people in the room. So it also depends on like what you want to achieve and which tool you’re using. So it’s hard to say like that there are limits or rules or guidelines on when to do it. Because it really depends on what you want to achieve and which tool you’re using.

But for whatever (reasons if) you do it with a big, big group of people, that’s not something you will do every month, let’s say. Because that will be very, very challenging and very expensive. But very often what we also see in practice is like, maybe that’s the starting point to do it with a very big group. But then following your, for example, if you started with big picture event storming, then other stuff will follow from it. So maybe in smaller groups, you will start working on specific context that you have there or other groups will start working on different parts of the big picture event storming by zooming in on it on processor or design forms of event storming.

So yeah, it really depends on what you want to achieve and where you want to go. Because if you do it in smaller groups, then it’s way less expensive in that sense.

Gien Verschatse: Yeah. I most of the time, like, do it on my own as well. Because then, you know, it’s, it’s…

Evelyn Van Kelle: Collaborative modeling on your own.

Gien Verschatse: But no, the visualization part. And, uh, I collaborated alone, and there are many people. No. We just did it because I like the visualization. And I like sort of the thinking. I like the temporal modeling thing about it. So temporal modeling is a mapping according to time so that you can see, okay, this happens first, that, that, that. And I love example mapping because you then can understand, you know, the business rules, the constraints better that you have to implement and often they lead you to, oh, I hadn’t thought of the situation yet.

And if you do it on your own, then if you’re stuck or if you have questions that you don’t know, then you have something to take to a collaborative modeling session and say, I had like four questions left and you show you did your homework. But I still have these sort of questions left and I need your input on them. Do you have half an hour and then it doesn’t have to take long at all anymore to do this. So yeah, people have like, oh, we have to schedule two, three hour sessions and it has to be long and we have to have everything answered. And that’s often how you start out with it. But I think along the way, I’ll just have like, hey, it’s a half an hour meeting. I still have these, these and these questions left. Let’s model a bit together. I’m sure we’ll figure it out. And then it gets less expensive, because, you know, you have more experience and you’ve done it more and it gets easier to do over time.

Henry Suryawirawan: Right. Thanks for the tips, right? For the advice when, how we should do it. Again, there are so many tools, right? So maybe you can use one for certain things. The other one for a smaller group, right? So you mentioned about event storming, impact mapping, example mapping, so many mapping. So please use that depending on your situation, your context, right? And I think it will be also great that people build awareness to always want to collaborate, because sometimes in software development, for some reasons, they always think in silos. So maybe I’m an engineer, you are a tester, then you are a business analyst, right? We don’t want to talk and collaborate with each other. So maybe also that kind of a boundary should not be there as well so that we can collaboratively talk whenever something to be discussed.

[00:55:34] Remote Collaborative Modeling

Henry Suryawirawan: So the other thing is very important is about remote collaborative modeling, probably. So maybe if there’s anything different that people should be aware of, maybe some tips here as well?

Gien Verschatse: I feel it’s harder to read people’s body language, right? Cause, well, you only see the upper half. As a facilitator and a participant to read other people, that is, I feel a lot more difficult when you’re with remote. But then you have your Miro board and you have your post-its and then, you know, like moving stuff around and doing the actually, you know, doing event storming or doing example mapping, because you’re on a whiteboard, virtual whiteboard that actually gets a lot easier to do. And you can start tracking the history of your design decisions, because, you know, next session, you copy it over and you change it and you can sort of see the evolution. So I think that’s the biggest benefit and the biggest downside of remote.

Evelyn Van Kelle: Yeah, I agree. I think, indeed, the virtual whiteboards are… Yeah, I love them. I mean, also, you can read everything, you can make changes more easily, you can keep track of what you did and the versions. But indeed from an observation perspective, which is a very important skill as a facilitator as well, it gets harder. And not just because you can, you have only limited, yeah, parts that you’re seeing. I mean, if you’re, if you’re in Zoom, there’s only a small frame that you’re seeing. But on top of that, you usually, when you’re doing it in a remote way, you have to watch the frames of the people, but you also have the chats, you have the Miro board that’s going on. Maybe there are some other back channels that are going on during a session. So you have a lot more channels, let’s say that you need to watch and that you need to observe what’s going on there. And when everyone is in a room, there’s still a lot to see and a lot to observe and a lot to pay attention to, but at least it’s centered in your vision. And with remote, that gets more difficult. So that’s the biggest challenge for me when it comes to indeed observing people and behavior and what’s going on in a room. So that’s harder. But yeah, I mean, it’s, we’ve been dealing with it for a few years now. And it’s, yeah, but we managed to do it. But indeed, there’s other stuff that you need to pay attention to. Yeah.

Henry Suryawirawan: Thanks for these tips and tricks as well. So before I go to my last question, since I’ve read this book is in MEAP, Manning Early Access Program, right, I’m going to ask the same question that, Evelyn, you brought as an example. So when will we expect to see this book being published?

Evelyn Van Kelle: So here you can drop the anchor then, that’s fine.

Gien Verschatse: No, no, it’s a bit difficult because, you know, we’ve never written a book before. So we sort of have to guess a bit. But like we’re almost finished with all the drafts of the chapter, right? The 12 chapters, we’re almost finished with writing all the drafts. And then there has to be a review round, which takes four weeks. And then we have to implement the feedback from the review. And then it goes to editing. Right, and so we don’t know. I would guess November or December, something.

Evelyn Van Kelle: It’s scheduled for fall this year, so um, yeah, let’s wait for November then, probably.

Henry Suryawirawan: Yeah, don’t take it too hard, so I’m just joking in a way, right? So we know software engineering, right? We always misestimate, so don’t worry about that.

[00:58:45] 3 Tech Lead Wisdom

Henry Suryawirawan: So I have one last question that I would like to ask you. So this question I call three technical leadership wisdom, which I asked to all my guests. So think of it just like advice that you want to give to the listeners so that maybe they can learn from this episode, right? So if you could probably share your version of three technical leadership wisdom, what would those be?

Evelyn Van Kelle: So, I think my main, yeah, wisdom is a big word, but I think if I would have to pick one, it would be like, be prepared to deal with socio dynamics that fly around as soon as these humans get together. And you have to prepare yourself in a way. And the best way or the easiest way to prepare yourself to do that is by at least come up with some heuristics for yourself. So whenever you enter your next meeting, starts noticing what’s going on and start to see if you can come up with heuristics. So for example, when the group starts to discuss something, you can start observing behavior, right? So who’s saying what, who talks first, who’s more silent, who’s standing where? Are stickies moving around? Are there subgroups forming? Are people asking questions or are they making statements? All these kinds of things like you can start observing that and that will help you to prepare at least for all of the social dynamics that are going to be flying around in every room that you’re in. So yeah, long story short, like be prepared to deal with the social dynamics. And one of the best ways to do it is to come up with heuristics for yourself.

Gien Verschatse: Yeah, I think mine is it’s not all about you. It’s actually not about you at all. That’s completely based on my experience with leadership, of course. I think that even if you’re in a lead, like they feel the pressure that, you know, they have to share their opinion. They have to rule. And I’ve, you know, had some team leads or CTOs that like, one person that took up 90% of the speaking time in any meeting. Even if they were checking in on you and how you were doing on the team, they were speaking 90% of the time. I had team leads that felt it was a software developer’s responsibility to convince them we were making good decisions.

So it’s not about you, I think is the best advice I can give, because we have to make the decisions, we have to live with the consequences, we do not have to convince you. And if you, you know, in a meeting, it’s not about you at all. There is no pressure for you to express your opinion. That is not showing leadership necessarily. So just do once in a while, remind yourself of that.

Evelyn Van Kelle: And then the third author who isn’t here, but he did share his wisdom with us. So kind of the third wisdom that we want to share is coming from Kenny. So I’m going to, yeah, hopefully convey this in the right way. But his wisdom is to look at what people do not say. What are the topics that people avoid? And what are the taboos or the tensions and the conflict that are in a room?

So if you as a facilitator can lead the group to identify all of the opinions in a group, and let the group present and support these opinions, even those who do not like or believe to be useless, then we can talk about what we accept to be a good design for the group. And that is the catalyst in making sustainable design decisions. So he really focuses on like, what is not being said? What are we avoiding? What are we suppressing? And actually making that more visible in a group, because that eventually will help you in creating the best things.

Henry Suryawirawan: Thank you for this creative version of three leadership wisdom, right? So there are three coauthors. So basically one for each, right? And I think thanks for mentioning, looking out for the hidden things, right? This is like the hidden ice below, it could be bigger than the surface, right? So I think that’s very important for leaders to also think about.

So thank you so much for this time. If people want to maybe connect, find out more about the resources of the book, is there a place where they can find you online?

Gien Verschatse: I’m on Twitter. As Gien Verschatse, if you look for me. I’m on mastodon.social and on LinkedIn. So feel free to reach out to me there, or any social media you use these days. I’m not quite sure which ones I use anymore.

Evelyn Van Kelle: Yeah. Yeah.

Gien Verschatse: So feel free to connect and just, you know, say something like, hey, listen, if it’s LinkedIn, like listen to the podcast, loved it. Just want to connect with you on LinkedIn.

Evelyn Van Kelle: And also, if you didn’t love it, then you can still connect and tell us what you missed or what you want to discuss further. And I think we can get some useful links or resources in the description of this podcast or something. So yeah, we will make sure to have some interesting stuff there.

Henry Suryawirawan: Right, I’ll put it in the show notes, definitely. So thank you for explaining about this collaborative modeling. So I hope people here get to understand about the socio dynamics aspect of software engineering, right? And use collaborative modeling. Or if not collaborate more with others so that you can build better software. So thanks for that.

Evelyn Van Kelle: Thank you.

Gien Verschatse: Alright, thank you so much for having us.

– End –