Being a tech lead doesn’t mean having all the answers

It is sometimes easy to fall into the unhelpful thinking pattern that tech leads should know everything. But that’s unrealistic and Google’s Jack Franklin is here to show you why.

In October 2021, I was asked to step up from an individual contributor (IC) role on my small team of three engineers to a technical lead. At the time, this offered position was a completely new prospect to me. Taking that step up would increase my responsibilities significantly, requiring me to set the technical agenda and approach to building a product. 

At first, I was thrilled but also intimidated by the role. My reasoning for this was mostly rooted in the fact that the person I was taking over from had had over ten years of experience in the field, being also widely considered an expert in the subject matter. Comparatively, I felt my background in this field was not as varied.

However, through exposure and my continued involvement in this project, I was able to learn that extensive expertise did not immediately equate to being a good tech lead. 

Your expectations are not the same as everyone else’s 

Walking into this role, I held the assumption that people expected me to have abilities that equaled that of my predecessor, with a deep understanding of the codebase and specific product. I anticipated that my team would expect me to guide them and provide answers when they were unsure of the next steps. And if this was the case, I wondered what would happen when I didn’t know the answer to something asked by a stakeholder, another team, or one of my team members.

Unsurprisingly, this viewpoint was unsustainable and, of course, completely incorrect. I soon realized that knowing everything and having all the answers was an impossible task – a fact that is true of every project – especially in mine, which focused on web tooling. 

The tool which I lead was one that has existed for ten years; it is an area that has changed drastically and multiple times, seeing countless iterations, rewrites, and developer contributions made to it. It would be impossible to build up knowledge of all of its nuances, history, and approaches within a short space of time. 

Therefore, being concerned about a lack of experience having just joined a team or become the technical lead is pointless. No one else can reasonably expect you to have all the knowledge on a codebase that is newer to you.

Acknowledge that you don’t know everything

I decided to acknowledge the fact that I didn’t know everything to my team. Doing so was freeing and transformative, both for them and myself. The act itself wasn’t an admission of inferiority or a lack of skill, but a nod to the fact that I was new to the role and did not have the context of the previous tech lead on the team.

Admittedly, the first few instances where I asked for help or declared a knowledge gap was slightly uncomfortable for me, but these instances were embraced by my colleagues. Without exception, they were understanding and delighted to be able to clarify concepts and decisions for me. 

In fact, by adhering to a code of faking it until I made it, I realized I was hindering my teammates more than anything else. Many of them are experts in their field – so, who better for me to ask and learn from? My pretending to know everything only meant I was turning my back on the wealth of expertise that was surrounding me. 

Once this realization hit, I embraced knowledge gaps wholeheartedly, regularly emailing colleagues for assistance, spending hours diving into the codebase to increase my understanding, and writing technical and architectural documentation highlighting sections I didn’t know the answer to. I would invite people to help me fill in the gaps and they would willingly do so. 

Certain times, I discovered that many of the people who I asked (those newer to the company and those with many more years than me) also didn’t know the answer, and so my questions were forwarded to others. In these scenarios, not only did my knowledge increase, but my connections did too, as I had the opportunity to network and converse with individuals outside of my usual circles. 

Moreover, this also meant that my learning journey was highlighting areas of growth in other people’s knowledge, allowing them to propagate new skills themselves. 

And best of all? No one complained once. My manager didn’t suggest I needed to increase my output or change my behavior, and as a result of asking around, I gained more confidence in owning what I do and don’t know.

Being the unblocker

Once I realized that I didn’t have to hold all the answers, my role became a lot clearer to me. It’s true, tech leads shouldn’t know everything, but they should be able to guide their teams toward finding the right solutions to problems. 

For instance, recently a team member was stuck on a piece of work that was growing wildly out of scope. Every time we thought we had clarified something, more unknowns and confusion would surface the next time we looked at the problem. 

I didn’t know how to solve the issue, but I did know of someone on another team who would be able to help. I dropped them an email and arranged a video call comprising of myself, my colleague from my team, and this colleague from another team. Within half an hour they had answered all our questions and we had a clear path forward, with links to relevant documentation we would otherwise not have found. 

The value I added here wasn’t from my deep technical knowledge of the exact code at hand. Rather, it came from my connections and my ability to step back and know who else in the organization could provide the path forwards.

Final thoughts

Technical leads are advisors, guides for a team of engineers, and force multipliers. A good tech lead keeps their team productive, free of restrictions and blockers, and impacts the velocity of their team positively. I hope this article will empower you to embrace the unknown, working with the confidence to acknowledge the gaps you have, and to not fear them.