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 AnymoreWhen 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.
I’ve had a long history of being a bit of a perfectionist and making sure that everything is exactly the way that I think it should be. I discovered that people didn’t like me as a result of that. People don’t like being micro-managed. The reality is that there’s usually more than one solution for most problems and situations.
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.
One piece of useful advice that I received early on as a Tech Lead was to go around and talk to people - having 'water cooler conversations' with the people that are the stakeholders in your project. Don’t restrict it to work; understand how their kids are doing, talk about their favorite restaurants. Engage with them, because if you have a good working and personal relationship with someone, they are a lot more likely to let you know when things are going badly, as opposed to waiting and seeing what happens. They are also more likely to get you involved earlier or give you relevant, timely feedback. Those relationships are important. You can’t retroactively create a relationship, but you can proactively build one.
Relationships Are Key: Have 'Water Cooler Conversations'
Growing and giving opportunities to the next set of Tech Leads is crucial. It’s possible to give people leadership opportunities within the project. My leaders gave me leadership opportunities, which is how I grew into being a Tech Lead. I feel it is important to pay those opportunities forward, and having a successor prepared makes it easier to move on to new opportunities. I have always tried to figure out opportunities for others to do cool things and experiment. Sometimes those experiments sprouted into leadership opportunities for them, but sometimes they didn’t.
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.
A lot of what happens in your career is organic or unintentional - the way we help each other become Tech Leads, the way you end up owning the Tech Lead role. At the end of the day, whether you are a Tech Lead or not, success is being prepared for the next thing that comes up. It is sort of like having a toolbox with a bunch of tools that are ready to be used and is about knowing how to pick the right tool to deal with whatever situations come your way. Over time and with experience dealing with different situations, your toolbox gets bigger and filled with more tools. You often don’t know what is next, and the truth is that random things will happen. If you’re lucky, you are prepared for what comes next and as a result, you will be successful.
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.