For many years I have been working as a developer, absorbing the knowledge and the plethora of possibilities a few lines of code can achieve. Then one day I got a call from my manager who asked a question that I hadn’t prepared myself for - “Would you like to become the tech lead for this project?”. A myriad of thoughts rushed through my head but the focal point of them all was “How the hell does one become a tech lead???”.

In this blog, I shall go through four aspects to consider when transitioning to a tech lead role. I shall use my own experiences and mistakes in an attempt to help you as a developer when you transition to becoming a tech lead.

Have a Firm Grasp of the Tech Stack

As a developer you are required to know (and learn) the tools and platforms for the specific tasks you’ll be working on. When transitioning to a tech lead, your previous hands-on experience with the tools, platforms and technologies is paramount to be able to guide, support and influence the team’s technical direction. Consequently, having a firm grasp on the tech stack will also help build self-confidence, help you better explain ideas to the team and develop a mutual trust.

To help with this, I always ensure to have a local or a developer sandbox that can run most (if not, all) of the tech stack. This is crucial to be able to run tech spikes, proof of concepts and help triage and troubleshoot any issues the team may raise.

A tech lead should never stop coding. It has been said that once you become a tech lead that the number of meetings, planning and administrative tasks you have will increase. Despite this, it is just as important to still stay close to the ground and be able to ‘get our hands dirty’ and code.

Understand the Solution

As a developer, there’s a feeling of being a small (but important) cog, knowing that the tasks you’re working on contribute to the entirety of the machinery. As a tech lead, you become the point of contact to various stakeholders (client, business analysts, solution architects, etc.). Therefore, it was vital to understand the solution architecture. This understanding, coupled with a firm grasp of the tech stack, has provided me a way to help and guide the team on different considerations (e.g. performance, scalability, security, etc.) while writing code.

One thing to be mindful of is falling into the trap of the Ivory Architect anti-pattern, wherein you’re making technical decisions without understanding its overall implications and the maintenance required.

What I have also found helpful is to organise ‘brownbag sessions’ with the team. These are short 30 minute to an hour sessions to illustrate various components of solution architecture to the tech team, so that they can appreciate how their work fits in the grand scheme of things. This opens up the communication within the team, allowing them to further probe into design decisions and considerations. This will also ensure that you get the developers’ ‘buy-in’ and encourage their ownership.

A mistake I’ve done in the past is to only give individual developers just enough information to be able to do their tasks (almost at a pseudo-code level). This controlled and constricted information flow resulted in creating a tight coupling and bottleneck, slowing the team’s growth which can lead to a demotivated developer. I know that some developers like this approach of being ‘spoon-fed’ the design. However, I personally feel that in the long run, it’ll help the developer tackle hard hitting bugs, support the final product and feel accomplished.

Learn to Delegate

As a developer, I felt a great deal of satisfaction in solving a complex problem, which involved searching up various ways and patterns on achieving the desired result, coming up with an elegant solution and fist pumping when it worked.

When transitioning to a tech lead, I still looked for getting the ‘kick’ of solving problems and my first instinct was to take over the complex problems and work on finding a solution myself. I learned the hard way, that this approach is not only unsustainable in the long run (it can lead to burn out and stress), but also can demoralise the team due to an implicit lack of trust in them to work on the tough problems. Being given a challenging problem or even a new technology to learn as a developer is exciting. It reenergises them and relieves me from bearing all the load. Learn to delegate the tasks, especially those that you know can be accomplished quickly and focus on staying ahead of the team by looking ahead and navigating the team away from unwanted or unnecessary tasks.

Establish a Culture of Openness

As a developer, there were times when I just wanted to be left alone to code and other times when I needed people’s experiences and skills to carry me through a difficult problem. Transitioning to a tech lead is not any different, although now the consideration and understanding of everyone’s experiences and skills can help carry the team through the tough times particularly in the the current ways of working.

I make it a point to have a 15 minute one-on-one conversation with my developers once or twice a month to check-in on them and to provide a space for feedback on three things:

1. What do you think you’ve improved on and could do better?
2. What do you think the team improved on and could do better?
3. What can I do better as your tech lead?

Think of it as a mini retrospective and a chance for the developer to voice anything they like with no judgement. I got this idea from a Software Engineering podcast featuring Markus Blankenship about motivation. I found that after adopting it (alongside this Google study of successful teams), I was able to shape the team using their experiences, skills and aspirations, creating an environment of collaboration, growth and high performance. The openness allowed the team to communicate better and improve on the platform together.

In summary, the fundamental lesson I learned as I transitioned to a tech lead is to have a sense of appreciation on the technology, the problem to tackle, the encompassing team culture and, most important of all, the developers I work with. Getting a pulse on these aspects has helped my transition to a tech lead manageable and very rewarding.