About This Book

Modified

May 22, 2026

Who should read this book

This book is for people who own delivery outcomes they cannot personally produce.

That means CTOs, VPs of Engineering, and engineering directors in organizations where the gap between what the business needs and what engineering delivers is the central tension of the job. It means engineering managers running programs large enough that they depend on people they don’t directly control. It means technical founders who have crossed the line from building to leading and found that the skills that got them there aren’t the skills the next stage requires.

It also means CEOs and other senior executives who manage technical leaders and want to understand what’s actually happening when engineering delivery struggles. Throughout the book, brief callouts addressed directly to CEOs translate each lens into business-outcome language. If you manage a CTO or VP of Engineering, these sections will help you evaluate what you’re seeing and decide when to intervene.

This book will not help you if you want a recipe. The lenses here are ways of seeing, not steps to follow. If what you need is a checklist, a maturity model, or a named methodology, there are better books for that. This one develops the judgment that makes those tools useful — or tells you when to set them down.

It will not help you if your problem is primarily technical. If delivery is stalled because the build pipeline takes ninety minutes, or because the data model genuinely cannot support what the business is asking for, fix that first. The lenses in this book are about everything else.

It will land best if you have your own war stories. The chapters work by giving you language for dynamics you’ve already lived through. The more experience you bring, the more will activate. Readers early in their first leadership role will find the ideas interesting; come back in two years and they will read as obvious.

How this book is organized

The book opens with a framing chapter and then moves through five parts. The parts follow a logic: the most immediately actionable work first, the deepest and slowest-to-change last. The chapters within each part are largely independent — you don’t have to read in order, and most readers will get more value from picking the chapter that names the problem currently in front of them.

Chapter 1: The Lens, Not the Law

Introduces the book’s organizing distinction — the difference between a lens that reveals cause and a framework that prescribes action — and walks one delivery scenario through five lenses to show how each reveals something a process fix would miss.

Part I: The Alchemy of Self

The most immediately actionable work in the book is also the cheapest: it requires no budget, no organizational approval, and no structural change. It requires only that you look clearly at what you are actually doing and what it is costing. Part I covers the four lenses that operate on you before they operate on anything else.

  • The Economy of Political Capital — Political capital works like a bank account with each stakeholder. They decide what counts as value. Hit zero and technical correctness won’t save you. This chapter covers how to earn it, spend it, and recognize when you’re about to run out.

  • The Blub Paradox — High-leverage work is persistently misperceived by the people who need to fund it. This chapter explains why, and what you can actually do when the people you need aren’t yet able to see the value of what you’re proposing.

  • The Thermodynamics of Emotional Intelligence — Frustration is a diagnostic signal, not a state to suppress. This chapter is about learning to detect your own emotional state before it has traction, and using it as an early warning system for organizational dysfunction.

  • On Being a Good Soldier — The discipline of subordinating ego to mission. Ego is the tax that runs on top of everything in Part I. This chapter gives it a direct examination: what it means to act in service of something larger than your own preferences, and where that discipline — taken too far — becomes abandoning judgment entirely.

Part II: The Alchemy of Organization

Once you can see your own defaults clearly, the question is where to push. Part II covers the four organizational levers — strategy, structure, people, process — in order of leverage, and closes with the judgment that makes them useful.

  • Strategy: The Decision-Making Razor — What makes a strategy actually useful as a decision-making tool — and how to recognize the kind that looks like strategy but can’t cut anything.

  • Structure: The Architecture of Delivery — Organizational structure determines what’s possible before anyone shows up to work. This chapter covers how to design it deliberately and how to navigate the realities you inherited.

  • People: Gardening Your Teams — Growing people, matching them to the work they’re ready for, and pruning when you must. The patient, non-linear work that no other lever can replace.

  • Process: Outcomes Over Rituals — Process is a means, not an end. This chapter is about designing process that serves actual delivery rather than the performance of delivery.

  • The Art of Judgment — The four levers above require a disposition underneath them: the willingness to make the call that the situation demands, not the one that’s most comfortable.

Part III: The Alchemy of Time

Every transformation happens in time. Part III addresses the three ways time defeats you if you don’t understand it: the unknowable path, the relentless movement of the clock, and the momentum that cannot be rebuilt once destroyed.

  • The Unknowable Path to the Knowable Destination — You cannot know the route in advance. You can only commit to the destination and keep moving as the paths close. This chapter is about holding that discipline — committed to the destination, flexible on the path — without collapsing one into the other.

  • Harnessing the Relentless Movement of Time — Time moves whether you’re ready or not. This chapter is about threading long-term progress into short-term work so that urgency and importance stop competing.

  • The Conservation of Momentum — Every pivot and redirect doesn’t pause your team’s velocity. It destroys it. This chapter covers the invisible cost of direction changes and how to calculate it before you commit.

Part IV: The Laws of the System

Some things cannot be transformed. They can only be understood and worked within. Part IV names the three organizational laws that apply regardless of intent, effort, or urgency.

  • The Bones of Growth — Organizations develop real capability through specific conditions, not through pressure. This chapter names those conditions and explains why effort without them compounds into exhaustion rather than capability.

  • The Essential Work of Becoming Unessential — Every leader who successfully builds something eventually becomes its bottleneck. This chapter is about building toward your own obsolescence — and why that is harder than anything that preceded it.

  • The Inevitability of Inclement Weather — Some storms you inherit. Some arise on your watch. Knowing the difference changes how you respond, what you owe the team, and what you can honestly tell stakeholders.

Part V: The Laws of Self

The laws that govern organizations operate on what you build. The laws of self operate on you. Part V closes the book with the three dispositions that underlie every other lens — not skills to acquire, but disciplines to practice, lose, and relearn throughout your career.

  • The Principle of Right Action — Leadership ethics aren’t about choosing between right and wrong. They’re about navigating competing obligations when law, regulation, company standards, and personal conscience don’t align. This chapter addresses the gray that most leadership books skip.

  • The Discipline of Stillness — The hardest decisions don’t resolve through direct analysis. They resolve when you create space for a different kind of thinking. This chapter is about building that space deliberately rather than optimizing it out of existence.

  • Who You Must Be Now — The presence a leader projects is not private. The room reads you. This chapter examines presence as a deliberate choice, what it costs when you abdicate it, and what it takes to make the choice repeatedly, under conditions that make it hard.

About the examples

The anecdotes in this book are drawn from real events. The individuals and organizations involved are anonymized and not identifiable. In cases where several similar situations reinforced the same lesson, I’ve sometimes compressed them into a single account. The dynamics are real; the details are protected.

liveBook discussion forum

Manning maintains an online forum where readers can comment on the book, ask questions, and receive responses from the author. The forum is accessible at liveBook. Manning’s commitment to our readers is to provide a venue where meaningful dialogue between readers and author can take place. It is not a commitment to any specific amount of participation on the part of the author, whose contribution to the forum remains voluntary (and unpaid). We suggest you try asking the author some challenging questions lest his interest stray!

About the author

I grew up poor in rural central Florida, in a world where college wasn’t assumed. School bored me, and I dropped out a few weeks before high school graduation — I needed extra credits and couldn’t summon the energy to care. The GED proctor who handed me my scores told me they were the best he’d ever seen. “You’re going to college, right?” I wasn’t. College wasn’t in my world.

I bounced around for a while before landing a job answering phones at an unsaleables company doing reverse logistics for retailers. My manager saw something and offered me data work on the side. One day he came to me with a proposal: the company was adopting something called Lotus Notes, and he thought he could get me a developer license if I was willing to learn it.

“Buy me a book,” I told him, “and we’ll see.”

He bought the book. I taught myself from nothing, and something clicked. That was my first taste of building. I did that for a few years before following the same deal — buy me a book — into Java. Java led me to discover there was an entire field called computer science I’d never known existed. I fell into it completely. For the next five years, nights and weekends, I studied lambda calculus, programming language theory, distributed systems. The most intellectually alive I’d ever felt.

That self-directed education eventually carried me to Amazon, where I spent an all-day interview and got the job. I think of that day as defending my thesis — proof that a kid from central Florida with no degree could compete at the highest levels of the industry. I landed on a small R&D team working on problems that produced patents and taught me distributed systems at a depth I couldn’t have gotten anywhere else, then moved into Amazon’s large-scale build and deployment infrastructure in the early 2000s — deploying and managing software across tens of thousands of servers, doing things that wouldn’t become common practice for another decade.

I eventually left Amazon and spent the next ten years doing distributed systems work across several companies. What I didn’t expect was how much I’d learn about organizations. Almost every engagement involved building new teams. I made a lot of mistakes. And I started to notice a pattern: we rarely failed for technical reasons. When things went wrong, the cause was almost always communication, or incentives, or structure, or politics.

That decade culminated in Erlang and OTP in Action, a book on building distributed systems at scale. It marked a transition point. I went from someone who was doing the work to someone who was also teaching it.

But the pattern kept nagging. If the failures weren’t technical, being a better technologist wasn’t going to fix them. So I moved into leadership.

The transition was hard. I came in at the director level, which meant I’d skipped all the lessons you learn by growing into the role. I learned them the hard way instead — through mistakes, through being wrong more often than I expected, and eventually through a more useful kind of humility. The engineering version of “right” is not actually right. Real decisions require weighing risk, probability, context, people, and politics. I thought I understood that before I led organizations. I did not.

In my current CTO role, I inherited an engineering organization delivering roughly one new feature every two months. Within a couple of years, we went from twenty deployments a month to hundreds. We solved problems that had been dragging on the business for years, and revenue started growing again. We did it with fewer people than we started with. That turnaround didn’t come from better technology. It came from teams that understood they are the business.

The Dao of Delivery is the book I wish someone had handed me before I started.