9 Books I Wish Every CTO Had Read
Table of Contents
This is not a list of my nine favorite books.
It is also not a ranking. Ranking them would miss the point: the value is not inside any single book. The useful part appears between them.
One book explains how people express what is really going on. Another shows how organizations hide problems behind management frameworks. Another turns DevOps into a thriller. Another brings evidence. Another asks why we still organize complex work as if it were a factory line. Another reminds us that excellence is not decoration, but an operating principle.
That is why I wish every CTO I work with had read them. Not because the CTO has to quote them in meetings, and not because everyone should apply every idea literally. I care about the shared baseline.
This also explains what is not on the list. The absence is intentional. There are many books about OKRs, scaling frameworks, management systems, strategy processes, and delivery playbooks. Some are useful in narrow contexts. But this list is not about adding another control mechanism to the organization. It is about understanding the organization as a complex system first.
Context
This article is my synthesis from many companies, industries, conversations, meetups, books, and observed patterns, written from a software engineer and architect’s point of view.
When we discuss a production bug, I do not want us to stop at the broken line of code. I want us to ask: why could this happen? Who owned the system? Which team had the context? Was the architecture visible? Was the work sliced across silos? Did someone notice the risk but not feel safe enough to say it? Did our metrics reward the wrong behavior? Did we outsource thinking to a framework?
Those are not separate questions. They are the same question seen from different angles:
What kind of organization do we build, and does it fit the complexity we ask it to handle?
The Map Behind the List
Software is complex. Markets are complex. People are complex. Organizations are complex. Then we put all of that together and act surprised that a certification, a dashboard, or a quarterly transformation program did not magically fix it.
I also do not use the word complexity casually here. My PhD was at an institute teaching and working with complex systems, so for me complexity is not just a way to say “this is hard”; it is a scientific research topic with different implications than complicated work.
Technical leadership therefore needs more than technical taste. It needs sensing: noticing what people are not saying, when a process hides fear, when a team is called autonomous but cannot decide anything important, when speed is fake because quality is accumulating debt, and when the system, not the person, is the problem.
These books build that sensing from different directions.
1. Nonviolent Communication
Marshall B. Rosenberg
The familiar book title is Nonviolent Communication: A Language of Life, the title most readers will recognize today.
At first glance this may look like the least technical book on the list. That is exactly why it belongs at the beginning.
Rosenberg’s work is about observations, feelings, needs, and requests. That sounds simple. In a company it is not simple at all. People usually do not say, “I have an unmet need for clarity, ownership, or trust.” They say, “the platform team is blocking us,” “product does not understand engineering,” “architecture is an ivory tower,” or “this team is not senior enough.”
The word compassion is often under-specified in business. It can sound like a mood, while in intense situations it needs a technique. Nonviolent Communication helps there: first to apply compassion to yourself, then to make it easier for others to respond with compassion, too, because you express what is actually missing instead of only transmitting pressure, accusation, or frustration.
A CTO does not need Nonviolent Communication in order to make every meeting soft and friendly. That would be a misunderstanding. The point is sharper: if people cannot express their true needs without being punished, the organization loses sensor data.
Conflict is information. Frustration is information. Silence is information. The question is whether the organization can receive it before it turns into politics, resignation, shadow work, or production incidents.
I learned during preparation for this article that Satya Nadella is often reported to have asked Microsoft’s senior leadership to read Rosenberg after he became CEO. That does not mean NVC caused Microsoft’s transformation, and it is not why the book is on this list. It means something more modest and more useful: communication culture is not a side topic. It shapes what the system can perceive.
For a CTO, this is the first layer of organizational physics. Before we talk about agile, DevOps, platforms, or architecture, we need to know whether the system can hear itself.
2. I’m Sorry I Broke Your Company
Karen Phelan
The full title is I’m Sorry I Broke Your Company: When Management Consultants Are the Problem, Not the Solution. It was published around 2012/2013, depending on format and catalog.
This book is funny because it is painful.
Phelan attacks the theater of management-by-framework: strategic planning rituals, performance systems, talent grids, process optimization programs, and consultant decks that make everything look clean while the real organization remains misunderstood.
The important lesson is not “consultants are bad”. That would be too easy. The lesson is that leaders often outsource thinking because frameworks feel safe.
A framework gives language. A framework gives slides. A framework gives the illusion that the hard part has been done. But the hard part is usually not the framework. The hard part is understanding this company, these people, these constraints, these customers, these silos, this history, and this market right now.
There is a trap here that I have seen many times. An external person interviews people across the organization, connects dots, notices where things burn, and then presents a generic model. Leadership buys the model, but the real value was the discovery work that happened before the model appeared.
The CTO lesson is uncomfortable:
If someone else understands your organization better than you do, the framework is not the asset. Their context is.
That does not mean leaders must do every interview themselves. It means they cannot delegate curiosity. If the leadership team does not build its own learning loop, it becomes dependent on packaged answers.
3. The Phoenix Project
Gene Kim, Kevin Behr, and George Spafford
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win was published in 2013.
It is well known enough that one could ask why it still needs to be on a list. My answer is simple: because the problems in it still exist.
The book works because it is not written like a clean method. It is written as a story about people trapped inside a broken system. There is pressure from the business, invisible work, too many priorities, fragile deployments, heroic individuals, late nights, fear, blame, and the strange loneliness that appears when everyone is busy but the organization is still not moving.
That is why it is useful for CTOs. It gives language for things that otherwise stay vague.
The Phoenix Project popularizes ideas around flow, feedback, continuous learning, visible work, constraints, and the different types of IT work. But the deeper value is emotional realism. People in broken systems often think they are the problem. Reading the story can be a relief: no, this pattern exists elsewhere, and yes, there are ways to reason about it.
The book is not empirical research. It is an allegory. That is fine. Some truths travel better as stories because people can recognize themselves before they defend themselves.
4. Scrum
Jeff Sutherland and J.J. Sutherland
The full title is Scrum: The Art of Doing Twice the Work in Half the Time, published in 2014. Jeff Sutherland co-created Scrum with Ken Schwaber.
The subtitle may sound provocative before reading the book or experiencing such teams. It should not be read as a guaranteed productivity equation. Still, I understand why Sutherland chose it.
Early in my career I experienced teams of roughly ten to twenty people delivering work that larger enterprise setups believed would require many times more people. Not because everyone worked nights. Not because there was magic. Because the setup gave the team real Scrum: ownership, feedback, focus, and room to remove impediments.
The useful Scrum idea is not the ceremony collection. It is the small cross-functional team, the short feedback loop, the visible backlog, the inspect-and-adapt rhythm, and the relentless removal of impediments. In other words: reduce distance between the problem and the people solving it, especially when the work is too complex to plan correctly in advance.
Many organizations say they do Scrum while preserving the old system around it. Teams get ceremonies but not ownership. They get sprints but no real ability to change scope. They get velocity but no autonomy. They get agile language wrapped around command-and-control behavior.
Then Scrum is blamed for what the organization refused to change.
For a CTO, this book is useful if read as a question, not as a recipe:
What would we have to remove so a team could actually learn fast?
That question connects directly to DevOps, platform thinking, team topology, architecture, and organizational design. Iteration only works when the team has enough of the system in its hands to close the loop.
5. Organize for Complexity
Niels Pflaeging
Organize for Complexity: How to Get Life Back Into Work to Build the High-Performance Organization was published in 2014.
This book makes one of the central distinctions in the whole list: complicated is not the same as complex. A watch is complicated. It can have many tiny parts, but if the plan is correct, the assembly can be repeated. A market, a product organization, and a software architecture evolving with customer behavior are complex. Like weather, you can observe patterns and forecast a bit, but you cannot predict the exact state weeks ahead. Planning as if you could is waste; you need iteration.
That is why Pflaeging’s work is so useful. He does not just say “make teams autonomous.” He gives a language for the whole operating system around that idea. The BetaCodex is a set of principles for organizing beyond command-and-control: Alpha is the old world of hierarchy, fixed targets, functional departments, planning, and managerial steering. Beta is the alternative: decentralization, transparency, relative targets, market pull, mastery-based decisions, and flow coordination.
The center/periphery distinction is especially important for CTOs. The periphery is where teams touch customers, users, incidents, competitors, and market reality. The center should serve that periphery instead of ruling it. Otherwise the people furthest away from the signal end up steering the people closest to it.
The cell metaphor is useful here. A cell is not a random person with a ticket queue. A cell contains what it needs to perform its function. It is autonomous enough to act, connected enough to belong to a larger organism, and close enough to the market to learn.
That is a much better way to think about engineering teams than the old split between business, product, architecture, development, QA, security, operations, and support as separate stations on a conveyor belt. It also explains why many scaling frameworks feel heavy: they try to coordinate around a structure that should perhaps be redesigned.
For a CTO, this book helps explain why many technical problems are actually organization-design problems. If ownership is sliced wrongly, architecture will show it. If teams cannot decide, delivery will show it. If feedback is delayed, quality will show it.
The system leaks into the code.
6. OpenSpace Beta
Silke Hermann and Niels Pflaeging
OpenSpace Beta: A handbook for organizational transformation in just 90 days was developed by Silke Hermann and Niels Pflaeging. The English handbook and method are commonly associated with 2018; German editions appeared later.
If Organize for Complexity describes why the old organization model fails, OpenSpace Beta asks how to move without replacing one management fantasy with another.
That is important because transformation programs often reproduce the exact disease they claim to cure. A small group designs the future organization, announces the rollout, trains everyone, tracks adoption, and then wonders why people are cynical.
OpenSpace Beta takes another route. It draws on Daniel Mezick’s OpenSpace Agility and Prime/OS pattern, rooted in Harrison Owen’s Open Space Technology, and combines it with BetaCodex organization ideas. The claim is not that ninety days magically solves every company. The claim is that change must be done with the people in the system, not to them.
That difference matters.
People do not resist all change. They resist being treated as implementation detail. They resist fake participation. They resist already-decided futures wrapped in workshop language.
The interesting mechanics are invitation and authorization. Leaders make the need for change explicit and authorize the organization to work on itself. A broad group creates the agenda, exposes tensions, proposes changes, and learns in public. External support protects the process, but does not own the answer.
A CTO involved in transformation should read this book not to copy the method blindly, but to understand the standard it sets: the organization itself can be iterated on, and the people doing the work must be part of noticing and redesigning the work.
This is where the book connects back to Nonviolent Communication. If people cannot speak honestly, open space becomes theater. If leadership cannot let go of control, Beta becomes branding. If the system cannot hear itself, transformation becomes a slide deck.
7. Accelerate
Nicole Forsgren, Jez Humble, and Gene Kim
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations was published in 2018.
This book matters because it brings evidence into a field full of opinions.
Forsgren, Humble, and Kim showed that software delivery performance can be measured in a useful way, and that high performance is not a trade-off between speed and stability. The famous four metrics are deployment frequency, lead time for changes, time to restore service, and change failure rate. Later DORA work has evolved, but the core lesson remains powerful.
The measured gap was not small. Across the research, high and elite performers were often orders of magnitude ahead of low performers in deployment frequency, lead time, and recovery time, while also doing better on change failure rate. The point is not the exact multiplier from one year’s report. The point is that the distance compounds.
The book is also not only about the four metrics. It identifies 24 capabilities that improve delivery performance, grouped around continuous delivery, architecture, product and process, lean management and monitoring, and culture. Metrics describe the system. Capabilities change it.
The important thing is not that a CTO should put four numbers on a dashboard and declare victory. That is exactly how good metrics become bad management.
The important thing is the relationship between speed, quality, feedback, and organizational capability.
If you optimize for speed without quality, production will eventually punish you. If you optimize for quality without speed, feedback arrives too late and the organization stops learning. And if a slow, brittle delivery system is simply scaled up, it can scale queues, handoffs, rework, and incidents rather than learning. High performance combines speed and quality because they reinforce each other when quality is built in.
This connects back to Scrum’s iteration loop, The Phoenix Project’s flow, and Organize for Complexity’s local decision-making. Fast feedback is not a developer convenience. It is how complex systems stay aligned with reality.
For CTOs, Accelerate is also a warning about measurement. Metrics should help the organization see constraints. They should not become a proxy war between teams, or individual performance KPIs, or a maturity-model badge.
Used well, the metrics reveal where the system hurts. Used badly, they teach people to hide the pain.
8. The Excellence Dividend
Tom Peters
The Excellence Dividend: Meeting the Tech Tide with Work That Wows and Jobs That Last was published in 2018.
Tom Peters argues that as technology automates more work, excellence in service, design, leadership, employee development, and customer experience becomes even more important. For CTOs, that point is easy to underestimate because we often talk as if technology strategy alone creates advantage.
It does not.
Technology can amplify excellence. It can also amplify mediocrity. AI will not save a careless organization. Automation will not repair a culture where people ship half-baked work because everyone knows nobody really cares. Platforms will not create trust if users have learned that internal tools are unreliable. A beautiful architecture diagram will not matter if the product feels indifferent to the customer.
Excellence is not perfectionism. It is not gold-plating. It is the refusal to normalize broken windows.
If leadership knowingly rolls out a half-baked process, people learn something. If a product ships with obvious rough edges that everyone saw coming, people learn something. If an internal platform wastes engineers’ time and nobody owns the experience, people learn something.
They learn what the organization actually values.
That is why excellence pays a dividend. It compounds trust. People feel seen. Customers feel respected. Teams become proud of their craft. The system gets cleaner because broken things are not allowed to become the background noise of work.
For a CTO, this book is a reminder that quality is cultural before it is technical. The architecture of care shows up in the architecture of software.
9. Wiring the Winning Organization
Gene Kim and Steven J. Spear
The full title is Wiring the Winning Organization: Liberating Our Collective Greatness through Slowification, Simplification, and Amplification, published in 2023.
This is the latest book on the list, and it closes the loop nicely.
Kim and Spear ask how organizations can be designed so people solve problems in better conditions. Their language is useful: move work from danger zones into winning zones through slowification, simplification, and amplification.
Slowification does not mean making delivery slow. It means creating room to think before the expensive moment, before production is down, before the migration is live, before the incident call is full of exhausted people guessing under pressure.
Simplification means making the work easier to understand and change. Amplification means making weak signals louder so problems are seen early, not after they become disasters.
That is almost a summary of the whole list.
Nonviolent Communication amplifies human signals. Phelan warns against frameworks that simplify the presentation while complicating reality. The Phoenix Project shows danger zones from the inside. Scrum tries to create small learning loops. Organize for Complexity explains why local decision-making matters. OpenSpace Beta applies participation to organization change. Accelerate shows how flow and stability can be measured. Peters reminds us that excellence must be visible in the details.
Wiring the Winning Organization gives a language for the leadership job behind all of it:
Do not just ask people to perform better. Wire the system so better performance becomes more likely.
The Connecting Thread
These books are about developing better judgment.
The weak version of technical leadership collects tools: Scrum, DevOps, DORA metrics, platform teams, OKRs, architecture boards, transformation programs. The strong version asks what those tools are trying to make visible, and whether the organization is actually able to act on what surfaces.
That distinction matters because most people in organizations are not the problem.
People want to do good work. They organize their lives, raise families, buy houses, learn complex skills, help colleagues, and care about success. When they behave strangely at work, there is usually a reason. Maybe ownership is unclear. Maybe the incentive system is wrong. Maybe the team lacks context. Maybe the architecture forces coordination pain. Maybe nobody feels safe enough to say the obvious thing. Maybe the organization has split the work in a way that destroys feedback.
If a pattern repeats across smart people, look at the system.
That is why I want CTOs to read across communication, DevOps, measurement, complexity, transformation, and excellence. A modern technology organization is a socio-technical system. You cannot fix the technical side for long while ignoring the social side, and you cannot fix the social side while the architecture, workflow, and incentives keep producing the same pain.
The fun begins when enough people share the baseline. Then a bug is not only a bug. A delay is not only a delay. A conflict is not only a personality issue. A metric is not only a number. Each becomes a signal about how the system is wired, and each signal becomes input for the next iteration.
And once enough people can see the system, not only the CTO, the organization can start changing itself in iterations.
The List
- Nonviolent Communication: A Language of Life by Marshall B. Rosenberg: publisher, Amazon
- I’m Sorry I Broke Your Company by Karen Phelan: publisher, Amazon
- The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford: publisher, Amazon
- Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland and J.J. Sutherland: publisher, Amazon
- Organize for Complexity by Niels Pflaeging: publisher, Amazon
- OpenSpace Beta by Silke Hermann and Niels Pflaeging: publisher, Amazon
- Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim: publisher, Amazon
- The Excellence Dividend by Tom Peters: official, Amazon
- Wiring the Winning Organization by Gene Kim and Steven J. Spear: publisher, Amazon