Signals & Levers: Elisabeth Hendrickson and Joel Tosi on Change Theater, Open Loops, and Systems Thinking for Software Teams

Scroll down for how to subscribe, transcript, and more

---

My guests for Episode #550 of the Lean Blog Interviews Podcast are Elisabeth Hendrickson and Joel Tosi, co-authors of the new book Signals & Levers: Systems Thinking Tools to Unblock Software Delivery (IT Revolution, 2026). The book is aimed at software organizations, but its sources are Deming, Shewhart, Chris Argyris, and Donella Meadows, and most of what we discuss applies to any leader trying to improve a system.

Elisabeth is the founder of Curious Duck Digital Laboratory, where she advises and coaches technology leaders. She was previously VP of R&D at Pivotal, leading about 170 engineers, product managers, and designers, and she is the author of Explore It! Joel is co-founder and CTO of Dojo & Co., which helps organizations improve the flow of work through immersive learning environments. He has more than 25 years of experience delivering software and is co-author of Creating Your Dojo and Coaching for Learning. Joel was previously on the show in Episode 351 with Dion Stewart.

We start with the three illusions the book describes: predictability, progress, and control, and why Joel says they travel together like three kids in a trench coat. Elisabeth explains what it means for an organization to “run open loop”: making changes without ever reconciling what you intended against what actually happened. Joel's term for the result is “change theater,” and his example is the organization that measures its Agile transformation by counting how many teams hold the ceremonies.

We also get into process behavior charts, which Joel first encountered at an event I spoke at about ten years ago, and why he started using them with software teams to stop arguments about made-up numbers. Elisabeth makes the case that story points are an opinion, cycle time is a fact, and doing math on an opinion still gives you an opinion. We close on psychological safety: why a defensive “Model One” organization can score itself high on safety surveys while behaving otherwise, and why telling people to be brave doesn't fix fear.

What you'll learn

• Why the three illusions of predictability, progress, and control reinforce each other, and why leaders and engineers often respond to different signals in the same system
• What “running open loop” means, and how the reconciliation loop in Kubernetes connects to cybernetics and feedback
• How to recognize change theater: activity measured in place of results, often because the feedback loop got so long that nobody remembers why the change started
• The difference between naturally occurring latency and the latency organizations create by accident, such as separating strategy from execution or splitting skills that need to work together
• Why chasing predictability can increase variability, and how process behavior charts give teams something factual to discuss instead of arguing about process
• Why story points and estimates are opinions, why cycle time and lead time are not, and what happens when you do math on an opinion
• Why psychological safety survey scores can be incongruent with observed behavior in a defensive organization, and what a safe team looks like without a survey
• Why everyone has levers, not just leaders with positional authority, and why improvement should act where the pain is caused rather than where it is observed

---

Topics and questions

• Where the names Curious Duck and Dojo & Co. come from
• Elisabeth's and Joel's origin stories in improvement work
• The 2018 Toyota visit and what suppliers on site taught Joel about feedback loops
• Is Signals & Levers a software book or a systems book?
• Why “we know this will work” should be reframed as a hypothesis
• Open loop vs. closed loop, cybernetics, and Kubernetes
• How a leader can tell they're in change theater
• Time delays in feedback loops and why humans misread cause and effect
• The next book: Delineations, on why drawing lines is hard
• Why process behavior charts appear in a software book
• What Joel would most want to see charted: cycle time, lead time, and whether what you ship changes revenue or customer friction
• Story points, T-shirt sizes, and estimates as negotiated opinions
• Chris Argyris's Model One and Model Two organizations
• Why you can't fix fear by telling people not to be afraid
• Closing insights from each guest

This podcast is part of the #LeanCommunicators network. 

---

---

Watch the Episode:

---

Thanks for listening or watching!

This podcast is part of the Lean Communicators network — check it out!

---

Episode #550: Elisabeth Hendrickson and Joel Tosi, Signals & Levers

Mark Graban: Hi, welcome to Lean Blog Interviews. I'm your host, Mark Graban. Our guests today are Joel Tosi and Elisabeth Hendrickson. They're co-authors of the new book called Signals and Levers: Systems Thinking Tools to Unblock Software Delivery, and it's from IT Revolution. So let me tell you about the two of them.

Elisabeth Hendrickson is the founder of Curious Duck Digital Laboratory, where she advises and coaches technology leaders. She was previously VP of R&D at Pivotal, leading about 170 engineers, product managers, and designers, and was VP of engineering at a startup. She began her career as a programmer and tester, and she's also the author of Explore It.

So before I introduce Joel, welcome to the podcast, Elisabeth. How are you?

Elisabeth Hendrickson: Thank you so much. I'm so grateful to be here.

Mark Graban: Well, I'm glad you both are here. And Joel Tosi, also joining us, is the co-founder and CTO of Dojo & Co., which helps organizations improve the flow of work through immersive learning environments. He has more than 25 years of experience delivering software products. He's the co-author of Creating Your Dojo and Coaching for Learning. Joel, thank you for being here too.

Joel Tosi: Always great to be here, Mark. Thanks for having us.

Where the Names Curious Duck and Dojo & Co. Come From

Mark Graban: So it's an interesting combination of company names. This was unplanned, but Elisabeth, I'm going to ask you first. Curious Duck. Where's that come from?

Elisabeth Hendrickson: Well, it comes from a family story. Our youngest child, who is now a full-grown adult living on her own, but at the time was about four years old, I think, had been very quiet in the backseat on a very long car trip, and all of a sudden out of nowhere she piped up and she said, “There's always a duck.”

And her dad and I said, “What?”

She said, “There's always a duck.” And we said, “What do you mean? Where did this come from?” There were no ducks in the vicinity. And she said, “I don't know, but there's always a duck.” And the really funny part was that at the time I was doing a lot of business travel all over the world, and I found that my four-year-old was very accurate about the ubiquity of waterfowl.

There is in fact always a duck. There were ducks in China. There were ducks in Hungary. There were ducks in Poland. Not only were there ducks in Finland, but outside the big opera hall in Helsinki there is a heated duck pond to keep the ducks safe over the brutal winters.

So there is in fact always a duck.

So when I knew that I was going to found a company and needed a name, duck was definitely going to be in the name. And then the question is, all right, ducks need an adjective, and curious was natural given who I am.

Mark Graban: Not just your daughter, but you, both curious.

Elisabeth Hendrickson: Yes.

Mark Graban: And Joel, the name Dojo, I have some thoughts about where that comes from, and you've been on the show before with Dion, but go ahead and tell us about Dojo and Company. Or is it Dojo and Co.?

Joel Tosi: It's Dojo and Co. Obviously the “and Co.” is there's more of us, right?

And so the way that the Dojo thing came up was, back in 2016, 2017, a lot of organizations, and Target in particular, were looking at ways to improve some of their engineering practices. And at the time Target had this kind of internal discussion and they said, “Where do people go to practice?” And somebody said, “Well…” At the time everybody was calling DevOps people ninjas. And so the question was, “Where do ninjas go to train?” And they said, “Well, they go to the dojo, of course, to train.” So Target had created this little thing called a dojo, where the engineers would come and they would work with myself and Dion and some other people, and they would learn good engineering practices.

And so that was the way they became engineering ninjas. It was a really nice way of doing immersive learning. And so we just kind of used the name for the company going forward.

Origin Stories in Improvement Work

Mark Graban: Yeah, and you and Dion Stewart were here in Episode 351 if people want to go check that out. Did I ask you your Lean origin story in that episode? I just started doing that after…

Joel Tosi: I don't even remember, to be honest.

Mark Graban: Well, the listeners might not remember either, but I'm going to start with Elisabeth. If you can tell us your origin story when it comes to improvement. It may or may not be framed around Lean, and I'm going to throw one point at you. The dedication in the book, you thank your dad for teaching you to see systems everywhere, so this must have started young?

Elisabeth Hendrickson: I can only assume that it started young, so young that I don't actually remember. I definitely got a lot of my curiosity from my dad, and critical thinking skills from my dad. My dad always invited me to think about things and debate with him, even when I was a very small youngin.

But professionally, I would point to… Well, I guess I would say professionally, I probably always wanted improvement, but in terms of what we might think of as the modern era of improvement, I would probably point to my dissatisfaction with the status quo led to my being on an early Pivotal Labs project, circa 2004, give or take.

And that experience really cemented my path going forward in the Agile, Lean, and DevOps space. My world is different because I managed to weasel my way onto an early Pivotal Labs project.

Mark Graban: And I'm reminded, I'm sorry, of a Simpsons episode where Homer Simpson says, “Weaseling out of things is what separates us from the animals… except maybe the weasel.” You were weaseling in, so.

Elisabeth Hendrickson: I was. I was weaseling my way in, yes.

Mark Graban: We got ducks, weasels.

Joel Tosi: Everything.

Mark Graban: Animal fact episode today. Joel, how about you? I mean, was it Agile, or was it… I'm not trying to play framework bingo here, but what was your origin story when it comes to improvement?

Joel Tosi: I think maybe it had a longer duration. An organization that I was at where I actually first met Elisabeth, going on probably two decades ago now.

I remember early on, I was trying to do some improvement work there, again, kind of still in the engineering space, and ultimately, when I ended up leaving and Elisabeth came in, I was sitting down with a bunch of our directors and executives, and somebody had made a comment around, “Why do you all think we need to get better?”

And everybody kind of goes around the room and everybody says, “Well, we're pretty good the way we are,” right? And everybody said, “The stock price is high. We have a lot of employees. We're getting a lot of things done.” And when it came over to me, I looked around and I just said, “I don't want to be okay. I want us to be great. And I feel like you're all happy with okay.” And I just can't do that. And that was kind of a trigger for me. Like, I've got to scratch this itch. And then unfortunately I left, and then Elisabeth came in to help the organization out, so we didn't get to work as closely there or as long as I would've liked.

But I think that was the first step. When I moved on to some other organizations, I was the lead architect for an organization for North America, and I was the weird guy that sent systems thinking books to all the other architects.

Because I wanted them to understand, it wasn't just you give them the best design. You have to do the design in a context that solves real problems, that actually helps people do things better, and it wasn't just about what's right right now. I don't know if that ever made a difference or not, but I think that was the start. And then of course the dojos were always about improvement, Mark.

And then the stuff that we did down in Toyota kind of opened my eyes to more stuff. And so it's kind of been that itch that's always, maybe getting itchier. I don't know.

A Toyota Visit and the Economics of Feedback Loops

Mark Graban: We don't have anyone here to give you medical advice around that. A professional. It's okay. That's fine. And you mentioned the chance we had to go visit Toyota. It was pre-COVID. So what was it, 2018?

Joel Tosi: Yeah.

Mark Graban: We called this our learning symposium that we collaborated on. You had a lot of people from your circles and software space. I had a lot of people there from manufacturing and healthcare. That was an event I would love to do again because it was PowerPoint free.

We visited Toyota. We had a day of, you know, open space, and I did the Red Bead Game and things at the Garrison Brothers Distillery. You know, I think calling it the learning symposium, I'm going to credit you or Dion for that. Like, that's how you could get someone's company to actually pay for that.

Joel Tosi: Yeah.

Mark Graban: What do you mean? Go to a distillery, what? Like, there was no drinking during the day. We were focused. It was a good working discussion environment, right?

Joel Tosi: Yeah. And Mark and Elisabeth, I think you'll greatly appreciate this. I remember when we did the Toyota tour, the one thing… Elisabeth and I will talk a lot about how the economics are constantly changing, your context is constantly changing. And I remember the one thing at the Toyota trip that we did was Toyota, instead of bringing the parts in, they had the vendors there.

And so I remember that kind of blew my mind. And sure it costs more money, right? It costs more money because you have to have space for your vendors, but the fact is then when you encounter problems, you don't have to wait, you know? The feedback loop is so drastically different.

And I remember when I saw that, I was like, “This is the craziest thing.” Because in software we would never do that. We wouldn't say, “Yeah, bring the vendor and have him sit with us,” because we want choice. We want private. This is our stuff. But that triggered in my head that the economics are different. And you can look at economics differently.

Mark Graban: Yeah, I mean, I guess in the software space, you can bring people in virtually. Toyota had the shorter loop of sending the signal for parts and parts coming by, and parts being sequenced directly to the Toyota schedule. I mean, that's far easier to do when the system design has them on site.

But yeah, you're right, that communication feedback loop of somebody pulling an andon cord and you realize, okay, the problem with this part traces back to a supplier. The supplier is right there at their gemba, and being there physically probably matters so much more in manufacturing.

But you're right, a lot of companies are choosing… Well, I'm going to bring up Dr. Deming soon. A lot of companies still violate the Deming advice. They choose the supplier based on the cheapest price, and that cheapest price might come very, very far away, and it's hard to collaborate. You can't have a pull system or just-in-time. Ugh, common mistakes.

Is It a Software Book or a Systems Book?

Mark Graban: So let me ask about systems. You know, the subtitle of the book frames this around software delivery, but your sources include the aforementioned Dr. Deming, Walter Shewhart, Chris Argyris, Donella Meadows. I mean, is it really a book about software or is it a book about systems and leadership and such? I'm trying to help expand the market for your book, right?

Elisabeth Hendrickson: Oh, well, that's very kind. So I think that it's probably best to think of it as systems thinking applied to software delivery.

So while, just as I read The Goal and got a lot out of it, even though I wasn't in manufacturing, at the same time, I think that The Phoenix Project does a much better job for people who are in the software world of creating a text that is much easier to absorb because the examples don't require you to squint and look sideways.

So we wanted to create something that had that same flavor of being applied specifically to software because there really are very few books out there that take systems thinking and say, “Okay, and this is what it looks like in software.” We have the Poppendiecks did Lean for software, doing a direct translation. The Phoenix Project did a Theory of Constraints for software. We wanted to do systems thinking for software. So while we would love to believe that there is a larger market for it, I think, to be fair, we should warn everybody that all of the examples and the fictional component are all very software focused.

Mark Graban: Okay. Well that's fair, and that's probably more of an advantage for you in the book of having that targeted audience. And I'm going to name drop or make connections. Tom and Mary Poppendieck were on the podcast together. Gene Kim. We didn't talk about The Phoenix Project, but he's been on here with Steve Spear and their more recent book.

The Three Illusions: Predictability, Progress, and Control

Mark Graban: Joel, let me bounce it to you, and Elisabeth, I'm sure you'll chime in of course as it's a conversation here. In the book you talk about three illusions: predictability, progress, and control. Which do you see most often, let's say amongst senior leaders?

Joel Tosi: So I kind of always go back and forth with this. I would say I go back and forth with which one is my favorite. I honestly believe, and Elisabeth and I even have a little joke, that they all kind of travel together.

Like the three kids in a trench coat trying to sneak into a movie. Elisabeth did a wonderful drawing around that. It feels like they all kind of come together and almost reinforce each other to make things look more prevalent.

What I would say around leadership, I think the interesting thing is, at least in software, leadership sometimes gets a bad name from the workers, the individual contributors, the engineers building software.

And the perspective is occasionally the leadership is disconnected, the leadership doesn't understand what we see. And I think what's interesting is most leadership aren't trying to do the wrong thing. They're just seeing different parts of the system, and they're responding to different signals than the engineers are seeing.

Your CTOs or CEOs are responding to market pressures that your engineers aren't seeing. And your engineers are seeing challenges building and shipping that your executives aren't seeing, and they don't really understand. I shouldn't say understand. It might not resonate with them as much.

So coming back to your question around the illusions, I think they all kind of come together at every level all the time. So maybe that's a cop-out.

Mark Graban: Well, hey, it's a system. Things tend to be interconnected.

Joel Tosi: Yeah.

Mark Graban: They're part of a business system and broader system elements that would affect their view and perspectives. I think a different word, I'm not saying you picked the wrong word, but around predictability, I've heard people talk about the illusion of certainty or the demand for certainty when it's just not possible.

Like, tell us if we invest this, we are going to get that result. You're both nodding, and now shaking your heads. Elisabeth, why? That sounds so straightforward, right? If we're going to invest in something, you should know what the result is going to be. Why is it more complex than that?

Every Change Is a Hypothesis

Elisabeth Hendrickson: Because the world is not that deterministic. One of the fun things that I got to do while I was at Pivotal was, our finance team, I had such a good relationship with our finance team. I'd never had that good a relationship with the finance team. They tapped me to go speak to a local committee of the IRS.

And the topic was about R&D tax credits. And don't ask me hard questions about this. I wasn't there to talk to them about tax law. I was there to talk to them about software delivery. And one of the key aspects of the idea of R&D tax credits is that it's predicated on the idea that you are making an investment with an uncertain return. That you don't know. When you're innovating, you just really don't know what you're going to get out the other side. So even the IRS in the US recognizes that it's not as simple as you put your coins in and you get your pellets out. That is not how the world works.

But I think that the reframe that I would offer anyone is that you'd better have a hypothesis.

My hypothesis is that if I make this investment, this is what we expect to get back, and then figure out how to turn that into a series of experiments, so that you don't end up facing down the sunk cost fallacy 18 months in and realizing that you have absolutely nothing to show for all of the investment that you made.

Mark Graban: So, Joel, tell us more. I was going to come back to this later. I'm going to bring the question to build on this idea of treating every change as a hypothesis. In some settings that might seem, I don't know, highfalutin science guy talk or science woman talk.

Are people more comfortable with that language in software? Are we still trying to come around from this idea of we've got an idea, we know it's going to work, let's implement it, versus I have a hypothesis. I feel like I should be wearing a fancy hat and tipping it.

Joel Tosi: Monocle, right?

Mark Graban: Yeah. I have a hypothesis. Shall we explore our hypothesis together?

Joel Tosi: Yeah. I wish it was more prevalent. And I think maybe it's more prevalent, at least in the software side, it's more accepted on the pure product side than it is on the engineering side. Product seems to at least accept uncertainty a little bit more than engineering does.

I was with a group this morning, and putting aside the fact that the whole discussion was around symptoms and not the actual problem, after 45 minutes this group of engineers decided they had the solution, right? Like, “This is what we're going to do.” And I simply asked them, “Well, how will you know… What result are you looking for that will tell you it is doing what you wanted it to do?”

Elisabeth Hendrickson: Silence.

Joel Tosi: They had the solution though, right? But they had no idea how they would know it worked. And so I think on the engineering side, we get fixated on the build sometimes, or fixated on this thing will do something that is interesting, and we don't kind of close the loop. As Elisabeth would say, we run open loop quite often.

Running Open Loop: Cybernetics and Kubernetes

Mark Graban: Yeah. Well, tell us more about that, Elisabeth, for people that… Well, I'll ask it for me. I'm going to pretend like it's the listener who doesn't know. What does that mean, open loop thinking?

Elisabeth Hendrickson: That's running without feedback. I first learned the phrase ages and ages ago, long before I'd ever heard of control theory or had encountered cybernetics as a topic. But I had heard we're running open loop, and it resonated for me even back then, before I knew that there was a much deeper tie to far more academic work.

Because it means that we're continuing to go forward without ever having a way to check if we're where we think we should be on the map.

However, to tie it to the more academic side of things, I kind of love that Kubernetes is itself tied to cybernetics. Linguistically it ties to cybernetics, because Kubernetes introduced this idea of a reconciliation loop as a vocabulary term. Cloud Foundry and other systems of the time may have had similar concepts baked in, but Kubernetes gave us the phrase reconciliation loop, and that's where you have set what you want to be true.

You want three instances of this thing, and you are setting an intention, and then there is a control loop that is measuring what is true today, and then trying to reconcile what you intended with it. So it's getting the feedback and acting on the feedback. There's only two instances. I'll spin up another one.

So running open loop means that we never try to reconcile between the intention that we had and the observed reality. And closed loop, especially these days, it's more and more possible to do this in a very tight closed loop where we can say we're going to now steer towards what we intended to be true.

Mark Graban: Okay. So I'm going to again lead by example and say I'm not afraid to say I don't know. And so I'm here, I hang out with smart people and I get to learn things. This is outside of my usual space. First off, cybernetics. I've got to ask you, tell us a little bit about that. And then Kubernetes.

Elisabeth Hendrickson: Oh, okay. Let me actually start with Kubernetes, because I honestly know more about Kubernetes. Kubernetes is a deployment platform for software. Back in the old days you might have installed things on bare metal on towers in data centers.

And then we got virtualization, so now you're running on VMs on towers in data centers. And these days you run on containers that are typically managed by some kind of orchestration system, and Kubernetes is probably still the most popular of those. So it is a deployment platform for all of your software needs. Not literally all, but you know.

And then cybernetics. I'm looking at my bookshelf now to see if I happen to have the book handy, and I am sure I do, only I have no idea exactly where I put it.

Mark Graban: Too many books.

Elisabeth Hendrickson: Yeah, too many books. There is a classic book on cybernetics called literally Cybernetics, by Norbert Wiener, I believe. And there was a whole field of study. And here's the thing that is amazing about it. It is the study, it's very deeply mathematical. I have not studied it in depth because it is very daunting to try to read the original texts. But if you ask ChatGPT to explain it like I'm five, what it boils down to is this idea that everything, pretty much from biology to social systems, it's a form of systems thinking that is looking specifically at those feedback cycles and reconciliation loops. Hence the connection with Kubernetes. There is a whole etymology there.

Did I say that right? I think I did.

Mark Graban: I know that word.

Elisabeth Hendrickson: You used the right one. I didn't say Entenmann's, which is a branded pastry.

Mark Graban: Coffee cake place.

Elisabeth Hendrickson: So there's a whole etymology there for Kubernetes and the connection to cybernetics.

Mark Graban: Okay. Great. Well, thank you for that. See, if you were on a show hosted by a software guy, you're going to get different questions, and I'm sure there's software people listening. But we've got a broader audience here.

Elisabeth Hendrickson: Oh, software people would not be asking about cybernetics. It is not very well-known, nor is the connection with Kubernetes very well-known. They might know Kubernetes, but they probably would not know cybernetics.

Mark Graban: Okay. And cybernetics, it's not L. Ron Hubbard. That's a different… that's Dianetics. That was from back in the day. You know, when we were kids, we would see ads for that book on TV. Not L. Ron Hubbard. Anyway, sorry, not to go there.

Change Theater and Measuring Activity Instead of Results

Mark Graban: So Joel, I'm going to ask you, I love phrases like this, change theater, and the goal is stopping change theater. How do you describe that, and how can a leader tell if they're part of it or seeing it happen?

Joel Tosi: Change theater for me comes down to changing for the sake of change without a reconciliation loop. A lot of leadership, at least in the software space, they want improvements, right? They want improvements.

And I think what happens is, without understanding of the system and the context they're operating in, Elisabeth and I joke that they're like kids in the lever store, right? There's all these levers. We're just going to start pulling things. And they get into this space where they're just changing things because they know there's a problem, and they have good intentions, so they want to change things, but it becomes change theater because they're never kind of seeing if they're getting the changes that they wanted. And if they are not getting them, they're never adjusting based upon the feedback they're getting.

And so success looks like… To give you an example in the Agile space, hopefully it's better now. But for a long time, if an organization was trying to improve by becoming Agile, the metric they would use is they would count how many teams are doing the Agile ceremonies.

And it's just like, well, that doesn't really give you anything. It's just you're following a process to act like you're changing, so it's change theater. You're not getting the improvements.

Mark Graban: Yeah. It's a measure of activity.

Joel Tosi: It's a measure of activity. Yeah.

Mark Graban: It's easy to measure activity. It feels like progress. That's part of the illusion of progress. We're implementing all the things, but at some point, who cares, right?

Joel Tosi: Yeah. Exactly. And so when I think of how would a leader know if they're kind of falling into that illusion, for me, it comes down to if they're looking at signals that are different than what you might see on a dashboard.

If you're not looking at the activity. You're looking at are things actually improving based upon the ideas of improvement you're looking for. Are you looking at faster time to market, right? If you are, then you should easily be able to say, “Are we actually getting quicker to market?”

Are your customers happier, right? Are you getting less calls to your operations center, right? These are things you could actually tell.

And I think what happens a lot, and this might be one of the causes of the illusion, the feedback loop becomes so long that we forget why we started and changed in the first place.

And so people, because it's been so long, they can't correlate an outcome to the intent, and so then they start measuring activity.

“Well, we don't know if we've improved, but a lot of people are doing this stuff.” And so, again, you fall into change theater because of open loop, because of lack of reconciliation, because of latency in feedback loops. And so that's how you get into change theater.

Time Delays and Latency That Organizations Create by Accident

Mark Graban: Yeah. I mean, the point about time delays is one I remember from Peter Senge in The Fifth Discipline and the way MIT teaches system dynamics. And one of the key lessons there is when you have time delays in a feedback loop, it's really hard for humans to correctly follow the cause and effect.

Like when the cause and effect happen immediately, we are less likely to be wrong about the connections. So what would you add about trying to reduce those time delays within the development of a product or the growth of a company, Elisabeth?

Elisabeth Hendrickson: Oh, sure. I mean, that is in fact one of the biggest challenges that I see in so many organizations, and it's not getting better with AI even though you would think that it would.

And that's because the series of things that has to happen from the time that we've got a change that somebody somewhere thinks is ready to go to production, then there's a whole series of things that have to happen before it can actually go to production, including potentially reworking it because there was a problem with it, because that's the only place in the cycle that we detect that there was a difference between what we intended and what we got.

And so, again, this comes back to I'm making an investment, I have a hypothesis. It is super critical for these organizations that want to reduce that delay, which is essential for being able to, as an organization, be adaptable, for them to have a hypothesis about if we automate our tests, for example, then we should see a reduction in the delay.

And all too often it turns out that we have another kind of example of change theater, and it turns out that that investment does not actually yield any reduction in the time to production. Or they do successfully reduce the time to production, but they actually did so by incurring greater risk, so things get worse and then that just spirals out of control.

So that's why I made a face at you when you were talking about reducing the delay, because it's not that simple.

Mark Graban: Sure. Well, I read the faces. I've got something I really want to say on that. Which I think turned out to be true, whether you wanted to say it or you had something to say.

Elisabeth Hendrickson: Oh, yeah. It's so true. I have lots to say on that.

Joel Tosi: I think what's interesting too about that, Mark, I forget if this was in the book or something we discussed afterwards, Elisabeth, so please keep me honest. I'm pretty sure it's in the book. We talk about there's naturally occurring latency in systems, and then there is latency that the organizations create, usually accidentally, right? So if you're building a product, by the time your product gets out to market and you actually get customer feedback, there's natural latency, right?

Just because people have to use it and get feedback. And if you're trying to build an organization, you can't just say, “Everybody trust each other,” right? It takes time to build trust. So there's natural latency in systems and interactions. But then there's latency, like Elisabeth's alluding to, that organizations tend to accidentally create.

When you start separating, like Deming would say, the strategy from the execution, now you are accidentally creating latency because you're separating these concerns. You can't separate strategy and execution. When you're separating people by skills, but the skills are required to work together, you're introducing latencies.

Like, you're trying to create plans and five-year roadmaps, but you can't really address, you can't ship things in smaller increments, and the world changes.

Now you're accidentally creating latency. And so that's one of the things we talk about, too, is use systems thinking to identify ways to learn sooner, but also identify where you're accidentally creating latency.

Mark Graban: Yeah. And that makes me think of a different form of the illusion of predictability, maybe. Could you imagine if somebody tried putting together a five-year AI roadmap? We just have no comprehensible ability to know where we're going to be in a year, let alone five.

Elisabeth Hendrickson: I guarantee you that somebody somewhere has, as part of their quarterly objectives, to put together said five-year roadmap. Somebody somewhere has that.

Mark Graban: A beautiful PowerPoint.

Joel Tosi: It's a beautiful PowerPoint, I'm sure.

Elisabeth Hendrickson: Yeah. It's in the same organization that is advertising for engineers who have a minimum of five years experience with agentic AI development.

Mark Graban: Yes. And I know you're not making that up.

Elisabeth Hendrickson: Well, I don't know. No organization that I have run into at this time fits this. In case anybody's thinking that this is a real example from empirical evidence, it is not. But I understand the nature of the world.

Mark Graban: You have a hypothesis that that's happened somewhere, right? I'm not asking you to be certain.

Elisabeth Hendrickson: Yes, and I hope someone in the comments will tell me if I am right. Like, “Oh, yeah, you must've been peering through the windows of our organization.”

Mark Graban: Yeah. How'd you know? That was us.

Elisabeth Hendrickson: How did you know?

The Next Book: Why Drawing Lines Is Hard

Mark Graban: I was going to just comment real quick as an aside, don't you hate it when you're at that point of, was that in the book or not? It's not that far in the rear view mirror, but I think that's a sign that you're still thinking and still learning and like, “Oh, crap, we thought of something new and it's too late to put it into the book.” I mean, that happens.

Elisabeth Hendrickson: Yeah. No worries. We have a next book planned.

Mark Graban: Oh, tell us about that real quick, if you don't mind. You brought it up.

Elisabeth Hendrickson: I don't mind. I brought it up. So one of the things that we kept running into as we were writing this book is that drawing lines is hard. I've run into this before we even started this book with figuring out, should this responsibility belong to this team or that team? Should we organize the code this way or that way? We're drawing a line here or over there. Is this one function or two, one method or two, et cetera. So drawing lines in general is always hard, but we found it particularly difficult as we were writing this book, especially as we realized that we were over our word budget, which is something we did not expect to have happen.

We kept thinking, “Oh, no. What if we don't have enough words?” Because, of course, IT Revolution gave us a range. It must be between this and this. And we kept thinking, “Well, I don't know. We've got like 10,000 more words that we've got to find.” That turned out not to be our biggest problem at all. We had to figure out where to cut, and drawing lines is hard. So that was where we drew lines. We decided that if it involved drawing lines, as opposed to feedback loops and the classic systems thinking, U curves, choices, trade-offs, et cetera… But if it was strictly about how to organize a department or structure a thing or categorize this versus that, all of those are examples of drawing lines.

And so our next book is about drawing lines being hard. It is tentatively titled Delineations. We have not yet started on it, which is probably good because in this age of AI, the farther we get into it, the more I'm seeing all kinds of lines blur that used to be very firm.

Every job description is currently a little bit fuzzy around the edges, as responsibilities shift in response to the tools that are now available that didn't used to be. So, what a great time to be collecting material on general principles for how to determine where to draw lines.

Why Process Behavior Charts Are in a Software Book

Mark Graban: So I'm going to shift directions, but within the realm you gave me a segue. Drawing lines, there are lines on the cover of the book. The word signals makes me think of something I know is in the book, and I was so excited when we were talking about this as you were writing, process behavior charts. So is that where the signals in Signals and Levers, or at least one of the connections to the title of the book?

Elisabeth Hendrickson: Yes, definitely one of the connections. There are many types of signals.

Joel Tosi: But I was going to say, we even talk about process control charts as almost like a meta signal. They're signals about signals, right?

Mark Graban: Yeah. So we talked earlier about the difference between measuring activity and measuring results that hopefully have a cause and effect relationship between activity and results. There's an illusion of meaningful progress. We can confuse trivial moves in our metrics versus meaningful metrics, and we could use the language of signals versus noise.

The illusion of, well, we want to tell a story that it got better, but the illusion is that the metric's just a little better than it had been before, and it's in the realm of reasonable possibility that if we had done nothing, we could have generated the same metric. Boy, that doesn't make you popular, saying things like that in an organization.

So there's this illusion of progress. Let me turn it to you about why, and thank you again for doing it, why include that in the book? Why bring that to people who… I have a hypothesis that a lot of people reading the book don't know in advance before reading what a process behavior chart is.

Joel Tosi: Yeah, I think, at the root of it, what I was seeing in the software industry, and of course, many thanks to Mark, because Mark, you were who introduced me to this, I don't know, nine, 10 years ago.

Mark Graban: 10 years ago. Yeah. It was an Agile event in Chicago that you guys invited me to come talk at, right?

Joel Tosi: Yeah, and it was blowing my mind then. And what I remember was a lot of organizations in the software space, like you said earlier on, they wanted more predictability. And at some level you have to respect it because if you're trying to tell your customers what to expect, or you're trying to create marketing plans, or you're trying to create pricing, you have to kind of know what's going to be there.

But what I saw happening inside a lot of the organizations I was working with was they were trying to create predictability. And by that desire to make everything predictable, they started increasing their variability, right? Because what was happening was they were trying to squash the variability out, and it would move somewhere else. And so then they would start changing what they were measuring to make it look simple and predictable, but then something else was wildly out of control.

So it was this Whac-A-Mole problem. And so I remember talking with a lot of organizations back then around, if we're just focusing on becoming predictable and we don't understand how much variability we have in our system, along with what's causing the variability, we'll never get any sense of predictability.

However, if we start looking at how much variability we have, is it affecting our decision-making? If it's affecting our decision-making, then we need to understand the influences on variability. Then we can start talking about becoming more predictable as a byproduct because then we start understanding the systemic effects and what happens there.

And so that's kind of how I got into it, and now I've lost the question.

Mark Graban: About why process behavior charts, I think was the high-level question, right?

Joel Tosi: Oh, why process behavior charts. Yeah, so to take that a step further, a lot of organizations, what was happening was they were imposing process on teams because they were trying to become more predictable.

And the process was just causing kind of like… What did Deming say? If you give me a number, I'll hit it, even if it causes the company to go under or something.

Mark Graban: Yep. His warnings about targets or quotas, yeah.

Joel Tosi: And so that's what was happening with these organizations, is they would create a process and they would want numbers, and the engineers, because they didn't have good information, it was still early on where you have imperfect information, they would make up numbers.

And so then it became, “We'll make the made-up numbers better.” And so it became everybody arguing about nonsense. And so I wanted to introduce variability as, you know… First of all, we had to get rid of the fake math games, right? We can't do math, as Elisabeth would say, we can't do math on opinions, right? And so we had to get to actual data. In a lot of organizations, we look at cycle time, which I'm sure your audience is familiar with. Cycle time, lead time, kind of things that aren't opinion-based, they're fact.

I mean, it started, it shipped, right? And then we could look at the variability that was happening in cycle time or lead time, and then we could talk about what's happening there. And that created better conversations where we weren't just arguing about the process, and nobody was right. Everybody was aggravated. And so that's why I started introducing the Shewhart charts, was I wanted to stop arguing, and I wanted to get to something better.

Mark Graban: Yeah, and terminology, control charts as they might be called. Walter Shewhart, the statistician who created those, and Dr. Deming was in kind of the lineage of learning from Shewhart. And then, still working and teaching today, Donald Wheeler, a statistician who's been in private consulting work for a very, very long time, who both learned things from Dr. Deming and taught Dr. Deming some things as they were contemporaries. Not the same age, but they were working at the same time. And Don Wheeler calls them process behavior charts. And so there is, funny enough, variation in the terminology. But I think incredibly helpful.

If you were looking at software practice, Agile measures, or even just metrics in a startup, what would you most want to see in a process behavior chart format? For what reasons and what benefits?

Joel Tosi: I think there's a couple different ones. For me, I want to know process control charts around cycle time and probably lead time. And I think those are interesting because if we don't know how effective we are at getting from a customer-identified problem to in the customer's hands, and there's high variability in there, then how do we know how to handle feedback on our product?

So I'd want to understand those. From a product perspective, I would want to know something around… I don't want to get into, it's never about new customers or something like that, but there's got to be something around revenue and kind of how the money is fluctuating.

I want to understand if the ideas that we're actually generating and delivering are reducing customer friction, if they're increasing revenue. In software, I think we all feel this, I feel like there's a lot of software built that shouldn't be built.

And that's very expensive, and then I think it makes it harder to learn. And so if I'm in a startup space, I would want to really know, are the things I'm doing making a difference? I'd want to know how effective am I at shipping, and are the things I'm doing making a difference?

Why Story Points Are Opinions

Mark Graban: Yeah. So the one thing you haven't mentioned, and I only know some of the lingo around, I think this is Agile, story points? Is that trying to measure an opinion? Elisabeth's shaking her head no. That doesn't come through on the podcast.

Elisabeth Hendrickson: Yes, that is measuring an opinion, yes.

Mark Graban: So tell us about that, Elisabeth, then. Thoughts on story points?

Elisabeth Hendrickson: So let's put it this way. Anything that you can… I was going to say anything you can negotiate, but technically customers could negotiate price with an enterprise software product. And money is different. But the reason that story points are an opinion is because teams habitually negotiate how many story points is this thing.

And the way that they were originally intended is it does not represent a unit of time. It is framed in different ways depending on who you're talking to. It could be framed as a mechanism to determine the level of certainty around how large or small this thing is, a gut feel for how large or small this thing is, a comparative, not absolute, but relative comparison, like T-shirt sizes, small, medium, large.

Whatever you want to frame it as, the reality is that it is not a thing that you can point to and everyone who is observing it would see it the same way. By contrast, cycle time, calendar days elapse. We started, we might argue about when do we actually call this started, but that's what working agreements are for, to say, “All right, it started when somebody picks up the ticket,” or whatever the condition is.

And it ends when… And then the stuff in between, those are days and you can count them. We don't negotiate about, “Well, those days, you're overblowing how many days that was. That wasn't actually that many days.” There's a calendar, I can tick off the number of days in between.

So, count of days, not an opinion. Story points, 100% an opinion. An estimate, “Oh, but it's count of days.” No, that's an opinion about how long it's going to take until you have the actual value. You don't know. It's a guess. And any time you do math on an opinion or a guess, what you end up with is still an opinion or a guess.

It's just one that looks a little bit more official. And therefore, it creates a beautiful illusion.

Mark Graban: Yeah. And so there's the deeper illusion, as opposed to papering over it with process behavior charts. Like applying a process behavior chart to a thing you shouldn't be measuring is probably not the greatest idea.

Elisabeth Hendrickson: No. That's like taking a second order derivative on an opinion. You still end up with an opinion. It's just a very fancy looking opinion.

Mark Graban: Yeah, yeah. The rate of change of the opinion.

Elisabeth Hendrickson: There you go. Still an opinion.

Model One Organizations and Psychological Safety Surveys

Mark Graban: So, Model One organizations, that's Chris Argyris terminology, right?

Joel Tosi: Yep.

Mark Graban: So I want to ask, because again, I'll say I don't really know, what is a Model One organization and why do you argue that Model One organizations overrate themselves on psychological safety surveys?

Joel Tosi: So Model One organizations, based upon Chris Argyris's definitions, tend to be more defensive in nature. And you kind of look for the one throat to choke. They tend to be less information gathering. And Model Two is more information embracing, kind of collaborative. Let's figure these things out together.

Mark Graban: Okay. Yeah. So I would want to be part of a Model Two organization.

Joel Tosi: I think most people would want to be.

Mark Graban: Right. Because, just a quick aside, at General Motors, I had somebody put their hands around my throat one day because they found the person to blame for reporting a safety problem. He didn't squeeze, but it was still, it was more weird than it was threatening. I'm okay. I was okay.

Elisabeth Hendrickson: That still counts as assault, right?

Mark Graban: Yeah, I would've made things worse to go to HR. That's why. We'll unpack that over a drink sometime.

Elisabeth Hendrickson: Okay, okay. I'm really sorry that ever happened to you. That should never happen.

Mark Graban: Well, yeah, all right, so be it. But anyway, it was surprising to me that you used that phrase, a throat to choke. Triggered a little PTSD. Took a deep breath. Said, “No, no, no, it's fine.” I can laugh about it now. I laughed about it shortly after, but help me get back on track.

Elisabeth Hendrickson: Yeah, so we're talking about Model One versus…

Mark Graban: So Model One, why would a Model One organization overestimate the level of psychological safety, or overrate themselves on surveys? Is it because they're giving the answer that they think they should give? Or no, I should just let you answer.

Joel Tosi: Well, so this would, again, not be based on any empirical evidence. This is mostly just kind of observational. In the organizations that I've been in, one organization even recently, they did a really nice thing that, you know, I thought.

They would just send out surveys on psychological safety. And what was evident was their scores were all very high based upon this survey. And we would joke, “It's all fours and fives.”

Mark Graban: Out of five, right? Not out of 10?

Joel Tosi: Out of five. Yeah. Five was great. And all the scores were a four and five. And the questions would be like, when I identify a problem, I feel like I'm heard and there's no repercussions, right? The questions were right, and then the answers were incongruent with the behaviors you would observe.

And so I remember I was sitting with one of the groups and they had just taken this survey and something came up. The team's talking about it, and I go, “Why can't we tell your manager about it?” “Well, we can't tell the manager because they're going to interpret it wrong and they're going to blame us.” “So we have to figure it out without telling them.” And I remember saying, “You just took this survey, and you said you can do things without repercussion.” “Yeah, we have to though.” “But this is kind of different,” right?

And so it became like everything was… I think they wanted to feel that way. But they also, they didn't like the mirror. And so I think a couple things are happening. One is either people feel defeated and so it's like, “It doesn't matter what I say so I might as well just say we're good so I don't get bugged about it.”

And so you kind of get that information hiding happening. Or the other thing is, they don't really realize it because it's almost like, not an imposter syndrome, but they're just used to it being that way so they think that it's okay, until somebody points it out and says, “That's really not right.”

Mark Graban: It might be more Stockholm syndrome, because they've gotten used to it, I guess.

Joel Tosi: Stockholm syndrome. There you go. Yeah. And so that's my observation, has been a lot of that tends to happen. I remember one organization that I was with 10 years ago doing some consulting. Wonderful organization. They didn't do these surveys. And psychological safety wasn't as prevalent 10 years ago then. They had me sit down with this team, and then after the end of the day they asked me what I thought. And I said, “You all don't need my help.” And they go, “Why don't we need your help? We paid you because we want your help.”

And I said, “All day I heard you all ask each other genuinely what they thought about something. And then you would go sit together and you would work on it together, and then you would show other people and get their feedback. You all have everything you need together. Just embrace that.” And so I remember that. There was no survey but observationally you could see that that team was safe.

Mark Graban: Yeah. What would you add to that, Elisabeth, in terms of what to look for, what you'd hope to see in terms of behaviors, or what you'd hope not to see?

Elisabeth Hendrickson: Yeah. I think probably in terms of adding, I could just add more stories that are kind of aligned with what Joel's talking about, seeing organizations where, coming back to estimates, and estimates are opinions. Sometimes estimates are what somebody prenegotiated in their head would be acceptable to whoever, leadership or whoever it was, who had the authority to ask for an estimate, as opposed to what they actually thought it would take.

Organizations where you have to kind of walk on eggshells and aren't allowed to say what you really see. You have to pretend not to see things, because otherwise it's political suicide to be honest about what you're seeing. None of these are healthy behaviors.

And so, in addition to Chris Argyris' work, we also lean heavily into Amy Edmondson, who wrote extensively about psychological safety. And I honestly believe that everybody in leadership should read Amy Edmondson's work, and Chris Argyris', but Amy Edmondson's work on psychological safety is so crucial, I think, for anyone in a leadership position to deeply understand, because not everybody who makes it to leadership really understands how the mantle of leadership affects how other people relate to them.

So they think, “I'm a nice person. I'm just a little fuzzy, fluffy bunny person,” and other people are seeing, like, Dracula. I don't know. I don't know where I'm going with that. So I'll just stop.

Why You Can't Fix Fear by Telling People to Be Brave

Mark Graban: Just stop. I'll start. No, Amy Edmondson's work is great. Now I feel like I'm bragging. She's also a previous guest on the podcast. You can search for Amy Edmondson. Her book, The Fearless Organization, in particular, really influential to a lot of us. So I think you make a great point, as I've kind of learned and try to share about psychological safety.

I'm going to drop another Simpsons reference. This idea that you can't fix fear by telling people not to be afraid, I think that's important. I'm reminded of, it's the Phil Hartman, oh my goodness, late afternoon brain cramp. The actor, you might remember me from such films as… Troy McClure. In one of those “you might remember me from,” it was like, “From such educational films as something or other,” and, “Get confident, stupid.” I'm sorry. I just wanted to throw that in there for no other reason.

Saying, “Hey, don't be afraid,” it makes to me about as much sense as saying, “Get confident, stupid.” We'll put aside Troy McClure. So tell me why you can't fix fear by telling people to be brave or to not be afraid.

Elisabeth Hendrickson: Because they think you're lying.

Mark Graban: So say more about that.

Elisabeth Hendrickson: “Oh, it's perfectly safe. You should be brave. Say what you really think. Oh, you're fired. You disagree with me.”

People, especially in today's job market, which is kind of, well, beyond weird, and it's terrifying for people who, especially if they're in a situation where they simply cannot afford to lose their job. They're already going to be approaching any situation with a fair amount of caution. I'll use the word caution. And then you layer on top of it a perception that leadership says one thing and behaves a different way.

And what you will end up with is people who have no malice in their hearts whatsoever, but they definitely have self-preservation in their hearts, which is completely understandable and fair.

Mark Graban: Yes. That is, you know, and that's why I don't like when others frame it around, like, you need to be courageous. Like, no.

Elisabeth Hendrickson: No.

Mark Graban: People are holding back because they suspect, they have a hypothesis, or they know from what they've experienced or what they've seen happen. They tell me I should feel safe to speak up. I know it is, or I fear it is not safe to speak up. And that's why it comes back to leadership and what you stop doing and what you do more of. You can't just go and say, “Oh, well, tough job market. We're going to filter out and hire uniquely brave people.” Well, it's like, good luck with that.

Joel Tosi: I mean, the whole reason why you're saying you can't just tell somebody to be confident, or it's safe here, be confident and be brave. It's a system, right? Our ability to feel confident is a function of our system of ourself, which has signals based upon the signals we're receiving around us and the organization as well as the market, as Elisabeth was saying.

And so you can't just say, therefore, be confident, and that overrides all of the other signals, right? The best thing you can do is create the environment where safety becomes something that we aspire to.

Closing Thoughts: Everyone Has Levers

Mark Graban: Yeah. So, Signals and Levers, that's the book. In some parts of the world, people might say signals and “lee-vers.”

Joel Tosi: Yes, that's happened already.

Elisabeth Hendrickson: Yes, it has. That's fine.

Mark Graban: Would also be okay. The book is Signals and Levers: Systems Thinking Tools to Unblock Software Delivery. Elisabeth Hendrickson, Joel Tosi. This has been a lot of fun. It's fun kind of riffing on these things.

And if I don't know some of these things, at least I know early Simpsons seasons. A less useful skill, perhaps. Thank you for entertaining my detour with a laugh. But let's bring it back to the serious point at hand. When I'm being interviewed, I hate this moment, but I'm going to put the pressure on you because I'm the host.

What one insightful thing would you like to say before we wrap up, to leave the audience with? Joel's pointing at Elisabeth. I'm sure you both have something to say, but it's really an unfair question.

Elisabeth Hendrickson: I think it's a perfectly fair question. It is completely reasonable that you're asking it. The pressure, of course, is to leave the audience with something actually useful to them as opposed to whatever is flitting through my brain at the moment.

Mark Graban: I have a hypothesis that you can do this, though.

Elisabeth Hendrickson: Well, the thing I want everyone to know is that, whatever position you find yourself in, you always have levers.

So we tend to think of levers as things that are only accessible to leaders who have positional authority. They have the ability to determine hiring, performance, team staffing, et cetera, all of the policy levers. But everyone has levers, just simple actions like deciding whether or not to attend a meeting or thanking a colleague.

All of those are examples. Now, don't y'all get manipulative with this because that is not the point.

Joel Tosi: A different lever.

Elisabeth Hendrickson: Yeah. And not one that I endorse. But the point is that you have the ability to influence any environment you find yourself in, and so the concept of signals and levers applies to you, whether you're in leadership officially or not.

Joel Tosi: That was wonderful.

Mark Graban: That was. Joel, I'm pretty confident that you could…

Elisabeth Hendrickson: You could top me, man.

Mark Graban: You get the last word.

Joel Tosi: Yeah, I know. Now I feel bad for pointing. I should have pointed at myself and set the bar. Elisabeth set the bar too high. What I would say is systems thinking, at least in the software space, it might have felt hard to start with. Or made sense in theory, but now what do I do with it? I think through, not just with the book, I think systems thinking is something a lot of people do intuitively.

Sometimes we don't think about it because we're in a rush, and so it's just, I've got to fix this problem and put out the fire.

But Elisabeth and I have worked with enough teams and organizations where even if we just ask them, like they're making a decision, and we ask them, “Well, what else are you considering around this decision?” And they'll talk about five or six other things that this decision will influence.

And then you ask them, “Well, what else is influencing those things?” And so people are naturally thinking inside systems, it's just the intentionality around saying we can actually make better decisions if we just take that extra minute and see it together, see the same reality together. And one thing that Elisabeth and I would love to say is, act where the pain is caused, not where it's observed.

I think that's a really nice thing that we can be thinking about. If we want to do improvement, we should act where the pain is caused and not just where we're seeing it pop up.

Mark Graban: Yeah. All right. Hey, well done, both of you. Thank you. Fun conversation. Thank you for sharing insights and thoughts from your experiences and the new book, Signals and Levers.

Everyone check out the link in the show notes, and hope you will check it out. I enjoyed the preview, and even as a non-software guy, there are some of these stories I think resonate. You put yourself in the shoes of the stories and the situations.

And so I encourage people to go and check it out. And if it's not for you, give it to a software person you know. So Joel, Elisabeth, thank you. Thank you so much for being here.

Joel Tosi: Thank you.

Elisabeth Hendrickson: Yeah, thank you so much.