When developers become Tech Leads they have to find a balance between leading teams and continuing to do technical work.
In the book Talking with Tech Leads- From Novices to Practitioners Patrick Kua shares stories from Tech Leads about their situations, challenges and approaches for leading teams.
The book explores the role and activities of technical leaders, and provides suggestions how to deal with responsibilities that come with technical leadership.
InfoQ interviewed Kua about the Tech Lead role, on practices for working with teams and dealing with people issues, the pros and con's of being a Tech Lead and getting support when becoming a Tech Lead.
InfoQ: What made you decide to write a book for Tech Leads?
Kua: There are countless books that teach you how to write “good” code, and even more on software methodologies like Extreme Programming, Scrum, Kanban and Lean. There are also many books on leadership and management but almost none for “Leaders who still code.” I have seen the difficulties when developers first step into the Tech Lead role and they all struggle with the same challenges. With this book, I wanted to capture their stories, their lessons learned and their struggles to help other Tech Leads understand their situation is not unique and that others have successfully overcome their challenges.
InfoQ: The book contains interviews with Tech Leads in which they share their experiences. Why did you choose this format?
Kua: Although I have an opinion about what makes a Tech Lead excel, I wanted to find out how other people approach their role. Interviews were a natural way to keep it neutral. After the first few responses, I was surprised at how strong people’s stories resonated with each other. I also know how powerful stories can be. I felt that these stories could other Tech Leads, because the role can be very lonely. After conducting the interviews, I arranged them into themes that organically emerged from the breadth of Tech Leads who I interviewed. This format was not intended to give people the, “One True Way” (because it doesn’t exist) but represents the different approaches to playing the Tech Lead role. I also felt that this format was most ideal for people wanting to dip in and out of the book, making it more accessible for people with less time.
InfoQ: What is a Tech Lead? How does this role differ from an Architect, a team leader, or a Scrum Master?
Kua: A Tech Lead is the role that a developer plays when they are responsible for a development team building the same system. A Tech Lead role has several overlapping responsibilities with other roles such as an Architect, team leader or a Scrum Master but the role is unique in that it brings together both the leadership and technical aspects. A good Architect looks like a Tech Lead. However I know of many organisations where they struggle to define what an Architect is and what an Architect does. You have titles such as Enterprise Architect, Data Architect, Business Architect and often they are given because those roles take on a broader view, but often they are not involved with the day to day. Where I see a Tech Lead differing is that they have both the responsibility to deliver a software system (like an Architect) but they should be involved with the system implementation day-to-day. In short, they are an Architect who codes. A team leader is often responsible for the care and feeding of the team, something which a good Tech Lead will also take on. On the other hand, not all team leaders are technical which makes it much more difficult and sometimes impossible for a team lead to facilitate technical discussions and to steer the technical direction and decisions of the team. The ScrumMaster role is only defined in the Scrum agile method and only exists in those environments who adopt Scrum. In contrast, any sizable development team will always have a Tech Lead role who is responsible for the technical direction of the team. Tech Leads may also take on the ScrumMaster role, but like a team leader, not all ScrumMasters can play the Tech Lead role if they do not have the technical knowledge needed to lead the development team and technical direction of the team.
InfoQ: Can you share some good practices describing how Tech Leads can work with teams?
Kua: Absolutely. Although I have written about how a Tech Lead is responsible or accountable for the technical direction of a development team, there are many different ways that the Tech Lead can achieve this. Some Tech Leads will be more directive in how they achieve their vision, which is perhaps a more useful mode with a less experienced team. They will not only outline their vision, but also be very specific in what details it might take to get there (using specific tools, libraries, or frameworks to do so). Other Tech Leads who work with a more experienced team can rely on team members’ experiences and knowledge to solve problems, meaning they only really step in to facilitate the problem solving process and to help the team move forward when they cannot reach a decision by themselves. Although I am not a fan of the heavy-weight RUP (Rational Unified Process) tools, I am a big fan of using different diagrams to help a development team form a common understanding of what they are building. Drawing diagrams and storytelling are often underrated but invaluable skills for Tech Leads trying to help people understand their Technical Vision. A good way to do this is to bring the team in front of a whiteboard and to try to model the architecture of the system they are building.
InfoQ: Do you have examples of people issues that Tech Leads often have to deal with? How do they do it?
Kua: There are two clear people issues that I see very commonly on teams. The first is dealing with disagreements between developers. For an idealist, a self-empowered team should find a way to resolve their own conflict. In reality this does not happen as much as one would hope. A Tech Lead must often mediate the conflict between two different approaches from a team. This involves being clear about what the problem is, exploring alternative solutions (not just the two proposed) and perhaps even conducting a trial of various solutions to validate the benefits and disadvantages. The XP practice of a Spike can often be used to evaluate two different approaches, and it is often easier to validate the merits of a prototype, than simply arguing back and forth. The second people issue is often dealing with a skill gap between what is needed and what the team has. Technology and tooling changes all the time and software systems are so complex that it is almost impossible to always have the skillsets readily available. An effective Tech Lead will find ways to balance time for the team to learn at the same time as delivering. They are also constantly looking for ways to spread knowledge and skills to other team members to prevent knowledge silos and to allow more than just one particular developer to work on one particular task. Tech talks focused on a particular topic, or a team code walkthroughs are great examples of how a Tech Lead might do that.
InfoQ: In the book you mentioned Tech Lead lunches. Can you explain what they are and which benefits they can bring?
Kua: One of the hardest challenges stepping into any leadership role is that it is increasingly easy to feel isolated in your role with no support. We started running Tech Lead lunches as a way to create a support network for Tech Leads working on different teams.
Our Tech Lead lunches brought about 4-6 Tech Leads together during a communal lunch to talk about issues that they were facing. Participants were invited to present a challenging situation they were facing, and for the others to share how they would approach it. In many ways, our Tech Lead lunches were akin to an informal coaching circle for people in similar roles. We found that it was a really effective way to share tips and tricks with each other about topics such as time-management, how to balance staying hands on with code and taking care of other responsibilities and dealing with difficult people.
InfoQ: Can you describe some of the pros and con's of being a Tech Lead?
Kua: A Tech Lead will find themselves with both the accountability and responsibility for the technical direction of a software system and a development team. An advantage of this role is that you often end up with a broader view of the system, thinking more strategically and longer term than what you might as a developer. A Tech Lead will also spend more time with people from the business, giving them a bigger influence on product direction based on technical capabilities and on planning activities that have an impact on what may end up delivered long term. On the other hand, a Tech Lead inherits far more responsibilities that takes away more time from coding and this is one of the biggest struggles for developers transitioning into the role. At the same they, a business will hold the Tech Lead accountable for a system, but the Tech Lead will lose more control over the detail, which requires more trust in the people on their team.
InfoQ: Becoming and being a Tech Lead can be rather challenging as we can read in your book. Where do Tech Leads go if they need support?
Kua: Although there will only be one Tech Lead on a team, in most organisations, there will often be more than one Tech Lead in the organisation. Finding a peer that a Tech Lead can confide in is often a good start. I would also recommend that a Tech Lead find some sort of coach or mentor to help them clarify their observations and evaluate their options to problems that do not have a clear answer to them. A project manager might serve as a good informal coach if a Tech Lead has a good relationship with them. I would also remind Tech Leads that their entire development team is a form a support and team members will often have much better solutions to some types of problems and it’s a good sign.
InfoQ: What are the main differences between novice and experienced Tech Leads?
Kua: I think the biggest difference between novice and experienced Tech Leads is their ability and confidence moving from “doing” to “enabling.” A novice Tech Lead will want to try to control the design and implementation of the code, because this is what they are used to as a developer. At some point, they will realise that this fails to scale, but also takes out the creativity and problem solving fun for the other developers. As a novice gains more experience, they start to become more comfortable that the code may not be written exactly how they would have approached it, but that the solution they end up with is still suitable. An experienced Tech Lead will be much better at articulating guidelines and knowing when to step in, and when to step back.
InfoQ: What can teams do to learn about the needs that business people have?
Kua: I’m going to take a page out of the Lean community, and suggest that developers go to the “Gemba” or the place where work happens. I think developers can write better solutions when they understand business problems and end-user problems a lot more. Of course, it depends on what sort of software you are writing, but I would definitely recommend developers see how and where their software is being written and try to empathise with what drives users. Another good way teams can learn about the needs is to give visibility to business goals and metrics to the development team that helps remind people about what their system is doing. Some examples might include: Improving conversion rate (i.e. % people actually buying something versus browsing), increasing repeat buyers or number of paid subscribers.
InfoQ: Can you mention some resources for developers that want to become a Tech Lead?
Kua: Some books I find myself recommending include:
- “Becoming a Technical Leader” by Gerry Weinberg - A good summary of what it means to be a leader, general problem solving and understanding how to navigate an organisation
- “Crucial Confrontations” by Kerry Pattern et al. is a great book that describes a specific approach on how to communicate without changing the strength of the message.
- “Getting to Yes” by Roger Fisher and Willam Ury is a really short, concise book on how to handle negotiations which will be essential for Tech Leads trying to resolve conflict around technical solutions in their team.
- “Software Architecture for Developers” by Simon Brown is an accessible book that gives good guidelines on how to communicate architecture effectively; and of course
- “Talking with Tech Leads” by Patrick Kua shares the situations, challenges and approaches of over 35 Tech Leads.
About the Book Author
Patrick Kua is author of “The Retrospective Handbook: A guide for agile teams” and "Talking with Tech Leads: From Novices to Practitioners." Patrick brings harmony to technical and non-technical realms, leading teams and writing software for production systems in .Net, Java and Ruby. Patrick is passionate about working closely with teams, helping them grow and learn with sustainable and long-term change, and sometimes facilitating situations beyond adversity. Patrick relies on retrospectives as a basis for improving teams, and is passionate about helping people achieve maximum value from the retrospective practice. You can follow his blog or on twitter at @patkua.