The Dao of Delivery
A FIELD MANUAL for CTOs (and the CEOs who rely on them)
Introduction
For the past decade, I’ve been called in to fix engineering organizations that were struggling. Each turnaround taught me something new about what breaks delivery and what I had been doing wrong in my own leadership journey. I called this book the “Dao of Delivery” because it’s about developing the judgment to know when methodology matters and when it does not. However, I could have just as easily called this book “Eric’s Litany of Failures,” because that’s what it really is: thirty years of painful lessons learned without a mentor, distilled into the lenses I wish someone had taught me earlier.
Those lessons didn’t come easily. The productivity improvements and successful transformations emerged only after years of making every mistake in the book. The lenses here don’t spring from natural talent or brilliant insight, but from the political, emotional, and cultural dynamics that repeatedly humbled me until I finally learned to pay attention to what actually matters in leadership.
This pattern isn’t unique to me. Engineering leaders fail a lot. Sixty percent of new managers fail within 24 months, and in engineering specifically, about half eventually return to individual contributor roles (First Round Review, 2021; Arruda, 2023). Those failure statistics only capture the obvious collapses. They miss the soft failures that are more insidious and painful: managers who are just effective enough to keep their jobs but not effective enough to deliver reliably. The causes aren’t technical. They are failures in planning, people management, and adapting to the reality of a messy system composed of people (Pinto and Mantel, 1990; Herz and Krezdorn, 2022).
Most of us who struggle with delivery aren’t incompetent. We optimize for the wrong things. Process gets most of our attention, while the real drivers of delivery are ignored. Reliable delivery depends on shifting factors like stakeholder relationships, team dynamics, technical debt, communication patterns, resource allocation, and timing. Their importance changes constantly with context, and learning to read those shifts is brutally hard.
It’s natural to reach for methodology fixes. They feel concrete, safe, and measurable. A new framework gives us steps to follow and creates the impression of progress. I’ve reached for them myself more times than I can count. But delivery challenges almost never live there. They are system problems, which means the real work is learning how to read the shifting variables and recalibrate, over and over again.
That’s where many of us fall into the trap. We copy a method that made another company famous, hoping it will rescue us. Or we borrow something that worked for a colleague without asking whether our own team has the capacity to sustain it or the resilience to face the pushback. Almost inevitably, it doesn’t work. The approach doesn’t fail because it’s bad. It fails because methodology alone is never enough. The real test is whether we’ve developed the judgment and steadiness to know when to apply a method, how much weight to give it, and when to move on.
This is why I focus on developing judgment rather than providing another methodology.
This book is called The Dao of Delivery, not The Laws of Delivery, because leadership inside organizations is never fixed. It’s a living system, always shifting. The Dao represents a way, a living path that adapts to what’s in front of you. There are no universal laws. At best, there are lenses, ways of seeing, that help you decide what matters most right now and how to act with balance and proportion.
Nothing here works 100% of the time, in every context, for every organization. Many books promise a magic bullet. They describe a process or framework that once fueled a company’s success, then hold it up as cure-all. But those were snapshots of a moment at that company, with that leadership, and that culture, at that time. Some of those ideas may serve you well, and if they do, use them. But you shouldn’t expect them to, because leadership is fundamentally dynamic.
It never becomes easy. Leadership always resists simplicity. Every decision touches people’s lives, organizational momentum, and the credibility of the leader making it. But the struggle is not pointless. Over time, you grow steadier. You learn how to carry the weight without being crushed by it and how to protect others from being crushed as well.
The reward of developing that judgment is not perfect freedom. No leader ever has that. Constraints, politics, and trade-offs are constants. What changes is your posture. You gain freedom from anxiety, because you know how to read the system in front of you. You stop chasing the next process fix hoping it will save you. Instead, you develop steady confidence in your craft. You can experiment without fear, navigate resistance without panic, and adjust as circumstances shift.
These lenses focus on what actually drives delivery: stakeholder dynamics, team capabilities, organizational momentum, and the discernment to know when methodology matters and when it does not.
I wrote this book for technical leaders, CTOs and VPs of Engineering, who are responsible for delivery but can’t figure out why their teams miss deadlines, stakeholder relationships sour, and process improvements fail to stick. My focus is on developing leadership judgment through better ways of seeing organizational dynamics, not on providing step-by-step methodologies. You’ll find lenses for understanding political capital, team dynamics, and organizational momentum. These are tools for discernment rather than recipes to follow. If you treat them like recipes, you won’t get as much out of them as you should.
Throughout the book, you’ll also find callouts addressed to CEOs and other senior executives. These sections help non-technical leaders understand what’s really happening when engineering delivery struggles, when to intervene, and how to support their technical leaders in addressing root causes or symptoms.
When your technical leaders focus on process improvements, technical fixes, and methodology changes while delivery still struggles, they are avoiding harder leadership work. This signals gaps in political capital, emotional control, or organizational awareness that no technical solution can fix.
Consider whether they’re proposing new frameworks and tools while stakeholder complaints persist. Are they blaming methodology instead of team dynamics or communication failures?
Your response depends on context and urgency. If delivery isn’t business-critical, you can afford patience. If you see genuine potential and have capacity to invest, coaching might work. If the business needs reliable delivery now, replacement is your only option. What you must not do is wait for methodology alone to solve what is, at its heart, a leadership problem.