In Extreme Programming Explained (right at the start of Chapter 5, “Cost of Change”), Kent Beck asked a deceptively simple question: “What if the cost of change didn’t rise exponentially over time, but rose much more slowly, eventually reaching an asymptote?”

The question holds profound economic implications. If a change tomorrow costs essentially the same as a change today, there is no penalty for delaying a decision. You can start with the simplest thing that could possibly work, and only make further investments when signals from actual customers—not just opinions—show that it’s needed. Whenever additional complexity starts creeping in, you can invoke the principle of YAGNI: You Aren’t Going to Need It. You don’t have to commit to an approach; you can learn as you go.

That was back in 1999. Today, the promise of AI opens a new line of questions about software economics: What if the time and cost of writing code shrinks to almost nothing?

Yes, we’re in the middle of a hype cycle and actual outcomes have been mixed. You might be skeptical, and rightly so. Perhaps you’ve seen too many instances where AI took indefensible shortcuts, and obsequiously responded “You’re right to challenge this…” when called out on its mistakes.

But suspend disbelief for a moment. What if the promises were real? What then?

If 1K lines of code costs just pennies in tokens, experimentation becomes absurdly cheap. Can’t figure out how to crack that gnarly technical problem? Take 100 runs at it in parallel. Unsure what features real users will actually use? Build them all and collect telemetry. Historically struggled with a flood of demands on engineering’s incredibly limited capacity? Code isn’t a constraint anymore.

And then what? There’s the rub.

Just because experimentation becomes incredibly cheap doesn’t mean your customers will appreciate the thrash of a rapidly changing user experience. Just because you can collect near infinite telemetry data doesn’t mean you’ll be able to turn all that data into actionable insights. At a certain point, an overwhelming amount of data makes even legitimate signals feel like noise. For that matter, just because initial development costs pennies doesn’t mean that maintenance or operations are cheap. Keeping production systems up and running can be expensive.

Every solution—no matter how powerful or good—brings new problems. Software delivery remains a non-linear, socio-technical system. You poke the system and the system pokes back. More code doesn’t guarantee more value.

When we wrote Signals & Levers, we avoided talking about AI. It gets a short mention at the beginning of the book and again at the end of the book. But in between? No mention. Our editors and early readers asked us about that: Why would we ignore the thing that is radically transforming software development right now?

The answer is that we believe systems thinking is evergreen, and we didn’t want premature declarations about the nature of AI’s impact to limit the shelf life of our book. And we were right. When we started this book two years ago, AI was essentially a powerful auto-complete. Now you can unleash fleets of agents to build entire systems nearly unsupervised, and those systems actually work. (There are some big caveats about what has to be true in your system to see those kinds of results, but that’s a topic for another day.)

The thing that hasn’t changed, and won’t change, is that if you want to take advantage of the full power of AI, you have to understand your system. AI is poking the system. Systems thinking tools can enable you to see how to get the most out of it within your context, and anticipate the ways in which your system will poke back.

It was one of those meetings. We were supposed to be figuring out what to do about an initiative that had gone off track. The debate had been going in circles with no signs of stopping. I glanced at the clock. We were already over time. I sent a message to the chat: “Sorry! Gotta drop.” I didn’t even have another meeting; I just couldn’t take it anymore. We weren’t getting anywhere.

Sound familiar?

It took me a while to put my finger on why the conversation was so unproductive, but once I did it seemed so simple. We’d skipped the basics. We hadn’t agreed on what we were trying to accomplish, and we didn’t have the same perspective on the current situation. That meant everyone had come in with their own ideas for how to get things back on track, but no one agreed on what “on track” actually meant in this context.

We needed to answer three foundational questions.

Where are we trying to go? We had goals for the initiative, but things weren’t going to plan. Something had to give. So what did we want to prioritize? Was it more important to deliver all the promised capabilities? Adhere to the schedule? Ensure that we were setting ourselves up for success for future deliveries? Stick to the process we had agreed on? The conversation would have been more productive if we had centered it on the outcomes we wanted.

Where are we now? Everyone had their own perspective on the current situation and instead of sharing information, people were pointing fingers.

You’re moving too slow.
You gave us unclear requirements.
That is an excuse.

The points people were raising reflected their judgments and conclusions, not the raw data they were drawing on. What was completed so far? What had we learned? Where were the remaining hurdles? We needed a shared, objective view of the situation based on empirical evidence, not opinions. We needed to see the same reality.

What are all the ways we can get from here to there? Our circular debates stemmed from circular thinking. Problem: we lack clear requirements. Solution: get clearer requirements. Even if we had clearer requirements, we couldn’t deliver the initiative according to the original plan. Instead of getting locked into position-based arguments, we needed to explore all the paths from where we were to where we wanted to be.

A cartoon from Chapter 11 of Signals & Levers that illustrates the difference between problems and solutions.

If we’d been seeing the same reality and agreed on where we wanted to go, we could have treated all the ideas about how to get there as hypotheses. We didn’t have to agree on one approach. We could have tried several, and we could have treated each one as a small experiment. That reframe is the essence of what Signals & Levers Chapter 11, “Hypotheses in Change,” is all about.

So the next time you’re trapped in a meeting that’s going nowhere, consider asking the three questions: Where are we trying to go? Where are we now? What are all the ways we can get from here to there? That might just be enough to cut through the circular debates and lead to a productive discussion.

In the Signals & Levers Introduction, you meet Theresa, VP of Engineering at Limitless Systems. (Fun fact: Limitless Systems exists in the same fictional universe as Parts Unlimited from The Phoenix Project. We had such a blast inventing details about the company that we built a whole company website complete with a spoof ad spot for April Fools. Our book blends fiction and non-fiction, but definitely had a lot of fun with the fictional aspects of the book. But I digress.)

At the beginning of the book, Theresa is anticipating an on-time delivery of the latest release. Alas, her confidence was based on metrics that didn’t tell the whole story. She was under the spell of illusions. That happens. Who among us hasn’t had the stomach-dropping experience of discovering that all our plans and expectations were incompatible with reality?

So how do you see past the mirage? Signals & Levers offers a wide range of system thinking tools to help you do just that, but here’s one you can start doing today. Ask yourself:

“If that were an illusion, how would I know?”

On the surface it seems like a simple question, but answering it honestly and deeply requires you to examine not only the information you’re working with but your approach to gathering information and decision-making.

Consider the story of a CEO who asked himself that question about an ongoing initiative to replace the company’s ERP system. All the status reports painted a rosy picture of on-time delivery, but this was a high-risk, high-stakes project. Perhaps mindful of the Hershey’s ERP disaster, he knew that he couldn’t afford to succumb to illusions. He didn’t ask for more, different reports though. He went to see the workers—not the managers, the people doing the actual work. He asked them face-to-face: how’s it going? Is this going to work? Should we trust this system to run our business?

You can imagine the uncomfortable silences and foot shuffling that followed his questions. It is perhaps a testimony to his leadership that the people who were up to their elbows in the migration were willing to be honest with him. They shook their heads: No. Things weren’t going smoothly. They would not be ready on time.

The CEO decided to delay the switchover. Instead, he ran the new ERP system alongside the existing one. That decision came with a cost: all the data had to be entered twice. But by running both systems side by side, they could compare results over a period of months. His decision paid off: they discovered surprises that would have caused their own Hershey’s-like incident.

The thing I loved about that CEO’s story was that it was a true gemba walk. He went to see the people doing the work, and in doing so he had access to signals he otherwise would not have.

How could you do something similar?

Maybe you aren’t in a situation where you could go and see, but you could still talk to people closer to the work. Maybe different metrics could give you a new perspective. Or perhaps you could design small time-boxed experiments.

Whatever approach you take, the key is to keep asking: If that were an illusion, how would I know?

Someone recently asked us, “Why this book? Why now?”

It’s a great question. We’ve known each other since 2010 when Joel was instrumental in bringing me in to work with his employer at the time. We kept loosely in touch, but writing a book together wasn’t on our respective bingo cards even three years ago.

Joel had been developing a systems thinking workshop. He saw the way organizations struggled when people with the best intentions try to control a system with linear cause-effect thinking.

At the same time, I had been building a simulation showing the effects of decisions on overall software delivery. I wanted a way to help leaders explore the consequences of decisions in seconds rather than months.

When Joel saw a video that I posted about the simulation, he reached out to ask if he could use it in his workshop. I was thrilled for my passion project to have found a purpose and immediately agreed. That led to us co-developing a new version of Joel’s systems thinking workshop around the simulation.

Our work co-developing the class showed us that for many, systems thinking felt abstract. As we developed more exercises and ways to explain the concepts, people told us that for the first time systems thinking felt more concrete and approachable. The book was a natural extension of the class, enabling us to help even more people use these tools to make sense of what is happening in their organization, make better decisions, and shape their context.

It took us two years from the time we said “this might be a book…” to the time we turned the final manuscript in to IT Revolution. We didn’t plan the timing: It was sheer luck that we finished the book just as our industry is in a state of upheaval, making systems thinking tools more important than ever before.

We hope you find the book helpful in understanding your context, reasoning about the influences within your system, and helping others see what you see.