#265 - Signals & Levers: Systems Thinking to Navigate Software Delivery Illusions - Elisabeth Hendrickson & Joel Tosi

[00:02:03] Introduction

Henry Suryawirawan: Welcome, Elisabeth and Joel, to Tech Lead Journal podcast. Very excited to have both of you here. Both of them are the co-authors of the new book, published by IT Revolution. The title is called Signals & Levers. So it’s like one of those books, that discuss about, you know, this kind of system thinking and all that. One of my favorite topics to discuss because, every time I chat about it, there’s always something new that I learn somehow. So welcome both of you to the show. Looking forward for this conversation.

Elisabeth Hendrickson: Thank you so much for having us.

[00:02:34] The Backstory Behind “Signals & Levers”

Henry Suryawirawan: Right. So maybe in the beginning, let’s start from the background story, right? What made both of you decide to write this book?

Elisabeth Hendrickson: Sorry, Joel, go ahead.

Joel Tosi: All right, that’s a wonderful story. So a quick background for you, Henry. I had been teaching a systems thinking workshop, for some clients, you know, for a few years, a little bit off and on. And one day on… It’s gonna sound silly, but one day on LinkedIn – LinkedIn or Mastodon, Elisabeth you have to keep me honest – Elisabeth had posted this video of this simulation she was working on, and it blew my mind. Because when I was teaching the systems thinking workshop, it was a lot of hands-on kind of sticky note stuff, and you kind of had to kind of like feel it out. And then Elisabeth’s simulation allowed you to like make decisions and see how the system changed and, you know, go through it very rapidly. And I reached out to Elisabeth, who we had known each other for years, and I said, “Elisabeth, this is amazing! This is exactly what I’ve been looking for forever. Can we please work together on this?” And that’s kind of how it’s, it started. Elisabeth, you, I know you have much more color to add to that.

Elisabeth Hendrickson: Oh, and I was so grateful when you reached out. Because that simulation, I’m still working on it. It’s a passion project. And I did the build a thing and then figure out what to do with it pattern that you’re not supposed to do. And I was so thrilled that anybody had a real use for this thing. But we started co-teaching and ironically, the simulation actually kind of fell by the wayside the more that we co-taught. But the more that we co-taught, the more we realized, you know, this is really a book. And so that’s how the book came about. We’ve been working on it for what? I think we started working on it two and a half years ago. But three years ago, neither one of us would’ve said that this was in the works at all. Not on our bingo cards.

Henry Suryawirawan: Right. Thank you for sharing such an interesting story, right? So I’m really curious about the simulation because, yeah, systems thinking is one thing that is quite difficult actually, I think, to explain to people. Especially sometimes it’s quite abstract and, you know, there are interrelated parts that you actually don’t know about. So yeah, looking forward to seeing the simulation being used in more wide audience.

[00:05:55] Why Has the ‘Software Crisis’ Never Actually Gone Away?

Henry Suryawirawan: So looking at the book, right, I did have a read before this conversation. One of the very interesting thing in the introduction that I pick is actually this story about the software crisis. Why Maybe tell us a little bit about this because I think it’s worth to re-emphasize about this.

Elisabeth Hendrickson: Yeah, absolutely. Especially because it puts all of our experiences in context. So the year was, I believe it was 1968. I’m not looking at my cheat sheets, and I’m not great at dates, but it was late ’60s. And NATO, of all organizations, organized a software engineering conference to address the emerging software crisis. So at the time, the field of computing was so new, and yet, as I was reading through this historical document, ‘cause the notes are widely available on the web. You can search for the NATO conference on software engineering. And parts of the notes that came out of that conference read like a transcript. It’s like the back and forth he, well, it was all hes. So he said, he said, he said. And I’m reading this and I’m like, “I have been in that meeting.” I mean, I … This feels so familiar. And they’re all complaining about how, Some of them are complaining that software takes too long and costs too much money, and others who clearly were a little closer to the keyboard were saying, “Well, you don’t understand. How hard it is, and this is why.” And it felt so familiar. The only thing that was different was the vocabulary around the specific technologies. But the essence of the meeting was the same. So that is the meeting that gave us the, that popularized the term the software crisis.

And our realization as we were working through the materials for this book was that this is– Jerry Weinberg liked to say that it looks like a crisis, but it’s the end of an illusion. He wrote that in one of his books, and he also liked to say it a lot in person, and it is so true. There’s this illusion that software should be easy to create. And frankly, in the age of AI, that illusion just gets even worse, because obviously the magic genie is gonna create all the software for us, so we don’t need to worry about all of these, you know, hard things about software creation anymore, right? No, that’s not how that works. So yes, we have been, as an industry, dealing with the supposed software crisis, that the fact that it takes so long, longer than anybody expects to create it, and it’s harder and costs more since the very beginning of the field. And this is not a problem that’s going away anytime soon, no matter what kind of advances we have in our field.

[00:08:41] Why Do the Same Software Development Problems Keep Appearing?

Henry Suryawirawan: Yeah, so it’s actually very interesting when you mentioned that. I’m sure we are, we have been in that kind of meeting as well, where we talk about, you know, first is schedule, right? We cannot meet the deadline. Second thing is the cost to deliver the software. And then the complexity, how hard it is to actually change the software. I think in a sense also, it’s kind of like relative, right? Because technology changes, there are some things that gets easier, but still these kind of things, this kind of theme keep appearing, over and over again. Why do you think it’s never been a solved problem, or we just don’t appreciate that things actually have advanced since then?

Elisabeth Hendrickson: Well, I mean, I agree. Some things get easier and, but expectations also get higher about what we should be able to do. So some of the technology that I use on a day-to-day basis would’ve been science fiction when I was a child. So certainly things have advanced. I think it really does boil down to the fact that it’s a system as a whole, and that the, that maybe our expectations for how much it should cost or how long it should take are unrealistic. That’s absolutely true in many cases. But also there are complications that we can’t predict by thinking linearly about them. The, everything that we do affects the system. And I, we like to say in the book, “You poke the system and the system pokes back.” So when you do a thing, it may have some very surprising consequences.

Joel Tosi: And even beyond that, it’s, your, the software and the organization exists inside of its own system, but also exists inside of a larger ecosystem of its, all of its competitors and the world around it. So like, there is no, we’ll just work on this for six months and the world won’t change, and our competitors won’t change, and the customers won’t change. Everything is changing all the time. And so, and another thing I like to say in the book is, you know, right today can be wrong tomorrow. And I think that’s why this why it won’t be a solved problem, ‘cause we could have the best ideas and the best approaches today, but then everything around us, the system around us changes, and now we’re wrong. And so we have to be able to sense those things.

[00:10:55] What is an Adaptive Sociotechnical System?

Henry Suryawirawan: Yeah. So I think we all know that AI is coming. I’m sure this thing will still again a crisis in the next few years ahead, even though the AI maybe helps us to generate a lot of code.

So which brings me to the thing that you mentioned in the intro as well, right? You mentioned that software delivery, software development, right, is actually, an adaptive sociotechnical system. I think for many, maybe I would say non-technical users, this is something that is quite important for them to understand, especially if they want to relate later to the systems thinking. So tell us about this adaptive sociotechnical system.

Joel Tosi: Sure. So we’ll start with the kind of simpler, more evident parts, the socio aspect of it. Software is built by people, interacting with people, for use by people. Even if machines end up using it, it’s for the benefit of people. So there’s a definitely a social aspect, socio aspect of that. People being complex creatures, that of course just adds to the unpredictability of the system. The adaptability is very much that the outputs from the system becomes feedbacks into the system. So the system’s constantly adapting to the situations that’s fed into it and all of the influences with inside it. The fact that it’s a system has a lot of interesting attributes. So when we talk about a system, we talk about a system of software delivery as a whole. So when we think about it as a system, you have a system of your team, and your team is working on its product. But your team exists inside of a larger system, inside of your organization, possibly an organization or a portfolio which exists inside of a larger system, which is the whole company, which exists inside of a larger system, which is the, you know, economy or the product space it’s in.

And so you have this interesting thing where it’s systems all the way up and down. And that because it’s a system and it’s adaptive, that means that they’re all influencing and affecting each other constantly. So the decision that the organization makes affects the team, but it also affects the broader economy. If the organization decides to adopt a new technology, it affects the teams directly, and of course, affects the, its competitors. And so you see all of this kind of adaptive situations happening inside the world. And then the other interesting aspect about it being a system is that, no change happens in isolation. And I think that’s super interesting, especially in software, because everybody’s been having the best intentions, right? We’ve seen the DevOps teams, and we’ve seen the platform teams, and we’ve seen microservice, and all of these were great ideas in isolation. And they’re great ideas in general, but when you take them, you have to take them in the context of the system it puts into play. So for example, if you’re saying, well, we have a monolith, and it’s too hard because everybody’s always stepping on each other’s toes, therefore we’re gonna go to a microservices architecture. It’s not just that the team gets impacted. It’s now the deployments, and operations, and support, and resiliency, and the product changes, and all these, it has this ripple effect. And so you can’t make a change in isolation without understanding the system play. Elisabeth, what would you add to that?

Elisabeth Hendrickson: I would say that that’s right on. And I think we saw an example of this two decades ago when Agile was the hot thing and teams started adopting Agile. We saw how a team adopt Agile, and all of a sudden now we see the ripple effect pushing out from the team. So Joel, you described the organization does a thing, it affects the teams, and it affects their competitors. So that’s a system in this sort of web of systems. That happens everywhere. A team adopting a new practice, a team adopts AI today, that’s gonna have a ripple effect on the rest of the organization.

So coming back to your question, Henry, you asked, so adaptive sociotechnical system, help me unpack that. It’s adaptive because the output of the system then becomes an input into the system. So the system is constantly adapting. The system is made of people for people, and technology is at the core. And that is why it is so complex to reason about.

[00:15:09] Why Do Business Executives Fail to Understand Software Development?

Henry Suryawirawan: Yeah, so thanks for unpacking that. Definitely, quite interesting, right? So I think mostly the people who work in tech really understand this, right? Because there are so many variables, there are so many things that could affect, you know, the velocity of software development. But I think when we talk about, you know, delivering software to the business or the executives, all they do is just create like, for example, deadlines. You know, pressure us, you know. “Okay, we have to deliver on this date.” Maybe throw more people, throw more budget for tools like AI, for example. So tell us why seems like the other counterparts of the technology people actually doesn’t seem to get it.

Elisabeth Hendrickson: Well, first of all, let’s be fair and acknowledge that sometimes that works. And sometimes it does. And sometimes the people… Like, let’s take pressure. I’ve, I have had leaders tell… When I was an engineering leader, I had a business leader say to me, “Oh, come on, Elisabeth, you know, you have to light a fire under engineers to get them to do anything.” This person was very clearly used to pressure working, and it didn’t work with me, but that’s ‘cause I’m extra stubborn, which is why I work for myself now. But he was accustomed to it working, but also he hadn’t been in a job for more than, like, two years. He would… Even if he stayed with the same company, this particular person was constantly… he was very ambitious. Nothing wrong with being ambitious, but he was constantly shifting roles, which means that when the chickens came home to roost and all of that pressure led to technical debt, which led to slower delivery, he wasn’t there to feel the pain. And so let’s start with why do they pressure? Because it works. But what they don’t have to live with is the consequences of that. And I think that we’re gonna see that even more with AI. AI AI is… frankly, it’s magical. It is science fiction in its ability to deliver not just software, but good software. And there are a lot of folks who were working with the tools, like six months or a year ago, and experiencing the frustrations of the AI lying to them. And I’m not saying it doesn’t still do that, but I’ve been using…

i’ve been working with Claude, partnering with Claude on this simulation, which doesn’t show up in the book by the way. But on this simulation, Claude and I have been partnering closely, and Claude’s ability to write good code is amazing. And yet, if I were not paying very close attention to the design decisions that Claude is making, then I would be in a world of hurt. And so the pressure is gonna lead people to say, “Yeah, whatever. It’s good enough. It, clearly it works. It’s fine.” And then a year from now, how many of those systems are gonna be so convoluted that they’re impossible to reason about? So I… You know, why do they not get it? ‘Cause they don’t have to. They’re not gonna be the ones who actually have to live with the consequences.

Joel Tosi: I think I might even give a little, yes and. Because some managers and some executives are there for a bit. And so what I would even offer up for the audience, Henry, is that, if were to take like the best intentions, I think they’re all doing the best with the information that they have, right? So like if I were to kinda say, “Well, why is a manager applying pressure?” Well, it’s probably because they’re feeling a responsibility to deliver something to a customer because of some other kind of promises. And they might not understand all of the other things, all the systemic effects that are influencing the ability to ship the software. And so the only thing, like in the book we call them levers, the only levers that they’re able to reach, the only levers that they know that they have available to them, are pressure. And so, I think they’re doing the best what they can with maybe a limited perspective. And they just don’t know different, right? And I think that’s one of the big intentions of the book was to help executives and help leadership understand like it’s a big world. There’s a lot of things we need to understand because it’s not linear.

Elisabeth Hendrickson: 100%. And I didn’t mean to imply that, you know, the people who are putting pressure are evil in any way, shape or form. They’re doing the best they can to achieve their objectives with the levers that they have available. And for that matter, they are probably under pressure as well. The business leader who I was describing who said, “You know, Elisabeth, you have to light a fire under engineers,” he was under enormous amounts of pressure. And so he’s responding. That’s, you know, that’s the adaptive part. He’s responding to the forces that are acting on him and, you know, then he’s turning around and passing that on. But to Joel, Joel is hinting at the fact that there are other levers available.

[00:20:03] What Are Signals and Levers in Engineering Leadership?

Henry Suryawirawan: Since both of you have mentioned about levers, right? So I think this, probably signals and levers, right, referring to the title of the book, are the two things that we engineering leaders or maybe all the people within the systems, right, are able to observe and play around with in order to make better changes to the system. So maybe explain a little bit about what is signal, what is lever for all of us.

Joel Tosi: Sure. When we talk about signals, signals are simply quantifiable or qualitative measures of the system. Things you can either experience, measure, sometimes you just feel. So like obvious signals that a lot of teams use and a lot of management might use are things like cycle time or defect rate or ship or deployment rate or batch size. Like these are all kind of very quantitative signals that we could all see. But there’s also all of these kind of qualitative ones as well. The pressure the team feels. Sometimes, some people in your audience may love meetings. But let’s just be honest, many times meetings are a signal and we don’t think about them as a signal. Sometimes they’re a signal that nobody really understands what’s going on, or it’s a signal we’re doing too much, or it’s a signal that there’s a different problem because we’re having the same meeting over and over again, and we think that the meeting’s the answer. So there’s all, there’s this wonderful world of signals, and one of the largest intents of the book was to make the audience aware of the myriad of signals that are around them so they can make better sense of what’s happening. I did signals. How about you take on levers, Elisabeth?

Elisabeth Hendrickson: Sure. Well, levers are the choices that you can make in response to signals. And so by recognizing that it is an adaptive sociotechnical system, that helps you think about the fact that lever that looks so obvious. Like the velocity is a signal. I’m gonna come back to that signal in a minute ‘cause it’s not a great signal. But, you know, velocity is a signal that a lot of organizations use, and the velocity is lower than we want, so we’re gonna pull the pressure lever. That’s an example of a choice. But it turns out that levers can be big, like big policy levers, like we’re gonna reorganize or we’re gonna embrace this new tool or we’re gonna do this big rollout, but they can also be really small.

So there’s two categories, two giant categories of levers. There’s policy and then there’s culture. Policy is anything that you need organizational authority to enact, like a reorg or changing the hiring criteria or… So those are all potential levers. But also culture, literally everyone in the organization is pulling culture levers all the time, whether or not they realize it. Just deciding whether or not to attend that meeting is an example of a lever that everyone gets to pull. And so if you just think about that one decision, like you’re thinking to yourself, “Okay, this is a Zoom meeting that is a ceremony with 73 people invited, of whom only 30-something are gonna attend. And of the 30-something, half of them are gonna have their cameras off and be completely disengaged. And then partway through, somebody’s gonna say, ‘Hang on. could you repeat the question?’” Right? You- We’ve all been in this meeting, right? And you get to decide, “Should I bother to attend?” That decision alone, that is an example of a lever. So a lever is every choice that you’re making that is gonna influence the system. And spoiler, everyone in the system, regardless of their role, regardless of their positional authority, actually has more levers at their disposal than they think they do.

Henry Suryawirawan: Yeah, so I think when I read that part, right, so when you mention levers can be two categories, policy and culture, right? I think it’s quite interesting, right, to me especially. Because one thing that we always realize is that whenever we wanna make a change in, let’s say, engineering organization, right, we make policy, new policy. Maybe new executives come in and decide a new policy, but we forgot about the culture part, the aspects where, you know, like how things work, how people feel. I think that’s also another lever that not just the leaders can do, can take, can pull, but also everyone in the, you know, in the team or in the organization.

[00:24:31] What Makes Proxy Metrics Like Velocity and Lines of Code Dangerous?

Henry Suryawirawan: So you mentioned about velocity. I think you might refer that as a proxy metric. So let’s go into that, like because in so many different organizations still, this kind of proxy metrics is something that is quite dangerous. Maybe like velocity, lines of code even, number of incidents, those kind of stuff. So maybe tell us the danger of this.

Elisabeth Hendrickson: Totally. Let’s start with just the definition of a proxy metric. You want a piece of information, but it’s really hard to get at. So for example, quality. There is no one measure that tells you about quality. Quality is a multidimensional thing. But if you’re looking for a way to measure quality, you need a proxy, something that will kind of approximate some information about that thing. So there’s no way to get away from proxy metrics completely. We use proxy metrics all the time. But when you don’t realize that it’s a proxy, that’s when you end up with problems.

So let’s come back to velocity. So the way velocity is usually counted in most organizations that I see anyway is they’ve got some method of pointing, whether it’s the Fibonacci series or whatever, they’ve got some way of saying, this story is a three, this story is an eight, whatever. And then they take the sto- the numbers associated with stories and sum that up, sum up all of the stories delivered in a given sprint, time period, whatever, and say, “That is how fast we can go.” All of this started, again, with the best of intentions. This was way better than the very heavyweight, massive work breakdown structure method of doing project planning that was common in the late 1990s. But the problem is that, the velocity numbers, they’re made-up numbers. They are our best attempt at sizing a thing at the moment that we know the least amount of the thing, least amount about the thing. So then we take these made-up numbers and we perform math upon them. They look very scientific at this point. They are not. When you take made-up numbers and you perform math upon made-up numbers, you still have made-up numbers.

Joel Tosi: But if you put them on a chart…

Elisabeth Hendrickson: They look so official, right? And that’s why I’m not a fan of velocity at all because it’s so easy to game. If somebody puts pressure on you have to increase your velocity, I know exactly how to increase my velocity. That three-point story, nope, that was, that’s actually an eight. And without… And now it actually takes longer to get anything done because we’re arguing more about what the velocity numbers, like what the points should be.

And so I don’t see any good coming from this. So I much prefer cycle time because now you actually have a timestamp. This is still a proxy for productivity. Like by itself cycle time does not actually tell you if we’re using our time well, but it gives you a much better sense for from the time that we started working on this story to the time that we delivered it, what is that time? And you may discover that between lead time, from the time we asked for the story to the time it’s in production, and cycle time, from the time we started working to the time we delivered for whatever delivered means in your organization, that between those two you may get some really interesting information. Like maybe the minimum lead time, even for the highest priority thing, turns out to be like 140 days. That is interesting information, and that is way more interesting than our average velocity is 37.6.

[00:28:23] Are DORA Metrics a Good Proxy for Software Development Productivity?

Henry Suryawirawan: Yeah. So I think the trend in the industry, definitely, the way I see it is that software, the productivity, development productivity is something that is still kind of like the golden metrics, right? All every engineering organizations want to improve their productivity. And that’s why every time there’s a new research coming out on how to quantify, how to measure productivity, be it, you know, story points, you know, velocity, or recently the DORA metrics, and maybe lately it’s the number of lines of code or tokens, will always be there. And people think it’s a silver bullet that they can use to measure, right?

So how about DORA metrics? Because this is also something quite, you know, referred by a lot of organizations. Is it something– Cycle time is definitely one of the DORA metric. But is it overall a good kind of like proxy metrics to measure software development productivity?

Elisabeth Hendrickson: I love the DORA metrics, and the reason is because they really are more about the outcome than about outputs, which lines of code is an output. Token… Don’t even get me started on tokenmaxxing, ‘cause that’s not even, that’s not even an output. That’s a sheer, that’s a game. Yeah. Oh, with bad prizes. Play stupid games, get stupid prizes. That’s just… No. But the DORA metrics are focused on outcomes. It’s not really sufficient to steer your whole organization, but it is way better than a lot of the measures that were used before “Accelerate” the book came out. So I’m a huge fan.

Joel Tosi: I like the DORA metrics as well. I think they are kind of more right side in value stream than holistic value stream. That’s not a… But like Elisabeth said, they’re still much better than, you know, kind of anything we’ve had before. While I, and I do like them, I think it’s sometimes it’s almost even simpler though for organizations. Instead of like, if they actually wanna measure developer productivity, instead of asking what everybody else is doing and then following the leader, this is what executive and engineering leadership should be doing. They should be asking, what does productivity mean to us? How would we wanna… Like how would we know we are more productive than not? And then get into the causal modeling, the systems thinking of it, of about, talking about what inside of our organization is influencing our ability to be productive.

‘Cause that, that… if you just measure a number, lines of code or something, then what do you do if the number is not high enough? You tell them, “Well, write more lines of code.” And that’s not helpful, and that’s not leadership. And so like when I think about it, it’s you actually have to study the system. Like what does productivity mean to us? What’s influencing it? And as soon as you talk about what’s influencing it, you see this world of levers, this world of options available to you. It might be things like our environments aren’t as good as we thought them to be. People can’t spin things up. There’s no isolation. The architecture isn’t right. There’s fuzzy requirements. You know, there’s, the feedback loops are too big. All of a sudden you get these things that in your context make you more productive. And that is so much better than saying, I read Netflix does this one thing on Tuesdays, we should try that. Like, it’s just so much more better if you understand what you’re doing.

Elisabeth Hendrickson: Well, and my favorite part about that, Joel, is I’m thinking now about the number of times that I’ve been either in an organization or consulting for an organization where they actually knew the answer to the question about what’s getting in their way.

Joel Tosi: Yeah.

Elisabeth Hendrickson: But they viewed that as too hard a problem to solve.

Joel Tosi: Right.

Elisabeth Hendrickson: And so they didn’t. So like you mentioned environments, like, “Oh, don’t talk to me about environments anymore because we can’t afford…” This was, I’m thinking about an organization way before containers were a thing and spinning up containers and VMs and whatever was super easy. So to be fair, it cost a lot of money to stand up new environments because it meant you had to get a new rack in the data center and, right? So don’t talk to me about environments. We have to solve the problem without adding more environments. Okay, but that constraint is actually the constraint in your organization, and anything else you do that doesn’t address that constraint is just gonna make that constraint hurt even more.

[00:32:50] What is the CREATE Framework for Avoiding Unintended Consequences?

Henry Suryawirawan: Right. Frankly speaking, I mean, borrowing from my experience as well, so I was also kind of like guilty on this kind of thing, right? Because things that are quite difficult to kind of like first observe, right, identify what’s the issue. You will need to deal with a lot of people, not to mention maybe there are also executives who may have power, politics, and all that. And just to come up with the, you know, the idea of, you know, understanding your system, understanding your signals, probably is very, very difficult. And maybe most of us would not attempt that, unless it’s like a very clear that we have to do something. And usually it’s the crisis that force us, and then become a policy. So I think in your book you have a better way. You have this CREATE framework. Tell us about this so that we can use it rather than, you know, fighting against each other.

Joel Tosi: The CREATE framework’s really interesting, Henry. So I’ll give you the, quick background story, which Elisabeth always loves, and then we can get into how to use it. When Elisabeth first started talking about this and she was just… We, She was trying to kind of form it. I’m not gonna lie to you, it looked like a radar chart to me. And so when I first saw it, I was like, “Elisabeth,” I was like, “I can’t stand radar charts.” I’m like, “They are overused. They are, they’re not helpful.” And then as I started getting into it, I started realizing how powerful this CREATE framework could be. And for the readers who haven’t seen the book, I don’t think it even looks that way anymore.

An early sketch of the CREATE framework actually looks like a radar chart. But with the CREATE framework, it was meant to be was just different dimensions to be considering when you’re looking at making kind of decisions, with the idea being that you really don’t wanna have, call it unintended consequences.

So the CREATE framework, keep me honest here Elisabeth, it’s Capacity, Risk, Execution, Adaptability, Trust, and Economics.

Elisabeth Hendrickson: Yes.

Joel Tosi: And so to give a very clear example of that. Sometimes a very common pattern, engineering is going too slow, right? Engineer’s going too slow, we need to ship sooner. And so some people confuse a capacity problem – we don’t have enough people, we don’t have enough resources, we don’t have enough systems – sometimes people confuse that problem with an execution problem, right? So sometimes what happens is when you think the problem is you need more people, you bring in more teams. But if it’s not a capacity problem, it’s an execution problem, bringing in more people makes all the execution problems harder. Now you have more merge conflicts. Now you have more environment conflicts. Testing is harder. The data’s messed up to test. Shipping’s harder. And so if you think about the C in CREATE was Capacity, and one of the E is Execution, we brought this out there so people could consider multi dimensions of the decisions they were making so they didn’t end up with being blindsided. Same thing with like risk and adaptability or, you know, trust and economics. There’s all these kind of facets. It’s not to say that they’re just two. In many decisions, there’s multi dimensions to be considered. And so that’s how we came up with framework and kinda layered it in.

Elisabeth Hendrickson: Yeah. My goal as… Part of where it came from in my own head was just trying to be, to figure out how to characterize different contexts. Because it- every context is different. So when you think about some extremes, like you’ve got a software as a service company where they’re relatively young, they don’t have a huge number of customers in production.

Maybe they aren’t doing anything that’s regulated. They can move fast and break things. And then by contrast, you have somebody who is in the financial space, been there for forever, and people are trusting them with their money. Very different contexts. And how do you really… You can say it’s a different context, and that’s kind of obvious.

But when you think about how to characterize what’s different, then it becomes kind of like this meandering, “Well, you know, you have to bear in mind regulated and…” Okay, let’s find another way to talk about the dimensions of context. And that, that was where I was in my head when I drew a thing that looked like a radar chart, and Joel had an allergic reaction to it.

But then as we were talking through this, that’s when we started realizing that one of the biggest sources of unintended consequences occurs when we think we have a problem in one dimension and address the problem in that dimension, but the problem was actually in a completely different dimension. And Risk and Adaptability are a good example also. Joel mentioned Capacity and Execution. But the things that we do to reduce Risk may actually be inhibiting our Adaptability so much that they create more problems, and potentially even increase Risk. Yeah.

Joel Tosi: I mean, if you think about all the change control boards that, we put a change control board in place to reduce risk, and therefore we can- we don’t ship as often because the work has to wait for the board to come up. But now you have work that’s ready to be delivered that you might not know if it’s meeting the customer’s needs for an extra month.

And so you don’t get feedback for another month. And now you’ve, to- by trying to control risk, you’ve lost adaptability, and now you have higher market risk because your customers aren’t– You’re not getting feedback fast enough, and your customers might not be happy. So again, it’s just a, it’s a beautiful kind of simple way. By no means are we saying it is the end-all be-all, but I think we’re offering it up as a nice way of looking at these dimensions of context and avoiding unintended consequences.

[00:38:26] How Do You Quantify and Apply the CREATE Framework?

Henry Suryawirawan: Right. So definitely quite kind of like quite interesting, right, the different kind of like variables, within the context that you can look at. So I think for some it’s kind of like intuitive, right? Like fo- so for example, capacity, execution, economics, right? Maybe it’s kind of like easy to quantify, but how about quantifying risk, adaptability, and trust, right? So like you mentioned about radar chart. I assume there’s some metrics, some number that represent, you know, whether we are doing good or not. So how do you quantify some of these? Do you have like a question with survey or, you know, how do we use this framework?

Elisabeth Hendrickson: So for adaptability, I, my… So let me back up and say it isn’t a radar chart, and we don’t have metrics for each one of these dimensions. So I just want it truth in advertising. I don’t want anybody to think that this book is gonna tell them exactly how to measure all these dimensions. The framework really gives you a little bit more of a… the intention is take a holistic view and think through the potential implications of when you make a change over here, what are you putting…. well, to overuse the word risk, what are you putting at risk over there? But coming to Risk and Adaptability, let’s start with Adaptability.

I love what I think of as the tracer bullet test, which is, how long would it take to make the simplest non-functional change. For example, just changing a prompt on a field kind of thing. It’s the… There’s no behavior change. We just have to change some text. How long does it take for that to get all the way through the delivery system from the time the ticket is created to the time that we see that change in production? That’s gonna give you a pretty good sense of your adaptability as an organization. If that is measured in minutes, and in some organizations it could be potentially measured in minutes, you’re gonna be a highly adaptable organization. You may have other issues, but being able to ship a change is not your constraint here.

By contrast, I worked with an organization that in general was very agile. In general, very, very, good at turning on a dime as needed. But that tracer bullet test to go from the time we identified a change to the time we could see it in production for the simplest possible change was still well over two weeks, which was a surprise to that organization because their self-identity was, “We are super adaptive.” Well, some stuff has happened and things aren’t as adaptive as you think they are anymore.

Joel Tosi: I love that example. Some of like the signals we talk about, like in the Adaptive space or the Trust space, sometimes they get into a little bit more of the qualitative aspect. You know, like the… If you think about, especially on the Trust side, like the things that, the things people say versus the actions that actually happen, right? Pr every- all… When the leadership says every team is autonomous, but then you see that no team can make any decision on their own, right? Like they have to defer the decision. Then you feel like there’s a disconnect in the trust space. There’s something not quite right there.

In the adaptability space, I love the example of the tracer bullets. I also like the idea… Like, for me, adaptability comes a lot into architecture. And so, like, there’s definitely, like, signals around architecture that you could see. Can teams independently test or does d- do- are all of your tests have to be regression? Because if all of your tests are regression, I can’t guarantee you that your architecture is tightly coupled, but chances are you’re gonna be pretty low on that adaptability because you don’t have that independent testability aspect. And so when we think about adaptability, we look for different signals. In the book, we go through some kind of like examples of signals in these spaces. But again, they’re gonna be, some are quantitative, some are qualitative.

Elisabeth Hendrickson: Right. And, Joel, what you’re pointing out is that that whole signals and the CREATE framework thing, it’s less about identifying the perfect metrics and more about, for your environment, getting a read on the signals that would tell you about that dimension. And Risk is interesting because it encompasses both the what are the risks that we have, where you might be looking at your number of incidents, the number of rollback, looking again at DORA, the number of rollbacks that you’ve had to do, failed changes. Those are quantitative. But you also may have qualitative risks that are more about what is the market sensitivity to a risk here for the world that we live in. And that’s where a financial services company is gonna have a very different risk profile than a startup that matches dogs for dog play dates or something, right? Like the risk profile is just so different. So really what you’re looking for is what are the signals that tell us about this dimension.

Henry Suryawirawan: Yeah. So speaking about the tracer bullet example you mentioned, I think in your book you refer that as the done gap, right? So the gap between, you know, after you finish your work, but something to put it into production, right, might take, you know, processes or maybe approval, review, whatever that is, right? I think it’s quite interesting for leaders to actually identify the gap, this done gap, right, so that we can actually improve the systems, how we deliver software to production.

[00:44:09] What Are the Three Illusions That Leaders Face in Software Delivery?

Henry Suryawirawan: So I also want you to mention about these three illusions that you mentioned so that all of us actually get enlightened, because sometimes we are under curse living in this illusion. So tell us about these three illusions so that we always can refer to it whenever we make decisions.

Joel Tosi: The three illusions: illusions of progress, illusions of predictability, and illusions of control. I’m not even sure how we… I think it started off as just us sharing stories, and then we started seeing patterns in the stories. And then at first, Henry, the, each of those illusions were their own chapter, and then it felt like a little bit us too much glorifying the illusions. And Elisabeth did a wonderful job of consolidating them down.

Elisabeth Hendrickson: Well, let’s be fair. I’m gonna interrupt you briefly to say we got some early feedback on the book that I will be forever grateful for. One of our reviewers read the first three chapters and said, “Could you give me a break? Because it was so depressing. Just, I need a win in here somewhere.” Okay, we’ll consolidate that into the… So now illusions is the first chapter. So it’s one chapter. All right. Go ahead, Joel. Sorry.

Joel Tosi: And so in no particular order, because sometimes each ones are my different favorites at that point in time. Like when you think about the illusion of progress, it’s that, you know, we think we’re getting somewhere, and we think we’re getting there quickly, but we’re really not getting there. It’s the individual team’s velocity or cycle time or something. They’re shipping really fast, but the product’s going very slow, right? Or we’re shipping lots of features, but nobody’s actually using it. It’s this illusion of progress, this illusion that we’re getting somewhere better. In some examples, in some organizations I’ve been with, what’s wild, and Elisabeth has a wonderful story about this as well, I’ve seen organizations say, “We’re gonna take, adopt a microservices architecture. Therefore, every team can be on their own and they can ship independently.” But what’s interesting is every team is going really fast, but the product experience goes across services. And so it doesn’t matter how fast each team goes until it all comes together to deliver an experience. So it’s an illusion of progress. The teams feel fast, but the product feels slow. So that’s one example there.

There’s the illusion of predictability. So a wonderful story in the book around, you know, traversing the coast of California and how long will it take. And, so the idea behind the illusion of predictability isn’t to say estimates are bad, because at some point in time somebody has to be able to say, what’s gonna happen when. But this idea that we can predict everything in software, like we’re building systems that usually haven’t been built before on technology that was just built yesterday with people that are learning it today. And so this idea that we can predict how it’s gonna happen is just kind of silly. The book gets a little deeper into predictability where we actually start talking about variability, which is a topic I love. But for an example, I had one group I was working with, wonderful people, wonderful product owner, love them to death. The product owner was convinced that the team didn’t know what they were doing because, they, you know, they weren’t shipping predictably.

Elisabeth Hendrickson: Hey, that’s trust.

Joel Tosi: Blind trust, there you go.

Elisabeth Hendrickson: Sorry, go ahead

Joel Tosi: No, you’re fine. And so what I did is I looked at their cycle time, and I looked at the variability in their cycle time. And so I go, the cycle time is 12 days plus or minus 12 days, right? And so, like, so you– so it’s, the PO is like, “Why aren’t they predictable? Why aren’t they predictable? They’re not doing their job. They need to be predictable.” The problem wasn’t that they weren’t predictable. The problem was they had so much variability that predictability was out the window. And so the PO– So again, this illusion of predictability, right, is what’s kind of sitting inside there.

And the last one, the illusion of control, right? The idea that, that we– if we have meetings, the problems will go away. If we have a risk control board, we won’t have defects. Like all of these kinds of ideas, they make you feel good. They make you feel like you have control of something, but they’re not changing the system. And so we call that, you know, the illusion of control. Which one’s your favorite, Elisabeth, today?

Elisabeth Hendrickson: Today, well, I wanna expand on that. You mentioned the story. So we got permission from Michael Wolfe who has the best answer on Quora ever given. The question was, “Why does, why is software so difficult to predict?” And he wrote this essay that is just, as far as I’m concerned deserves to be highlighted, so that’s why we reached out to get his permission to quote his essay. Because it is hilarious. The whole thing is hilarious. It starts with, okay, so we’re in San Francisco. My buddy and I have decided that it would be fun to hike down the coast of California and meet up with our friends in Newport Beach. And whipping out a map, it’s this many miles, and if we do so many miles a day, we should be there by Sunday, so we’ll call them and let them know to expect us for dinner. And then the story goes on involving angry sea lions and wiped out a trail and having to go backtrack inland and unforgiving terrain and blisters and illness and everything that can go wrong will go wrong. So the essay itself is absolutely hilarious. But the thing that I didn’t know when I first encountered that essay is that it is a wonderful send-up of a classic essay from, I think, the 1960s, “How Long is the Coast of Britain?” by, catch me if I’m wrong, Joel, I think it’s Mandelbrot. The same guy who did fractals wrote this wonderful essay about how it’s impossible to measure the coast of Britain because of the fractal nature of coastlines. So that is my favorite illusion, the illusion of predictability. I’ll just stop there, yeah.

Henry Suryawirawan: Yeah, so I think we all sometimes live in this illusion, I think most of the time I would say. Especially again, like we don’t understand the system, we don’t use the systems thinking. So we think just by pulling one lever we can actually kinda like predict, make good progress, and kind of control, right?

[00:50:27] Will AI Truly Speed Up Software Development?

Henry Suryawirawan: So I think I wanna take the last part of our conversation speaking about AI definitely, right? So, because AI is like one big variable in the systems now. And most of the companies in the industry will think AI will speed up their development or even like reduce the number of developers they need. So what are your point of view in this? Is it also an illusion of progress or illusion of something that we are living in?

Elisabeth Hendrickson: I think it’s very real. I mean, Claude and I are buds. We work together on stuff all the time. I think that there is a set of skills that we are all figuring out on a day-to-day basis. As the capability of the tools change, like practically day to day, and the tricks that were, the things that people were learning six months ago, like this is how you actually make it do what you want it to do or this is its limitations, those things aren’t true anymore. So for example, six months ago, the wisdom was that if you said, “Oh, pretend that you are…” and then you gave it a persona, that it would behave differently. And apparently, I mean, I haven’t tested this extensively, but apparently that is just not the way that it works anymore. The… how do you save on tokens? And what is a good Skill look like? And all of these things are changing day to day.

None of that invalidates the notion that this is in fact transformational, and the question isn’t is this useful or not, it’s useful. It’s already proved itself. It’s useful. The question is, for our context, given everything we care about, given the world we live in and the codebase we’re dealing with and all of the peculiarities that are specific to the world that, to what we have to deal with, what is the best way for us to apply this technology? I think that is the question. Not is this… can this save time? Yes. Can this reduce the number of developers that we need? Maybe. Like I’m not gonna say no. Does it change the lines about what responsibilities should be for a given role? 100%. And what’s the answer? I don’t know, and even if I did, it’s gonna be different in two months. So that’s why it’s so important, more important today than ever before, to be able to read the signals and figure out what levers you have at your disposal.

Joel Tosi: Yeah. I mean, AI is– If I took a step back and I– before we even get to the AI aspect of it, if you, if we get into like the systems and the cause of modeling and we talk a lot about loops, right? And so there’s an idea of reinforcing loops. Now rein- a reinforcing loop could be virtuous in the sense that things are continuously getting better, and get better, and better, and better. And they could also be vicious in the sense that they just kinda get worse, and worse, and worse. And so anything you do in kind of one of those loops, if you make a change into one of those loops, sometimes a simple nudge can take a vicious loop to virtuous or a virtuous loop to vicious or kind of balance it out. And that’s the first step was we need to understand kind of what’s happening inside of our organization, where are those loops sitting at, and what’s influencing them. Because whenever you introduce new technology, whether it be the platform team or the cloud or AI, it’s going to have a ripple effect on some of those loops. And the risk we always run is by introducing a new technology that we take a perhaps a virtuous loop and turn it into a vicious loop, or a balanced loop and becomes vicious.

I’ve been with some organizations where they have a great idea. We’re gonna have platform teams, so therefore the product teams can just focus on the product stuff. This way the, all the Kubernetes and cloud stuff is abstracted away, teams don’t have to worry about it. Wonderful idea until, right, until the teams can’t deploy because they don’t understand the errors they’re getting, and then they have to wait and file a ticket and then wait two weeks and they can’t do anything. And so like with the best intentions, you might introduce something that actually shifts your system around.

And I think that’s where AI is gonna end up falling, is that if people– if leadership doesn’t understand the system at play, they could introduce AI in such a way that it exacerbates an existing problem. If you live in existing code base that is already hard to reason with and you’re getting thousands of lines of code jumped at you, and it’s already hard to test, probably– you’re probably gonna have a bad time. If you’re working in a simple system with simple architecture and clear domain boundaries and clear context and clear separation of concerns and you have high confidence in your testability, and you can work in small steps, AI could be an amplifier for you. It could help you kind of reason through things.

There’s one interesting thing that we leave I think maybe as an exercise for the reader. There’s an interesting question to think about is, if you can ship– what happens when you ship faster than you learn, right? And I think that’s a really interesting question for us to be thinking about in a systems kind of world. If you’re shipping faster than your feedback loop back into your learning cycle of your product, what happens? That’s something to see and kind of follow.

Henry Suryawirawan: Wow, very interesting question. What happens if you ship faster than the way you learn from the feedback, right? Sometimes even like you ship faster, but you don’t actually remember what you ship. I think this Is what I feel as well.

Joel Tosi: Yeah.

[00:55:55] How Should Leaders Integrate AI Into Systems Thinking?

Henry Suryawirawan: Yeah. Yeah. So maybe tell us also, like, maybe you have consulted with different people, like seeing in the industry, how best engineering leaders should tackle AI, this AI question, right, in, the context of systems thinking, right? So I think you mentioned a couple of things, right? But maybe tell us the best, kind of like the best practice. I know it’s maybe difficult at this moment to come up with the best practice. But what have you seen work? Like how do people apply AI in the context of systems thinking such that it can create a reinforcing loop that is like virtuous?

Elisabeth Hendrickson: I have an answer to that, and it’s something that I will say that I have. It has caused me to change my mind about something. I think that the way, the best way to use AI right now is to think about optimizing for learning specifically. And I saw an organization where they were committed to AI, using AI all the time, but everybody was using it differently and they took a week to do essentially like vibe-athon kind of thing. And the whole purpose was to learn. There wasn’t a, like no prizes, not the typical hackathon thing. But instead, we’re gonna take a week to learn what happens when we apply AI. We’re gonna learn from each other. We’re gonna have a way to come together and share learnings every day. And they took a week to do this. And I realized something, ‘cause in the past, as an engineering leader, I was 100% all for taking time to learn, and I put some pretty clear guardrails on it. So like we would do a, kind of a hack day kind of thing to where it’s just go play. Go play with technology. Go learn like one day a month, or sorry, one day a quarter. That is not enough anymore.

And so my… now what I believe is that you do have to decide for your own context what the right cadence is and what’s the right duration. But if you think about we need to optimize for learning, and what is it that we need to learn? What are the questions that we need to answer? My personal belief is that at this point, at this moment in time, we’re in the moment where figuring out harnesses is the big question in front of every organization. Because ultimately, I believe that the general purpose frontier models are not gonna be how we’re developing software a year from now. And rather it’s gonna be harnesses that have many agents that are attached to many different models, and the harness is responsible for figuring out what kinds of work goes to which. And, in my head, the analogy is like, database query optimizers, where it’s the database query optimizer that knows how to farm out the query. Like this is the age that I think we’re in. We’ll see whether or not I’m right about that, but that’s not the point. The point is the learning, figuring out what questions do we need to answer, and creating more space than you ever thought was necessary to enable the organization to answer those questions, I think that is the most important thing that any organization can be doing today.

Joel Tosi: I would add on to that, that I would– So I love the learning aspect for a variety of reasons. I would off– also offer up that it needs to be done, not individually based. It needs to be done at least in a pair, if not in a small group base, because otherwise we kind of get into our own kind of niches of kind of what worked and what didn’t. And we actually do need some constructive, you know, conflict. Conflict– good conflict, right? Like I’m not sure if that’s kind of saying what we think it is. Is that helpful?

The other thing I would offer up for leadership that’s looking into AI is again, kind of like… AI is a hypothesis for something inside of your organization. And so whatever you’re looking at adopting, you should be thinking about how could we find out sooner if it’s going the right way or the wrong way, right? Like so how do you find shorter feedback loops as well as what are the countermeasures that you want to look out for… Sorry, the countermeasures you want to have in place to make sure things don’t go off the rail. Or what are the other, you know, if you look at the CREATE framework, if you’re bringing an AI to help with execution, does it affect something else, right? And so that’s the kind of systemic things that you want to be thinking about in addition, right, is the how do I find out sooner if it’s going where I want it to go? How do I avoid unintended consequences? And how do I know we’re going the right way?

Henry Suryawirawan: Yeah. I love optimizing for learning and for the feedback loop, right? So definitely something we all can do, right? And I like the vibeathon idea. So I think I haven’t heard about that before, but I think it makes sense now.

[01:00:53] Can AI Be a Thinking Partner for Systems Thinking?

Henry Suryawirawan: So, I think one thing that also I would like to ask, like system thinking is very hard to understand, and sometimes we all, one person, right, it’s very hard to understand everything, right? Can we use AI or have you seen, you know, someone using AI to help you in doing systems thinking in their organizations? And if so, what kind of things that we should feed into the AI?

Joel Tosi: So I personally have not seen it. That’s not to say it couldn’t be done, by all means. I’m a big fan of, if we’re gonna do systems thinking, if we’re gonna do causal modeling, if we’re gonna do a look at anything, I’m a big fan of us doing it together because we need to have different perspectives. So like if I’m an engineering leader, I’d wanna do it with a product leader and maybe, you know, different types of leadership so we could talk about the system at large and talk about how we see the influences and the data we have behind them. I’d be nervous. I mean, I just don’t know. I’d be nervous to see how well AI would do that, especially if it was overly confident in its results, but I have nothing to back that up on.

Elisabeth Hendrickson: So I have a theory. So first of all, I wanna challenge the idea that systems thinking is hard. I actually think that every single one of us is a systems thinker. I think that is just how we navigate the world, because otherwise we would not be able to deal with the ambiguity of the universe that we walk through every single day. The problem isn’t the systems thinking part, it’s articulating…

Joel Tosi: Yes.

Elisabeth Hendrickson: What we’re reacting to, being able to explain so that somebody else understands the signals that we’re seeing. And I love, Joel, you’ve got a phrase about, show other people what you see…

Joel Tosi: See the same reality.

Elisabeth Hendrickson: See the same reality. Right. So making it so that we can see the same reality. That is the biggest challenge so that we can navigate the same system together, because we all have our own perspectives on the system. So when it comes to AI and seeing the same reality and being able to articulate what we’re reacting to, I don’t think we can feed it all into AI and have AI give us the answer. I think that’s how we end up with the answer to the universe is 42, but everybody has forgotten what the question is.

And instead, it can be a fantastic thinking partner. Like if you say, “Hey, I wanna make sure I’m thinking through holistically all the signals, with respect to capacity, risk, execution, adaptability, trust, and economics, can you give me a list?” Give me a list of 20 is one of my favorite things to do with ChatGPT. It’s amazing at giving me a list of 20 whatevers. Like, and– So I think that the way that I would wanna use it is more as a thinking partner and less of an answer machine. And as a thinking partner, because all of the, especially the general purpose frontier models have been trained across such a huge corpus, it’s gonna be able to surface things that I think no one person would’ve been able to surface. And that can help with the thinking and articulating amongst a group of people.

Joel Tosi: Nice.

Henry Suryawirawan: Love the seeing the reality because I find it that’s the most difficult thing do in an organization.

So we have discussed a lot. Before we jump into the last question, anything else that you wanna call out that we haven’t really discussed? Anything from the book or maybe some things that you encountered recently?

[01:04:26] Why Is the U-Curve a Powerful Tool for Modern Leadership?

Joel Tosi: Oh boy. There’s a myriad of things in the top of my head. I think one of the things that I liked the most from the book, something that we, let’s say we kinda added late in the book. And that is, one of the tools we introduce in the book is the idea of U-curves, not something that obviously we created. It’s from economics and we both are in debt to Don Reinertsen for his wonderful explanation of it. But one thing we did late in the book that I thought was really beautiful is we started talking about showing U-curves and showing how context affects U-curves. And I think that is a really powerful technique for leadership. Because like if you wanna ask the question, how, where should we invest in test automation? Well, it depends. What does it depend on? Depends on context. How would I know what’s the right context? And so… Or how do I know what’s right for me? And so you could use U-curves, and you could see in different contexts what the appropriate blend might be based upon your architecture, the coupling of the code, your current testability.

Like, you could make these decisions. And what I also love about, kinda how we went through that is by using U-curves in context, you could also see things that the right decision today could be the wrong decision tomorrow. And as Elisabeth very eloquently pointed out to me last week, the wrong decision today could actually be the right decision tomorrow because the context changes and the system adapts. And so I think that thing, we haven’t really talked about it, but this idea of using U-curves in context and starting to blend some of these system thinkings tools together, there’s a world of power inside there that I hope our readers get.

Elisabeth Hendrickson: Absolutely. The tools are all self-supporting. Sorry, go ahead.

Henry Suryawirawan: For people who don’t know U-curves, what is U-curves? ‘Cause I’m not familiar with that as well.

Joel Tosi: Oh, so the… I think the quickest way I can explain U-curves is when you have multiple contributing factors to a decision. And so it’s seeing those contributing factors create a total kinda answer. So if we were to kinda talk about, what should the batch size be? How big should our batch size be? Well, there is contributing factors. One contributing factor is the cost per unit, right? And so if you’re doing manufacturing, if you set up the machine and you can produce a million screws, the cost per screw goes down, right? But if you need to, if you have a… If you produce a million screws, but you can only sell one at a time, you have a holding cost of holding all the inventory. And so you’re… As you increase your batch size, your price per unit goes down, but your holding cost goes up. And so you see if you add those two lines together, you get this U-curve.

The same thing happens inside organizations when we’re talking about how many people should be on a team. It’s Brooks’s law, right? As if you add more late people. If you add people to a late project, it gets later. You can see it because it becomes a U-curve problem. It gets into testing. It gets into all of these wonderful aspects. A U-curve is just multiple contributing factors coming up to one total value.

Elisabeth Hendrickson: And figuring out the sweet spot, it’s particularly useful when, maybe you’ve got position-based arguments happening in your organization at two ends of a spectrum. Like hypothetically, not that anyone I know has ever had this argument, but we should be producing one at a time versus we should be producing a gigantic batch. Those are two extremes, and the U-curve is a mechanism to find the sweet spot in between that is specific for your context. But a, probably a more realistic debate inside an organization would involve something like absolutes related to maybe how we think about the release process. That we shouldn’t think about releasing until we have finished everything versus we should be releasing every feature as it’s completed. And that you can have people who get really locked into position-based arguments instead of thinking through, well, actually, there’s a whole continuum of answers, and the question is where is the right answer for us on this spectrum.

Joel Tosi: There’s that example. There’s the, every team has to be full stack and has to be able to do everything versus we have a team of specialists, right? And so like those are two ends of the spectrum. And the reality is based upon the context of the organization as well as even the context of the problem, the answer is going to be different.

Henry Suryawirawan: Yeah. So yeah, this is a perfect example of how, you know, systems thinking can give us, you know, kind of like an idea how to kind of like solve problems based on our context, right? There’s no right or wrong. I’m sure there’s no silver bullet that we can refer to. So I think thanks for explaining that. And thank you for the book. I think for people who love systems thinking, this is definitely one of the book you should check out. Because, yeah, this is quite interesting, the way you guys kinda like narrate the concepts.

[01:09:17] 3 Tech Lead Wisdom

Henry Suryawirawan: So as we go to the end of our conversation, I have one last question, which is like a custom in my podcast, which is to ask you to share with me the three technical leadership wisdom. I’ll leave it up to you how do you wanna share it, but yeah, maybe if you can share, that would be great.

Joel Tosi: I’ll go first for one, then I’ll turn it over to Elisabeth and we’ll see where we… So my first one, Henry, and this is the one that I, hopefully Elisabeth isn’t tired of hearing me say it. I think the takeaway for technical leadership is act where the pain is caused, not where it’s observed. And, because again if I come back to leadership, they see– they, it’s like the best intentions, I see problem and I solve problem. And it’s quick because you know things need to be solved quick and you’re trying to make the world better. But you could spend a little bit more time being a little bit more intentional, understanding not just where you see the problem, but actually what’s kind of causing the problem. And if you’re addressing where the pain is caused, so much better. So it’s not superficial, right? It’s not just, that it’s not just there’s not enough test coverage, it’s that it’s hard to test, right? It’s like there’s all these kind of nuanced problems. And so that’s the thing I would have, I would stress is act where the pain is caused, not where it’s observed. That’s my first one. Let me turn it over to Elisabeth for her first one.

Elisabeth Hendrickson: Well, and I think my first one actually dovetails really nicely with that, because it’s about being very careful to not conflate problems and solutions. And let me unpack that a little bit. Way back when I was a baby engineering manager and I believed that our problem was that we didn’t have enough unit testing. Well, no, that’s… Unit testing was in my head the solution. It wasn’t actually the problem. And so as a technical leader, being able to not express a problem as the problem is we’re not using AI, the problem is we don’t have enough testing, the problem… That’s not the problem. That is your belief about the solution. And so drilling down to get to the point where you can express the delta between observed, what you’re observing in the world and the outcome that you’re trying to drive to, the outcome isn’t unit testing, that is not what customers pay for. There is something else that is the real problem, and you believe that unit testing is gonna solve that problem. I’m not saying I was wrong. I’m just saying that wasn’t the problem. That was potentially the solution to the problem.

Joel Tosi: And then a pi- a third one here for you is be aware of the world of signals that you’re– that aren’t there for you. It– One of the… There’s– Look, I love the book. I’m biased. One of the things I think is wonderful in the book is when we talk about dashboards. Dashboards tell you something happened. They don’t tell you kinda how it happened or why it happened or what it took to get there. And so when I– And so like, we need to have better signals. And I would tell leadership that there is this world of signals around you. You just have to like kinda tune in a little bit, right? Kinda like it’s not difficult. Like Elisabeth said, systems thinking is very approachable. I think people do it naturally.

What I’d stress for leadership is to be more attuned to the signals, right? It’s– Maybe it’s the hesitation in the voice of the engineers. That’s a signal, right, of something else, right? Or it’s this meeting, like I mentioned, that’s happening over and over again, or there’s all these little signals that are happening that tell you that maybe there’s a different problem that’s happening, and I need to understand a little bit deeper around what’s going on here. Be attuned to the signals.

Elisabeth Hendrickson: And I guess I’ll add to that, ‘cause if we’re talking about signals, let’s also talk about levers, because it is very tempting to reach for the levers that worked in your last job. In my last job, we did this set of things, and so pulling on those same levers, only you’re in a different context now and those levers may not have the same effect that they had somewhere else. Furthermore, you may not necessarily have been reading all the signals ‘cause we only can see what we have access to, and you may not have seen the consequences of some of those levers. And so being open to the possibility that levers you never would’ve considered before are in fact gonna be more effective within your current context, being open to the possibility that there are levers that you haven’t identified yet that would actually be just as easy to reach as the ones that you already know about, I think is really important for nav- especially navigating in so much uncertainty and ambiguity in today’s world.

Joel Tosi: Last thing I might offer up is, no problems are bigger than us. And I think that’s something that engineering leadership, as well as even teams kind of need to hear. And I mean that in the most kind way possible. Very frequently we’ll get together with groups and they’ll say, “Well, you know, the environment is a bigger problem than us. We can’t solve it on our own.” And it’s like, well, but there are things that within your control that you can influence that will shift it a little bit, right? And so, that’s where I think some of the beauty of the systems thinking comes into play is that we don’t become powerless now. We understand kind of the things we can influence, and there aren’t problems bigger than us. Because let’s be honest, if engineering leadership is always saying, “Well, the problem’s bigger than us, we can’t solve it,” those problems don’t get solved. And so we have to be thinking about what we can do.

Elisabeth Hendrickson: I think that’s a great place to end it. So there, between the two of us, you got five.

Henry Suryawirawan: Nice. Nice. I love all the systems thinking wisdom and the interrelatedness between both of you, so I think really lovely, and it’s a very good food for thought for all of us.

So thank you, Elisabeth, thank you, Joel. For people who would love to, you know, learn more about the book, maybe reach out to you for questions, are there places for them to reach out?

Elisabeth Hendrickson: Well, we have a website, signalsandlevers.com. The book is not officially released yet. It is available for pre-order. And signalsandlevers.com is currently just a landing page, but that is the best space to keep watching. We’ll be building that out as we get closer to the release date.

Joel Tosi: And on the Signals and Levers website, if you sign up, the– we are starting to publish a newsletter. The newsletter has some behind-the-scenes information as well as upcoming events. And Henry, I, if I told you there wasn’t a second book probably cut from the first book, I think we have like 70,000 words that were cut from this book already. So there is plenty of extra content that will be dripped out as well. So if you’re interested, please check out the website.

Henry Suryawirawan: Nice. So yeah, for those of you who love these kind of topics, definitely check out, signalandlevers.com, right? And do subscribe to the newsletter as well.

So thank you so much for both of your sharing. So really looking forward for the release of the book. So good luck with the release. So thank you for your time today.

Elisabeth Hendrickson: Thank you so much.

– End –