Review & Reflect: Talking with Tech Leads

TL;DR: Review & Reflections on the book “Talking with Tech Leads”, by Patrick Kua. To me this is a "must read" for anyone starting as Tech Lead or people shaping this role on their organization. Tech Lead is a rather unclear and undefined role in many organizations (many (mis)interpretations, many (unclear/implicit) responsibilities, unclear career path, etc., leading into a lot of stress for people taking this role). To address that Patrick Kua takes the interview approach and collects how 35 Tech Leads see their role. To me this is a great way to shed light on the many aspects of the role and especially draw interesting patterns and lessons to improve the life of Tech Leads. The book is neatly divided into two parts: starts with mistakes, frustrations and realizations of first time Tech Leads; and then goes to lessons, patterns and recommendations of seasoned Tech Leads. As software professionals community we can really improve how we support people in this role. This role is crucial in the age we are as technical leadership is a central ingredient to set product teams in the organizations for success (they are the ones governing the product technical vision, coaching/developing people within their teams and making sure that there is a clear balance with the product/business disciplines in the product being built). I thoroughly enjoyed this book and got many learnings and especially confirmations/validations. Highly recommended! #TechLeads #TechnicalLeadership

Review & Reflect

I have been Tech Lead/Architect on different jobs, teams and organizations. Today I am involved on activities of developing/coaching new Tech Leads, specifically helping individual contributors (IC) on taking the step to lead teams and technical vision of the products they are building. This “setting-up” activity is not yet clearly understood and well defined in our industry and basically each organization has a different approach to this (or simply has no approach and people are “thrown/promoted” to the job “because they are the most senior engineer” or “they need to be promoted” - a lot of wrong reasons). A clear example of this is the fact that Technical Leadership career path is not widely defined in our industry, you either stay an individual contributor (IC) path - and become an expert, or you go into the management track. Technical Leadership does not fit well any of these two boxes, it is a sort of hybrid and could very much be set as a “third way” to progress in the career.

(Link to book in Leanpub)

This book reflects a lot of these challenges and how people try to cope with them. Patrick Kua conducts 35 interviews with Tech Leads and he gets 35 different interpretations/views on the role. Why does this happen? This role is very difficult to generalize, as it involves many different elements (technical, people and organizational). The result is often that we have people coming to this role and end up “figuring out” on the fly what they need to do, which is most of the times a rather unpleasant experience. Also different organizations (depending on different factors, such as size and product) will need Tech Leads to focus more or less on certain aspects of the role.

I really appreciate the effort from Patrick on this book. He did not just write a book with “how you should do it” but put together many different views and experiences on this role, which gives us (prospective Tech Leads and people trying to develop/improve this role within their organizations) a lot of ideas, patterns and learnings that we can use on our own situations.

The book is strategically divided into two main parts: interviews with novices (or first time Tech Leads) and interviews with practitioners (people that were on the role of Tech Lead on multiple occasions). This organization allows us to learn and capture a lot of insights on the different Tech Lead levels of maturity.

In the novices section you can understand common mistakes, frustrations and realizations of being a first time Tech Lead. Bellow I highlight some interesting parts and give a reflection on each point:

• Common Mistakes:
  • Still very much focused on getting time to code. If not doing that “I am not productive”. This is one of the most common feelings amongst first time Tech Leads.
    • After transitioning to Tech Lead one should accept that it is not possible to spend the same amount of time coding (this will vary from organization to organization and even team to team, but the general pattern of coding less stands). The focus now is on “empowering the team” and set the right conditions for them to code as swiftly and good as possible, i.e.: from one person coding to enabling a group of people coding better.
  • Still try to do everything herself, as this is normally faster.
    • This causes a lot of problems to Tech Leads, as they will have so many things on their hands that it is just impossible to do them all. It is really important to filter, prioritize & delegate. Tech Lead becomes more a mediator and advisor and less a doing the deep dives on the work that needs to happen.
  • Still try to “learn everything in detail”.
    • While IC there is the time and need to learn things in depth. However, when working as Tech Lead in many different things at the same time and having the responsibility to lead and guide the team, one should focus on “understanding well enough” but not necessarily go in depth in all the topics. It is just impossible to do that => no time! However, it is important to say that the Tech Lead needs to stay up to speed on the technical developments relevant for the team. The reason for this is because Tech Lead has the responsibility of governing the technical vision of the product and coaching people within the team. The realization is to focus on “understanding” and not be the expert. Tech Lead must make sure team has the expertise and delegate/rely on the team.
• Common Frustrations:
  • “I have to deal with people and have many more meetings”.
  • “I am not doing Tech all the time”.
  • “I spend a lot of time in mediation, away from keyboard”.
  • “I have to work across multiple teams and with business”.
• Common Realizations:
  • More responsibility and ownership, which most people appreciate.
  • It is a role that requires multiple views (inwards and outwards looking).
  • Major focus on mentoring people within the team => enable them to do better.

It is particularly insightful to learn about the common “mistakes and frustration” that Tech Leads have when first taking that role. This can really save a lot of time to the people jumping on the journey. Patrick (and interviewees) also provides some nice recipes of “steps to take” to avoid falling into some of these traps.

On the Practitioners section you can find a wide variety of lessons, patterns and recommendations (of things that work and don’t) from people that went through the role multiple times. Bellow I highlight some interesting parts and give a reflection on each point:

• Team must know what is important. Tech Lead must help team on understanding where to focus efforts and define the direction for the team.
• Team over self. Tech Lead is 1 in N people in the team. The focus is to empower N, the team.
• Accept moving away from being a “main coder” or the “best coder”. Time will not allow and it is not fair/productive for the team to have Tech Lead pick up crucial coding activities, as most likely step away and not make progress in due time. Furthermore, it is important to have a clear mission where Tech Lead enables the team to have the best coders, not being the best coder.
• Tech Lead is a relationship manager. Tech Lead has to continuously deal with different people in different situations, i.e.: manage relationships. If this is something one cannot do well, or is not willing to do, it will be challenging to properly do the job of Tech Lead.
• Balance between Facilitating and Leading modes. In general Tech Lead should spend most time on facilitating the team (i.e.: put enough structure in place to enable the team to move independently). However, there will always be moments that a call needs to be made, and taking lead there is essential (e.g.: team is stuck and cannot move; or there is a conflict between team members). It is key to balance out these two modes in order to create autonomous and confident teams. If Tech Lead spends all the time in leading mode, team will never take ownership and develop/mature. However, it is important to understand there will be moments that lead mode must be used.
• Own and govern technical architecture. It is one of the main tasks of Tech Lead, namely: make sure the product has a clear technical direction, technical risks are properly managed and all this is continuously governed. For example, it is the role of the Tech Lead to make sure the architecture view is clear and all sorts of developments are taken into consideration to avoid building unnecessary technical debt.
• Tech Lead is in many places called Software Architect. This is a remark from Simon Brown, another great author on the topic of technical leadership. I can agree with that, however there will be organizations where the two roles exist. In my view the most important point is to make explicit what they encompass (e.g.: in my organization Software Architect tends to be a more multi-team supporting role, while Tech Lead is a role within a product team).
• Be a master in communicating the direction and architecture of the product. There are many ways to do this (visual representations tend to be the most effective ones), however the important thing it to continuously do it so that everyone understands what they are building. This makes sure that everyone is aligned on where we are going, which in turn brings clarity to the work everyone needs to perform. This is also important when having discussions with product/business counterparts, i.e.: make sure there is a clear and shared understanding of the vision for the developments and how to implement them and how that is aligned with the product vision.
• Provide and foster good development patterns and principles. Essential to make sure the team is set for success by having a robust way of working.
• Be self-aware and play to your strengths. Each person has different strengths, as Tech Lead it is important to understand one’s strengths but also the team strengths. With this you know who complements you and how to bring a wide range of strengths to the team (when hiring, for example) so that the team is set for success. It is very important to be self-aware that one cannot excel in many things and it is more important to have a group that combined can provide such capability (instead of having a lot of people with the same “super-powers”).
• Work with your team to make you obsolete/redundant. If I had to select one single sentence to describe Tech Lead this would probably it. I don’t believe this should happen to the full extent, but the mission of empowering the team to lead and take decisions should be a top goal for Tech Leads. Nevertheless, I still think it is very beneficial to continue having someone that takes explicitly the role and represents the team in many places the team needs to be represented. I like to think about this in two dimensions: developing technical leadership in the team and have someone explicitly on the tech lead role. To me this is a great way to maximize a team’s performance.
• Embracing change and adaptability. Things will be different every day, so it is better to accept it and get into the mindset of adapting and pragmatically respond to the situation at hand. Embrace the “Observe-Act-Learn” pattern.
• Understand and learn to rely on experts. This is another very important skill to have as Tech Lead, and one that most first time Tech Leads really struggle with. Tech Lead’s main responsibility will be on mediating, facilitating and leading the team. Given this, being very clear and understanding who (which expert) to bring to the table in each situation is very important to be impactful in this role. Related with this it is important to continuously make sure that the team is coached and developed so that there are ICs that become experts on the different important topics for the product team. That is also part of the responsibilities of the Tech Lead.
• “Be the scout of the team”. I loved this expression. It really captures another responsibility of the Tech Lead, namely: Tech Lead is like a scout for the team, she goes ahead of the main body and surveys the landscape, sorts obstacles and reports where the team should head next, the possible challenges there are and how to prepare for them.
• As Tech Lead my first responsibility is my team, not my code. Already mentioned above, but this is a good one to close the highlights: Tech Lead is about empowering the team over self, I like to say that the Tech Lead is “an amplifier of coders, not code” - this is great, because it is a multi-factor amplification. I really believe in this approach as opposed to the 10x engineer approach.

Such insights are rather useful and provide several principles to succeed in being a Tech Lead. They are also great tips to avoid and address several of the common pitfalls that first time Tech Leads often encounter.

Conclusion

Patrick is a reference for Tech Leads and a proven mentor on the topic, so this book is, in my opinion, a “must read” for people growing as Tech Leads or supporting people on growing into that role. I have learned a great deal from this book, in particular it helped me to organize and validate patterns of being a Tech Lead. I hope as an industry we can be more explicit and supportive to people taking the role of Tech Lead. They are a pillar within teams building technical products, by clearly defining and promoting the product technical vision and making sure that teams are aligned and mature. Patrick has another good resource for this, namely the Trident Model, which contrary to the classical model that only has ICs and Managers career paths, also adds the Technical Leadership track. I think all of these resources are great contributions on making this role much clearer and explicit within modern technical organizations.

ℹ️ I offer consulting services and products on this topic

If you are looking for help on these topics feel free to contacting me, and/or check my consulting and products pages for more details on how I may be of help.