Learning to say "I don't know"
In October 2021 I took on a new role within the Chrome DevTools team as a Technical Lead (TL) of the DevTools Performance Tooling team, who are responsible for all things website performance inside of DevTools, the most well known being the Performance Panel.
My journey to this point had begun a year prior when we started building a new panel that would come to be named Performance Insights. I was asked to build the panel, and for the first time in my career I came face to face with Chrome trace files. These are large JSON files that contain all the trace data that Chrome generates when asked to perform a trace, and it’s these that contain the information that we parse and present in the DevTools panels. It’s also part of what other tools like Lighthouse, or third-party tools like WebPageTest, use to display data.
There was a lot of knowledge and information about performance that I didn't know. This is something that I’m never comfortable with, but as a contributor to the team I felt happy admitting to my manager (and TL of the team) when I didn't know things, and asking them to jump on a video call to walk me through something. I’d never even used the HTML Canvas API, which I had to learn along with the intricate details of Performance tracing.
When I then became TL of the team, I was suddenly the person who people would ask questions to. On the first "official" day that I became TL, someone asked me a question about traces and how certain trace events are represented. I realised I didn't know, and I was going to have to admit it. But I'm the TL, I'm supposed to know that! I panicked; assuming that my lack of knowledge would now be unearthed and I'd quickly be "found out" as not being ready for this role.
As you've probably guessed, none of that happened. I decided to embrace not knowing, and put my efforts into figuring out how to find out and fill the gaps in my own knowledge. Sometimes I could do that by spending thirty minutes reading a trace file and understanding how the data is linked. Other times I could find an old design doc, or documentation that would give me the answer. And sometimes, best of all, I had to email someone else who I thought might well know the answer. This has been one of the best decisions I've made recently; emailing people to ask for help has not only given me the answers I need but helped me build relationships with a bunch of folks who I would never have otherwise engaged with, from all over the world. One of them even explicitly thanked me for being curious, and reaching out to ask!
Becoming comfortable saying "I don't know", or "I don't know, but I bet X will", or "I don't know, but I'll find out for you" has become one of the most powerful tools at my disposal. I've learned that being a good TL isn't about knowing everything - there is simply too much to know! - but about being able to fill those knowledge gaps and help your team be more productive as a result.