Aloha people,
I recently returned from a sailing trip that not only gave me time on the water but also the chance to finish a book I had been searching for. Throughout my career as a software engineering consultant, I’ve been fortunate to work with incredible colleagues who collectively shaped my vision of what makes a great technical leader (TL). As I advance in my career and consider the possibility of leading a team, I’ve often found myself exceeding the expectations of my role but still questioning if I truly understand what leadership entails.
In the past, I’ve been part of teams where the TL either lacked experience or favored an authoritarian style—situations that never ended well. I wanted to avoid creating a similar experience for my colleagues. While failure is part of learning, preparation is key. As I reflected on what I needed to learn for my first TL role, my colleague Mesut Ayata introduced me to his book, The Three Pillars of Effective Technical Leadership. It's a resource I now recommend to all aspiring technical leaders.
Overview
The book starts off strong and explains the “DORA” metrics which drive all parts of the three pillar idea and discusses what success could mean for an TL. This is followed up with a chapter per pillar that contains a section for each aspect with tips and do's. Those pillars are:
- Leadership: How to build an effective team that
- Technical Excellence: How to build software effectively and with quality
- Value: How to build a product and manage risk and time constraints
The book ends with a chapter on “Potential role distribution” which focuses on the distribution of responsibilities in different team setups and a not so convenient table about methods on “Five Dysfunctions of a Team” and “This book highlights the main topics and duties of a technical leader”.
Deep dive into each pillar
Safe to say, I was happy with myself that the first and second pillar were all too familiar to me. Each of the aspects of those I knew and am always trying to implement on a team. The third pillar product was mostly new to me. I had participated in the workshops described by Mesut, but as a developer I had been in a different position. I was not leading the workshop or driving for a bigger strategic outcome. The chapter about the third pillar allowed me to learn about the strategic product methods. Before reading the book, my focus had been on the first and second pillar. Speaking of which:
Leadership
This pillar is focused on three things, the social dynamics of a team, how to motivate people and how to help them grow. We are talking feedback culture, the five dysfunctions of a team, tech huddles, recognition, delegation. Notable from this chapter was the section “Reading between lines” and what I should listen for in technical conversations to support a healthy conflict. In the past, I had found myself in a situation where I either was surprised that the TL chimed in and defused a situation perfectly or corrected the course in a discussion. I often wished I had heard the cues, so I would have said those words. Over time, I got more familiar with such situations, and it shifted to: “Should I say something? Is this the right moment?”. Therefore, I am grateful to receive such hands on tips.
Technical Excellence
Whoever reads or is familiar with the suggestions from Martin Fowler's blog will feel that this chapter is a good summary of the bread and butter of how to deliver quality software. I like that this is included in the book, as every reader will be on a different point in their journey and might not be familiar with one or two topics.
Value
This chapter outlines how a TL can help stakeholders define what “value” means in the context of the product, team, and company, aligning with strategic goals. It also emphasizes enabling team members to think critically about value. Mesut highlights that it's not just the “business people” who should focus on the product—everyone is involved. I fully agree with this approach, as it increases accountability within the team. When every member participates in the creative process, they become more invested in the product’s success.
Who should read this book?
In my opinion, the book is great for seasoned and even more for aspiring tech leads. If you are one of the seasoned TLs out there, the book is still worth to pick up to see where you are getting challenged. For aspiring tech leads, the book is a must-read in my opinion. The ideas explained in this book are in my opinion the baseline of how a TL should act.
Summary
I’ve been on the lookout for a book that clearly summarizes the core responsibilities and challenges of technical leadership, and I finally found one in The Three Pillars of Effective Technical Leadership by Mesut Ayata. It’s a concise, well-structured guide that addresses many of the topics I’ve been reflecting on for years—something I even considered writing some blog post about myself.
The book is an excellent resource for aspiring tech leads, offering a comprehensive overview of essential leadership concepts and techniques. Mesut has masterfully articulated the topics and methods I’ve picked up through experience, making it a valuable reference to revisit when you need guidance or fresh perspectives on leadership.
However, while I loved the overall clarity and focus, there are a few areas that felt underdeveloped for me. For instance, the chapter on distributing responsibilities fell flat—it could have gone deeper into the importance of letting team members take ownership of certain tasks. From my own experience, I’ve seen the benefits of allowing developers to step into leadership roles when they’re ready. A funny situation that comes to mind is when I ended up in a room full of technical leads, surprising them by representing my team instead of our TL as a graduate. Although I wasn’t able to contribute as much as others, the experience was invaluable for my growth.
Building on that, I’ve found Cristian Benedit’s, a former TL I worked with, idea of having “champions” for different areas—like Frontend, Backend, Security, and Infrastructure—very effective. Each champion is responsible for driving improvements and addressing technical debt within their domain. It’s a great way to distribute responsibilities and empower individuals to grow into leadership roles, which I wish had been explored further in the book.
I did feel that some chapters, especially toward the end, lacked guidance for handling challenges when things don’t go as planned. The leadership chapter addresses this well, but overall, the book could have benefited from more focus on troubleshooting difficult situations. There’s room for an extended version that digs deeper into these challenges—although where to draw the line between leadership and general software engineering practices is always tricky.
Lastly, the book has a table for each section reminiscent, which I haven't found very useful. They inspired me thought as they reminded me of Anki card's, I plan to create and upload a set of such cards based on the book’s content to help others memorize and apply the lessons (link will be shared here later).
In conclusion, The Three Pillars of Effective Technical Leadership is an invaluable resource for anyone looking to step into a technical leadership role. While it could benefit from a few expansions, the core content is exactly what I’ve been searching for—a practical and well-organized guide to the world of technical leadership.