Techly Journal has a mission to elevate the technical leadership and excellence of all engineers in collaboration with the one and only Patrick KWA. I am excited to share that I'm organizing 2 workshops in Singapore in early November 2023, The Technical Leadership Master Class and the Engineering Manager Essentials. You can find more information at techly journal dot def slash courses slash TL and Techly journal dot deaf slash courses EM.
Register early while the early birth discount is available. See you there. Hey, a quick message for those of you who are listening to this episode on Spotify, I have a small favor to ask. Spotify now allows mobile users to rate podcasts. I would really appreciate it if you can take a quick pause to go to the Technically Journal podcast page and leave your favorite show your best rating on Spotify. It will help me a lot to get this podcast to reach more people on the platform.
Thanks a lot. Declarative 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. Either 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 that you
invite who needs to be there. Basically, it's everyone who is relevant to that specific part or that specific topic that you are doing the collaborative modeling session on. 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 interests. But you do need them because you want to be on the same page about what it is that you're
actually solving. Hey everyone, my name is Henry Suryaviravan. And you're listening to the Technical Journal Podcast, the show where I'll be bringing you, the greatest technical leaders, practitioners and thought leaders in the industry to discuss about their journey, ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our journal. Hello again to all of you, my listeners.
Welcome back to the Techly 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 Techly 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 Techni journal contents and would like to contribute, support my work by either buying me a coffee at technijournal dot deaf slash tip or becoming a patron at technijournal dot deaf slash patron. My guests for today's episode are Evelyn, Fanquel and Hin Versace.
Evelyn and Hin 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 Hin started by explaining the Kinafin framework in software development and the importance of having heuristics for making quick decisions.
We then dive deep into discussing what collaborative modeling is, how to get people involved to collaborate, and the important role of the facilitator. We also talk 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 5 star rating and review on Apple Podcast 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 Hin after quick words from our sponsor. Are you looking for a new cool swag?
Techly Juno now offers you some swags that you can purchase online. These swags are printed on demand based on your preference and will be delivered safely to you all over the world. Where shipping is available, check out all the cool swags available by visiting Techly Juno dot dev slash shop and don't forget to break yourself once you receive. Any of those swags? This episode is brought to you by Miro.
As you will hear in this episode later on about the benefits of doing collaborative modeling, one challenge is for teams to find the tools that can support doing this collaborative modeling session effectively, especially when you have some
team members joining remotely. Throughout my experience running collaborative modeling and similar other exercises, there is only one tool that I trust and keep coming back to and that is Miro Miro. At the first glance, it might seem just like a simple digital whiteboard, but Mirrors capabilities run far beyond that. It's a visual collaboration tool where the whole team can build on each other's ideas and create something innovative together
from anywhere. You can quickly start collaborating within 90 seconds without having everyone registered as a mirror user before. There are also more than 300 predefined templates you can use to kick start your collaboration within seconds. And these templates include top use cases commonly used such as Agile and design thinking workshops, strategy and planning exercises, brainstorming and ideation sessions.
So the next time you are looking for a digital tool to support your online collaboration or brainstorming sessions, do give Mira a try. You can Sign up today at mira.com Podcast. Miro.com/podcast and your first three mirror boards are free forever when you sign up now. Hey everyone, welcome to another new. Episode of the Technic to Know 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 Hin are with me today. So happy to have both of you here. So maybe let's start by hearing more about your story, right? Any highlights or turning points you have in your career? Yeah, I'll start. So I'm a software developer. I did that for about 17 years and then I moved to consulting for Artlin.
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 because I was still young and little 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 a liberty to do that, that would be my advice there. 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 thesis, I 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 do things that I'm focusing on. So sometimes it's more 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 the 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 is 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 and I'm liking it. So yeah, let you let yourself be
surprised every now and then. I think that's the main thing there. Thanks for sharing the story. Right so it's very interesting. So one is from software engineering background, one is from social scientists. There's another call from the book, actually. Kenny, right? Yeah, I think he has the same background on me in software development primarily. Yeah. And he's a real expert as well on Domain Driven Design. That really is just fashion
there. And yeah, so I think he and Kenny are a bit similar, but we're all sharing the same interest in the social part. So I think that's a good balance. 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? So part of the job of being a software developer is to actually understand the problem that you're trying to solve. Fire 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 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 their 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 1st 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. Yeah, 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. 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.
So maybe let's start from there, because I think still traditionally some people think that building software is 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 would be great.
All right. I think like my first job, which I spoke about, it was in tank stations, right? So where you go with your car and you fill them up with gas. A gas stations 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 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 could 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 we're sort of going on unexplored territory and collaborative modeling is very good at how I see it is comparing that complex in too complicated. Like we experiment, we try things, it's very cheap because most of the time you know we're doing it with post it or some cards laying on the table and we're trying to figure out how this 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 complicated because you need to create software. Before, 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 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.
Yeah, you mentioned this keyword heuristic, right? So first of all, thank you again for explaining that. Complex and complicated and simple most likely. I think in software anything that is simple is suspicious, right. So which are even 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? And 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 used 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 came 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.
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 and 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.
Yes. If the audience wants to dig a bit deeper into that, Billy von Kuhn has a book where he also talks about mostly design heuristics, and he just 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 try to figure out what works and what does work. And these rules just help you find ways to design. That as well. Yeah. So thanks for mentioning. There's no perfect 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 mention about heuristics and when you explain 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? For me, they're two very different things. So design patterns is 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, OK, 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 design patterns, is then OK. I'm going to implement this like that because it's easier in the code. So for me there are two very different things, a bit on architecture and design in your code and so that's sort of how I see it. Right. Thanks for explaining that. So maybe let's go to the actual thing that you explained in a 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? 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 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. Either 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 ask, who do you invite? Who needs to be there? And he 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 relative 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 interests, 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 to complexity and 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.
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. 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. Oh, first of all, so explain why it's beneficial for them to join. Yeah, I think I have always tackled that with a genuine curiosity on what these people
are doing. Because they know very often the sort of the conversations they had before with the software development teams might not have gone that great or via e-mail 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 debate 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 and developers is an extra add on for them. So understand that the burden that that brings. They have different priorities than you do, yeah. It's basically 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 he 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. 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 right, you sort of trying to understand this whole picture and that's where you start off with. While what you shouldn't 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 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 The 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. 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. Yeah, now, 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 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 if a facilitator's job is not really do, he's not responding or she's not really responsible for the outcome, right. Like what? The outcome of of such a session is that 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 perspective. 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 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.
So you will have an opinion that 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 want to say. Everything needs to be set right. So minority opinions or minority perspective 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. 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 a architect or a team lead or a technical lead is a very good person to take that responsibility upon themselves
to lead these sessions. 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 and so be very specific about which role that is that you are taking on. Are you the architect now or are you the facilitator? Because that implies different behavior in a way. I don't know about Kenny, I don't know where you live, but I have made that mistake. Like I stepped into this facilitator role and I stayed neutral, right? It was about making sure everyone has 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. 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. 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 social technical skills.
So maybe explain a little bit briefly about social technical skills and why collaborative modeling is actually perfect for solving social technical skills in software development. Yeah, as he 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 rankled states.
The whole thing for us is like collaborative modeling is a social 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 your event storming session or your collective 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 St. 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
sociodynamics 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 conflicts, 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, yeah, huge fans off. I think that's if I can put it that way. Sure. I mean, we're enough fans to write an entire book about it for a year and a half. So yeah, true. So we can say that probably, yes.
Yeah. 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 and maybe we don't have the social technical anymore. But until then, right, We need humans to collaborate with each other, right? So you mentioned a couple of things that are pretty interesting in the human dynamics, right? There will be conflicts, like you said, there will 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 2nd is to probably identify before we make certain decisions in software design. And I remember that you also asked before like why is this all social technical thing related to the collaborative modeling part.
Well the short answer there is of course there are lots of people in the 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 social dynamics will fly around and you have to deal with that in a way. And with social dynamics, we also mean that the biases that you mentioned, sorry. And these biases are like, yeah, I I really like them.
And that's because, well, some people see them as some sort of a negative thing. But actually in in almost every situation they help us. They are kind of like mental shortcuts that we used 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 post 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 them well, they can handle the
process, let's say. So for example, when you, 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 1st 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 anger. So whenever he 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 it may at 2024, let's say and he is saying is December 2033. And then I'm like oh, OK,
there's a big difference. But if he talks 1st and she drops that anchor of December 2033, I will move towards that anchor maybe I'll say yeah, so maybe January or February 2024 that. So we move towards the anchor that's being dropped. So in a collaborative modeling session, the person who starts talking, sure, 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 want to sort out that anchoring effect, let's say. So we want to let people have the 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. Yeah, and to go further, like it affects the socio, 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 of vision. And then, you know, when a new feature hits the deck, you're sort of like, oh, 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 of version and just you know see OK how can we actually deal with this new information that we just got and how can we change your models and evolve it so you know impacts technical as much as it impacts the the social as well. Yeah, thanks for mentioning these two biases, right. So for people, maybe now you realize why certain things are done.
For example, in the 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 lots of version, 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 changes, Yes. Yeah. But that's true. I mean, we're laughing, but it's definitely true, yeah.
We're all laughing because we have done that before. Exactly. 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 should be virtually difficult. You know, my solution is so much better. Why doesn't they want to see that? And then you're, you know, you can just say, oh, you know, he's having loss of version. 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, yeah. So I think knowing about all these biases I learned as well in the past, right. So knowing all these biases versus a create awareness, right, that you are actually in this kind of bias. So I think that's really important as well. So another important aspect maybe apart from bias you mentioned earlier, Evelyne 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. Yeah, we did. Yeah, we could. 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 the 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 to think that you're seeing your own position, you'll feel like okay. So I'm relatively here compared to the others and 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 letter 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 whatever you do, collaborative modeling, for example, ranking also determines who starts to speak first, or who is sharing opinions, or who is 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 ranking and use 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 want to 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 rank and he or she has this tendency to start talking for us 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 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 with sharing it with the rest of the group and eventually having everyone sharing what they wanna share in that session. I have plenty of examples about ranking. I'll give one.
Yes, 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, 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, were 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 try 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 or 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 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, cuz science has shown that these are the effects. 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 higher 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. Yeah, and they don't have to live with the consequences, right? Because 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. 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 mention about some people who have this magical power somehow, right? So ranking doesn't always mean hierarchies in the social context, right? Absolutely it. Could mean someone who have influence. And in your book you mentioned maybe some kind of like a Difa programmer or maybe people who
are loud, right? So I think these are some of the samples. 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 1st place. But it might be a burden even for those people having that ranking might be a burden and, you know, sort of limit ID's and solutions.
Yeah. And I think like also why we added this chapter, why we spend a little 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 old social
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. But we feel that's a very important skill to, or at least a very important knowledge to have for these people. Yeah. Again, we come back to awareness, right? First is to be aware that'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. 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 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, 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? 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. We talk about you have the prep, you have the check in, then you have the actual collaborative modeling, you have the 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 and 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 check out I think are very important as well.
So and then you can hop in if you're done thinking, no, yeah, I was indeed thinking about 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. But you explained it very well. So I'm again impressed. But yeah, I think in there's a structure. If you've never done it before, then this general structure and
it really helps. But like he 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 you to check it 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 and stick these 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 are looking for structure apart from the preparation and it to invite and the documentation and then communicating for check in and check out is really something that we would always do in sessions like this and it helps. Very small, like when I'm consulting and 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 to check it.
Like do you have any feelings about what we did last time we were talking? And then the wrap up is like, OK, we discussed this, this and this, so it doesn't have to belong. The better you know someone, the shorter you can actually make it more comfortable to group is. 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 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 upfront 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, 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's just no preparation, even if you're not doing collaborative modeling, but just general because it makes the meeting so slow and so boring. And that's sort of how I got
into decision making as well. So, like, it has to be a better way to do all this, because I don't want to do this type of meetings for the rest of my life. If you don't, that's weird. No, I know, I know. But yeah. 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 small feature can also use this kind of modeling? So maybe from your experience what would be your advice? 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 in beat 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 workly 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 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 a very, very challenging, a 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, yeah. I most of the time do it on my own as well, because then it's go back to the simple on your own. No, the visual is issue hard
and. Our collaborators alone and there are many people. No, we just did because I like the visualization and I like sort of the thinking. I like the temporal modeling thing about it. So temporal modeling is some mapping according to time so that you can see, OK, this happens first 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 have like 4 questions left and then 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 doesn't have to take
long at all anymore to do this. So yeah, people have like, oh, we have to schedule 2-3 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 having like, hey, 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. Right, thanks for the tips, right for the advice when how we should do it. Again, there's 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 and 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 collaborate if we talk whenever something to be discussed.
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. I feel it's harder to read people's body language right? Cuz when 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 micro 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 the white board, virtual white board. That actually gets a lot easier to do. And you can start tracking the history of your design decisions, cuz 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. Nah, I agree. I think indeed the virtual whiteboards are yeah, I love them. I mean now, so 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 to the my report that's going on. Maybe there are some other back channels that are going on during the 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 the 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, we managed to do it.
But indeed, there's other stuff that you need to pay attention to, yeah. Thanks for these tips and trick as well. So before I go to my last question, since I've read this book, it's in me Manning Early access program right? I'm gonna ask the same question that even you brought as an example. So when will we expect to see this book being published? So here you can drop the anchor then that's fine.
No, it's a bit difficult cuz 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 12th chapters, we're almost finished with writing all the drafts. And then there has to be a review round which takes 4 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, it's scheduled for full this year. So yeah, let's say for November then probably. 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. So I have one last question that I would like to ask you. So this question I call 3 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? 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 the humans get together.
And you have to prepare yourself in a way. And the best way or the easiest way to prepare yourself to 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 our stick
is 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, luxury shorts 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.
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 the leader, like they feel the pressure that they have to share their opinion, they have to rule.
And I've, you know, had some team leads or Cto's 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 developers responsibility to convince them we were making good decisions. So it's not about you. I think it's 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. And then the third author who isn't here, but he did share his wisdom with us. So kind of the 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 so 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 the 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. Thank you for this creative version of three technical leadership wisdom, right.
As Hindus houses or if you look for me, I'm on Mastodon dot social and on LinkedIn so feel free to reach out to me there or any social media you use these things I'm not sure which one yeah yeah. So there are three quarters, so basically one for each, right. And I think thanks for mentioning looking out for the hidden things, right. This is like the hidden eyes 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 books, is there a place where they can find you online? I'm on. So feel free to connect and just say something like hey, listen if it's LinkedIn, like listen to the podcast. Loved it. Just want to connect with you on LinkedIn and also if you didn't love it that you could 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. 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 social 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. Thank you. All right. Thank you so much for having us. Thank you for listening to this episode and for staying right
until the end. If you highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on the episode page at techlyjuno dot dev website, including the full transcript, interesting quotes, and links to the resources mentioned from the conversation. And lastly, make sure to subscribe to the show's mailing list on techlyjuno dot dev to get notified for any future episodes. Stay tuned for the next Techlyjuno episode, and until then, goodbye.