Learning Systems Thinking with Diana Montalion and Lisa Schäfer

Welcome to a new episode of Software-Architektur im Stream.

Today’s guest is Diana Montalion.

Welcome, Diana.

Thank you, Lisa.

We will talk about her new book, Learning Systems Thinking.

I will have a copy right here so I can put it in the camera sometimes.

And we will talk about systems thinking in general, I think.

In the chat, you can ask your questions if you have any, and you get a discount code of 15% for tickets of Software-Architektur gathering in Berlin next week because Diana will speak two times.

The first time is on Monday from 9 to 5 with a workshop, I guess, systems architecture life experience.

But this is already sold out if I had a look at the program.

And on Tuesday from 15.15 to 16 o’clock, she’s talking about architecture as designing knowledge flow.

So welcome, Diana.

Now we will switch over to talk about your book and about systems thinking.

But first of all, who are you and what are you doing?

So I’m a systems architect and the founder of Metrix.

And also I do a fair amount of teaching and writing and speaking.

At the moment, I’m in Berlin getting ready for next week’s conference and juggling the fact that Wi-Fi went down just before we started and my phone wouldn’t work at the hotspot.

So my friend Javiera has a hotspot.

And so what I’m doing right now is juggling technology mostly.

Very cool.

And you’ve been a guest in a Software-Architektur stream before.

I will post this in the chat too, because you’ve been here nearly two years ago on October 7th.

Yes, it was October 7th.

And it was about non-linear thinking.

And maybe you can tell all of us, because you wrote the book Learning System Thinking.

Is system thinking the same as non-linear thinking or is it something different?

Yeah, it is the same.

And one of the challenges is that.

So O’Reilly liked the title and wanted the title Learning Systems Thinking.

And that’s actually been a very smart move.

Not anything that I regret.

But in fact, there are a number of different approaches to thinking and communicating that.

Aren’t technically systems thinking, but also what I mean, like pattern thinking.

Edward Dubono’s work also describes non-linear thinking teams that are learning driven teams or learning organizations, like in Peter Sanjay’s fifth discipline, that is also systems thinking.

And in different areas like academia versus engineering versus say marketing, you could take a systems thinking course and it would include a pretty wide variety of things.

And so and so.

Really, we really can’t be too concerned with a specific definition, although in the book I define what I mean by it and what the book does.

But it’s basically the antithesis of linear thinking and reductionism and things that we all practice and need on a daily basis.

So it’s expanding our tool set as software professionals by adding more ways of thinking about software systems.

Do we have some concrete example of a way of not thinking linear?

Yes.

So for so linear thinking is concerned with top down control and being procedural and.

Trying to make things as certain as we can and predictable.

And so it’s that when we think of thinking, usually that’s what we think of.

And certainly when we think of writing code, we are thinking about procedural and predictable and we are very concerned with control.

When we add the tool set for systems thinking, we’re more concerned with how relationships produce effect.

So, for example, rather than specifically how one piece of software is coded or another piece of software is coded, although that definitely matters.

We think about how when those two pieces of software are in relationship to each other, you have behaviors and patterns and outcomes that neither of them can accomplish alone.

It is the relationship between them.

Same thing with people.

When we look for solutions just in the in technology, in the tech, if we add Kubernetes, we can solve our problem.

Then we are we are thinking about just part of the system.

But when we think about how.

What the code we’re writing helps the system overall do better at what it’s meant to do or how people interact with it, how it generates revenue, how some of the the patterns that we’re using help us to improve the relationships between software parts.

Then we’re then we’re thinking about the system.

And the challenge is that.

It is about abstract thinking, and I would argue code is an abstraction.

We’re not literally writing ones and zeros in memory.

And so it there’s a lot of this word concrete comes up a lot.

And I have a slide of the molecular structure of concrete and it looks a lot like a software system.

Actually, it’s the molecular structure of of part of it, because concrete is a mixture of other things.

Right.

So.

So one of these one of the challenges is that as a culture, we tend to have preference for what we would call concrete thinking.

But when you’re thinking about systems, you have to be very careful about where you pour the concrete, because concrete is very hard to change, very hard to move.

And it very much defines how things will will work.

And so in if we think of it as an access, as an access like the X, Y axis, when we think about a system, when we’re designing a system, we think about different perspectives of that system.

So along this axis.

But we also think up and down the macro micro scale of this particular very concrete technical decision actually helps the software do what we want it to do in the domain as a whole, have impact.

We think in systems is more about and rather than having control, it’s aiming to have impact that we want the work that we’re doing to positively impact whatever circumstance we’re trying to improve.

And when when you’re talking about this, it sounds so complicated to think in systems because you have all these different approaches, you have all these different things which has to come into your mind to form something good about it.

Do you give tips or introductions on how to think in systems without, I don’t know, burning out or getting crazy because it’s it’s a lot to think about?

It is.

And that question came up last time, actually.

I’ve talked about that a fair amount.

I already have so much to think about.

And it sounds like you’re asking me to think about everything.

But that’s you know, and the the reality is that.

These things, when we learn and systems thinking just systems architecture is a practice, right? less of a job title or a job role, although it certainly often is, but that when you’re designing a system, it’s a it’s a group of practices that when they’re done well, actually helps both the people and the technology have certain qualities that give us better results as as a system.

But that doesn’t mean that everybody all the time is thinking about every aspect of the system.

It’s a tool in our toolbox.

And so sometimes when we have reoccurring outages in production, for example.

That.

I joke, but I’m not really joking that for me, it’s a good day when the bug is in the code because then we can fix it.

But it’s much more often in the relationships between the parts in eventual consistency in the shape of the information that flows across the system and how it changes context.

And so.

Having those other tools in our toolbox help us when we need them, but it isn’t something that everybody either everyone has to do and certainly not all the time.

I mean, I do it all the time because that’s my thing.

But what we’re what we’re really focused on, because systems are all about relationships and how they produce effect, that’s in people, too.

So, for example, I can’t possibly understand the complexity in the systems that I work on anymore.

There was a time where I could be pretty expert, pretty holistically, have holistic expertise.

But those days are long gone in my career.

And so I don’t necessarily know the perspective that, say, someone, a product person might have.

So I partner with them and I synthesize what I understand with what they understand and what my experience is and their experience.

So we aren’t we we do it alone because having metacognition, meaning understanding the way our own minds work, because we are a thinking system, every individual is a thinking system.

Every team is a thinking system.

Every organization is a thinking system.

And so there are things that we do alone.

But more importantly, it’s not just increasing our cognitive load.

It’s proactively engaging with other people.

Right.

And one of my headphones.

It’s proactively engaging with other people so that we can synthesize the information and have an understanding about how things are working.

And so it is when we get good at it.

My experience has been it lessens our cognitive load because we’re designing communication systems that make information more readily available to us and more readily available to other people who are making decisions that impact us.

So over time, it’s less noise is my experience.

A lot of our cognitive load comes from the fact that we work in an environment where people are cats and everyone has their own agenda and we don’t really know how to synthesize that into taking impactful action.

So when we get better at this, we’re usually better at finding stigma.

So it is a bit counterintuitive that saying thinking about everything makes our lives easier.

But when we do have a really good practice as an individual or a team or an organization, there’s less we have to worry about because it’s easier to find information that we that we need and people to partner with who can help us.

I wonder, so you talk a lot about communication and the funny thing a few months.

Yeah, it must be a few months ago.

We asked what is the main skill in IT and technology and tech?

And the answer was communication.

That was given a lot.

And you also prove it right right now that that’s a main skill.

But I wonder if systems thinking and communicating with each other, is it something that I guess it’s something I can only go into.

I don’t know, but I am the English word.

Sorry.

I have to want to do it.

So you can’t force me to do more communication.

You can’t force me to get into systems thinking.

But is there something an organization, because everyone knows or you show in your book, it’s good to think in systems.

It’s good to communicate.

It’s good to to have the whole thing in mind or in multiple minds.

Is there something an organization can do to put their members into the right direction to make it more attractive to think in systems?

Yeah, so that’s a really excellent question.

And we’re very used to a top down control as a process.

Right.

And the challenge for a lot of people is exactly what you’re saying.

That systems thinking and communication, that type of proactive learning together not involves consent.

You you can’t lead a horse to water or make them drink.

If people are involved, if you have five people in a room trying to solve a novel challenge, a problem that none of them have solved before.

And there’s someone in the room that’s like, I don’t care what you say, I’m not doing this.

Then you can’t actually do systemic reasoning like that.

That is a behavioral challenge.

Sometimes it’s somebody is in a leadership role and they’re going to make a decision no matter what anyone else says.

That’s a political problem.

And so systems thinking itself.

I don’t anyway have a solution for how you you make people do it because it involves consent, a willingness to do it.

And so what my experience is often, though, is that if people don’t have any experience of its benefit, then I understand why they would avoid doing it.

I feel that when I go out to a restaurant and something’s put in front of me, I’ve never tasted before.

I’m always like I never think, oh, I really like this.

I don’t know what this tastes like.

And so.

So there are smaller practices that don’t feel like a big jump for people that that can give a taste of the experience that can can show the benefit of it.

And if people are willing to try the experiments, which I’ve been very pleased and overwhelmed in a good way by how many people have been come into workshops and we do something that they’ve not done before.

And maybe it seems a little strange.

And not only are they willing to try, but they’re actually really good because we are already doing this.

I mean, if we’ve designed an API interaction between two software parts, then we’ve started thinking in systems.

And so the the.

The ability to sort of have these experiments of learning teams, teams that don’t know they they don’t have a problem they don’t know how to solve, and they develop the ability to work together to solve the problem.

Kind of like pair programming.

A lot of people.

And I don’t love it all the time, either.

I can’t say that I’m always like, oh, yes, pairing.

Yay.

But I have experienced with some of my colleagues tremendous benefit from it.

So I think that you can’t really force an organization or a team to improve their communication if they don’t want to.

If they do want to, though, and most do, then you can reinforce when people and teams use the benefit of thinking well together.

And you can discourage the idea that one lone 10x hero developer is the person who’s going to save the day.

So I think it’s a lot about what we reinforce in our own behavior and in other people’s behavior.

But ultimately, we don’t have to design the system, but the system will be designed by our not designing the system.

Like the system will have a design whether we choose to explicitly do it or not.

And so it’s definitely to our benefit to participate in how things are designed so that we have better opportunities to do hard things together.

So you’ve mentioned that there are some practical examples which we can check out systems thinking on a low level or with a low hurdle before it.

Do you have one practical example? no culture, we tend to be listening for what’s wrong.

And then we point out what’s wrong.

And that just adding the practice of an improvisational comedy, it’s called Yes, and before an improv team goes out on stage, they practice kind of a Simon Says game, a yes, you know, someone says, pat your head, and everyone says yes.

And, you know, which makes me think, yes, chef, pat your head.

You know, they, this idea that, that they warm up by acknowledging each other before they then take another action.

And if you’ve ever seen, and if you’ve ever seen improv in person, and someone didn’t do that, you would have seen the scene completely crash, just completely fall apart.

And the same thing is happening to us in our daily lives.

And we don’t even notice it, we often misunderstand, or we’re reacting, or someone else is solving a problem, and we don’t really understand the problem yet.

And then we quickly start engaging with what’s wrong.

And then all we’re doing is spinning around and bike shedding.

And so just the habit of acknowledging first, right?

So, you know, okay, Lisa, this, let me make sure I understand this is the question that you’re asking me and say yes, and then and offering whatever I might also think to help improve the situation.

It sounds like a very tiny thing.

And it doesn’t sound like a tech skill.

But the block, the fact that we represent a blocker to solutioning together is a very common thing that we don’t, we don’t notice.

So one small shift is just spending a week with a yes and kind of practice and see if that yields better decisions.

And nine times out of 10, in that week, at least one time, you’ll see that it does.

And that doesn’t mean agreeing.

I’m not saying yes, Lisa, you’re right about everything.

I’m saying yes, meaning I’ve acknowledged what you’ve input, and I’m using that, and I’m adding to it.

And together we’re adding.

The next step up from that is we’re also very opinion driven.

So we’re sharing our opinion.

This looks like a graph, graphs don’t scale, right?

This is insufficient in systems design, because everybody has lots of opinions.

And we’re actually trying to help other people understand how we reach this conclusion.

So for example, if I’m saying that there’s something we need to do in the system that will improve it, event sourcing, for example, I don’t just offer my opinion, I also give the reasons that convinced me.

Why in this circumstance, is this an impactful thing for us to do?

And what are the options I considered that I don’t think will be as helpful?

And why are those not as helpful?

And why does this matter to do right now?

Like, because there’s a million decisions to be made on any given day.

So why should this one get to the top of the queue?

So the combination of practicing acknowledging what other people are inputting before you then add more, and giving the reasons that convinced you that an action or an idea or a theory is matterful in this situation compared to other ones, shifts the structure of the communication between people to be more thinking about the reasons.

Because in any particular situation, what’s best in one situation might not be best in another, you can’t just do what Netflix does, right?

And so when people reach these decisions together about how to act, they need to understand why other people have the opinion they have.

And that’s how we really understand the system.

We understand the logic that brought somebody to a particular conclusion.

And again, I know this is can be a challenge when we’re like, well, why isn’t she saying Kubernetes?

Why isn’t she saying Kafka Stream?

Why isn’t she saying like one particular solution?

And the reason is, it depends on the circumstances, whether a particular solution would be the right one.

And the people in the circumstances are often the best ones to decide.

So adding informal logic, the process of informal logic, to our current process of logic, logic, like a formal logic, helps us make better decisions, helps us take better actions.

Well, the second example you taught of the second practice, really reminded me of architecture decision records, because you have to reason why this one is the right decision for this architecture.

And I think these can be done alone.

But I think they are more powerful and more convincing for the whole team when the whole team decides on which is chosen and why this solution is chosen in this case.

Yeah, I had to think of these.

Yeah.

In working with ADRs, one of the things that’s often missing is why this matters to the organization, to the system as a whole.

So we’re solving a tech problem, but we don’t even really understand why this tech problem is a problem for who, who, you know, like, I hear arguments about performance.

And I’ll say, but so why does the system need to be more performant?

What is being impacted?

And often, we don’t know what is being impacted.

And so and the other thing with ADRs is people often use them to capture a single decision.

And they neglect to put the other options that they considered.

That’s also insufficient, in my opinion, because it’s much more trustworthy, when people have thought about three different things they might do, and why the one they chose was the one that was most appropriate to solve their problem.

So I think that those are a great structure, as long as we use them to think more broadly than, I chose, we chose this particular tool.

That’s it, like, we chose this tool, because we had this problem.

And we chose this tool, like a little more meat on the bones, so to speak of, of the of that decision helps other people to understand the context you were in when you decided, because guaranteed, you write an ADR today, two years from now, the chances are very high, it’ll be perceived as the wrong decision, because the context has changed.

Yeah.

As you said, that you don’t know why you are choosing something or why do we want performance right now?

I think one very useful method are quality goals and quality scenarios.

So when we agree today, performance is very important to us, because of, and we can do the whole thing.

So we have it already in mind.

So why do I come up with this?

I thought about it, that already the ADRs and quality scenarios, quality goals, are already small steps into systems thinking, because we, we write them, and we think about them to see our system as a whole, but put it down into single pieces to have it better in mind or better communicated with other people.

Yeah, and constraints that, you know, the, we have some fixed constraints, and then, and also heuristics, things like that we’ve decided really matter in this situation that aren’t quite as concrete, but they help us remember all of those things together, form what we’re calling systems thinking, right?

They help us to get a grasp of the context in which we’re solving a problem, and the value of a solution, because everybody who’s been in this industry for more than like three minutes knows how frustrating it is to be in a conversation, an endless conversation about something that doesn’t really matter all that much, right?

And so these are all the tools that we put together to help us to understand what, what will, so systems are all about leverage points, meaning places where you can make a small change that will have a big impact, and the thing is leverage points are harder than doing a whole bunch of things to see, to put your things, like, because we think of productivity, right?

Like productivity, how many lines of code?

Well, if I write a thousand lines of code that don’t have a positive impact on the system as a whole, how valuable are those lines of code?

But if I write two lines of code that unblock something that is really important for people using the system, then that is, that’s more of a measure.

So the, the, all the things you’re saying is exactly right.

When I say systems about relationships, I absolutely mean relationships between artifacts, like there’s the, you don’t, it’s very difficult to describe a system just on one two-dimensional model.

I mean, you can, but for me, the, the linkability, so meaning if I have a model, but I can click a link and then I can find out more, and I can click a link and I end up in the code, that when we’re making artifacts to describe a system like ADRs, like maturity models or quality goals, or the nearly infinite amount of tools that we could use as, as to, to come to some conclusions and, and design decisions, they all intersect.

They have, that’s a relationship that all together produces a system that’s better than if we don’t do any of those things.

Yeah.

So, yeah, sorry.

I, my, my, my, my brain is right now turning around and thinking about some things.

So you, oh, we have a question on YouTube, sorry.

So I will write, read it to you, and maybe I will get less confused in this time.

Jude Root says on YouTube, but to reasoning about something isn’t always what we normally do when we try to convince others.

Do you always try to put pros and cons to each other to make the decision process transparent?

So, yes.

So the, when I talk about what I’m describing as systemic reasoning, when we, when we give our reasons, and one of the ways of, of describing our reasons can absolutely be pros, cons.

And, and also Gin suggests in, in a talk that I saw her give just last week, but also in the book in, and I, now I can’t remember if it’s collective modeling or collaborative running.

It’s sad that I wrote this for the book.

I think it’s collaborative modeling because I remember to, that I wrote it on a schedule.

Oh, good.

Okay.

So it’s, I’m having a, it’s, this is not my time zone.

And so my brain is like, what the heck are you doing trying to think right now?

So I love this book, by the way, which is even more so it’s like, I can’t remember the name of my favorite book exactly.

But anyway they talk about also fixes.

So if you have a con, is there something you could do to mitigate it?

If in fact, that was the experience.

So I do think that one artifact is absolutely pros and cons.

But I think to the question, which is very true, is that people don’t usually change their minds because they hear words.

And this is a failing I have certainly had in my career.

When someone doesn’t understand something, I think they just want me to say more.

So I say more.

And that generally does not fix the problem sometimes.

So when people are experiencing doubt, when they doubt, and if, I would say systemic reasoning is always the first thing to do because you still need people to understand where you’re coming from.

But then often people need an experience.

So this is where experiments can come in, prototypes can come in, demonstrations, pairing on something that people might lean in the direction that you’re saying, but often they need to experience it as well in order to really understand it.

And so I think that’s a great question that in reasoning by itself, and that’s the thing in systems, there’s nothing, nothing by itself that solves the entire problem or the entire challenge.

And there’s no one practice that will work the same in every situation.

So we basically are adding tools to the toolbox because we might pull out the hammer, but we really needed a saw.

And then if the hammer and the saw don’t help other things like experiences, prototyping, the kinds of things that help us really dive into something.

When you talked about that not one thing will be the solution.

I always have to have your cat example in mind.

So one quote from your book is, we are all always debugging a cat and I have to think about the cat example the whole time.

Would you like to share it with the audience?

Sure.

Yeah.

So one of the things for me that’s been incredibly helpful is reading about the cat example.

So it’s very unclear because my camera will share.

I love those, by the way.

Your sketchnotes added so much to the book, because I spent a year with it without them.

So once they were there, I mean, I rewrote two pieces of parts of the book because your sketchnote summary was so much more clear than my words, the architecture of my words.

So I made the words match the sketchnote better.

And so I think a good example of relationships between the parts and then you get something better in the end.

Thank you.

So one of the things that’s been really helpful to me is reading about and studying systems that aren’t tech.

And the reason it’s so helpful is because we often think we’re sort of a special, unique little snowflake with problems no one can understand.

And a lot of our problems are just systems problems.

And the just doesn’t mean they’re easy because they are definitely not.

But it’s not unique to our industry.

There’s a lot of overlap between agriculture challenges and technology systems in terms of the types of patterns and what works well and what doesn’t.

So the cat was my cat, Marisha, was ill and struggling to breathe.

So we took her to the vet and the vet said, yeah, I need you to go to the cat emergency hospital because this could be a heart.

I mean, her heart might be failing.

And so I did.

And they brought her in and three or four veterinarians came out different times over a couple of days.

This is the diagnosis.

Well, what convinced you?

Like, oh, well, I’m sure this is what it is.

One of them said, and we checked everything.

It’s not her lungs.

She’s fine.

You can take her home and then got up the next morning and she was near death.

She was struggling.

She was not OK.

They had not solved it.

So brought her back.

We know this.

We fixed something in production.

Production goes down again in the middle of the night because we fixed something, but we didn’t fix the thing.

So the person who was the chief medical officer at that facility came in and introduced himself and said, I’m going to take over her care.

And he basically did systemic reasoning towards me.

He he doesn’t know what he doesn’t know because they don’t know.

And he never pretended to know.

But when he was making decisions about what to do next, he would.

Well, this is why I want to go in this direction.

There could be this option as well.

Now, I didn’t understand the technology of everything he said because I’m not a very skilled veterinarian, but I understood enough to follow the logic.

Oh, I get it.

We’re debugging the cat.

And it took a minute for him to understand what I was saying, but that the the the conversations that he and I were having were engineering conversations I was having with my colleagues.

We don’t know what the problem is, but we do have a process of reasoning about what to try.

And so they never did figure out what was going on and she fully recovered.

And so now we call her the five thousand dollar cat because that is, in fact, what it costs us to debug the cat.

But that experience really helped me to reinforce how how essential this skill set is, whether or not it leads to software or healthy a cat that’s in crisis.

This process of debugging through reasoning and through understanding the system as a whole and finding places to investigate or make a change isn’t unique to us.

And and it’s a quality that I certainly recognize in other professions.

And it works the same for us.

When you’re good at this, you often get more ability to do the things you think are the right thing to do. the system thinking.

And when I wrote the notes for our episode, I noticed the second line of your title.

So it’s the reality is I’ve every time only read learning system thinking, but I’ve never read what’s down below.

Isn’t it funny because I had the book so long, but I didn’t read it before.

And it says essential non-linear skills and practices for software professionals.

And before I read it, I thought, well, I will give it to everyone around me because we are all knowledge workers and it will fit for nearly everyone I know, I think, because everyone who does something with other people, communication, or trying to make the world a better place with whatever, will have great benefits from reading this book.

And why did you decide to call it for software professionals?

Because I think the methods are great for all of us.

My guess is that you wanted to make the hurdle very small to get into system thinking for explicitly software professionals, but I might be wrong.

Oh, I love this.

No one’s asked me that question before.

I love that question.

Well, partly so it’s what I’ve been doing.

I started as a backend engineer and built monoliths and then now platforms and microservices and multiple systems that interact with other systems.

And so I’d been through some big digital transformations and modernization projects with organizations that just ended up being, I used the slide of the Titanic, right, of hitting the iceberg and sinking.

And so I became very interested in why, like, obviously, because it’s very essential to us that we’re actually able to, that complexity is increasing so quickly for software people, myself included, that it’s increasing faster than our ability to handle complexity is.

And so for me, again and again, it was applying strictly linear industrialized mechanistic approaches to designing systems of software that were actually many types of software that work together, even in a single piece of, in a relatively small system now.

We also want, like, if I were to make a WordPress site for vegan recipes, I also want them to be on social media for people to come to social media.

And I want to see other people’s recipes and maybe bring that information into my software.

So even if you’re doing a Saturday morning project to build something or you want to send a newsletter, these are figuring out how to get information to flow across software parts.

And then, of course, for software professionals, we tend to be doing that at scale.

And so I was really interested in trying to translate what system science has been learning and experiencing and teaching, like Danella Meadows thinking in systems of primer to translate that into something usable for us, because we have, of course, our own language and our own challenges.

And so that was my goal when I started writing the book.

And that is what appealed to O’Reilly about the book was this translation.

And it is doing for me kind of what you’re describing, which is that it doesn’t just apply to software professionals, but because that’s what I am and because those are my people and this is my tribe, then I want to translate these things into some frames we can look through and actually see our particular challenges.

The next book is more about knowledge flow, like how we design knowledge flow.

And it’ll still likely focus on the questions you’re asking about artifacts and how we think about and model and make decisions about a system as opposed to here are the requirements for a particular feature.

And then I call it feature driven engineering, where we have a feature and we engineer the software to do the feature.

But what I’m discovering is that practicing these with the tools that we use every day has a tremendous impact on the rest of our lives.

It certainly has for me when I was writing the book that that this does apply to a lot of areas of experience and it begins to change the way we solve problems outside of work as well.

And so maybe at some point I’ll do it in a more general way.

But the problem is that you don’t know a system that you don’t know.

So I can give people general advice about systems thinking, but if it’s not really interrelated with anything more specific, it’s it’s hard to understand why it matters.

So I focus on our industry because it’s what I know and it’s what I do.

And it’s because a lot of us feel like we’re out there alone in the wilderness screaming, why are we making these decisions?

It doesn’t make any sense.

And so we’re trying to develop a language, a vocabulary, a way of talking about this and sharing these these types of practices so that they just become part of what we we have access to.

So if there’s time after that, I might extend it out a little bit.

But I still think it would always focus on particular systems because without a story, it’s hard to know what it’s hard to translate.

So we need a story.

My story is software.

Yeah.

When you’re on right now, you’re saying story.

I like that your book is full of examples and you have an ongoing example which explains all the techniques or all the principles described in the chapter before the Margo example.

Is it something you experienced?

So is it a real example or is it a mixture of some different systems you’ve seen before?

Yeah, so it’s a mixture of systems I’ve seen before, but in part because I didn’t want to pick one one organization and then publicly display all of the things that are a challenge because it’s not fair in the sense that all systems have their dark side, their challenges.

Right.

So I made an amalgamation of that represent the challenges that most information systems have.

Now, I work in digital information systems.

So it’s very.

It’s.

It is specific to that that that piece of the software professional industry, but increasingly, especially at events, I am discovering that these tend to be relatable for people in very different scenarios because, again, systems challenges tend to be systems challenges similar in most in most in most systems.

So so it’s a fictitious company, but it is absolutely based on real life experience.

And other people that have co-taught workshops with me and such like that, they go, oh, I know this system.

I’ve worked in this system a lot.

So I’ve also gotten a lot of feedback from other people that it it tends to fit their pain.

It tends to fit their pain as well.

So, yeah, both personal and industry experience.

And you said that the goal was to build a translation of the system thinking principles to our software professional people.

Was it also the reason for you to write the book or was the reason a different one?

The reason when when I look back, I’m not entirely sure because there is a the one thing about creativity is how intuitive it is.

Like in Einstein talked about this, the value of intuition in science.

Right.

And so I knew why I was writing the book.

And it’s what I said.

It’s the I can’t be effective with organizations, with teams, in my own mind without these skills.

And that when I’ve worked with teams who are very good at learning, thinking, self organizing, they were also the more high performance at teams.

And we tended to be able to build hard things with not much friction.

The work was hard instead of the.

Instead of work that instead of like the organizational political kind of challenge is hard, you know, the thing we were trying to build was our challenge, the things we were trying to understand.

So I was increasingly frustrated and I was also and I still do carrying a tremendous amount of derision towards exactly the type of skills that actually help us succeed at building really good software systems.

And so.

I felt like I’d spent a lot of my career just shouting at a tidal wave, telling it to not tidal waves, like just just just being frustrated.

And and so set myself the intention of how can I be part of the solution instead of remaining frustrated all the time by our limitations?

And I offer and develop some things that might help because I have to do that professionally.

I was way harder than I thought it was going to be, like I’m glad I didn’t know and the impact on my own life, because if I’m writing these things, I’m also having to take my own advice, which I do not always like.

Do not always like being onto myself.

And so and so it was originally to basically the book is also me architecting a system, but it is for the benefit of all of us doing the work instead of one particular organization.

And increasingly, that’s what I’m interested in is can I help more of us who are out there alone shouting at tidal waves?

Can I help us to come together and figure stuff out?

Because I still don’t know.

So I need other people to partner, too.

And we need each other to be doing experiments, sharing ideas, seeing things that don’t work.

So the book was a way of doing that, right, a way of beginning to develop a community of people.

But it also ended up being something I really needed to do.

Like I needed that conceptual integrity.

I needed the cohesion.

I needed to show my reasons why I felt that more Kubernetes, AI is not going to solve these problems.

It might be a tool, but it is not the solution.

So so what is?

And the answer is, it depends on the circumstance.

So what I want to be able to do is help people figure out to discern what it depends on.

Like if you have these options, these ways of working in this situation, what what does the impact of the decision that you’re making about the software system?

What does it depend on?

Performance is a good example.

Not every system needs to be fast.

We like it to be fast, but it doesn’t always have to be.

What does that depend on?

Certainly if you’re writing software that does stock trading, then it matters.

I have a funny question, I think.

Did system thinking help you while writing your book about learning system thinking?

Yeah, so in an interview once, I was asked about my life.

It’s a wonderful podcast that’s on pause right now, but I really love it about the developer’s journey, I think it’s called.

So it’s the stories of how we ended up in the careers of the roles that we’re doing.

It’s just very interesting to explore my story that way.

And one of the things I discovered, and he pointed out as a result of the interview, is that I’ve always been designing systems, like that’s how my mind tends to work.

And so the book really helped me to be able to try and articulate what that skill is, so that we can make it more visible.

Because what we know is people who play glue roles, people who are trying to work cross-functionally, they often are invisible.

The work they do is invisible in organizations, and yet it’s essential.

So how do we help to codify or describe these types of skills so that we actually know to have them or that they matter?

Which meant me having to ask myself, why when I come into a situation to help to redesign or modernize or transform a system, why are there certain things I trust and certain things I don’t?

Because they don’t really make sense unless you just have been through it and been through it.

So for people that haven’t been through it yet, how can I describe it to them in a way that helps them navigate the situation better when I just did it by the seat of my pants?

I always just had to trust myself.

So it was a challenge.

But it definitely also improved my own skill set, and it improved my communication, my quality of life.

But it also challenged it too.

Because I have lots of opinions.

I love opinions.

It’s part of why I’m in tech.

I mean, everything I wrote about in the book that organizations do that don’t really help, I also personally do.

And so I loved it.

No, that’s wrong.

That’s the dumbest idea I’ve ever heard.

I say it’s a big deal that I never bit anybody in my whole career.

So writing about it means I can’t really get away with it myself as much.

That’s not as fun.

Very great.

So we’re nearly at the end of our session right now.

And I like to give some kind of tip or recommendation for the people out there at the end of the stream when I do it.

So I want to ask you, what is your favorite recommendation or tip from within your book?

Modeling.

And the thing is, I wrestled so much with the modeling chapter, because I wanted to put examples of do this model or do that model or do a domain model.

But every time I did that, I’m also leaving out a whole bunch of other things that might be really helpful.

So instead, it’s diagramming is when we draw a picture, a wireframe, a data model.

Those are very important.

Model by modeling, I just mean, instead of having a conversation about solving a problem, open a mirror board and and visualize the problem or things like event storming.

The types of activities where you gather together and you try and model what’s happening in a system that I think and Mago has some examples of that of modeling approaches that would help them in that particular scenario.

And then there are many other brilliant people who are in the industry focused on modeling.

So if you get your mind around the modeling part of the book, and then go out and try new types of modeling, try them in your own organization, get used to just thinking together without being so focused on control and concrete specificity, but be able to really think about a problem and model it.

It’s also fun.

It’s really fun.

That’s a cool recommendation.

Thank you.

Thank you very, very much for being my guest today, because I love to illustrate your book, I have to admit, and I love reading your book.

So I’m recommending it to everyone I see.

And I’m very happy that it was possible to do the stream, even with your handy internet, smartphone internet, it worked.

Thank you, thank Javiera, who added this.

And if I can end with the last thought of it, I know that you’re now teaching workshops on sketchnotes.

That is a form of modeling.

And B, I am a living example of, if you have to summarize something complex, by doing sketchnoting, you understand it so much better than if you just listen.

And so I’m really grateful that your work is in the book.

But I’m also really grateful that you’re helping us to learn to do it.

Because it’s great for developing conceptual integrity.

And I would really encourage people to do it more.

Thank you.

So okay, thank you again.

And now for all of you out there, the next stream will be tomorrow from 1 to 2pm with Cosima Laube.

And we will talk about, oh, I don’t know what it’s in English, I think, single person coaching, Einzelcoaching in German.

And I will be happy to see you again.

And I’m happy that you’ve been here.

And so I wish you all a great rest of the day.

Bye.