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.