What should a Tech Lead focus on and why?

In my experience as a Tech Lead, my focus is on ensuring the team’s vision and direction for the code matches the product’s vision and direction. As part of that work, I need to have conversations with both the team developing the product as well as the people driving it and anyone else that will live with that product (operations, other teams etc).
Most times, this calls for conversations. Be that in meetings or in corridor conversations or in front of a screen, most of the value I bring is not code producing. I will use the code as means for a better understanding from the team’s perspective and I might tackle a problem that I think is important to help me have other conversations but, end of the day, the majority of the code will come from the rest of the team. As a result, they know better than me what can and cannot be done although, sometimes, the team lacks experience to realize what is possible.

As I see it, this focus is a direct consequence of the team and organization structure. When there are less than 10 people involved, it is not that more expensive to get everyone in a room daily and adjust our shared vision. As the teams grow in size, it becomes unmanageable to use this solution and conversations take too long. We then chose to pay a communication overhead by having a person who bridges the multiple views and brings a vision for the technical aspect of the product/project. That’s the Tech Lead.

What are the challenges of Tech Leadership?/What has been your most challenging situation and how did you handle it?

Finding a good balance between sharing time with the dev team, business side and external concerns. Concerns and questions come from everyone and, most of the times, it is very hard to have a good answer right away. It means context switching a lot and being dragged away from conversations a lot. Being able to spend enough time with each party so that everyone shared the same vision about the product/project is probably the most challenging aspect of Tech Leadership.

My most challenging situation was at a client that had 3 major systems, one of which had a team of about 20 developers for whom I was the Tech Lead. One of our releases was a major cross-system release of 3 features that were demanded by our client’s clients. The 3 months that lead to the release stretched me thinner than ever having to balance between the needs of my project, a new team formed for the core of new feature, the 2 other systems tech leads and the business people involved (1 product owner for my system and 1 for the new feature). Trying to keep our technical delivery working as well as help the new team match the architecture we were trying to move to in our system and ensuring none of my teammates was feeling lost and abandoned was very hard.
I’m not sure I handled it as well as someone could but my approach was mostly to put down a list of things that had priorities when it came to my time. My team and the new feature team came first since I needed them to work together. The 2 other tech leads had second priority if they had urgent matters but lower if they wanted to discuss architectural concerns. Business people asking for more features had the lowest priority. We were already stretched and I knew adding more work would be insane unless we were ahead of our plans. As a result, when interruptions would come, I would postpone the conversations according to the priority. Managed to get us all aligned and deployed something that worked although the end result didn’t achieve the architectural goal we had. The following few weeks were a battle to allow us to work on improving that architecture but we managed to get approval and spent the extra time we had forecasted making things better.

What are your secrets to managing time?

I need things in my calendar. Not events assigned already but invitations. This way I prioritize things upon accepting or not. Along with that, I hold 4 notes in my evernote:
1. TODOs: list of actions to be completed and dates for completion as well as estimated time to complete. Added any time, reviewed and updated daily.
2. Short term goals: measurable outcomes to be achieved by the end of the month. Updated monthly at the beginning of the month.
3. Medium term goals: measurable outcomes to be achieved in the next quarter. Redone quarterly at the beginning of the quarter and slightly updated monthly.
4. Long term goals: measurable outcomes to be achieved in the next year. Redone yearly and slightly updated quarterly.

How do you strike the balance between writing code and dealing with other issues?

I love coding so I mostly have to control myself to not keep on doing it all the time. Most times, there are some dynamics around the teams I’m with that mean certain times are more prone to being interrupted and others are less. I try to make sure I book the uninterrupted time for sitting with the team pairing and getting up to date with implementation problems. The rest of the time will be trying to deal with other issues and concerns.

Hugo’s question: What decisions fall on the Tech Lead comparing and which fall to the team?

In my view, ideally, the vast majority of decisions regarding the actual code will be taken by the team. Decisions about architectural concerns (e.g. breaking part of the app into its own app) should be shared between the Tech Lead and the team. The only case where the Tech Lead actually makes a decision is when the team is stuck. If there is no actual consensus between members of the team, the Tech Lead unties the decision.

Hugo’s background

Hugo has been a consultant at ThoughtWorks since 2011 and has worked as a Tech Lead for a team of over 30 developers that shrunk to a team of 8 developers. Before ThoughtWorks, he was in a six people team building a brand new software in which everyone was empowered to make architectural decisions. He saw many successful changes as well as some less successful decisions.