For me, becoming a Tech Lead was not something that happened one day, or even after a planned transition. It was something that I now realize started way back in my internship during college. Being a Tech Lead is something that you grow into, often because other leaders gave you a safe space to practice leadership, and you observed them and learned from them.
It was early 2008, about three years into my career at Thoughtworks and 1.5 years on a leasing project, when I first had the official title of Tech Lead. I was staffed with Andy Slocum, the Tech Lead on the project at the time. He was transitioning out the Tech Lead position and he picked me as the person to take over for him. It was an ideal situation where I was going to be a Tech Lead on a project, while having the previous Tech Lead still staffed with me, making me the recipient of much detailed guidance. Given that I was learning from Andy, and I already knew the client and the tech stack, the transition was very easy. I was able to familiarize myself with what I needed to do, understand the roles and responsibilities, and I had guidance from the beginning.
What Got me Prepared for This
Prior to working at Thoughtworks, I was on a Scrum team as a developer and team coordinator, where my responsibility was to make sure that the team was successful at delivering software. That experience gave me a chance to practice the leadership skill of distributing work in a way that people would like it, learn from it, and be effective at it. Part of leading a team is making sure that liking, learning, and effectiveness are in balance as people work on different parts of a project.
Looking back, I see that I was prepared for this experience on the Scrum team because of my experience during internship in college. I had the opportunity to lead a small team (that included one contractor and me). I planned the work, took care of scope and project management details, and did a bit of development. I made sure that the contractor was successful and that our project worked. While it was the most minute version of tech leadership, since it was a two-person team, it gave me a chance to practice the skills you use when you are on much larger teams. Those skills paid off when I was Tech Lead on the leasing project, where we had twenty-eight people on the team.
Leadership isn’t really about having a certain job title. It is about making sure that the team is successful and doing whatever it takes to reach that. I started doing these activities long before I was given a title. In my case, it was a natural progression which led to an official job and title.
Maintaining that balance between thinking about your contribution to the code as an individual, and being at that point where you’re paying attention to aspects like team dynamics, staffing issues or something radically different from code is an art that can be mastered. You don’t stop caring about your individual contribution to the code, you just need to be okay with putting it on hold periodically and coming back to it. You just need to make sure that you don’t get too far away from the code, since that is what keeps you grounded in what you are doing as a team.
During team meetings, I’ve found it’s best to lead the conversation, without telling people what to do. I need to allow the team reach a solution, even one which I might not consider the most optimal. I’ve found that if the team really supports a certain solution, they will work hard to make sure it is successful. Often times, they will come up with a solution that is better than what I imagined. As a Tech Lead, we work with good people and it’s important to believe that they are going to do their best. If they come to a workable solution, go with it; but if they can’t, Tech Leads provide two important functions. They should act as a tiebreaker when the team is stuck between two similar solutions, and they should keep the team from thrashing by keeping the team from continually re-opening decisions that have been made.
Letting go means I learned to be more comfortable with ambiguity, be willing to accept sub-optimal solutions, and most importantly to know when it matters and when it doesn’t. For example, when you analyze a system for bottlenecks, it’s important to optimize aspects that have an impact on the effectiveness of the overall system. If it doesn’t matter to the overall system, don’t spend your time and effort on it.
Facilitating simple exercises within the team can be a chance to practice leading in a safe environment, so share those opportunities as often as possible. This helps people figure out what they want to do in their career and gives them concrete experiences which they can eventually draw from. Such experiences help them eventually transition into the formal role when it presents itself. When we help build the next generation, the reality is that individuals have already been doing a lot of the activities that you would expect a Tech Lead to do; the formal label comes later.
It was early 2008, about three years into my career at Thoughtworks and 1.5 years on a leasing project, when I first had the official title of Tech Lead. I was staffed with Andy Slocum, the Tech Lead on the project at the time. He was transitioning out the Tech Lead position and he picked me as the person to take over for him. It was an ideal situation where I was going to be a Tech Lead on a project, while having the previous Tech Lead still staffed with me, making me the recipient of much detailed guidance. Given that I was learning from Andy, and I already knew the client and the tech stack, the transition was very easy. I was able to familiarize myself with what I needed to do, understand the roles and responsibilities, and I had guidance from the beginning.
What Got me Prepared for This
Prior to working at Thoughtworks, I was on a Scrum team as a developer and team coordinator, where my responsibility was to make sure that the team was successful at delivering software. That experience gave me a chance to practice the leadership skill of distributing work in a way that people would like it, learn from it, and be effective at it. Part of leading a team is making sure that liking, learning, and effectiveness are in balance as people work on different parts of a project.
Looking back, I see that I was prepared for this experience on the Scrum team because of my experience during internship in college. I had the opportunity to lead a small team (that included one contractor and me). I planned the work, took care of scope and project management details, and did a bit of development. I made sure that the contractor was successful and that our project worked. While it was the most minute version of tech leadership, since it was a two-person team, it gave me a chance to practice the skills you use when you are on much larger teams. Those skills paid off when I was Tech Lead on the leasing project, where we had twenty-eight people on the team.
Leadership isn’t really about having a certain job title. It is about making sure that the team is successful and doing whatever it takes to reach that. I started doing these activities long before I was given a title. In my case, it was a natural progression which led to an official job and title.
5 Things I Learned Along the Way
It’s Not About You Anymore
When I’m leading a team, I have to balance my individual contributions against the overall productivity of the team. It usually ends up being more important to focus on the team’s productivity. It no longer matters whether I get any stories done or not; what matters is whether we as a team are successful. I might go through a week and not commit a line of code, because I am bouncing around removing roadblocks so that the team can be effective. This may feel completely strange for those of us that come from a background of “I need to get these features done”, but the reality is that you have to be able to step back and see the bigger picture.Maintaining that balance between thinking about your contribution to the code as an individual, and being at that point where you’re paying attention to aspects like team dynamics, staffing issues or something radically different from code is an art that can be mastered. You don’t stop caring about your individual contribution to the code, you just need to be okay with putting it on hold periodically and coming back to it. You just need to make sure that you don’t get too far away from the code, since that is what keeps you grounded in what you are doing as a team.
Let Go of Your Solutions and Encourage Team Decisions
During team meetings, I’ve found it’s best to lead the conversation, without telling people what to do. I need to allow the team reach a solution, even one which I might not consider the most optimal. I’ve found that if the team really supports a certain solution, they will work hard to make sure it is successful. Often times, they will come up with a solution that is better than what I imagined. As a Tech Lead, we work with good people and it’s important to believe that they are going to do their best. If they come to a workable solution, go with it; but if they can’t, Tech Leads provide two important functions. They should act as a tiebreaker when the team is stuck between two similar solutions, and they should keep the team from thrashing by keeping the team from continually re-opening decisions that have been made.
Letting go means I learned to be more comfortable with ambiguity, be willing to accept sub-optimal solutions, and most importantly to know when it matters and when it doesn’t. For example, when you analyze a system for bottlenecks, it’s important to optimize aspects that have an impact on the effectiveness of the overall system. If it doesn’t matter to the overall system, don’t spend your time and effort on it.
Relationships Are Key: Have 'Water Cooler Conversations'
Build The Next Generation
Facilitating simple exercises within the team can be a chance to practice leading in a safe environment, so share those opportunities as often as possible. This helps people figure out what they want to do in their career and gives them concrete experiences which they can eventually draw from. Such experiences help them eventually transition into the formal role when it presents itself. When we help build the next generation, the reality is that individuals have already been doing a lot of the activities that you would expect a Tech Lead to do; the formal label comes later.
Build Your Toolbox: Be Prepared for What Is Next
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
