Questions Asked Since the Book Launch
7 min read
Since the book’s release, many of the same questions have come up about why I wrote Profitable Engineering, what shaped its message, and what I hope readers take from it. The following 10 questions reflect those conversations.
Questions Asked Since the Book Launch
| 1. The belief I had to unlearn: Early in your career, what did you believe about engineering leadership that you eventually realized was wrong? I believed that if we built better engineering teams, hired great people, and adopted better practices, the results would naturally follow. I probably would have argued that pretty strongly at the time. Over the years, though, I worked with incredibly talented engineers who built quality software, yet the organizations still struggled to produce meaningful business results. Projects slipped. Priorities changed constantly. Teams became frustrated. Leadership questioned engineering’s effectiveness even though everyone was working incredibly hard. Eventually, and honestly, it took me a while to fully recognize this, but I realized engineering was not always the constraint. Leadership was. I do not mean that individual leaders were necessarily incapable. I mean leadership as the operating system surrounding engineering. Decisions about priorities, funding, structure, incentives, governance, and accountability shape what engineering teams can accomplish. That realization changed how I led. It also became one of the main reasons I wrote the book. |
| 2. When faster delivery stopped being enough: Was there a moment when you realized the industry might be solving the wrong problem? There was not one dramatic moment. It happened gradually, through years of acquisitions, rapid growth, platform modernization, organizational change, and, frankly, seeing the same problems recur under different names. Every few years, our industry introduced another solution. Agile. DevOps. Cloud. Platform engineering. Now AI. Each one genuinely improved something, so I am not dismissing any of them. But I kept coming back to the same question: If we are getting better at delivering software, why are so many organizations still struggling to produce better business results? At some point, I realized we had become very good at improving the movement of work without always asking whether the work should have been done in the first place. That is where the book’s central idea began. “Work has to move. But it also has to matter.“ |
| 3. Connecting Flow with Realization: You frequently connect Flow with Realization. What do those concepts mean, and why must leaders consider them together? Flow is about how effectively work moves through an organization. Realization is about whether that work produced a meaningful outcome. Most organizations measure Flow in some form. They track how long work takes, how frequently software is released, how much work is completed, and where delays occur. But Flow tells only part of the story. The harder question is whether the work improved the customer experience, strengthened the business, increased revenue, reduced cost, lowered risk, or advanced the company’s strategy. That is Realization. I do not think I appreciated the gap between the two early enough in my career. We could celebrate faster delivery without returning later to ask whether the expected value was actually achieved. The strongest organizations I have seen intentionally connect delivery efficiency and business outcomes. |
| 4. Measuring what matters:If outcomes are so important, why do so many organizations struggle to measure them? Outcomes are inherently more difficult to measure because they are lagging indicators. The feedback often arrives weeks or months later, making it harder to connect engineering work to customer and business value. Organizations that have developed a strong measurement discipline find output metrics much easier to collect because they are immediate and visible. We have become very good at tracking throughput, lead and cycle time, deployment frequency, change failure rate, cost, and now even AI token usage. Those metrics matter, but they mostly tell us what moved through the system. Outcomes often take longer to appear. Customer adoption, revenue, cost savings, and risk reduction may not become clear for weeks or months, which makes them harder to connect back to the work. Additionally, outcomes still need to be quantifiable. Leaders should ask: What should improve, by how much, and over what period of time? I don’t consider a deliverable done until we have documented that outcome feedback and closed the loop. Outputs tell us what we produced. Outcomes tell us why we are doing something, the purpose, and then whether it mattered. |
| 5. What the existing conversation was missing: Many books already address Agile, DevOps, product management, and value streams. What did you believe still needed to be said? A lot of great books explain how to improve engineering, and many of them have influenced how I lead. What I wanted to explore was why organizations can adopt those practices and still struggle. In my experience, engineering rarely fails because engineers do not know how to build software. More often, they operate within a system that makes success unnecessarily difficult. There may be conflicting priorities, constant interruptions, unclear accountability, too much work in progress, or incentives that reward activity rather than outcomes. Engineering teams usually inherit those conditions. They do not create them. That is why Profitable Engineering focuses less on introducing another methodology and more on the leadership system surrounding the work. |
| 6. AI amplifies the system: How does AI change or reinforce the argument behind Profitable Engineering? It reinforced it. AI will change how software is built. It will improve productivity, automate portions of the work, and influence how teams are structured. AI raises the importance of leadership. “Technology tends to amplify the system in which it operates.“ In a strong system, AI can accelerate value, learning, and Flow. In a weak system, it can accelerate confusion, risk, waste, and the production of work nobody really needed. I sometimes hear people talk as though generating more code faster is the goal. It is not. The goal is to solve the right problems and create meaningful value responsibly. AI makes judgment and accountability more important than ever. |
| 7. Leadership is the operating system: Why does leadership sit at the center of the book? Leadership shapes nearly every condition in which engineering operates. Leaders decide what gets funded, what gets prioritized, how success is measured, and how much work enters the system. They also decide whether teams have room to learn, whether technical debt is addressed or repeatedly deferred, whether people can raise concerns, and whether engineers are trusted to contribute beyond writing code. Those decisions often have more influence on engineering performance than any individual framework or tool. That is why I believe engineering excellence is ultimately a leadership outcome. Leadership creates the conditions that allow engineering to thrive or cause it to struggle. |
| 8. The meaning behind the cover: What inspired the book cover? I never explain it explicitly in the book. For much of the first half of my career, engineers were often treated like cogs in a machine. The prevailing mindset was essentially: tell them what to build, leave them alone, and expect them to write code. Ironically, that sounds a lot like how some organizations are beginning to think about AI today. I remember sitting in leadership conversations where people were not really talking about human beings. They were talking about resources, capacity, utilization, cost, and availability. Move this resource here. Shift that resource there. Add lower-cost capacity somewhere else. That was common language at the time, and I used some of it too. But psychologically, it always bothered me. These were people who wanted to solve problems, contribute, and know their work mattered. People want purpose, mastery, and autonomy. They want to understand the problem, participate in the solution, and see how their work creates value. |
| 9. The chapter that brings it all together: Do you have a favorite chapter? It’s a toss-up between chapters 8 – Culture, 9 – Economics, and 12 – Journey. I’ll pick Chapter 12, “Your Journey Starts Here,” as probably my favorite. During the final revisions, I even considered moving it earlier because so much of the book comes together there. Ultimately, I decided readers needed the earlier chapters first. That chapter connects Flow, Funding, Realization, and AI through the Value Stream Convergence Model. It also moves the discussion from ideas to action by asking what leaders can begin doing differently on Monday morning. I sometimes joke that readers have to earn their way to Chapter 12. But once they arrive, I hope it feels less like the end of the book and more like the beginning of their own journey. |
| 10. The idea I hope readers remember: If readers take only one idea from Profitable Engineering, what do you hope it will be? “Software engineering exists to create value, not simply software.” For decades, we have become increasingly disciplined about measuring delivery. That was necessary, and it has helped many organizations improve. Now we need to become equally disciplined about determining whether that delivery mattered. The organizations that lead the next decade will not necessarily be the ones producing the most code or releasing software the fastest. They will be the ones that consistently connect engineering decisions to customer outcomes, business performance, and long-term organizational health. When leaders connect Flow with Realization, engineering stops being viewed primarily as a cost center and becomes one of the organization’s most strategic capabilities. |
Faster delivery alone is not the destination. Leaders must understand whether the work created value and build the conditions that allow teams to connect delivery with meaningful outcomes.
That is the conversation I hope Profitable Engineering continues.
I would value hearing which ideas resonate, challenge your thinking, or reflect what you have experienced in your own organization.
Profitable Engineering is available now in paperback and hardcover through Amazon, Barnes & Noble, and other major and independent booksellers. The Kindle edition is also available, and the audiobook is currently in production.
For more information, please visit the website: https://profitableengineering.com
Connect on LinkedIn: https://www.linkedin.com/in/philclark/