Six books that shaped how I lead engineering teams
5 min read
Every engineering manager ends up with a handful of books they keep coming back to. These are mine. Some gave me a language for things I was already doing. Others changed how I worked. They are the ones that still come up when I am coaching a new manager or talking myself through a decision.
No order. No ranking. Just what I took from each one and why I think they still matter.
Good Strategy Bad Strategy
Richard Rumelt’s argument is simple. Most of what organisations call strategy is not strategy. It is a list of goals dressed up in corporate language. Bad strategy is fluff, goals confused with plans and the refusal to identify the actual problem.
Good strategy has three parts. A diagnosis of what is actually going on. A guiding policy for dealing with it. A coherent set of actions that follow from both.
If a strategy document does not tell me what the problem is, it is not a strategy. This has saved me from countless planning sessions where the real work was avoided in favour of aspirations. Applied to engineering roadmaps, it stops you shipping initiatives that do not connect to anything.
Atomic Habits
I was sceptical of this one. The self-help framing did it no favours. But the core idea is solid. Outcomes are the result of systems, not goals. If you want a different result, change the system that produces it.
James Clear’s framework around making good habits obvious, attractive, easy and satisfying sounds simple until you apply it to a team. Code review standards that are difficult to find stay ignored. Deployment processes that are painful get avoided. Engineering culture is habit at scale.
When a team keeps failing at the same thing, I stop asking why nobody does X and start asking what makes doing X harder than it should be. The environment is almost always the answer.
The Naked Leader
This one will not appear on most engineering reading lists. David Taylor wrote a leadership book, not a software book. But it is the one I hand to new managers more than any other.
Taylor strips leadership down to its basics. Know where you are going. Know why. Be honest. Be human. No heroic mythology, no pretending leadership is magic.
Leadership is not performance. It is consistency and clarity. Engineers can smell performed leadership from across the office. The manager who says what they mean, follows through and admits when they are wrong is the one people will follow when things get hard.
The Five Dysfunctions of a Team
The fable format grates at first. Push through it.
Patrick Lencioni’s model stacks. Absence of trust leads to fear of conflict. Fear of conflict leads to lack of commitment. Lack of commitment leads to avoidance of accountability. Avoidance of accountability leads to inattention to results. Each level depends on the one below.
Most team dysfunction I have seen starts at the bottom of that stack. A team that cannot disagree honestly in a meeting will never commit to a decision. A team that will not hold each other accountable will not care about the outcome. Fix the foundations first. Trying to fix accountability without addressing trust is wasted effort.
The Lean Startup
Not a book about startups. It is a book about learning under uncertainty.
Eric Ries frames product development as a series of validated experiments. Build, measure, learn. The goal is not to ship the plan. It is to reduce the gap between assumption and evidence.
When a team is building something new, the measure of progress is not how much has been built. It is how much has been learned. Six months of development that validates the wrong assumption is worse than six weeks of experiments that invalidate it early. I find myself reaching for this whenever a roadmap starts to feel more like a promise than a hypothesis.
Team Topologies
The most specific book on the list and the one I reach for most as an engineering leader.
Matthew Skelton and Manuel Pais define four team types. Stream-aligned. Platform. Enabling. Complicated-subsystem. They describe three interaction modes. Collaboration. X-as-a-Service. Facilitating. The argument is that software architecture reflects team structure, so team structure should be designed deliberately rather than left to accident.
If you want different software, you often need different teams. Restructuring teams is not politics. It is architecture. Most of the friction I see in engineering organisations is not technical. It is structural and the structure was never designed. It just happened.
Why these six
I have read dozens of books on leadership, delivery and technical strategy over the last twenty years. Most of them were fine. These are the ones that changed how I work.
They span different concerns. Strategy. Habit. Leadership. Team dynamics. Learning. Structure. Together they cover the actual surface area of leading engineering teams. No single book does that on its own.
If you read one, start with Team Topologies. If you want to feel uncomfortable about how your current organisation plans, read Good Strategy Bad Strategy. If you want to understand why your team keeps failing at the same things, read Atomic Habits.
The shared thread across all six is that they are specific. They offer frameworks that survive contact with reality. That is what makes a book worth returning to.