#219 - Why Learning Systems Thinking is Essential in Tech - Diana Montalion

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. 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. 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.