I was mad at everything often and frustrated and getting
caught up and just complaining about how product is bad to us
and the leadership is bad to us and everybody's bad to us and
nobody understands us. When I started, I pushed code to
a monolith, worked on multiple teams and we were pushing code
together and it was really complex.
And then the world around us started to change and now
software had to talk to other software.
Everything was a relationship was designing relationships and
we are not an industry with great relationship skills if
we're in time and in people within.
The tech teams, you can actually see a lot of things becoming a
problem simply because the system is not right.
The big question first is that what is actually system
thinking? My straightforward answer is
relationships produce effect. We think because we understand
one, we must understand 2 because one in one make 2.
But we forget that we have to understand AM, and to me is the
art and science of systems architecture, right?
We often think we're solving the same problem.
And when we're going around and around and we're bike shedding,
usually it's because we have completely different mental
models of what we're doing. We've got biases, we have
logical fallacies. We have so many bugs in our
thinking. System thinking is really hard.
You can't master it just by reading the book or maybe
listening to this episode. Yeah, in your book you mentioned
some practices that we can do in order to improve our system
seeking. So the first thing I'm going to
say doesn't sound like it has anything to do with systems or
anything, but it is the most important thing we can do.
So the first thing is. Hello everyone, welcome back to
another new episode of the Tech Lead General Podcast.
Today I'm very, very excited. So we're going to talk about a
topic that always intrigued me every time I learn about it.
So today we have Diana Montalian, the author of
Learning Systems Thinking. So if you have heard about
systems thinking or if you haven't heard about systems
thinking, hopefully today will give you a lot of insights of
what systems thinking is all about.
And hopefully you can use it in your career on your work so that
you can produce a better outcome for your work.
Anna, thank you so much for this opportunity.
Really excited to have you. Thank you, Henry.
I'm really glad that you've set this time for us to explore
this. Right, Diana, before we go into
systems thinking, so I'd like to invite you probably to share a
little bit more about yourself, maybe sharing some turning
points in your career that we all can learn from.
I think the biggest turning point in my career is probably
very similar for anyone who's been doing this for a long time,
and that is that when I started, I pushed code to a monolith,
worked on multiple teams, and we were pushing code together.
We had merge conflicts regularly.
That was very frustrating and it was really complex.
I felt like it was complex and then the world around us started
to change and digital information became ubiquitous
and now software had to talk to other software and
infrastructure is code. Everything was a relationship
was designing relationships and we are not an industry with
great relationship skills like if we're in tag and in people
and and yet I was being asked to deliver features still like
feature driven engineering, but where to put it, how to design
the system. So the reason I ended up really
being interested in the subject is that we were still designing
software in a world in which we worked in systems of software.
And it was painful. The outcomes were not great, The
work got harder. And so I really wanted to figure
out what helps like what will help us.
Yeah, something you said, I think it's really intriguing,
right. So we are not good in, you know,
working with relationship, be it with other people, first of all.
Yeah. And multiple systems, multiple
distributed systems especially, right.
So these days it's the era of, you know, micro services, a lot
of SAS applications that we have to talk to.
I think this is really, really important.
Yeah. So let's go to the main topic
today, right? So you wrote this book Learning
Systems Thinking from Me when I see it, right?
There's not many literature written on this, even though I
think the subject is really, really important, right?
So tell us, what is your background, you know, writing
this book? What kind of problems or gaps
that you see maybe in the industry, in the tech
professionals, right? What kind of gaps that you
actually try to solve by writing the book?
Yeah, that I love that question because the short answer is I
was mad at everything often and frustrated and getting caught up
in this noisy back channeling of just complaining about how
product is bad to us and the leadership is bad to us and
everybody's bad to us and nobody understands us and isn't this
terrible. And then I had this sort of
radical idea of what if I tried to be part of the solution to
provide more signal than noise, like what helps?
And this really sent me down a rabbit hole of exploring not
just Kubernetes like how we do it in a Kafka stream, right?
But also the system science in general, and then specifically
how it applies to the challenges we have.
And the thing that was amazing to me is how much we have in
common with say, agriculture, right?
Agriculture, especially in the US became monolithic.
And then you have all all these independent farmers who are
trying to rebuild these ecosystems where you grow
different things in harmony with each other and you solve
problems in a systemic way. And I read a book, Mark Bittman
wrote a book, Animal, Vegetable Junk.
And I kept highlighting things in the book because they were
the same pain that I had in tech.
And so the challenge when O'Reilly asked me about writing
the book, the challenge was, can we take, like Daniella Meadows,
thinking in systems and the other things that we know about
systems and natural systems and mechanical systems and apply
them to our challenges in ways that we can use.
And that's really difficult because we don't know what we
don't know. And so I got a lot of pushback
initially for talking about thinking it's too abstract.
Diana, what's in production except what we thought?
Like, aren't we knowledge worker?
Don't we think for a living? And also, code is abstraction.
We're not planting trees. We literally are writing in a
language we made-up on machines. We made-up doing things in the
hardware we built, like everything we do is abstraction.
So adding a little bit more helpful abstraction to me is not
the worst sin ever, anyone's ever committed, but it's a
challenge. It's a challenge to find the
language because we don't really have a language to talk about
this stuff, right? Yeah, especially also in my
experience, you know, working in tech, right?
I've been in the industry for maybe about 20 years.
It's always the same thing that you mentioned in the beginning,
right? We think everyone else is
against us, right? Be it the product, be it the
CEO, the founders, the stakeholders or whoever that is,
right? They just don't understand us.
And especially if you have become a leader, right?
Sometimes, you know, working in the tech teams, you can actually
see a lot of things becoming a problem simply because the
system is not right. And to me, when I found about
systems thinking, that gave me a lot of revelations as well.
Even though every time I read right, it's always a new thing
and new insights that I got from doing the book and including
your book as well. So I think I can see the really
important things that we could learn as a tech professionals by
understanding about systems thinking.
So maybe the big question first is that what is actually system
thinking? You know there's the advanced
way of defining it, and hopefully you can also define it
in the simpler term. Yeah.
And it's, I frustrate people. I frustrate people with this
because we want a straightforward thing.
And this my straightforward answer is relationships produce
effect and systems thinking is understanding the effect and
being able to architect for the kinds of effects we want in a
system. That's the straightforward
answer. But Donnella Meadows says that
we think because we understand one, we must that we understand
2 because one and one make 2. But we forget that we have to
understand and, and to me is the art and science of systems
architecture, right? That when you have two
microservices and you design interaction between them, then
you get a third thing. Whatever it is that they do
together, they can't do alone, right?
And yet we're very linear when we design these relationships.
So Fred Brooks says that most, most software systems are many
good but uncoordinated ideas. And this is every model I have
ever made of a software system like these might be good, but
they're duct taped together, right?
We just build these rickety bridges.
And so for us, systems thinking is about understanding how all
of these relationships deliver an outcome.
So for example, FedEx, FedEx fast package delivery, that's
what FedEx does. And anything we can do
technologically to create fast package delivery is a priority.
And anything that we do that is extraneous to that, less of a
priority. But we aren't very well trained
to think about what we're doing in the context of fast package
delivery. Instead, we think about a fast
response from an API, which is important, right?
But does that fast response actually have an impact on the
system? The challenge, though, is that
systems thinking is defined differently in so academia, for
example, would define it. If you went to a workshop for
marketing people, or you went for a workshop for academics,
you went for a workshop on more biological systems.
They're going to say things differently than I am, and a lot
of people do not like that. They don't like the fact that
there's not one answer, but it's system thinking.
Of course there's not one answer.
It really depends on what kind of system you're looking at, how
that system needs. Systems thinking is going to
govern what you prioritize about systems thinking.
So for me, pattern thinking, which is sort of systems
thinking adjacent is probably even more important to for us
than systems thinking, critical thinking, the ability to create
sound recommendations using reasoning, those are all part of
systems thinking. It's called systemic reasoning.
But if you read about systems thinking, you don't often also
read about systemic reasoning, right?
So that's the challenge, is that in any given situation, there
could be 100 systems thinking practices that you could apply,
but you're only going to apply for five of them.
If I were to define systems thinking, I'd have to talk about
all 100, but in fact, you're not, you don't need all 100.
So it is, I would add, it's the ability to discern which of
those practices or tools will be the most helpful in your
situation. That's not a thing people love
either. They're like, where are the
templates and checklists? I want my templates and
checklists. I mean, I have those, But will
they help you in your situation? I don't know, like that's
something you're discerning. Yeah.
So anyway, see, it's a long
answer. And that drives people crazy a
little sometimes, Yeah. Yeah, I think one of the main
challenges, especially maybe for us engineers, right, we try to
think logically and also trying to kind of like build the
abstraction, you know, like in a way that it is easier to
understand. But obviously this is like maybe
against the system's thinking way of thinking, right?
Because we try to think linearly, trying to reduce, you
know, an abstraction into something that we can, I don't
know, understand in terms of relationship, right.
So maybe tell us this bias that we have as a maybe as a human in
fact right? Trying to think in linear terms
like what you said in the beginning, 1 + 1 = 2.
We always like facts, logical thinking, right?
So why this bias can become a challenge when understanding
systems thinking? Yeah, and that it's my favorite
subject because we also think in binary, meaning linear thinking
is good and systems thinking is bad, or systems thinking is good
and linear thinking is bad, right?
But in fact, we need both, right?
I can't write software. And by linear thinking, I mean
akin to following a recipe, right?
That either you are following a recipe or you could write a
recipe to describe what you've done, right?
Even when we're debugging, we're breaking down complexity to get
closer to understanding exactly where something is happening.
So linear thinking is predictable, procedural, top
down. So the way that we decision make
where strategic people hand decisions down to implementers,
that is linear thinking concerned with control.
So we want our software to do what we designed it to do all
the time under every circumstance.
And so we are concerned with control.
Test coverage gives us control. So these things are they're
essential. The challenge is that for many
of us, this is what we mean by thinking this is everything and
it's the most important thing and everything else can just go
away because it doesn't matter. And the problem is we can reduce
complexity. So that's reductionism.
Object oriented programming, for example, encourages us to break
a complex piece of software into its parts.
My first professor used a car as an example.
You don't just have a car code base, right?
You have a brakes code base and a steering code base, and that
these work together, right? The challenge is it doesn't work
the other way because relationships produce effect.
Nowadays when we're experiencing a bug, for example, in
production, I joke, I make this joke all the time, so I'm going
to have to find a better one, but that it's a great day.
When the bug is in the code, it's OK.
It's right here on line 492, but it's usually in something that's
impacting eventual consistency, some timing, asynchronous timing
of something is not working. And so when we want to design a
system that supports fast package delivery, we can't just
focus on the placing an order part, the managing the movement
of the package part, the software that handles deploying
the delivery truck every in in the different regions.
We also have to think about how they work together to provide
that capability. And so the challenge is that we
don't have a practice, we don't have language.
We work in organizations that are only concerned with control,
that are only concerned with top down thinking, that don't create
environments for knowledge workers to share knowledge and
to learn together and to innovate together.
We still apply an industrialized mindset to the development of
what is functionally a knowledge system.
And so it's more systems thinking for me where why I've
gotten into this is because of that friction, that tension.
It's not that what we're doing doesn't work, it's that as
relational complexity increases in a system, what we're doing
isn't sufficient. So what other skills do we need
in order to be effective in our role?
Be effective, make an impact, have influence, do hard things
together. That's kind of the whole point
for me, right? And I don't work on an assembly
line. I create something that doesn't
exist. And I need broader skills to do
that. Yeah.
So I think that even though
maybe some people may have heard about this, you know, knowledge
worker, the term knowledge worker, right?
But I think still many leaders of many organizations still
think, you know, for us these days, right, Even though there
are plenty of knowledge workers, it's not just the coder, right?
So almost everyone now is a knowledge worker.
They think, you know, they can just create a predictability.
So top down control, right, those kind of stuff.
So I think it's first, yes, I think we have to be aware that
actually with knowledge worker, these industrial practices may
not work as it used to be, right?
Predictable, consistent result and things like that.
And I think one thing that I'd like to clarify with you as well
in terms of definition of systems, right?
Because when people hear about system, maybe they have
different interpretations. System could be process, system
could be workflow, system could be something else.
But actually system here refers to many things you mentioned
about relationship, but relationship between what you
know. So maybe clarify a little bit
what do you mean by system and what are the parts in the
system? One of the challenges with this
entire subject is that a single word can mean different things,
for example. Go to a conference and bring up
the word architect and watch everybody lose their mind about
what that means and whether it's a good thing or a bad thing.
But what we discover is that that word has a whole bunch of
different contextual meanings that what we are asking from
someone with that label. There's no consistency there.
So if there's not really a definition, it varies.
So that's a challenge with system because we've used system
to mean infrastructure. There was, I was giving a talk
in 2019 and a young man sat down next to me and saw my badge and
said, oh, you're an architect. I want to be an architect too,
but I don't know enough about Kubernetes yet.
And I was like, oh, you're oh, I'm sorry that you're not going
to be happy that you sat up at my table because I have so many
thoughts on this. And it's not that an architect
can't be somebody who's really good at infrastructure
implementation and container orchestration.
It's just not what I mean by architect, or at least it's not
what I'm usually exclusively doing.
So I say all those words to say system is kind of the same kind
of word that if in context, when people say system, they mean the
infrastructure or they mean something different than I mean,
cool, because as long as we understand it, right.
But from a more purious point of view, components, parts like
software parts, for example, people, they are elements when
they sort of exist in the same space.
Those are just elements. It becomes a system when they're
in relationship to each other and when that relationship
begins to generate patterns and outcomes and things that the
parts don't do alone. So if I have two micro services
and there's an API between them, is that a system?
I'd say so. Well people could argue with
that to say, well, they're two components and there's a one way
flow of information between them.
I mean, it's a very simple system is there's no real
patterns develop. So I think reasonable people
disagree. But for our purposes, I think
anytime two or more people or software parts or combination of
teams and people and software parts are have to integrate,
have to form relationships, have to communicate back and forth in
order to do the thing they're doing, Then you have a system.
That's when you can apply what everything that we're saying, or
you can stay up till 3:00 in the morning drinking beer and
endlessly arguing about whether or not this is a system and
whether that word means what you think it means.
Because it is an imprecise, It is imprecise, unfortunately, as
much because we love imprecision, we love nuance and
ambiguity and imprecision and like it depends.
Everyone loves when they say it depends.
Makes people so happy. Yeah, and makes you clever as
well when you say it depends, right.
So I think it. Actually does.
It does. I can't fix that.
It does depend, I'm sorry, but it does.
Yeah, so I think it totally makes sense, right?
And especially so many different new knowledge being like this
one these days about, you know, in the software team is a social
technical problem, right? So you mentioned the elements
like the people, the systems, right?
It's not just about code, it's not just about infrastructure
architecture, it's the people, the relationship with the
system. And actually time is also a
factor, which I found in your book, right?
You mentioned time is also a factor in the system, right?
Even though you have the people and the system, but as the time
goes by, system might change, right?
So I think this is also a very good insight, this whole thing.
I think there's this term called conceptual integrity that you
mentioned in the book, right? Which I find is quite important
to understand so that you can actually understand about system
thinking. Maybe try to explain to us what
is actually conceptual integrity.
May I'm chuckling because this is the third question that has a
non the word concrete. I've come to dislike that word
very much. I have slides with the chemical
makeup of concrete to show that concrete's not concrete.
Concrete also is a system of interrelated things.
But anyway, so the challenge is so Fred Brooks in Mythical Man
Month said that conceptual integrity is the most important
consideration in systems design, but doesn't define conceptual
integrity. And so we're, we, we're kind of,
I'm very challenged by giving a very specific definition because
it's sort of like art. It's that you know it when you
see it kind of thing. But one way that I can describe
it, at least my experience, it resonates with my experience, is
that so you have two parts of an organization that have budget.
One of them wants to spend their budget, we need a car.
And the other one wants to spend their budget, we need a boat.
And so car, boat, they're having these requirements discussions
and, and it ends up that the engineers are asked to build a
car boat and everybody hates it because nobody wanted a car
boat, right? That didn't resolve the
capabilities that the people were trying to design, right?
And so conceptual integrity, Fred Brooks says basically when
you look at a system, you see similar patterns and structures.
It looks like it's designed by one mind.
But he also argued that he thought there should be 1
architect that is sort of designing the system.
So it has conceptual integrity. And I don't agree with that.
I don't agree with it because I wouldn't like to work that way,
but also because there's too much complexity for somebody to
do that. And also then the whole system
is held back by that one person and what that one person knows
and thinks. So I've challenged myself to try
and understand how we generate conceptual integrity.
And by this I just mean that it isn't good but uncoordinated
parts. That when that a software system
has some reliable patterns of communication, it might use
different tools but in different programming languages.
But if you moved from one part of the system, from one team
that was building software over here to another team that's
building software over here. The basic mindset, the way of
working, the way that we think about the fast package delivery,
the way that we make decisions, the way that we collaborate
cross functionally, those things are relatively familiar and
really useful. Like we understand how to work
together, how to form relationships between the system
parts, but we also can be self organizing.
It doesn't. Everything doesn't have to be
the same because we've created good boundaries.
So team topologies, for example, we could say that team
topologies is one way of trying to create conceptual integrity
in a system, meaning we think our concepts, right.
So our concepts are the building blocks of our of knowledge work
of our software. Our concepts are similar enough
that what's in production has some cohesiveness, has some
sanity, has some elegant simplicity.
There's enough integration and yet not so much that we are just
straightjacketed and we can't actually do anything new or do
write in a language that's right for our team, and the other team
can do something different without disrupting that
integrity. So that's the thing.
There's a lot of words to describe it because it isn't a
measurable thing. I can't write a test and give it
to you and you run it against production and says, oh, Diana,
we scored 8 out of 10 on the conceptual integrity list.
Because what can be the same and what can be different will be
different in every system. Sometimes it would be
disintegrating if everybody just went off and started writing
microservices in any language doing any using any event system
any of like some using cues and some are using Kafka and some
like that would be bad and in other systems that can do that.
So it depends. Yeah.
So one thing for sure, the illustration that you gave
right, the car boat thing, I think that gives a very good
insights, right, about this conceptual integrity.
The way I think of it, just like whenever you try to build a
system, right, there is a purpose that you try to achieve,
right? Be it the business outcomes, be
it, I don't know, architecture, alignment, whatever that is, as
long as you serve that purpose, right?
There's a conceptual integrity that maybe is well defined in
the systems, right? So if you can serve that
purpose, So system thinking, I think it's really hard.
You can't master it just by reading the book or maybe
listening to this episode. Yeah.
So in your book, you mentioned some practices that we can do in
order to improve our system thinking, maybe elaborate some
for us. If we want to improve our system
thinking, what should we do? So the first thing I'm gonna say
doesn't sound like it has anything to do with systems
thinking or anything, but it is the most important thing we can
do. It's very simple.
It's much harder, though, than it's going to sound.
But I'm going to say what it is and then I'll describe why it's
a really important practice, right?
So we started this conversation with, we're all mad because
everyone's against us, right? So part of either what we would
have done anyway or is a reaction to these, to the way we
work or both, is that we're a very no culture.
We're a very change my mind culture.
We're a very. I can't tell you how often I
share an idea, I give a talk, I write a book, I model something
and the feedback I get is that's wrong, that's wrong, that's
wrong, that's wrong, and that's it.
That is the whole, that's the whole thing.
Now, often it is wrong in those spots, and that's really helpful
because I want to improve my own thinking.
The challenge with systems thinking is systems thinking
because it's about how relationships produce effect,
because it's about looking at a problem from multiple points of
view so that you can really understand it, not just from
your own, but from other people's experience.
Our no culture, our change My mind is antithetical to systems
thinking. You stay in the silo of your own
head and you force people to their ideas.
They're sieging. They have to siege like you're a
castle and they have to climb your walls to get in to make you
too. As long as that's what's
happening, systems thinking cannot happen.
It can happen. So the first thing is yes and or
even no. And but improv teams learn this.
So improvisational comedy teams, they get out on stage, they have
no script, so they have to make things up and figure things out
using their skill set. That's what we do.
We get together and we make things up and we figure things
out using our skill set. They practice yes.
And before they go out, that's a warm up.
And if you've ever seen an improv team where somebody said
no, or somebody said that's a bad idea, or, you know, oh, that
looks like a graph and graphs don't scale.
Like the whole scene falls apart.
Nothing good comes of it. And the audience feels it when
it happens because it stops the flow of knowledge.
It stops the relationship, the informational relationship.
So the one practice is trying to acknowledge what you're hearing,
acknowledge other people's ideas, acknowledge you don't
have to agree. You're just acknowledging you're
just the OK, this is what's happening and offer something
that helps improve the idea, that helps improve the thinking,
right, that helps steer it in a different direction.
Again, it's someone might say something I disagree with and I
can first repeat, So what I understand you to be saying is
this because oftentimes I think they're wrong because I didn't
understand them. That happens at least 50% of the
time. If I open my mouth and start
saying that's the stupidest idea I've ever heard, 50% of the time
I didn't understand them. Either they didn't express it
well or I just didn't bother to try, or I have my own biases.
And when you have understood them, then can you help improve
it? Maybe you have an experience
that is counter to their experience that that will help
them understand the problem more holistically.
Maybe you have a fact that you can share.
Maybe you have a question that will help them think more about
it. If we just started there, if we
just decided this was going to be a year of communicating that
way, we'd be 30% down the road. The challenge is people will say
that has nothing to do with tech.
That has nothing to do with system science.
Where are my templates? And all I can say is try it and
see if I'm wrong. Like if you try it and you're
like, that was ridiculous. That had nothing to do with it.
I'm going back to Kubernetes. Cool.
But it's often the people that push against that idea the most
that are the ones causing the most block towards being able to
work well together and designing a system.
So yeah, that's my hard pitch for the first practice, right?
Yeah, I love that you mentioned about that because I think there
are so many things, especially in the tech world, right?
So nobody actually knows everything, right?
It's just so difficult. And plus these days, you know,
humans, culture, we all get exposed to different things,
right? You know, Internet, books,
resources, culture, whatever that is, right?
And different people will have different thoughts, right?
So I think I like the way that you mentioned that maybe first
is we should have open mind, right?
Accept what others have in terms of opinion, be curious why maybe
they're coming from that perspective, right?
Maybe the third aspect is about psychological safety, right?
Because you want to acknowledge others and you accept their idea
and you improve on each other rather than against each other,
right? So I think I love this fact that
actually it improves system thinking by, you know, doing all
that, right? And I think one challenge,
again, like you mentioned, right, sometimes we are not
aware of ourselves thinking in this, you know, kind of like
closed box or you know, we have a lot of bias.
And in your book, actually the first thing that you think can
improve system thinking is actually by being self aware,
improving yourself. So tell us the importance of
this. How can we improve ourselves?
Because most of the time, we don't know what we don't know,
right? Exactly and metacognition and
this so the Conway's Law says that organizations that design
systems will produce designs that are mirrors of their
communication structure. And this just makes sense in
that what's in production except what we thought and talked
about, right? Like the way we think together
structures piercing says that the real system is the
construction of rationality itself, that we create concepts
and then we act on those concepts.
And if we want something different in production, we need
to think and communicate differently.
So different things will end up. And then I hijacked Conway's law
because I'm not very creative and said Diana's law is that the
way what you think and communicate is what you'll push
to production. Like that's our own minds,
right? And so systemic reasoning when
you're making a recommendation for a change that you want a new
tool, for example, systemic reasoning is not just giving
your opinion, right. Oh, React is terrible and view
is good like we should do view. How did you reach that
conclusion? What are the reasons that
convinced you? And why does this matter right
now to whatever our version of fast package delivery is, right.
So every time we make a recommendation, the next step
after we learn yes and more is also not just to share our
opinion, but make the map. How did you reach this
conclusion? Because often that's where the
parts we can work together on are instead of yes it is, no it
isn't, yes it is, no, it isn't. We can figure out how we've come
to different conclusions and then examine Maybe my reason is
it's faster and your reason is it's more reliable.
And then we realize, oh, we have to figure out which is more
important, reliable or fast, or maybe there's a third solution
that gives us both, right? So then we're talking about the
right things, then we're we're solving the same problem.
So when we're practicing systemic reasoning and when
we're giving the reasons that the reasons that convinced us,
we're having to work with our own minds first.
I challenge anyone listening, anyone who listens to this, to
do it three times to have an idea.
So maybe there's an action you want people to take.
Maybe you have a theory about why something isn't working and
you want to share that theory. Maybe you have a solution that
hasn't been considered before. Before you say anything, sit
down, write it out and then write 3 to 5 reasons that
convinced you as and include why it matters, why this is
important to talk about right now and not why it matters to
just the tech. But why does it matter to fast
package delivery right? Why will this improve if you're
like most people? You'll discover you suck at this
really like the we don't know. We don't know how we've come to
the our conclusions and if we have to show our work, we
discover that we've got biases, we have logical fallacies.
We have so many bugs in our thinking and we don't know that
because we kind of just go around sharing our opinions
because they convince us. So the metacognition, the
self-awareness is recognizing that we need to create
conceptual integrity in our own minds before we can share it,
and that as smart as we are, we're not generally great at
that. Also, we often are reacting.
So I go into a meeting, someone says something and like I want
to bite this person. I just want to bite this person
so much like I'm just so this is awful what I'm hearing.
And then we respond from we start reacting, we start
communicating our frustration, our aggravation, our everybody
hates us product to suck though these.
We start doing that and OK, but it will almost never get us what
we need. Pretty much all it does is add
fuel to a fire to notice your reaction so you recognize, hey,
there's something wrong here, this doesn't have conceptual
integrity. Then take a step back, put on
some headphones, set a timer for 30 minutes and try and write a
recommendation. How would you improve this
situation? What would you do differently
than what you're hearing? And then you discover you love
to complain way more than you like to come up with your
engine. We all do.
It's fun, it's addictive, it's awesome, right?
And it's not a bad thing like linear thinking's not a bad
thing, but it doesn't get us what we need.
So those two practices of metacognition.
The other thing is when you do it, you realize the patterns
happening in your brain are happening at scale around you.
And it starts to teach you how you can help other people also
come to better conclusions because you're doing the work in
your own mind. And you begin to see things that
help. What helps, what question to ask
what and for example, for architectural decision records
for ADR's, a thing that stands out to me often is that people
don't describe other options they considered.
They're just recording the decision.
So just the question of hey, what other options did you
consider? And can you show me why the you
came to this? Like this seems solid, but when
things change I won't actually know what else was considered
and why it was not chosen. So can you add that just that
brings systems thinking to an architectural decision record.
Because there was no run right answer, they came to the best
possible conclusion. That's systemic reasoning.
Systemic reasoning is coming to a conclusion and taking an
action even though there's not one right thing to do That's it.
That's systems thinking. And you can do that in one
artifact. And for many of us, that would
be sufficient to improve our impact and influence and our
career significantly. Just those because it's
unfortunately pretty rare. Wow, I like that you mentioned
so many different things, right? I'll try to summarize as best as
I could. Right?
I think the first thing is about trying to explain what you think
it is right to other people by, I don't know, elaborating in
three reasons, three bullet points, and maybe we can even
use writing as a thinking tool, right?
And it reminds me also with, I don't know, I think it's Richard
Feynman who said that if you can't explain to others what you
think, you actually don't understand it, right?
So I think it's a very good reminder.
And I like the mentioning about, you know, instead of reacting,
you should, you know, maybe take a pause.
I think like creating a gap in the mindfulness practice, right?
Instead of reacting straight away, create a gap and then
respond, right? So I think I like that practice
as well because sometimes engineers, we are passionate
about something, right? We always try to argue with each
other. So I think that's a very good
practice as well. So I know that if we improve our
self-awareness, it's not enough to improve the system thinking.
It's a collective thing. The relationship with others
need to improve as well. And in your book you also cover
another thing. Another aspect is that we has to
improve in terms of system thinking as well.
Maybe it's a team, organisations, whatever that is.
So tell us maybe some practices that we can do in order to
improve the collective. You know, I don't know
understanding about systems thinking.
Yeah, so the first one is the we come right back to the war
between product and tech and everybody hates us.
But here's what I discovered. My leadership responsibilities
increased, but also my primary responsibility is to the code.
Always, right? It's always to, if we don't have
quality in the software, then it doesn't matter what else.
Like well, and that's not entirely true because sometimes
really crappy software actually does the job just fine.
So that's not always true. But generally speaking, right,
my responsibility is to the system, which means to good
tech, right? And whatever good tech means in
that situation. So I think that I speak business
well. So I'm in a situation where we
need millions of dollars. We need a bunch of money to do
the thing that we need to do. The system, the software is
becoming obsolete. The organization has whatever
its fast package delivery goals are.
But the legacy system wasn't designed for the modern world
where there's so much relationship between
information, right, that they could just put everything in a
database. So, you know, just stuff it in
Oracle and it'll all work. And now that doesn't work for
them anymore, right? So what do we do?
How do we figure out what to do? In order to figure out what to
do, we have to understand other points of view.
We have to understand, OK, we want to make this change and we
need money to do it. Now I have to talk to people
that won't understand my tech language to get the money.
But if we don't get the money, it doesn't matter what tech
language I'm using 'cause we can't build it, 'cause we have
to. I have a mortgage.
I do not work for free. So like, I, I mean, I wouldn't
mind working for free, but I have a mortgage.
I need to work for free. So this is something that we
haven't really been thinking about as engineers and tech
leaders is that we don't realize that we have to get the money.
Like that's just part of it. But also we are the group of
people to predict what users will experience because we are
not users of software. And I know this because I've
been dragged kicking and screaming to watch user testing
to. Once I was architecting a
systems change and the head of graphics made me go watch 12
people use the legacy system for what it was designed for.
And I'm rolling my eyes. I know what the system does.
I built a bunch of this software and Oh my God, they used it 12
different ways. They had all these hacks and
workflows that I would have built everything wrong for that
because I thought I knew what they did.
But I know what the software wants them to do that is not
what they actually do, right? So my point to all of this is
that I am not very impactful alone.
I need to partner with people who have expertise I don't have.
I think I speak great to business and I can be very
persuasive about why we need $1,000,000 until I try it.
And then they're like, geek, geek, what the hell?
What the hell are you saying? The point is like 3 pages down.
An accountant once said to me, you sent me 26 pages, Diana, I
can't read 26. And I'm like, but this is a
complex thing we're doing. And no.
So I have discovered that in order to build hard things and
to work on teams where we build hard things, I need more skills
than I have and so I need product.
I'm giving a talk with Kat Morris at Qcon next week and Kat
is on the product side, always has been, and I've been on the
tech and architecture side. We started to the planning the
talk by modeling our stories and discovering we had the same
pain. But when we started, I said all
of my stories, our product ruined everything.
And she said all my stories are the architect is the complete
pain in my butt and I can never get anything done.
And what we realize is that in our own tribes, we're fighting
about how to think about things and then cross functionally we
are and realize if she and I could work together from the
beginning and she could do bring in the knowledge she has and I
can bring in the knowledge I have, we'd get an outcome that
was so much better than this linear.
First I do a thing, then she does a thing, then we hate each
other in between and like. And so partnering that within a
team, the ability for my current team, five of us can get in a
room. We understand what we're trying
to do and then we figure out how we're going to do it.
And sometimes we experiment or prototype, sometimes somebody
recommend something and we just go in that direction.
So can you sort self organize to decide what to do?
But then also can you get the partners and the information
that you need in order to build something that really matters?
And for me, that comes from recognizing that your skills are
insufficient in the modern world.
You can know everything about JavaScript there is to know, but
if you don't know how to make people's lives better with
JavaScript, how much value are you really bringing, right?
Like, so it's both. It's being really good at
JavaScript and being really good at making people's lives better.
And they don't even have to know what JavaScript is to benefit
from it. Wow.
So I really love that because it reminds me of the past, right
when I used to work in a bigger organization.
It's always, you know, full of blame or maybe not just blame,
right? It's misunderstanding.
You know, we think other people are trying to make trouble for
us, right? And the same thing I believe the
other team will will also think we are making trouble for them,
right? So I think like partnering,
leveraging each other's skills and maybe perspectives, right
bring into the table and come up with a better solution.
I think it's a really good way of, you know, improving the
collective systems thinking in the team.
And I think you mentioned when you prepare the presentation
that you mentioned about modelling.
I think this is also a very useful practice.
In fact, you mentioned it. Arguably, it might be the most
important activity or skill set that one can do in order to
improve the system syncing. So maybe tell us why modelling
is so important and should we practice more modelling inside
our, you know, day-to-day work in the tech industry?
OK, so I have, I want to say one more follow up for the last one,
then I'll answer your question. But at the moment I'm distracted
by, so I'm just starting my next book and I'm like, Henry, will
you please be a reviewer in the book to give feedback?
Because your questions are exactly structured to really
help people understand how to build the skill set.
So I'm like, yeah, I love these questions.
These questions I want now I'm going when I watch, I'm going to
write them down being I'm going to make a talk that answers them
in this order because this is the best order of questions.
So thank you for that. The one follow up I want to
have, because this is really important.
I say partnering, I say collaboration.
I say these things. I don't mean them in a Kumbaya
summer camp. We all live in peace.
Oftentimes the other team, the other person, they are trying to
make trouble for you. They are.
And we often work with people who are being mean and bullying
and awful. That is true.
In that situation, you can't do systems thinking like that's a
political problem. That's a behavioral problem.
So one of the things, especially being an outlier in tech, there
aren't very many people. There are very few people who do
what I do, who look like me. What that means is that people
presume that I want to be the glue role, that everyone gets a
long role. I do not want to be that, and
I'm not particularly good at that.
But also, I think that people feel I suspect I'd get more of
the bad behavior than other people might, and I suspect that
I sometimes have to work harder to convince people to pay
attention to me. That's not great.
My point being, though, I don't want to suggest if we just
collaborate, yay, everything will work.
We also have to fire the people who refuse to create social
learning and we we have to move away from the 10X developer can
be the worst person in the world, but as long as they're
delivering code, they're productive because that ignores
all the emotional labor everybody has to do every single
time they have to have a meeting with that person, right?
So I mentioned the partnering, but I left out the fact that
both hearts have to be consenting to do that.
I don't mean try and get people being hateful to work with you.
No, the people being hateful need to stop being hateful.
We talk about cat herding roles. Nobody gets to be a cat.
That's not what systems thinking is.
It's not changing hearts and minds.
Change your own mind. That's your job.
That's not my job. So this willingness at the heart
it, it really, it matters. And so I said that and now I
forgot. Oh, modeling question.
The modeling question. OK, so the again, we're going,
there's a war of what modeling is, right?
Is it C4 diagrams? Oh, it's not UML anymore.
I've learned I'm supposed to hate UML.
I actually like UML. It's useful.
I mean, not for everything, but there's some things.
So I don't necessarily mean a specific model, boxes and lines,
although I do a lot of it. I mean open a mirror board, or
even better if you're in person, an actual whiteboard and when
you're trying to solve a problem, try and model the
problem. I also mean use things like
event storming to understand systemic issues, which is
something absolutely worth Googling.
I mean, if you're trying to figure out what is our fast
package delivery, do it in a in a model.
Because we get so entrenched in language and our communication
styles and often we think we understand each other.
We think we're saying the same thing, but we're not.
If I go into a room of 6 people and say we're going to be agile,
there are 6 reactions to what I'd said and they are completely
different universes. The one person's like yay and
one person's like I will murder you.
And then there's like all the things in between.
And then three people say you mean Jira.
Like no, I don't mean Jira, right?
So like we often think we're solving the same problem and
when we're going around and around and we're bike shedding,
usually it's because we have completely different mental
models of what we're doing. We're just not looking at the
same thing. So just having a conversation,
but including the visual element, moving things around,
making relationships. If you or if you're having a
conversation, we're having discourse.
We don't really understand the relationship between the ideas
we're sharing. But if you have 3 stickies and I
have 3 stickies, we're seeing if there's a relationship, the mind
just automatically thinks about the relationship between those
six stickies. So you've taken a step into
systems thinking as soon as you have two stickies and then you
think, well, are they the same? Are they different?
Are they? And so modeling is really, it's
a conversation. Modeling isn't reality because
you can only ever Model 1 point of view.
Modeling is defeasible, meaning I can only draw what I
understand right now, but next week it will look different.
I don't mean North Star model like I'm going to show the
engineers what you're building. Here's a model, go build that
because that's dumb. That doesn't work.
But I do mean that instead of just writing bullet points and
lists of requirements and when you're making these kinds of
decisions or you're understanding a systems problem,
use visual language, use shapes, use lines, relationships, when
you're trying to work together. This is how the product person
and I discovered that we have the same pain.
But when we talked about it, we talked about how much I suffer
because of her point of view, and she suffers because of my
point of view. And what, when we modelled it,
we saw a completely different reality.
Yeah. Yeah, this is like the funny
maybe cartoon, right? Where people draw different
shapes of, you know, the requirements, right?
Some draw triangle, some draw maybe circle, some draw squares
or also the other analogies like you are touching elephant in
different sides, right? People describe elephant in the
different ways, right. So I think modeling is an
exercise for you to actually align kind of like the same
perspective, same understanding. I think it's always great to
have this exercise. In fact, every time I have, you
know, requirement issue, it's always about different
perspective, right? It's about different, you think
different and I think different. And if we can come up with a
model that we agree and align together, I think that will
improve our understanding about the problem.
No, you're just the so model can be text too.
I was just thinking because I was having this conversation
yesterday, how a JIRA ticket, a ticket, however we do work,
right? That's actually a model.
Even if we don't use shapes, every artifact we create,
anytime we're sharing the concept, we are making a model.
And one of the things that I really learned.
My most recent team I built got to build it and so I brought in
people that I know we can do something really hard together,
new complex because it was a big challenge.
What I discovered is if there are six of us, if I write a
ticket to describe what it is that we need to build, I would
write 6 completely different tickets depending on who was
going to pick up the story. Like Claire loves, loves lots of
detail, right? Loves lots of detail.
But for another engineer, I don't even need to say much
because he works best if he can then have the discussions and
think about the problem and write his own ticket.
And that's true for a lot of us. I think a lot of us would do
better if we could write our own ticket, if we could say, here's
the information I need to think well and then take that and have
any follow-ups, ask any questions and decide how to
approach the work. So I wanted just to interject
that a model, I mean shapes and such, but that even the way that
we describe a piece of work is a model.
And that being flexible with how you have these discussions to
fit the brains of people who are going to be making these micro
decisions benefits the outcome. Because you get better outcomes
when people get information the way that their brains process
that information. So that sorry that was my add
on. Yeah, very good addition in
fact, right. So I think that's a very, I
would say it's a good insight, right, because people interpret
things differently. People like details on some like
maybe more abstract, more visuals, right, I think.
Yeah. Thanks for adding that into your
explanation. So I was about to ask one thing
that is probably can be a big disruption these days in the
systems thinking, maybe the introduction of AI with all this
kind of systemic problem that could happen.
So maybe in your view, right, as a system thinker, what do you
think would happen if let's say people start to use more AI or
AI become more entrenched in many of the things that we are
doing these days? Yeah, So that's a big question,
a common question. I will say, Speaking of
metacognition and knowing one's own mind, I'm a relatively late
adopter. People would say AI and I'd say
you mean fancy search. There you go.
AI can do that. Do you mean fancy search?
And because it's not intelligence, right.
So also, I've been in tech long enough to see we are so trendy,
were so trendy. We're like, this is the best
thing ever. And then this is the worst thing
ever. Like my joke now is that
apparently agile is causing climate change based on how much
people hate it. But I remember when it was the
silver bullet that everybody wanted, right?
So with AI, I've had a little bit of like, I think we all have
the perception of what AI can do and what it actually can do are
far enough apart that I get frustrated with all the
organizational adoption of AI that is not actually going to
solve their problems. And so I'm like, so just a
caveat with I'm in it now and I'm developing my skill, but
there are other people out there that actually have more
expertise and answer this question I think with more
knowledge than I do. What I can say though is that
systems thinking is about inference.
If I have an idea and I tell you my 3 reasons for doing it, the
thing that makes that idea strong is the relationship
between the reasons. How you can say if this and this
and this, then of course that, that's inference that and that
relationship. So if we think of a graph
database, we think in nodes, we think in objects and data
objects. But decisions, tech, software,
thinking, all of that is about the nodes.
It's about the relationships between them and what those
relationships signify, and AI can't do that unless it's told
to do that or unless we've juxtaposed.
We juxtaposed Taylor Swift and singing in all the information.
So AI knows that Taylor Swift is a singer, but that's not really
inference as much as it's those things are next to each other
all the time. So I have a colleague, Abraham,
who gives a wonderful talk on AI for architecture.
I'll send it to you. Maybe we can include it in the
comment piece. But he does a great job of
showing how AI can really help us and also what its limitations
are for architecture and problem solving.
And a lot of it is inference. And in the talk, he makes a
think tank with Mel Conway and Matthew Skelton, someone else
and me. And so I'm sitting in the top
the first time I saw it, and I'm watching what AI thinks.
I'll say when it's answered a question about what would Diana
recommend? And I'm like, am I that lame?
Am I that lame in life? Like it made me so lame and it
made me lame because it doesn't understand.
It depends, right? It doesn't understand that what
I would say would be based on exploring a particular situation
and not just saying sociotechnical.
It's sociotechnical. That's the thing, right?
So in terms of what we're talking about, I think that I'm
rightly not a fan of AI to help us much in that way because it's
actually what it doesn't do. That said, Oh my goodness, AI is
so much better at summarizing me than I am at summarizing me.
And AI is so fast connecting complex ideas.
So for example, if I were to say who out there is thinking about
systems and teaching about systems and what's their point
of view and how does it relate to these 4 chapters in my book,
it would take me months to do that research.
Now some of it is wrong and it's missing people that should be
there. So I still have to, I still need
knowledge to know that AI is wrong and limited and bias.
But that's true. Whenever we talk to other
people, we have our own. So AI is just a very smart
person that has more knowledge than most.
But is it knowledge or is it information?
And that's, I think the really big thing is that we say
intelligence and we say knowledge and I'm not sure it's
knowledge or intelligence. I think it's just very well
crafted information. So I do think that it's broke.
I've asked code questions and it's broke my code as often as
it's fixed it. But also it's very quick to
point out things I don't know. It's very quick to show me how
things are related. I had to write a bio for my and
I hate writing a bio for myself. I asked it to give me 4 BIOS of
me and I'm like, I'm really cool.
That's really good. Like I like right?
Because it knows best practices for language, for structuring
language and things like that. So I was a writer before I went
into tech and I quit writing. I was tired of being poor.
And I also wanted to do, I wanted to use my university
learning. So I moved to Austin, TX, where
all the cool tech was happening so that I could really just
focus on my career. And then, ha, ha, ha, as a
systems architect, I write a lot because language is what how we
communicate, right? And then I wrote a book and then
I didn't quit anything. But the structure, the way we
structure code, the way we structure language, these are
all very similar. We're doing an informal logic
where there's not one right way. We figure out sort of the best
way. And so AI where a lot of us
struggle with using spoken language or informal language to
describe our ideas. I'm sad to say 'cause I wanted
to hate it, but I think AI can really help us with that.
Not wholesale, not cut and paste.
And sometimes, like I have a friend who she writes a talk
abstract and then she asks AI for the titles and then she
makes sure she doesn't use those titles because those will be
like marketing speak like because it comes from the
Internet, Like they'll be awful. So you can even use it as an
example of what too many emojis and exclamation points in your
writing look like. But I think it can help us
communicate our ideas better and it can help us to bring in other
perspectives we don't know exist, and then we can go
explore them. So in that way, I think it's a
good partner and it's still fancy search.
Right, thank you for giving like such a balanced view about AI,
right. I I really think like this is AI
is going to be like one elements that we need to understand in
order to really understand the systems, how the systems work,
right, Because so many people leverage AI these days, right?
And sometimes they don't Fact Check, they just copy and paste,
right? And it creates, I don't know,
like impact into the downstream or maybe to the other things
that generates, right, The result that AI produce, it gets
used by other things, other systems or other person, right?
And I think the systemic impact is gonna be a bit difficult to
reason about because you don't know where it comes from, right?
The inference is missing like what you said.
So I think thanks for giving that perspective.
So Diana, unfortunately due to the time we have to finish our
conversation, but before I let you go, I have one last question
that I would like to ask you, which I call the Tree Technical
Edition wisdom. Think of it just like advice
that you want to give to us. So maybe if you can share your
version to us? Yeah.
So repeating the theme, you get more bees with honey, that kind
of thing that like maybe we just be like a little bit more
patient and kind with each other because we're all doing hard
things and especially there's a lot going on in the world.
There's I'm in the US, there's a lot going on here and that maybe
we just make a little more space for each other.
That one partnering with skills you don't have gives you more
impact and influence. It's a good thing for you.
Like it makes you better and it makes you more trustworthy.
So definitely worth doing and the value of deep work, of
knowledge work. Like I go back to the perennial
question, how many of us are trying to fight for three or
four hours a day where we've just put on our headphones and
focus and do hard things, challenging things, creative
things, not just fulfill tickets, but really try and
solve problems and really use our minds to generate new
thinking. I wouldn't go all the way to say
because I've also had people who have that all day and then they
have 15 minutes stand up and they complain because they don't
want to be there for 15 minutes. It's because they don't want to
socialize at all. So not to that extent, but yeah,
be a little kinder, do deep work and improve your skills by
partnering and leveraging skills, other people's skills,
because that's the magic that helps you.
Last thought, the number one question I get asked when I
teach is what do I do about the fact that nobody listens to me?
This is our number one pain. What do I do about the fact that
no one listens to me and I feel that pain?
Oh my gosh, so much. And so those three things
together are at least towards that answer.
It will help people listen to you.
And we really do want to be able to share our ideas and have a
positive impact in the world. Lovely piece of wisdom.
Thank you for sharing that. It's a lovely message.
So Diana, if people want to connect with you, ask you more
questions, maybe find out resources about systems
thinking, is there a place where they can find you online?
Yeah, so I'm Diana Montelian, my name on LinkedIn and just the
Fetaverse, so Mastodon and Blue Sky.
And there's a site, Learning Systems Thinking that tells
about the book. My company is mentrixgroup.com
and that will show also I have a blog.
The best way, my favorite way is I do a fair amount of speaking
and workshops and I have a community System Crafters
Collective that we're building were for people all of us out
there that say no one listens to us to get together and talk
about how to do those. So joining System Crafters
Collective, following and asking, especially on LinkedIn
and ideally in person. If you are somewhere that I am
and you've listened to this, I'd love to come up and introduce
yourself. And I love hallway chats.
We can talk more about some of these ideas.
Reading the book too. Reading the book is a good
thing. I forget to mention that or
people in the comments would be like, oh, she wrote a book,
She's just pitching the book now.
I wrote a book because I'm in pain and so are you.
So let's figure out together how to solve that.
Yeah, so I can highly recommend the book as well.
So I think it's rare to find systems thinking book, right.
Donnella middles book is one that always get referenced, but
something that is new with perspective of tech.
I think learning systems thinking is one book that I can
recommend. So thank you for your time Diana
today. It's been a pleasant talk.
So thanks for all the insights today.
Thank you, Henry. Thank you so much.
Thank you for the questions. They were terrific.