My Tech Lead journey

For a long time I thought about when will be a good time to write about my experiences of transitioning from a Software Engineer role into a Tech Lead role. With many things in life there is never a good time to do something.

There will never simply be an end to this journey. With every team I join, with every team member that is being added to the team, with every challenge you face, with every requirement and direction the company decides to go I will learn something and this might change how I think about some bits and pieces you will find this article. See this article as taking inventory in January 2020 after having worked in this role for about two and a half years.

Nevertheless, I believe I collected enough thoughts and experiences to try and share all this with you. I will refrain from giving any advice because it really depends on your situation that I don't know. Look at this article as a journal of things that happened to me and how I tried to handle the situation. I deeply hope that you will take something from this article, whether you are a technical leader yourself or about to become one. Enough intro, happy reading.

The journey begins

This journey starts in early 2017. By that time, I have worked for about a year as a Software Engineer at my company. The company itself was officially just about 15 months old. I recently changed to a team that required more focus and faster delivery.

With me an Agile Coach - and later on good friend of mine - joined the team. Together with a new PO we worked closely together to structure the work of the team and helped to add the necessary focus.

I naturally took over more of the organisational tasks, tried to bring order into the chaos. Not much later the Agile Coach suggested that I would become the Tech Lead of the team. I knew it would be a big change in how I would work and would challenge me a lot. My former manager - who was Head of Engineering back then and had personnel responsibility - told me that he doesn't think I am there yet. However, what he saw and heard from others was promising and he counted on me. He wanted to give me a chance.

What I learned before was that you usually regret what you do not do. Back then I knew, if I would not take this chance, I would regret it. I would ask myself later on how everything would have turned out if I would have taken the opportunity. So I did.

From the beginning the role was very unclear. Talking with my manager I asked how my work would change becoming a Tech Lead. Even he could not give a clear answer. There are just too many variables that influence how your work will look like. Back then a job description for the role did not exist.

It all broke down to leading a team towards excellence - without having a good idea what that actually means. Here are some bullet points of Tech Lead duties that I remember from the talks with my manager:

• Ensure that xy happens. How you do that depends on the team and what works for it.
• You are expected to write high quality code. After all, you are still a Software Engineer. It will probably turn out to be 70% coding and 30% something else.
  • No one can tell you what this “something else” means.
    • It could mean writing more documentation.
    • It could mean taking over organisational tasks.
    • It could mean leading the team towards making a decision.
    • It could mean handling interpersonal problems in the team. Back then the Head of Engineering had the personnel responsibility for all of the roughly 50 engineers which did not scale. So before escalating a problem the Tech Lead was usually responsible for dealing with the situation.

The first three months

The first three months felt enormously exhausting. The reasons for this have been:

• I tried to be an Individual Contributor (IC) and Tech Lead at the same time. This meant keeping the amount of coding the same while also doing much more in addition.
• I tried to look into details (IC thinking) and get an overview of what six senior developers produced (lead thinking).
• I tried to understand two new domains because I just joined a new team that was the core of the company.
• I tried to bring the team to decisions when they were very talkative (only senior developers \o/) and had strong, sometimes conflicting opinions.
• I tried to be in all the meetings and interviews.
• I tried to discuss and coordinate between us and other teams.

As the organization at that point in time was still very young all people in engineering got officially managed by one person. As this is clearly not enough when you have an engineering department of the size of 30 to 40 engineers we had to become inventive.

Because of that the Agile Coach on the team and I felt responsible for the general well-being of the team. We have been involved in hiring/firing (though not actually executing it). We were going into fights between the multiple A-males in the team and resolved them as best as we could.

At some point the team got more pressure from the business side. Our customers had been promised big features that fell into our responsibility. At the same time, we have been working on the oldest parts of the code base. We needed to make general improvements to keep the current customers happy. All of that we couldn't manage with the team and the amount of time we had.

Growing the team

We did not get any new joiners for some time. The advantage of that was that we had time to figure out how to work together. We transitioned from the storming phase into the norming phase (see Tuckman's stages of group development). We got pretty good at delivering and developed into a closely nit team. Having many proactive team members helped a lot and to cite a former colleague of mine: "We just crushed it!"

A few months later we got three new team members in a short amount of time, a bit later two more. This was a huge challenge for all of us and I plan to write a separate article about that.

Further down the road it got clear that we developed into at least two groups in the team. By then we have been 11 or 12 developers, 2 POs and 1 Agile Coach. The organizational and communicating overhead got too much. Also it became clear that we actually worked on two bigger products in one team. People were involved in conversations about code or business requirements that they barely touched. This was the right time to make a change.

The team split

We split the team into two, one per project. Each got one PO. Internally we developed a second Tech Lead that took over the other team. The split involved lots of talks about the desired quality of collaboration between the teams and outside the teams. If I remember correctly, it took us about one whole sprint for the teams to find their place, set up the organizational things properly and groove into it. Again, I plan a separate article for this part of my journey.

Leaving your team

As company priorities shifted an option popped up to join a currently understaffed team that would get much more attention in the future. It was hard for me to leave the team I helped building. However, I saw that this team was doing well, delivering, working together, helping each other out - just having a healthy atmosphere. I left with the thought that I would make room for the others to grow even more.

In retrospect this is what happened: other people stood up, took ownership and grew into new roles. As my Agile Coach, my PO and me had been a great team in the past we slowly moved into a different project team that got higher priority. The new team had non of those roles covered so far.

A new challenge

The team I joined bobbed up and down. It had a history of not delivering and researching too much to find the perfect solution. By that time two people had already left the original team, three new had been hired. When we were joining one of the three was about to leave. It wasn't a good fit. Overall the team consisted of one senior, one professional and one junior developer.

An additional person was able to code but was also responsible to steer the general direction of the project, was involved in company-wide discussions as well and was taking over PO work. In general, this person had too many responsibilities and could not help the team as a PO should be able to. From outside it felt the team had not found a good mode of working together and responsibilities were unclear.

The senior developer promoted the technical direction and had a lot of freedom doing that as the other two just joined some months earlier. My impression was that they were intimidated by the senior. Because of that they did not challenge the general direction the team had. On top of that, most team members did not have much experience with the chosen architecture. Hence, we needed to experiment a lot and obviously hit some walls doing so.

The challenges for me personally included learning a completely different architecture (event sourcing) and new programming language (Go). My image of a Tech Lead is a person who is not the best programmer on the team but has enough technical knowledge to write code in her domain, to steer the team and to help it moving forward. In the first three to six months I focused a lot on introducing standard processes and structure in the team. This would give team members more mental capacity to focus on delivery when applied subconsciously at some later point in time. I also pushed all team members to give input and challenge each other. Because of my passed experiences I helped maintaining existing, live Ruby services. Because of the points mentioned the time I could spend to dive into new technologies was limited.

I had the feeling I could not understand the technology we were using and the system we were building well enough to give guidance. More than once this lack of knowledge was a topic in 1on1s with my manager. I often was in doubt of how well I could support the team. I read up on the technology and ran through programming tutorials. That helped to understand the code and I was able to be helpful in code reviews. However, it didn't help to understand much of the system we were building.

To practice writing Go code I wrote a little tool that collects information of the services in our system and builds a service graph based on that. That helped me - and later on new joiners - to understand how the services are connected to each other and how information flows.

In the end, I settled with knowing less of the technology than each of the developers in my team. There was no way I could keep up with their speed of learning with the additional tasks I had on my plate. I helped the team by asking questions, pushing them to make decisions and develop them into equals in the team. This was less about technical knowledge but more about seeing the imbalances and finding ways to address them. And it was what the team needed most during those times.

Growing the team once more

After around six months the management understood that the system we build is a crucial part in scaling the company. By then the existing team of around four developers worked well together. We had the necessary processes set up, the PO that joined with me was able to build clarity about what needs to be build, the younger ones challenged the senior making the communication healthier. We exchanged ideas together, huddling around the whiteboard often to clear things up.

Hiring started slowly and by end of 2018 (roughly half a year after I joined) we got new engineers. This was a new challenge also for the younger team members as they haven't been in the company for too long themselves and needed to start mentoring others. They were now the "seniors" in the team with their six to twelve months of knowledge. We were lucky to get smart people that could be onboarded quickly.

Splitting the team once more

We grew steadily and when we reached about ten engineers we decided to split the team into two. This would allow us to have two separate working streams, which was nicely doable because of the architecture we chose. We also got a second PO which made both teams autonomous. The standards we set in the original team could often be transferred to both smaller teams.

The status quo

Now, 01/2020, both teams consist of overall twelve engineers, two POs, one Engineering Manager and one Agile Coach. Both teams are working independently from each other - sometimes even a bit too independent. As we are working on the same overall product we saw early that we needed regular syncs as technical decisions of one team might affect the other team as well - not on service level but on system level.

We introduced biweekly, very short sync meetings to enable all of us to talk about topics that would affect both teams. Those usually are very short meetings to align both teams and make decisions (~ 5 minutes per topic). Everyone is allowed and encouraged to bring topics. Bigger discussions are taken out into a separate session. Apart from that, team members take over responsibility for bigger topics in the project and grow continuously. In turn, this enables me to code more often, learn about the technologies we use better and generally be more involved in delivery again.

Another side effect of responsible team members is that the team is less and less dependent on me. In fact, my vision of the Tech Lead role is that a good Tech Lead - similar to a good Agile Coach - is helping the team to be self-sufficient so that she eventually is not necessary anymore as responsibilities in the engineering team are distributed between the team members. In turn, being a good software engineer is much more than just writing good, well-tested code in an acceptable time. Being a good software engineer also means to take ownership, to communicate well, to drive topics, to be proactive, to see deficiencies that need to be addressed, to judge how important certain tasks are independently from how fun they are.

Of course, there will be more challenges to come. Currently, we experiment with other approaches to bring the two teams a bit closer together. Also, with the teams growing we continuously need to think about clever means of communication.

I am curious to learn about your Tech Lead journey. What did you experience? What did work well for you and what not?

Post image taken by Richard Guy published under CC BY-NC-ND 2.0.