Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Software Systems Aren’t Just Software (with Diana Montalion)
1.9k Plays1 day ago
If you want to build really large software systems well, you have to stop thinking of them as just software systems. Beyond a certain size, everything your software touches becomes part of the wider system. You’re part of the system, your users are part of the system, and every other employee & department & priority eventually forms part of that system. And that can make it incredibly difficult to make changes, or even to understand which changes will actually matter.
That might be overwhelming, but there's hope. Understanding how systems work and how to improve them is something that can be learnt, and improved at. So in the pursuit of better systems understanding, I’m joined this week by Diana Montalion, coder, architect, and author of Learning Systems Thinking. She takes us through how she sees systems, and how we can get better at discovering and understanding our own systems, as we both chew through some difficult systems we’ve worked on in the hope of figuring out how to do it better next time…
–
Learning Systems Thinking (book): https://www.amazon.co.uk/Learning-Systems-Thinking-Essential-Professionals-ebook/dp/B0D9KWZRT2
Diana’s Website: https://montalion.com/
Scientific Management (Tailorism): https://en.wikipedia.org/wiki/Scientific_management
Jay Wright Forrester: https://en.wikipedia.org/wiki/Jay_Wright_Forrester
Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices
Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join
Diana on LinkedIn: https://www.linkedin.com/in/dianamontalion/
Diana on YouTube: https://www.youtube.com/@dianamontalion
Kris on BlueSky: https://bsky.app/profile/krisajenkins.bsky.social
Kris on Mastodon: http://mastodon.social/@krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Recommended
Transcript
Challenges in Software Engineering
00:00:00
Speaker
We all know the two hardest problems in computer science are cash invalidation and naming things. But that's computer science. Today, I'm thinking more like an engineer trying to build stuff and ship it. And I think maybe the two hardest problems in software engineering are knowing what to build and changing what we've currently got in order to get it built.
00:00:24
Speaker
It's that kind of systems design, systems change stuff that no one really teaches you. But you have to learn it. If you want to build anything that actually matters to people, you have to learn how to change existing systems, how to integrate new systems with old systems, and fundamentally how to figure out what changes are worth making and what changes are possible.
Software Design and System Design
00:00:49
Speaker
Because if you don't, you're just going to either end up busily building things that don't matter or don't ship, or you get into a world of frustration because your brilliant ideas never quite make it to production because you can't get other people to line up with you.
00:01:06
Speaker
The systems thinking you need is very important to learn and it's very difficult to learn. But I think I can offer some hope. I really do, because I've long had this suspicion that the skills that make us good designers of software, understanding constraints, understanding resource management and allocation and communication protocols and feedback loops,
00:01:30
Speaker
All those software skills might make us well placed to become great designers of systems in the larger sense, understanding the interlocking systems of software and people, and needs and supplies and provisioning, of understanding CPU limits and budgetary limits.
00:01:53
Speaker
I've got an inkling that we might get good at it, but it's just an inkling, and I'm going to need an expert to help us think from where we are with software to wider systems.
Introducing Diana Montelier
00:02:04
Speaker
My expert this week is the terrific Diana Montelier. She's the author of Learning Systems Thinking from O'Reilly.
00:02:12
Speaker
and She's a terrific repository of war stories and trench stories of software change and techniques for understanding the systems we're building and for finding opportunities for improvement.
00:02:26
Speaker
If you learn one thing from this conversation, it's going to be that the differences between software systems and systems in the larger sense are very thin indeed.
Defining Systems Thinking
00:02:37
Speaker
Maybe that difference doesn't really exist. But there's far more than that one thing to learn this week, so we better get started. I'm your host, Chris Jenkins. This is Developer Voices, and today's voice is Diana Montelier.
00:03:02
Speaker
Diana, good to see you. How are you? Good to see you too, Chris. Good, great. Thank you for having me. It's so good to see you again. I'm glad you're here. The last time we met, we were in Copenhagen at a conference and we spoke at that conference. We did an interview, but I just felt that 40 minutes wasn't enough. So we're going to stretch out and really give this topic a good going over.
00:03:24
Speaker
I love that. Plus, we did so much um talking before the interview that we then couldn't fit into the interview that i'm I'm glad now we can sort of bring it together. Yeah, let's do this topic properly. Let's do it justice. So your topic is large, very abstract, but sometimes the most useful large things are. Let's start with what it is. So you've written a book called Learning Systems Thinking.
00:03:53
Speaker
I think about systems a lot, but give me a definition of systems thinking. So a challenge with the phrase that the with that with systems thinking as a definition is that it's defined differently by different groups that are trying to define it. So for example, in academia,
00:04:21
Speaker
it would be different than in the way we might mean it here, which would be different than ah the way you might go to a ah marketing course that bringing systems thinking in.
Critique of Agile Methodologies
00:04:34
Speaker
And also, I don't just mean systems thinking, I also mean pattern thinking, and I mean all forms of nonlinear thinking in formal logic.
00:04:47
Speaker
So I think the best way to describe it is to consider how time and relationships produce effect. In other words, in as opposed to we when we think linearly, we're thinking about predictability. We're thinking about control. We're concerned with having control.
00:05:15
Speaker
We're practicing reductionism where we take something complex and we break it into parts. That's what we do in object oriented programming. And so what I focus on are the other tools in our toolbox that those skills are really important for building software, but they're not the only ways of thinking and they're not the only ways of understanding how to have impact in a system.
Complexities in Modern Software Systems
00:05:46
Speaker
Yes. So I feel like as an industry over the past 20 odd years, we have struggled with this and somehow we've latched upon the idea that the problem is waterfall thinking and the answer is agile thinking. And that's going to solve all our systems into relational problems so we get a scrum board.
00:06:13
Speaker
And it doesn't seem to work. And I'm just, I'm hoping you can pull me out of that morass. Cause it feels like we're, we're desperately searching around for tools to do a better job of the wider system. Yeah. And we, so we're in a situation where the relational complexity has increased exponentially. When, when I began my career, I,
00:06:43
Speaker
usually worked in a monolith. And the relationship was between the software layer and the database layer. And that's a pretty linear relationship.
00:06:56
Speaker
Meanwhile, um because I build digital information systems, meanwhile, the world around me became a ubiquitous knowledge graph. like Every piece of ah software that has a browser access is usually also communicating with social media platforms or with APIs, or now there's a front end decoupled from the back end. And so um so we really were struggling with this because A, we
00:07:30
Speaker
we're terrible at systems thinking humans are and we don't know that we are and we don't know what it looks like when we're bad at it that we're learning now. But also the world is changing around us the way that we do infrastructure. Now we do infrastructure as code and it's like all these pieces in relationship. So we're struggling But not just because we're struggling, we're struggling because we are actually faced with a whole bunch of change and figuring out what to do ah in this brave new world of information. Yeah, we definitely, um we always used to build systems as small and contained as possible and slip up terribly when it came to integration time. And now it seems like integration is so much a part of every large system.
00:08:26
Speaker
Yeah. And the, in a way I feel like we were able to maintain the delusion that everything isn't interrelated and that we actually could control how um a system behaves. And we we can't really anymore. um I was yeah um on a panel recently and it was talking about complexity and the the overwhelming sense was that complexity is bad and we should attack it and and we should make things simple and I'm actually relatively comfortable in complexity.
00:09:12
Speaker
ah any it it's and The things are complex. Complexity just is. um
00:09:22
Speaker
So it's and I don't think we're so we we have this very like command and control approach to increasing complexity. And I think that even we need to sort of figure out the difference between complexity and complication. Complexity is just the nature of all of the work. Like that's just how things are complex. Relationships are complex.
00:09:45
Speaker
ah Challenges are complex. People
Human Errors and Learning Opportunities
00:09:48
Speaker
are complex, like these are complex. true But complication is, and and the kind of complexity I think they're referring to, is what happens when we add a bunch of noise and can't find the signal, right? that In other words, we're trying to solve these problems, these new challenges. We're trying to solve them. We don't know how to solve them.
00:10:11
Speaker
So we do a whole bunch of things that often just make it worse, and then we we we call that complexity. and it it definitely been I've definitely been involved in systems and workplaces where you know something's fundamentally broken, but you have no idea how to fix it, and so you end up just trying to focus on the things you can change. Yeah, so in systems, it's um there are two things that are pretty much always true, which we know from you know decades of system science. One is that when we don't know what to do, when when we're in a situation where our attempt to control doesn't work the way we want it to, we blame. That's the first thing we blame. Our mind gives our mind justifies what's happening. um And we blame the wrong thing.
00:11:08
Speaker
it It would be great if we blamed the right thing. We great we blame the other team or leadership or we blame the wrong thing. And then there's what's called counter-intuitiveness, which is that we we kind of know where the problem is. We don't really know what to do about it. And we do the wrong thing. We do the things that make it worse, which makes sense because We are are the way that we built the current system is why we're having the problem in the first place, right? The system is changing. We designed it. Now we need to redesign it, but we're redesigning it with basically the same type of thinking that caused our challenges in the first place. So we tend to just be making it worse. And this is totally fine. It's really normal. There's not really a way of getting around it.
00:12:09
Speaker
What I find helps is if we recognize when we don't know what to do because it's a complex challenge or a new challenge, a novel challenge to us, that we're likely our first attempts at solving the problem are likely going to blame the wrong thing and do things that make it worse.
00:12:29
Speaker
And therefore, if we can recognize that that's going to happen, we can learn and grow and see what happens and then come to better conclusions. But we like to be like, here's the problem. Here's the solution. Done. yeah And if we're in management, there's a particular huge pressure to be that person. Yes. Right. Yes. There's a very big difference between systems leadership and management. Those are not the same rules. Okay. Explain to me.
00:12:59
Speaker
Well, you had mentioned, um, I, I really love, I love your questions. I just kind of sit and basking in the questions like these are exactly the right questions. So for me, early in my career, I worked on pretty high performing, healthy agile teams. Now everyone hates agile. Apparently it's responsible for climate change and Part of the reason is that we began there are two things. We didn't evolve it. they it it was It was born in a moment to solve some problems, but then things change. so it's not It's any approach that we develop.
00:13:50
Speaker
will need to continuously be iteratively improved. That's actually the design of it, right?
Feature-Driven vs Systems Thinking
00:13:58
Speaker
So we we didn't really iterate it and develop things that help us more, but also we kind of threw the baby out with the bathwater that a lot of the things that I learned early on was about reality refuses to bow down to power.
00:14:20
Speaker
There he refuses to bow down to power. Yes. Now I'm going to ask, I've got a particular question I want to ask you about that, but I have to first play devil's advocate and say it wasn't designed to evolve. Someone is going to say, well, that's what retrospectives are in Agile.
00:14:39
Speaker
Right, and it can very much be if people are using them um to learn and grow, if the industry was doing retrospectives, if we were figuring out together so what works and what doesn't work,
00:14:59
Speaker
And I'm not I'm not advocating any one methodology. Like I'm not saying waterfall bad agile. Right. In fact, waterfall. um ah Someone just told me recently that waterfall was actually very rarely practiced the way we have come to think of it. In other words, the there were more qualities of change in the way that it was practiced than then maybe have come through the historical record to us. I don't, I don't know, cause I don't have a lot of experience with it. I certainly have very early experience of the actual thing that happened being retro explained as though it were waterfall. Yeah. And that the, for me,
00:15:53
Speaker
The core of agility, and take Agile with a capital A out of it, but just being just having agility, the core of that for me is learning teams, is is that we're we're able to make theories and predictions about what we're going to do, how long it will take us, what how how much energy it's going to is going to take, and then be able to learn from that and adapt as we learn from users, as we learn from the tech itself, and that we're more performant when we are sharing our expertise
00:16:43
Speaker
developing more not learning and developing knowledge as we go. So the antithesis 20 years ago for me was that somebody could come up with a plan and give it to an engineering team. And then that's what would happen. Like, so this should take six months and you'll build these and they make a Gantt chart and it does this. And my experience is that doesn't work in most cases. Sometimes it's small enough you can know. And so for me, the agility is not about Jira, like it's it's, it's not about, it's not about the tools we use. It's more about the culture of knowledge flow, the culture of learning, the ability to bring five people together with very different
00:17:43
Speaker
priorities and understandings and enabling those five people to come up with the best possible action in these circumstances and know why they're taking this action. What are the reasons that convinced them that this was a good direction to go in and then they do and see what happens and iterate from there.
00:18:10
Speaker
So is that i'm I'm just trying to think of this from the perspective of a typical software manager who has that team of five or whatever people, has pressures from above to deliver features, features, features. you what are the and And genuinely wants this whole thing to work as best they can, right the whole wider system. And they want the promotion, because they but they also want the system to be built well.
00:18:39
Speaker
What kind of, you go into this bit in your book, what kind of mental tool should they be developing? And it's the first one you've hinted there, some kind of audit trail of decision-making. Is that what you're saying? Well, kind of. I call it feature-driven engineering. This is what we did in the beginning, which the which was we're given a feature and we break it down and we do it.
00:19:06
Speaker
and doing feature-driven engineering is the right thing in some cases. So for example, when I was working in monolithic software for a web presence, for example, and we were adding a form or whatever, then to some extent, feature-driven engineering pretty much works. You really don't need to over complicate it. Um, and, and so it's not necessarily a bad thing, but it is as complexity increases and it definitely doesn't give us the space to think about the system as a whole. So for example, um, how do the different, if you have multiple pieces of software in relationship with each other,
00:19:59
Speaker
Are you also improving the quality of those relationships? Are you improving the patterns ah in the system? How information is structured and shared, for example?
Role of Managers and Leaders
00:20:10
Speaker
And so feature-driven engineering is not concerned with the system as a whole.
00:20:19
Speaker
So this is where, when people say technical debt, sometimes they mean there's no systems architecture. There's feature-driven engineering. You're adding new features and adding new features, but you're never thinking about, are we improving this system's ability to have impact, to give a competitive advantage um to the organization? All the things that we may have systems do.
00:20:48
Speaker
Is this what you're talking about with um conceptual integrity? Because I've definitely been involved in systems where it is an aggregation of features. And I can think of ah at least one programming language, which hasn't been designed. It's just an aggregation of features, right? All the stuff that's been thrown at it over time. And you long for some overall vision that informs the shape of the architecture.
00:21:18
Speaker
Yeah, exactly. and an understanding So to your question about the manager, right ah fundamental to systems thinking is that um a system is not the sum of its parts. It's the relationship and interaction between those parts. That's what forms a system. right If you don't have multiple subsystems in relationship to each other,
00:21:46
Speaker
it's i will you maybe don't even have a system, right? You have um one unit that's working on its own. yeah This is really tricky where the boundaries between the word system or not are because um we could argue this endlessly and the answer is there's really not a right answer. But when for the manager who's doing feature-driven engineering, the success of the team then depends on the strength of the relationships within the team. How well does does this group of people self-organize to be able to do what they need to do? And so in a way, systems leadership, to my mind, is more about um making yourself obsolete.
00:22:38
Speaker
like how How am I encouraging this ecosystem of problems that we're solving? Are they being communicated well so that the team can really understand why it matters that they're doing what they're doing? What is the the real impact that they're having? And can they improve their impact? The ability to make recommendations that are very trustworthy and well thought out because that builds team but
00:23:09
Speaker
builds trust between the team and the organization, right? Are they able to articulate their ideas? Are they able to ah experiment? And then are they able to work together to row together towards their destination? And that as that ability of that cohesiveness improves. So does the team performance, right? These tend to be the teams that are the most successful.
Feedback Loops in Development
00:23:42
Speaker
Do you know, so if let me let me pin this to something in my own experience, because yeah I was having a conversation, this is really reminding me of, I was having a conversation last week with, and you you can tell me what your answer to this would have been. I love synchronicity. I love it. so
00:24:01
Speaker
um I was speaking to someone who had done their level best as a CEO to arrange such a team. right he'd given the He'd hired smart developers, given them an autonomy over how they work, how they prioritise.
00:24:16
Speaker
They worked closely together. He dabbled with Remoto on site to try and get a cohesive team. And they all seemed very busy, but they weren't doing things that the company needed. Right. um And he was wondering, has he been too free? Has he given them two? Should I put in systems that lock down what they're doing a bit? And I said to him,
00:24:42
Speaker
where So you mentioned feedback loops in your book. I said to him, how often do your developers speak to the users? And the answer was nearly never. The users speak to their product project manager, who speaks to their account manager, who speaks to the product manager, who speaks to Jira, who speaks to our developers.
00:25:04
Speaker
And I said, well, that's why your developers are working on the wrong thing because they can only see the priorities in front of them. They can only see the, I can see the ugliness of my code. So I'm going to refactor it, but they can't, but there's no feedback loop to the user, not a real one. I just felt in that system, you can have the most autonomous high performing team. And if the only problems they can find a technical ones,
00:25:32
Speaker
They won't solve the business problems. Yeah. and see what i mean i Absolutely. And that is that.
00:25:46
Speaker
So much is described by Conway's law that an organization ah that that design systems will design a system that mirrors their communication structure.
00:25:59
Speaker
yeah yeah And so is if giving the team autonomy to have impact, but from the from what you were describing, it sounds like there are six layers in between an engineering team and their actual impact. and though So it's a telephone game yeah of coming down to them to say, this is what you'll do. Then that's, from from my point of view, that's not autonomy. That's autonomy over their own work, but
00:26:46
Speaker
when we think about um When we think about designing a system, or we think about abstraction, for example, right we're talking about both the x and the y-axis. In other words, if I'm working on something, my so goal from a systems point of view is to improve the the system as a whole, meaning in every organization, there is a reason that they exist. And there is something about their their software system, their technology system, their people system, because those are the same thing, the socio-technical system that gives them competitive advantage that is very hard to do, that is hard, would be hard to go out tomorrow,
00:27:39
Speaker
and I decide I'm gonna compete with the CEO's organization and I'm going to do better then and put them out of business, why would that be hard for me to do? And why the reason it would be hard is the most valuable part of that CEO's system, right? Whatever it is that the system does that really has value that would be very hard for someone else to just magically come up with, come ah tomorrow and and build exactly the same thing. right So whatever that core domain is for that system, that's where most of the talent and the money and attention should go.
00:28:27
Speaker
Because that's and and and understanding it also from the user's point of view, because it has value to people, it doesn't just have random value, it has competitive advantage to people. And that is the guiding a guiding principle for every line of code that we write.
Top-Down Elaboration Strategy
00:28:46
Speaker
right that' Together, that is actually what we're doing.
00:28:51
Speaker
So for me, a first step in developing a systems architecture, systems thinking in, in an organization is to keep the how connected to the why. And the why isn't because the product manager told me to build this button, then it should be red. That's not the why. The why is how is that red button having a positive impact on the the experience of this system as a whole. How is it improving its value? and this is so How would you look to adjust the system that I described to address that? so and The easiest way, and I say easy in a lazy... Everything in life is hard.
00:29:44
Speaker
Yeah, but the easiest way. So I used to call it a top-down elaboration, and a TDE for short. And that just meant that um in however you're sharing knowledge, right? So basically, you're describing knowledge flow. you that The CEO has a particular understanding of the system. The business analysts will have a particular understanding. The product people will have a particular understanding.
00:30:11
Speaker
To a great extent, this is the cartoon of the ah the blind men and the elephant, or the blindfolded, memory right where ah you one person's describing an ear, one person's describing a tail. It's an elephant, but they don't recognize the whole. And so however information and and the knowledge, these points of view, however we're communicating them,
00:30:40
Speaker
um often the communication is very dissociated. Like you have ah different types of documentation, you have meetings, most people aren't in where strategy decisions get made and then that just rolls down, but no one knows why that strategy decision got made. Like no one really understands the thinking behind it, the reasons it's important. yeah And so the, for me, what I called the TDE was just,
00:31:12
Speaker
For every story that I'm picking up in order to develop, do I have a way to um to click, maybe to click through to a document or there's a one page description of why this matters, what exactly we're trying to do and how we'll know if we succeeded connected to the and how we're going to implement it.
00:31:42
Speaker
So there is a the CEO has in your story, the CEO says, the team's not working on what's important to the business. How does the team know what's important to the business? When they pick up a story or a feature to develop, can they also know, read about, have like a one page overview that shares why this has been prioritized. How is this connected to what the CEO says is most important to the business? And usually that doesn't exist. Like you like there's a frustration of you know ah this side doesn't know what that side's thinking. So I'll ask, well, then how does the knowledge flow between the two parts? Well, it trickles down. Well, it doesn't. yeah It doesn't trickle down.
00:32:40
Speaker
and I know the way they they they, the wide, broad, generic they, but they try to solve this by saying, okay, we'll have better written user stories. But I always think like what you should actually do is try and get the developer to speak to the customer occasionally. Because no matter how well written the user story is that says that button should be blue,
00:33:05
Speaker
It doesn't have the emotional impact of watching Dave click accidentally click the green button for the millionth time and ruin his morning. If our developers had an emotional connection and a direct verbal connection to the users who are feeling the impact, that I think would change their priorities in a way that user story can't.
00:33:30
Speaker
Well, and also user stories are reductionism. They are one tiny part of the user experience. So they really can be really helpful and really matter. I also like jobs to be done as a framework for stories, similar, but somewhat different depending on what I'm building.
Partnership and Collaboration in Design
00:33:50
Speaker
But these are trying to make that connection. But in fact, all the user stories together actually represent what is what the software is, what people are doing with the software. So that's one of the challenges is that a single user story is actually just a part of the whole. And it doesn't actually tell us a lot about
00:34:17
Speaker
what users value and how they how they behave as they move across these different features. Like that part's often missing. yeah um yeah But to you to your point, I have two very quick stories that totally prove it. One is um it was but lead on a team that we were doing um it some, um was very visible. The outcome was very visible. So this was a very important,
00:34:47
Speaker
um project that we were working on and we had spent a fair amount of time with it. And then I got dragged to the user study. So ah the UX team had invited users in to test the software interface because it was now different than what they had been doing before. it Specifically, um we were building the tool for the homepage of the Economist website for the Economist magazine. And it was a pretty big change. And you know I knew what the parts were of this display. And then, of course, we built all the stuff that was behind it.
00:35:33
Speaker
I could not understand what I was seeing, that users were just kind of all over the page and they moved and I'm like, but it's right there. Like the button is right there and realized we are not the users. Like if you're building software,
00:35:53
Speaker
you don't know anything about what it is for someone to come to the software fresh where they don't know any of the things that you know. So we're the worst people to guess how users use it and actually seeing and knowing and hearing is incredibly beneficial.
00:36:17
Speaker
The second story was that, um years later, I had ah come back to do more work with them and was architecting basically a ah ah big ah systems change because the software is becoming obsolete and ah the world had changed um had changed the way that print and digital and all the digital products flow together. right It's that what we call modernization. yeah And I was partnered with the head of graphics in trying to sort of figure out some elements of the system. And he said, I want you to watch the way the senior editors do their work in the current system. And I'm like, i Bill, I don't have to do this. i I understand how this software works. And no, no, no, I really want you to do it.
00:37:09
Speaker
First of all, there were 12 different systems because each of them had a completely different way of how they did their daily work. And they also had challenges I'd never considered before. If I hadn't done that, what I designed would be insufficient and in some cases ineffective because it was based on how I imagined the software to be used. so to prove your point that i I really have experienced first my own resistance to what you're saying because I'm like, I know, I don't have to see this. And also the incredible impact and benefit of integrating how users experience the software and how we're building the software that they are so interrelated and we really can't make that bridge unless we have some direct experience.
00:38:09
Speaker
Yes. How would you describe that? Is that is that tightening feedback loops? Are we to say that we need to do a better job of route analysis?
00:38:28
Speaker
um what what's the tool What's the way of thinking there that we need to prioritize that we don't? <unk> intosizing that synthesizing that when we think often, when we think about building and designing, architecting software, software systems, I think we really don't recognize the power of partnering.
00:38:57
Speaker
with people who have a point of view or a skill set that is different than ours, right? That for me, for example, I think I speak business very well till I try and do it. And then someone who speaks business well is like, geek, geek, geek is crossing things off my face. Geek, geek, oh my God, you're just, you can't help yourself. You're such a nerd. um And the same thing with people who think about the user experience,
00:39:26
Speaker
And they often use very different language and they use different models in order to understand it. And so for me, when I can't possibly understand um all the different perspectives, I don't necessarily need to, but I also can't, right? It's not within my skill set. And so what we're really doing is we're synthesizing knowledge and experience our own and other people's And then what the CEO is encouraging the team to do is that then they use sound judgment to decide how to best deliver what it is, deliver the impact that they're trying to deliver. But the synthesizing piece often gets left out, right? Which is that in order to really understand even a feature, we need
00:40:21
Speaker
to understand it from the user perspective, from the revenue, because we have mortgages, so we do want things to generate revenue usually. yep yeah And one person can't really do that, can't maybe be in a small enough situation. And so where we we say systems thinking that and relationships produce effect. It's relationships between people. Each person is a thinking system. And so if we're able to synthesize the knowledge and experience from these different perspectives into our our workflow, into our process, into our decision-making process, then we get better, more holistic results.
00:41:10
Speaker
And now you're going to ask me, how is this ADRs? is it mo like And so um collaborative modeling is certainly one of them, things like event storming and and just being together and opening a whiteboard. Instead of having a meeting where you're talking about um linear concrete priorities, can you model? Can you model the impact? Can you model together what's going to happen and what people, when when someone does something,
00:41:39
Speaker
What happens? like What then happens? um but Also, also ah reconsidering the way that we're communicating through artifacts, whether it's writing or modeling or Slack channeling, ah can we improve the way we're sharing this information so it's more synthesizable? In other words,
00:42:04
Speaker
If the product people have decided this feature is really valuable, why? What convinced them? What are the reasons that convinced them that this was the most important thing to do? Making that visible to me as an engineer helps me to understand what they're trying to accomplish So if the tech refuses because it's not able to do what they're imagining, I can make other recommendations because I understand what it is that we're trying to do better than if I'm just told the button should be read. Why? do You know, I have. So I've definitely witnessed people using like
00:42:49
Speaker
Jira not as a way of recording those things we want done and why But as a way of not having to engage directly with other people Yeah, like we use we use systems of record to avoid personal interaction Because if I write it down in the card, I won't get challenged on it Yes, so the It's a really tricky thing because what I want to say first is that
00:43:22
Speaker
there's a lot of noise. Like people get very frustrated with, and, and as an, you know, as engineers, we, we have a lot of experience of people telling us to do things that aren't particularly wise to do or even possible nowadays. yeah Apparently we can cure cancer with AI, like anything, whatever your problem is, AI is the solution, right? yeah So the,
00:43:51
Speaker
becoming kind of worn down from communication.
Management Practices and Knowledge Work
00:43:56
Speaker
ah I think I get that, right? I get to some extent why that can happen. Simultaneously,
00:44:05
Speaker
um If our communication structure designs our system and we willfully don't have one, if we are if every person is a silo, then that's what the software is going to look like too. like There are real repercussions to being unwilling to communicate is a form of communication.
00:44:30
Speaker
Yes. Yeah. So it's not just Conway's law predicting that the structure of communication will dictate the structure of the system, but the quality of the communication too. Yeah. And ah and I would argue that using a JIRA ticket to create a human silo of a person who is has no responsibility for ah maintaining the socio part of a socio-technical system is a systems design. that That is a design. That is one way you can do it. You can have artifacts that isolate individuals and just have them do their thing. We suffer, I think, the delusion that that type of mechanistic and industrial control process makes a more productive team. This is not my experience.
00:45:25
Speaker
This is something I was going to ask you, because I've always felt that there is this thread in the backbone of management sort of praying we can make a production line of software development. Yes. Yes. It comes out of... tit So most of the way that we work comes out of Taylorism, which is scientific management. so this was So Taylor was an engineer and um um said that he was very frustrated with ah that he thought his team did like maybe 30% of the work they could possibly do. And that the the foundational theory is that workers will do the minimal amount of work that goes unpunished. Basically that workers are all lying, employees are, they're all lying and trying to make it look like they're doing work when really they're not. they're not
00:46:22
Speaker
And so we have a whole structure of power and control, like of how you, and and it's very focused on the body as well. So Taylor said that if a manager tells you to sit, you sit, if tells you to stand, you stand. So this is in our back to the office ideas, even though um the studies are not suggesting that we're more productive if we're all in the office,
00:46:51
Speaker
still the majority of CEOs actually believe that that is the case, even if it's not actually a data-driven decision. And this came, so um we've probably all seen Gantt charts. And Henry Gantt's family um um had a um was in the American South during the time of slavery. So they relied on slave labor.
00:47:17
Speaker
And when the civil war ended, they lost that. So Henry Gantt went to Baltimore and studied with Taylor. And so the Gantt chart comes directly from how do we still have that kind of labor structure, but we have to pay. So they would, uh, they'd advocate for paying us by lines of code, for example, because lines of code show productivity. If you write more lines of code, you make more money like piecemeal.
00:47:47
Speaker
Yeah, this is where educated our education system is designed to feed this and I don't want to overdo that like sound paranoid conspiracy. There's a giant conspiracy theory to bake Taylorism. It's just, this is the system that we're used to. So we think that it's normal. And the the challenge is we are knowledge workers. Like we, we are not building a single widget over and over again in a factory. We are,
00:48:19
Speaker
sharing our knowledge and expertise and experience. We're learning, constantly learning and growing. We're making recommendations. We have to think well as an individual. We have to recognize our own logical fallacies and cognitive biases. And then we have to work well as a team. You know you and I here today, we get people will only get value if the you and I are doing well at at knowledge sharing. right where're We're knowledge sharing in order to knowledge share. right yeah and so the The CEO in your story, in my experience, the challenge almost every organization makes is they try and keep this
00:49:06
Speaker
um hierarchical trickle down kind of linear ah coming out of Taylorism structure and have systems thinking and learning and growing happen inside of that structure. So they keep, as soon as you said, well, they and theyre the engineers are empowered, I'm making air quotes to to do their own thing, but there's product and business analysts, and are like there's all these layers of hierarchy above them, then that's that those two things don't fit very well together. Yes. Yeah, I'd not thought of it that way. But yet the information flow is still very much hierarchical. It is. Even if the choice of how to execute is freeform.
00:49:56
Speaker
Exactly. And so when when we're shifting ah to improve the kinds of things that you were describing want to improve, the the we have to shift the way knowledge flows and we have to shift the way people um are ah partnering in order to think and solve challenges and it focus less on control and more on impact. How do I enable this cross-functional group of people to have impact on the system that pushes it in the right direction? That's the kind of leadership
00:50:38
Speaker
That's systems, more of systems leadership, right? How do I create an ecosystem where knowledge sharing, where knowledge workers can thrive and I can leverage their brilliance and their expertise and get more than I can if I try, I'm going to get more there in that way than if I industrialize and and sort of in linearize and factorize.
00:51:08
Speaker
yeah the process. So as a CEO, what I'm looking for is in order to do that, I am looking for the levers I can move. Yes. And in in a lot of cases, I think it is it's like, oh, I should have better procedures documents. I should come up with a procedure for this a procedure for that. Seems to me what you're saying is I should start by considering information flows in the system.
00:51:34
Speaker
Absolutely. That knowledge flow, Larry Prusak says that um organizations that don't recognize knowledge flow as um the source of production will die and they'll never know what killed them. Knowledge flow is the source of production. and And I'm not sure now if source is the right word. i might be miss for It might be force, not source, a force of production. But the point is, so everything I think is what i push to production everything we think together and talk about together there's nothing in production that is not a result of our thinking and communication. like That's what we push to production so if we want to push something different to production we want to.
00:52:22
Speaker
have micro asynchronous microservices instead of a CRUD software. First, I'm changing my own thinking. I've got ideas about what's the right thing and the wrong thing to do, and they are not going to apply. And the same thing, then, with the team and the teams and the way that information flows to make these decisions, it's going to also need to change.
Leverage Points in Systems Change
00:52:49
Speaker
the ah the The iceberg I think that modernization and transformation initiatives hit is that um we we want something different in production, but we're not going to change the structure of our thinking and communication in order to get that. We're going to control it the way that we're used to controlling.
00:53:14
Speaker
And some of that is necessary. i'm I've also worked in, oh, we're a flat organization, and we just all and that was just giant cat farm, like there very little gets done. you do need um You do need workflows, and you do need constraints, and you do need some rules of any culture, needs rules to get along well, like we have streetlights when we drive.
00:53:40
Speaker
Right. It's not, I'm not saying everything's a free for all and it'll work out, but what you're describing in systems is called the leverage point. Meaning where can I intervene to make a relatively small change that will scale to have big impact, positive impact on the system? It's very hard to find leverage points. It, we're so distracted by our linearization of things.
00:54:10
Speaker
So when what you're describing for the CEO is very much a systems approach, meaning what's the actual blocker here? What is it that's keeping us from being as performant as I envision us to? What could I change? What could I make easier? What could I make easier? What could I,
00:54:34
Speaker
ah change about our mental models, the the rules and structures that govern the way that we work, what could I change that will actually move us in that direction? And that's often an experimental process because it's it's tricky to find those. It's much, much easier to just add more process.
00:54:56
Speaker
Yeah, yeah and i I'm sure I've seen companies that change their messaging coming from the top a lot more often than they change the structure in which that message will flow through the system, right? Yeah, yeah um yes, yes. yes i'm just If I can play devil's advocate for a second, because it might be illuminating, I remember there was a reasonably famous memo from Jeff Bezos at Amazon that I could prey see as we're all going to move to services-based architecture by the end of the year or you're fired. right and In some tellings of that story, that's how AWS was born. Everything is going to be service-based first. and The difficult thing there is it sort of seemed to work. like the big The big scary decree from on high,
00:55:53
Speaker
did seem to change the way Amazon worked internally. So I i wonder,
00:56:02
Speaker
um one of the things in these types of situations is I think, it's is that why? like was that you know we We correlate the outcome as caused by the decree, but Was it? Was, is that why they, they, they changed? I don't know. I know that, yeah that's fine right? Like maybe, maybe they, maybe that would have happened anyway, or in many other kinds of ways. I actually don't know. I do know that personally, um, um,
00:56:43
Speaker
I only have swear words in my mind, so I won't say them to the audience. This is a family show. Don't make me bleep it out. I don't feel like I do my best work when someone treats me that way. Like, you'll do what I say or you're fired. You do it.
00:57:05
Speaker
Can you do it? like i This is not right. So I i can't say that i I think that that way of communicating to adults is really a great and in effective way. So I bristle a bit at that. But I do think though that the, or you're fired aside,
00:57:33
Speaker
Constraints can be really energizing. like One of the things that people think that that abstraction is a lot of faffing around and thinking about everything, but it it is it's definitely not. It's about figuring out from this giant pile of ideas. In every organization, there are nearly infinite opinions about what we should do and how we should do it.
00:57:59
Speaker
and there's all kinds of ideas and those ideas are ah uncoordinated, right? They might be good, but they're uncoordinated. The real science here is about being able to bring together the points of view and the ideas that actually are going to get us where we need to go. Like using judgment to sort of figure out how you can synthesize some of these and ignore other things. What you ignore also designs a system right yeah to know what to do.
Building Knowledge Work Ecosystems
00:58:35
Speaker
So constraints are a part of design. Every time you're choosing to ah use one tool instead of another tool because you've done some consideration and you think this tool is going to meet your need better, you are you're also
00:58:56
Speaker
architecting constraints into the system, anything you might have gotten with the other tool, you won't have. So in this case of saying, um I mean, there's a number of things that that would do. In any organization, there are always competing priorities.
00:59:13
Speaker
In that case, you just got rid of anything else. Anybody comes up to your desk and says, this is what you should work on. We need a red button. Nope. Services. I'm only doing services, right? So you get rid of a bunch of the noise um and you're you're allowed to ignore all of a whole bunch of ideas.
00:59:35
Speaker
um You also have the constraint of this is the ah this is the highest priority. this this This architecture is the highest priority and people feeling like motivated to collaborate, cooperate, figure out the problem. um Yeah, I can imagine some people under that decree feeling distinctly demotivated about the way they're being treated, but other people feeling very motivated in that here is a clear goal to run towards.
01:00:11
Speaker
Yeah. And so i I mean, I think you could potentially create that without the, um, or your fire thing. Like, you know what I mean? Like I don't, I definitely don't think that you need to have a strong man approach to knowledge work. Um, I don't, I don't, I don't think that, um,
01:00:38
Speaker
i think I think respecting the the people's expertise who are choosing to help you make your organization successful. i you what's the they keep um You get more bees with honey kind of thing. yeah I don't, i'm didn't I'm definitely just not a fan of that. But that said, I do think that ah clarity of purpose, um the ability for self-organizing to say, this is what we're going to do. We're going to go to the moon or we're going to do this. And people can know to cross collaborate and solve problems in a particular way.
01:01:23
Speaker
Most organizations have so many things pulling, ah so many gravities pulling on people's priorities and attention that it can be hard to focus on any one thing for a period of time. Yes, I would agree with all of that. And I don't take specifically that example of Jeff Bezos as being an example of what I think tech leadership should be, even if it happened to get the right result. It makes me wonder if what what you think good management, particularly at the top, would look like? I think for me, I i think it's the same at the top as it is at the bottom. In that, what you're paying for
01:02:22
Speaker
is minds, right? Is is is minds is it's people's experience, their ability to think well, their ability to ah problem solve, share perspectives, um their ability to learn because whatever they're doing this year, they'll be doing something different likely next year. So
01:02:49
Speaker
so you So for for me, there's a whether it's one team or a whole organization, there that's where the richness and value is right is in that people's willingness to share their knowledge and experience, their willingness to um strive towards goals that are beyond their own personal goals, right? Trying to do something together. And so the better you are at developing an ecosystem that really brings out as much of that as possible, that that that encourages the type of emergent innovation that can only come from
01:03:37
Speaker
ah ideas coming in contact with other ideas right and and growing and learning. and that and and The way that I used to describe myself as a leader is that if if the team is an apple orchard,
01:03:58
Speaker
And there's no apples. I have no purpose. My purpose is apples. And so therefore I'm concerned with the quality of the soil. I'm concerned with do they need protection in the wintertime. I'm concerned with water and fertilizer. In other words, I'm developing an ecosystem where each of these apple trees are able to produce the very best and tastiest apples that they can produce.
01:04:27
Speaker
So I'm really developing an ecosystem where people's knowledge thrives. And so this idea that I'm in charge of the apples, I can yell at them and make them produce
Self-Organizing Teams and Effectiveness
01:04:41
Speaker
more or whatever. I mean, maybe maybe apple trees like to be yelled at, I don't know. um But I think that scales, right? It scales the same way, is that this um this ability to create ecosystems that leverage the power of the people who are there doing the knowledge work, enable them to work well together, enable them to thrive.
01:05:07
Speaker
then you get the most for your payroll dollars. like I wish it was just because I'm a nice person and I like being kind to people, which I do. ah But also from a business sense, I work with brilliant people who want to do hard things. So how do I help them succeed to do, and and myself as well, how do we succeed doing hard things? Because I can't do it by myself. I need them. The difficult thing is always, though, like with an apple orchard, I sort of know the inputs to to a ah generating good apples at the output.
01:05:44
Speaker
But with people, I could in all the best faith say, we'd buy everyone the best laptops and we don't use Jira, we use githubish GitHub issues and all these things. Sometimes it's very hard to know what nurturing that soil looks like.
01:06:00
Speaker
so Absolutely true. The one thing about the apple orchard though is that i think we think we know the inputs, but one of the things, there's a lot of overlap between the challenges in agriculture and the challenges in our industry. We take a very industrial, monolithic approach to agriculture as well. But in fact,
01:06:20
Speaker
we actually don't understand what makes good soil. It's so complex that we probably couldn't even necessarily computer analyze what's happening in soil. Soil is a very, and it's always changing, and then there are pests, and then there are climate change, and then there are like, I kind of feel like there's nothing like an but an orchard to really show us how not in control of things that we think we are. But to your point, if you develop expertise in it, it's more straightforward than humans, right? Because they you know the apple tree is not going to um talk back to you, for example. aren't i to tell you vote did they They don't vote, right? There's a ah whole thing there. and um And so I want to acknowledge right that even
01:07:11
Speaker
Even now in the circumstance that I'm in, we're doing something novel and there's seven minds involved mostly. And it's very hard to synthesize seven minds because we don't all want the same tools. We don't all process information the same way. So when you scale that up and as an organization level, it is it is legitimately a challenge.
01:07:39
Speaker
there will be no one thing that works for everyone. I think it's a mistake to try and standardize over standardize. But this is where this is where um what we call self-organizing self-organizing is a very high leverage point in systems. If a subsystem is able to effectively self-organize, that has more benefit than five nines, increasing storage, failover. like that's one beat A team being able to self-organize is going to have, in most systems, more impact than anything we could do with the tech.
01:08:24
Speaker
I think I know what you mean by self organized, but I actually think it's good if you give me your definition. So meaning that they can proactively get the information and the insight and the understanding that they need and make good decisions about what they do.
01:08:43
Speaker
in order to have a positive impact, that they don't need a lot of control, they don't need a lot of being managed, that they are actually able to get the job done. And if they don't know something, they'll find out, they'll ask.
01:09:02
Speaker
um But then does it become the job of the manager to ensure there are those lines of communication between between their subsystem and customers, for instance? Yeah. So they so if relationships produce effect, then the the ability to ah remove blockers, to work with because often we're still working in a hierarchical structure.
01:09:29
Speaker
right so often like that the team If I'm working with a team, they'll want to make a recommendation and I need to get money. right for us to do We want to do a thing and we need some money. Give me the budget. I might structure the way that I pitch our idea. somewhat differently to business people or product people, then I'd talk as an engineer. like I might like um go outside the team to hunt and gather money and come back um because I'm sort of an interface between these two subsystems, right? Between ah the subsystem that is accounting and the subsystem that is engineering. um But I'm still
01:10:17
Speaker
speaking the truth as understood by the team, right? Like I'm not, I'm not, um, I'm not trying to control or I'm not trying to make, I'm not trying to make all the decisions. I'm just trying to improve the effectiveness of our ability to communicate our needs. Yes. Yeah. I totally see that. So.
01:10:43
Speaker
There are two threads I need to pull on from that. I think I'm going to go with the language thread because this reminds me of like, um, is it domain driven design? Ubiquitous language. yeah How important do you think that is? Do we all need to be speaking the same language across the board? I don't, well, I don't, it doesn't think it has to be the same necessarily as it has to be understood. Right. So, you know, people, um,
01:11:12
Speaker
um what one of the things so I talked about canonical data modeling once and the the the person I was training with had a very strong reaction because canonical data modeling in his experience is bad. What I realized is that in his experience, it was one data structure to rule them all, and all the subsystems had to use the same data structure. I'm like, oh, I don't mean that. like I just mean some agreed upon ubiquitous data language. like i don't I don't mean it as ah so rigid. um Recently, I was having a conversation with a team from a very big, well-known publishing company, and they were having the same problem I've had a number of times, which is if I were to get from the database, if I were to, or or multiple databases, if I were to make a JSON structure that described, let's imagine a news article, like on on the New York Times, there's a news article. One part, you have the little summary, right? That kind of tells you what the article is about.
01:12:28
Speaker
yeah There are five different names for that. right Maybe it's an abstract. Maybe it's a description. Maybe it's a summary. The Economist editors called it a rubric. right And so they were saying how many meetings they were having to figure out data structure that would be different in one database because it would be called summary in one and one and another or something else.
01:12:52
Speaker
So I use vocabulary like schema dot.org, for example, not necessarily designed for data structure, but it is describing the types of data or information or content, all the same to me, but we call it different things. When a machine reads the article,
01:13:15
Speaker
Do they know what the title is? Do they know what the summary is? does it you know if if we're If it's feeding a large playing ah ah ah faing a ah language model or if it's Google is putting it into the information graph, so search results. And so developing ubiquitous language in my experience goes all the way down to data structure, goes all the way down to my team and I have worked very hard to make sure that our code and our functions use the language of the the software, of the user, of the organization.
Interrelated Systems and Information
01:14:01
Speaker
Because I've had modules called
01:14:04
Speaker
by their vendor name, right? And it has a bunch of code in there. And then we I don't know what it actually does. I just know that it's named after the vendor that is interacts with it. um My point being, ubiquitous language is really important for people. And that often when you're in a meeting,
01:14:27
Speaker
And you're arguing, for example, bring up agile and watch the whole room explode because nobody means the same thing when they use that word. So when you're not understanding each other, it's often because you're using the same word to mean different things or you're using two different words, but you mean the same thing. So and a fundamental architecture practice is defining words, is making sure that We, the definitions of these words are clear. But my point is it isn't just about getting along better with people. It'll end up in the code. It'll end up in the database that making our software more ah human understandable, have more conceptual integrity is also comes from our ability to create ubiquitous language to be able to
01:15:25
Speaker
ah make software that mirrors the circumstances in which it exists, the experiences it serves. Yeah, yeah yeah I can see that as it will end up reflecting the natural conversations we have. yeah That takes me actually to the other thread I was going to pull on, which is very related, but sort of in the opposite direction.
01:15:49
Speaker
Which is, I've often wondered if the skills we develop as a software designer, like architecting this database talks to that REST interface, or these two actors in an actor model system talk to each other over this interface.
01:16:09
Speaker
I've wondered if getting good at designing those kinds of systems translates into also working with the soft systems, right? And when you say that a manager's job can be to be that interface between the communication of the software department and maybe the accounts department, that really makes me think, oh, there's a soft system that really looks like a hard system.
01:16:40
Speaker
So what system science would tell us is that there really isn't a difference, that that they are they are so interwoven, that we love to think,
01:16:54
Speaker
ah that there's a big separation between hard and soft, between social and tech and all of this. But there's very little experientially that that supports that. blank um And this is the challenge of concrete versus abstract, right? like But everything isn't we yeah everything is a concept, even code is a concept. And having integrity in our ideas generates integrity in the code and vice and vice versa.
01:17:25
Speaker
The tech is also teaching us because we have all kinds of things we'd love the tech to do and it doesn't it has constraints of its own as well, especially when they start being in relationship to each other.
01:17:40
Speaker
um there's information missing or it's not particularly well structured or one service is slow because it has to munch a whole bunch of information to answer a simple question. Another one is fast because it just says yes or no, right? So the system itself has communication issues and humans will have communication issues. And yeah these issues are an endless cycle of feeding on each other.
01:18:07
Speaker
And so I do think that my experience has been that, for example, people who don't really care about the impact of communication on other people, we're more likely to say, well, we're just going to um do a database query and then basically vomit that via JSON on the API.
01:18:36
Speaker
Yes, but then we're not structuring the information for the consumers of that API. We're not using the language or the structure that they consume it in. We're using the structure that we save it into a relational database in. And they'll say, well, they can just use regular expressions.
01:18:59
Speaker
If you're forcing writing regular expressions on people, there is an empathy problem. right My son loves regular expressions and I don't, so this is an endless Thanksgiving family ah discussion. Oh, that must be a great Thanksgiving table. We we are a very, very geeky family. out it's it's um ah Yes, there are so many of these I could point to. But the point being that
01:19:27
Speaker
Structuring an API response for the consumer from the way the consumer is looking for information. So if if we if we say a very simple decoupled front-end React application and a backend where people are creating content, right?
01:19:45
Speaker
ah On the back end, the way that we think about the structure of that content of that data will be different than the front end who is serving the user and and is is meeting the needs of the user. And that ability to then have a good translation between the way the back end would provide information, the way the front end consumes it without making the front end do all the work. That's how I translate using regular expressions, making the front end do all the work. If there's a good relationship between the back end and the front end, if they're both doing work, if they understand the constraints and trade-offs, you have a better software system, but you only get that if you have a good people system that can work together to identify the design of that interaction.
01:20:40
Speaker
yeah Yeah, I think some people are going to listen to that and say, well, that's GraphQL, right? But it's but it's not the technology. I think a technology like GraphQL comes out of a place where they're having more discussions about the way they will in do communication between systems. Also, if if I mean, I can't speak for everyone, but my own experience is if you have a pile of swear word behind GraphQL. GraphQL will give you gray hair and make you run away screaming like the
01:21:20
Speaker
It's my experience has been we work harder at the data structure when GraphQL is involved because it's even more important that the information is inherently interrelated. We can't just have a big giant pile of information. We need to understand in the storage, in the way we store it, how they're interrelated to each other. like you know if you If I use an article in the New York Times, the authors, the topics, the um the the region, like there's a lot of things that are interrelated with the information in that article. GraphQL on the front,
01:22:06
Speaker
enables a front end to get that article, but also everything by that author, also everything about that region, also everything about plane crashes, because that happened to be what it is. And in order for GraphQL to serve the front end,
01:22:23
Speaker
you actually have to be even smarter about your storage and your relationship, your data relationships, the structure of your data. GraphQL can can't really sort through a giant pile of and un unless you have a graph design, GraphQL isn't going to design your data structure. That's not gonna do that. It's not gonna fix it for you.
01:22:49
Speaker
Yeah, it's making me think. if It's like if you opened a phone line that allowed people to ask for one specific shape of answer. you would organize your internal data in one way. if you If your phone line allowed anyone to phone up and ask so arbitrary questions of you, you would get your information much more organized before you picked up the phone. Right. right And you'd also you'd have to make inference, right? So the the one thing that these data systems, and I would argue AI as well, does not do very well is inference, meaning
01:23:26
Speaker
If one thing is so, what else might be so? Or how, how is this sentence meaningfully interrelated, meaningfully justified by, or connected to, or similar to all these other words, adverbs you put in between, to other types of information? That's something we actually have to design.
01:23:50
Speaker
in order for it to follow those pathways. So for me, especially, this is, i'm I'm so glad we've ended up here because this is absolutely the thing I focus on by far the most, right? Is that and that the the way that we interrelate information,
01:24:15
Speaker
is the only generator of potential knowledge and understanding. right Information is just into information without any meaningful interconnection right with other types of information. And if we're helping our system, our consumers of a GraphQL um instance, for example, be able to get what they need,
01:24:40
Speaker
then we have to A, understand what they need and B, understand in what context because the consumers are in different
Managing Complexity in Design
01:24:48
Speaker
contexts. They would get different things in different contexts. What context do they serve? And then also how do we develop this interrelationship between information parts so that it generates meaningful responses as opposed to just, you know, give me the article with this ID. That's pretty straightforward. We know how to do that. Yeah. Yeah. Yeah. There is tremendous value in making connections between things, right? Often that's the way the real value lies, is what you're saying. Yeah. and And I guess that relates to the whole, are your developers talking to your user? Do you have a connection that relates this system piece of information person with that system information piece of person?
01:25:37
Speaker
Yeah, and that in increasingly um it isn't even just like there's there's the user, but also in a lot of cases there's multiple users with different agendas or different needs. So that gets it. That's more complex. And then also we're sharing information with other platforms, with other pieces of software. increasingly, there's as much if not more communication within the software system as there is between the software system and the users. And so this skill of designing relationships that take different points of view um in mind, different contexts in mind, um is increasingly essential for us to get really good results. And it's, I think,
01:26:31
Speaker
an architecture skill, a systems leadership skill, is that these relationships are changing. The patterns that govern them are changing. We are increasingly asked to serve multiple contexts. So for example, what we know is that um um this may this was a while ago, so it may have changed, but I got this lovely little factoid in my head and I've kept it there because it's a it's illustrative that when if you have a restaurant website, when people are go to your website on a desktop, they're usually looking for your menu. And when they go to it on their phone, they're looking for your address.
01:27:19
Speaker
And so if yeah in context, right like ah if you and but if you ask a question to Alexa, Alexa is getting information that is you wasn't published as an answer in Alexa. It was usually published as part of a Wikipedia page or an article or a website or some sort of digital publication. And and Alexa has extracted that little piece out of the bigger context. So the increasingly, that linear the linear connection between a software and a person, and the person's using the software and the software's doing things for the person, even that is getting more complex. Yeah, yeah, yeah, yeah. Then I think
01:28:13
Speaker
The next thing I have to ask you is, um because I can see all that, I can see the the connection between systems having value and the context that they in which they exist having value. I definitely can see a blurring between whether we're talking about people or software or a mixture of both.
01:28:36
Speaker
And I'm starting to feel slightly overwhelmed, yeah because the number of potential contexts and interconnections are almost infinite. And in a tiny company of three people, you're allowed that number of infinite connections. My question to you is, how do you prune down to the ones that matter?
01:28:54
Speaker
Yeah, and that A is the question. like if you say what um so someone what Someone quoted me once, I had two different slides, and they put the slides together to say, so what Diane is saying is that wisdom is knowing what it depends on.
01:29:18
Speaker
and I'm like, I didn't say that, but I'm going to say it now because that is done that is great. like that's I didn't put the two pieces together. right so when we say in you know The answer in in architecture is it depends right because it does right it does depend. You can't just do what Netflix does. You have to actually understand the force is acting on your system, right? Daniele Meadows says, i've i I can work on a system. I go into a new system. I have to spend time with it. i I need, I can't just come in and say, do this. You don't know, right? Yeah. So, um so the,
01:30:01
Speaker
the the The recognition of this increasing relational complexity and this potential for nearly infinite ah consumers, if you put up an API, like the whole world can come and they'll all have different needs and all of that is is really important. But the But figuring out in any particular situation, there aren't nearly infinite possibilities. In any particular situation, it's much like deciding with your family where to go on vacation. You can go anywhere. Let's say you have $10,000, which means you could pretty much go anywhere. But you have natural constraints, right? you maybe
01:30:50
Speaker
nobody's interested in skiing or winter sports. So that rules out half the planet in the wintertime. um Maybe um some people, some part members of the family are very young and so that limits. ah You just have preferences. So in any particular situation, understanding systems as a whole is what we're saying, meaning There's always change, there's always uncertainty. It's basically deciding uncertainty is welcome and invited and natural and unchangeable. But inside of our particular circumstances, there are um think that this the goal of the system is going to prioritize certain things over others. For example, FedEx.
01:31:43
Speaker
FedEx, FedEx's advantage is it delivers packages quickly. So in that system, if people were talking about performance and speed and optimization, yes.
01:32:01
Speaker
Right? Yes, because that system depends on on fast data, really, really fast data. If you were focused on making a really exquisitely fancy front end, maybe not so much, because it would be lovely to go to FedEx dot.com and have a really pretty user interface. But that really is not the highest priority in that system.
01:32:30
Speaker
And it's the same in our particular circumstances, just being aware of the fact that nothing is linear and that it's not as siloed and simple as we think it is. And being curious about that and and proactively um
01:32:54
Speaker
considering other points of view, that's, in most cases, that's sufficient. just and just Even just trying to understand the point that watching the user use the front end and realizing you don't know anything about user behavior, that is usually sufficient.
01:33:15
Speaker
And when you get to know a system and and and the value it provides, there are naturally going to be things that matter more than other things. And the challenge is usually all of the noise, all of the ideas that are are about how things should be done that are not actually very strongly connected to having a positive impact on the system.
01:33:47
Speaker
it's usually all the uncoordinated ideas more so than the one or two. So my, it's summarizing that very long winded way of saying it, but it's, it's the question I get asked ah all the time is that um when we get to the point of it's very overwhelming, then we've probably talked enough about the ah the um potential, right? the what What systems thinking means and all of the things we could probably think about. And instead then the point really comes to how can I personally have impact today? What can I do today? How can I change either the way I'm communicating or something in the system that really actually will
01:34:39
Speaker
improve the value of the system overall, improve the experience for users, improve it, improve its ability to exist and help me pay my mortgage. And that's not easy. It's actually very hard. But it's not as hard as sorting out all of the 70,000 million ideas about what we should do.
01:35:03
Speaker
in order to have impact, do you know what I mean? Yeah, yeah, yeah. yeah it It leaves me wondering how we can be sure that we connect ourselves to that value. Yeah, and and also too, how can we live with not being sure? So we we we want to, and and I think it's very it's very straightforward in that if teams can articulate how they're having impact on that value,
01:35:32
Speaker
Um, it's a sign of a good, healthy knowledge flow in an organization. I, I have worked with organizations where we tried to figure out what the core domain was like FedEx, you know, fast package delivery and discover the reasons the teams are having such a hard time is if you put a VP or hire whatever people in the room, they all have different ideas about what the core value is of the system. And therefore, how the heck would the teams actually know how to prioritize? So if it can be connected, that is a sign that that that people really do understand what they're trying to do with this software system. And if you can't do it, then that that triggers, I think, the need to keep asking these questions and
01:36:32
Speaker
challenging how these are coming together.
Reflections on Systems Thinking
01:36:35
Speaker
So the right question is often more valuable than the right answer, right? That we can ask questions to get more information. Do you think it's also the case that some kind of feedback and some kind of communication line is more valuable than just trying to get the right one?
01:36:58
Speaker
I don't know if we can know in When you're making a systems change, and they do i I say this different, if you know what to do and just do it, you don't need systems thinking. like You don't have to overanalyze every part, like, but will this, will this, but Diana said we should think about multiple contexts and all the different, no. Diana said that's systems thinking, not that you should do it for every action. That just causes paralysis. If you know what to do, just do it. If you're wrong, fix it. like That's cool.
01:37:35
Speaker
We use systems thinking when there isn't a right answer, and when there are meant multiple think ways. When I teach workshops, I put people in a situation where there is no one right answer and help develop over the day the way of still creating um a path to action. And so I think trying to be right will B.
01:38:07
Speaker
mmm making like because you're right but also the other team has a different solution and they are also right eat both of these ideas could potentially have benefit and so I think focusing on understanding the circumstances understanding how did you reach this conclusion like ADRs are a great way a tool for that right would not if you just say so architecture decision record okay so People use them to say, we decided on Kafka. That's not what i mean I mean. We considered this solution on that solution. We prioritized these reasons. we don't
01:38:48
Speaker
we didn't um This other tool had ah things we don't want. like Show your thinking. Basically, like a math test, you you're supposed to show your work so that Do you can see where you might've made a mistake? same yeah Same for us. Show our show our work. How did we reach the conclusion? And then ah so other people can understand how we came to that conclusion. And then how will we know if we had impact? How will we measure it? So I really think that giving up the idea that in these types of situations, there is a right way
01:39:28
Speaker
and a wrong way is dualistic thinking is a linear thinking feature, right? Wrong. Yes, no, good, bad. In systems, it it depends. Sometimes a thing that's good in one system is bad in another and vice versa. We get to figure out what it depends on. In this system, what's the value that we can contribute? and So I'm overwhelmed with all the the the um the ways that you get there, but we are doing it already most of the time. Like we we when you get to know a software system or a people system, most of the time, if you go in and ask people where the pain point is, they know they know they know what the bottleneck, they just don't know what to do about it. So that's... some
01:40:21
Speaker
At least we know where to focus, even if we don't yet know how to improve it. Yeah. OK, so one last question. um ah I was thinking about this this morning. and It's a fun question, but it may be a hard one. I don't know. I'm going to ask you and see what you say. OK, OK.
01:40:39
Speaker
But I was thinking about um how we play match two games with kids, like ah you deal out cards and they have to find two sevens and they get point, right? Yes. you know And it's um it's a game we play to train children's memories. And then I was thinking about chess and it's a game that's fun, but it's also about training people to think strategically.
01:41:05
Speaker
So the question I have for you, is there any place in this world of ours we can train to think in terms of systems?
01:41:17
Speaker
um Or is that software design? Well, software, quick I mean, yeah information systems for sure, like when I lucked into the work that I'm doing is very much, but they so There is one that comes right to mind and I use it in talks, but the the reason I hesitate just is accessibility.
01:41:43
Speaker
um and it doesn't It doesn't help us so much with software. so It's not a perfect answer, but I'm going to give it anyway. It's the beer game. so the beer game so we um Jay Forrester developed this a long time ago. The person who gave us with the understanding of counter-intuitiveness. So the word counter-intuitiveness comes from Jay Forrester. And so in the game, and if I understand correctly, I think MBAs at MIT, because he was out of MIT, ah they still play the beer game when as part of their education. I don't know for sure if that's the case. but So basically, there's a number of different ways to play it, but the way I describe it,
01:42:28
Speaker
is that you have a group of people, you split them into three teams. One team is the retailer. So they have a really cool craft beer and kombucha store in Austin, Texas that used to be a gas station. And now it's a craft beer and kombucha store. And on the other side, you have a ah brewer um brewery that are developing really interesting new beers.
01:42:58
Speaker
Now, when I've told this story in front of tech groups, especially in Germany, I've come up with an example of a beer, like a cranberry beer. And then people come right up to me afterwards and tell me how horrible that, like, I clearly don't know beer. This is a horrible example. And I'm sure they're right. I do not care for beer myself. So in this so very hoppy is the feedback I've got. like extra, extra Hoppy Beer is the right example. okay So they developed this especially Hoppy Beer. In the middle is the distributor. So they um that's kind of boring, administrative, but they make the most money. And they're the people that get beer from the breweries and bring it, deliver it to the retailers.
01:43:52
Speaker
Very straightforward information flow. ah Retailer fills out a form for the distributor. Distributor puts all the those numbers together and orders from the brewery with a form. like It's just a form to a form.
01:44:07
Speaker
right so The game begins because this is getting outdated now, but like Taylor Swift is drinking that beer at the Super Bowl or anywhere on the planet walking down the street. Taylor Swift is drinking the beer. So suddenly demand increases because a whole bunch of people, they even drive from Dallas to go to Austin to go to the gas station, kombucha, and craft beer store to get the beer, right?
01:44:31
Speaker
and Then the game so the game goes from there where if you played in person you do little block he move little blocks to order like um resources game board game and.
01:44:46
Speaker
ah And so they're just round after round of ordering and making decisions about what to order and inevitably it's a giant mess.
01:44:57
Speaker
It's a giant chaos mess. ah there's Everybody loses, basically. In the beer game, you end up with just a whole bunch of beer that's never going to get drunk in a warehouse, and everybody's mad at each other. The thing that we learn from this game is knowledge flow because you could do very well at the beer game if you made a Google spreadsheet that showed time delays and orders. And if you made the information transparent across the system, people would have a better time playing the game. But very few people think of that doing that. Instead, the game ends and it's a mess. And you ask what went wrong and
01:45:45
Speaker
This is one of the ways we learn that we blame and we blame the wrong thing. What went wrong? And that the the craft beer store blames the distributor and the distributor blames the poor brewers and the brewers blame the supply chain. And they and all of it was information flow, but they're very convinced.
01:46:10
Speaker
about they were getting screwed by the other teams. and these And they don't realize the reason it happened is they start over ordering. They think they're not getting what they need. They think they're not being heard. they not So they start over ordering and over ordering. And now the information flow is becoming antagonistic between the teams as opposed to ah what they actually need.
01:46:33
Speaker
um yeah And so you you have that experience and go, I live this every day. I live the beer game in every meeting I ever go in, right? We're constantly playing the beer game. Always, always, always, always. So having that experience and then applying it to your life begins to show how much drama comes out of what is simply the flow of knowledge and information and proactive cross-functional working, the lack of cross-functional thinking. Oh, I'm glad I asked that question. I'm going to see if we can set up a game of that at my next games night. Yeah. it's those So there's software you can do it, but so far I found it very expensive to to do. So I have not been able to facilitate it in a room of people, but I i very much would like to develop one that's more ah relevant to us, right, that is more
01:47:33
Speaker
software related so I sort of have this in the back of my mind at some point
Episode Wrap-Up and Book Recommendation
01:47:38
Speaker
to try. well say You'll move from being ah an architect to an author to a games designer. Which all three of those things I feel like they overlap an awful lot. like anyway I feel like sometimes I am designing games even though they're not as much fun as no
01:47:59
Speaker
I think on that note, I'll have to let you get back to designing the next game and hoping it plays out well. Diana, thank you very much for that. Yes, and it's my I'm so happy that we got to do this ah more. i i i I love the questions that youre that you ask. I feel like we could do that all day.
01:48:21
Speaker
We'll save that for next year's episode. When your game comes out, I'll invite you back. Again, we'll do a marathon game. Yes, okay. Live playthrough, yeah. Okay, now I have a deadline. See if constraints are good. Yeah, absolutely. Diana, thanks. Thank you.
01:48:38
Speaker
Thank you, Diana Montelier. And I have to tell you a quick story about her name before we go. So I always ask my guests the correct pronunciation of their name, because sometimes it's obvious, but often not so much. And I'd not seen Diana's surname before. So when we first met, I said, is it French? Is it something like Montelier? And she said, yes, yes, pronounce it that way, please. And she wouldn't tell me the way that she normally pronounces it after that.
01:49:05
Speaker
So, if you know Diana and you're wondering why I'm saying it the way I'm doing it, that's why I'm under orders from her to say it in my kind of mangled high school British French accent. So, there we go. If you want to hear more from Diana, regardless of how you pronounce her surname, she has an O'Reilly book called Learning Systems Thinking, a link in the show notes.
01:49:27
Speaker
I've been greatly enjoying my copy, kind of hoping that 2025 is going to bring me some opportunities to put the knowledge into practice. But we'll see. We'll see what the year ahead brings. In the meantime, if you've enjoyed this episode, please take a moment to like it, rate it, share it with a friend, share it on a social network. We are on Patreon and YouTube memberships if you want to support more episodes of Developer Voices in the coming year.
01:49:54
Speaker
But for now, I think it's time to get on with that year. It's time to go. I've been your host, Chris Jenkins. This has been Developer Voices with Diana Montelier. Thanks for listening.