How work changed being a Tech Lead

In this article I share the things that changed in my work life after becoming a Tech Lead. Especially I will cover how my contribution to the team changed and how my view changed in general.

How work changed being a Tech Lead

As a follow up of my article about My Tech Lead Journey I want to specifically go into detail about what changed after I assumed the role of a Tech Lead. Prior to this I was working as a Software Engineer. As such I spent most of my time writing code and was able to concentrate on that for longer stretches of time. In addition, I helped splitting user stories into smaller, digestible tasks and discussed with other engineers about possible implementation options for them. For the most part those tasks were connected to the team I was working in. In the following I share things you can expect to change when you become a Tech Lead.

Code contributions to the team

The biggest change that happened over time was how I contributed code to the team. As mentioned above, as a Software Engineer you more often than not have longer stretches of time that you can spend concentrating on a specific implementation task.

For me this was no different. There have been days were I came to work, opened my laptop, started working on a feature and except of a lunch break was not interrupted by anything that was not related to this task. In retrospect this has been a very relaxing time. Those days have been like meditation for me. I guess this is what people mean when they talk about "being in the zone" or "being in a flow state".

I wanted to find out how my code contributions changed over time, especially after I became a Tech Lead. In my thinking, the more code you produce the more time you probably spent doing that. Below you can find excerpts of the high-level Github contribution metrics from 2016 to 2019. During this period of time I worked for the same company.

I joined the company in June 2016. You can see a lot of gray in the chart which can be explained by me learning a lot of things and doing pair programming in the new company. This is underlined by the fact that I barely did any code reviews.

The picture changes a lot in 2017. I started contributing more regularly and had more impact especially in the first half of the year. Beginning of May I got the Tech Lead role in a team I joined beginning of the year. I also immediately went for a two week vacation. Afterwards, you can still see good contribution on Github.

However, towards the end of the year contributions get less and less regular. I touched this in my last article My Tech Lead Journey. Becoming a Tech Lead I didn't want to lose track of all the things that were implemented by my colleagues and also wanted to be in the details myself. It took me a few months to understand that this is not sustainable and I need to step back from coding a bit. This you can see in the above graph.

Looking at the types of contributions one thing stands out. I got a full member of the engineering team by not just producing and relying on others but also giving back and reviewing others' code.

The picture changes a bit in 2018. In general, the contributions seem to be more equally distributed over the year. They also halved from 2017. It seems I did much less work in general on Github. I have been on vacation for three weeks in March. Shortly before my vacation I joined a new team that worked on a completely different architecture from what I was used to and used a different programming language. Hence, after my vacation you can see less contributions as I was put into learning mode once more. Contributions got more during the end of the year.

The distribution of contribution types shifted a bit. I produced less commits and was more active in code reviews. I can explain this with the fact that I first was in learning mode a lot in 2018 and started asking questions and commenting on other peoples pull requests before creating my own. Second, I learned during 2017 that it is more important to have a good overview of what happens in the team instead of producing loads of code. This is why I looked at a lot of pull requests which helped me keeping an overview and steering the development implicitely. Also I had the chance to bring in information that others might not have. Nevertheless, I created the same fraction of pull requests with probably smaller changes counting in that the fraction of commits went down.

2019 shows a similar picture in terms of contribution types. Also the amount of contributions stays similar. However, they are distributed more evenly over the year which attributes for less peaks. 2019 was the year in which the team got much bigger. We also split the team in two and I was responsible for only one team during some periods of time.

By now I learned that I should not involve too much in the feature delivery of the team. How the sprint evolves for me is often not predictable. Hence, if I would pick a bigger implementation task and I am not able to finish it in due time because of my other responsibilities I could block the team or put the sprint goal at risk. Because of that I often take smaller tasks, tasks with a low level of uncertainty or tasks that are separate from the main sprint deliverables.

The bird's eye view

The pure personal output is not the only thing that changed. In general, I keep my mouth shut more often, I listen much more. With that I learn about group dynamics and the individuals in the team. I learn who speaks when and how much, I learn about their motivation and their goals. I learn about what everyone thinks is important and their preferred work environment.

I also have a closer relationship with my Product Owner and the architects in the company. We prepare roadmaps and sometimes are each others sparring partners.

Overall, I would call this the bird's eye view that you start having as a Tech Lead. Instead of loosing yourself in implementation details (ant's eye view) you need to learn how to best make systems and teams work nicely together. You gather information and requirements that are needed so that the team can make an informed decision. You ask the right questions so that the team can move on.

Somewhere between engineering and management

The most interesting and challenging part about the Tech Lead role is that this role can be a mixture of different roles. Some fraction is definitely technical, another can include management.

As a Tech Lead you are a person in a technical role. You must keep learning about technology, stay connected to the code and system. You need to understand how the system behaves and evolves. This includes getting your hands dirty from time to time. In addition, the Tech Lead is accountable for the output of the team and the technological development of the system as well as that the team can work well.

The last point could mean many things. What it definitely touches is that a Tech Lead also needs to understand her team members, their needs, their motivation, their goals and has her fair share in keeping the team happy (or help making it a happy team).

In that sense, a Tech Lead sits right between the engineering and the management career tracks which makes it a challenging role. You need to figure out and adapt to which side you are leaning towards more based on the team health and maturity as well as the company needs.

Do you have a story to tell about what changed when you got a Tech Lead? I would be glad to listen to it and learn from your experiences. Let's get in touch via Twitter, LinkedIn or good old Email.

Post image taken by Sunny M5 published under CC BY-NC 2.0.