Reflections after one year of Tech Leading
I still remember the exact moment in August of 2020. I, a "tech lead" just one year out of college, had just received a meeting invite to the biweekly software platform tech lead/engineering manager meeting. The meeting was filled with Senior and Staff engineers that were revolutionizing the computer industry when I was still crawling in my diapers. I was onboarding two engineers with extensive industry experience onto my lowly team of one, and my manager that I heavily leaned on had just left the company. I remember the mixture of excitement and fear that hit when I realized, "oh shit, I have no idea what I'm doing".
Since then, I've rolled up my sleeves and dug in, hitting so many "oh shit" obstacles along the way that I've lost track. A rollercoaster of a year later, I finally took some time to step out of the trenches and see how much progress I've made. The following is a nonexhaustive list of lessons I've learned from all the mistakes I've made, and ever so occasionally, some of my successes.
Delegate, even when it's work you don't know how to do
When I first took on the role of tech lead, I struggled to efficiently assign tasks to the engineers that were onboarding to my team. I mistakenly wanted to make sure I knew how to do a task myself before I assigned it to an engineer, because I wanted to be able to effectively guide the engineer if they ran into any problems. This slowed down our team overall, and frustrated the other engineers, as I became a bottleneck and they were unable to individually own and drive any part of the system. I quickly killed this bad habit after my new manager gave me feedback, saying "your unwillingness to give the rest of your teammates hard tasks are hindering their ability to grow and learn. As you move higher in leadership, you're going to ultimately have to continue giving tasks and asking other people to do stuff that you don't know. You have to trust them."
Foster an environment where everyone has a voice
"If you want to go fast, go alone. If you want to go far, go
together."
- African Proverb
One of my rarer successes was creating a team culture where everyone felt heard and empowered to bring their ideas to the table. I was well aware that even though I had the longest tenure on my team and the most context on our engineering systems, I had less working experience than many of my teammates. I deliberately made it a point to speak last so as not to bias any discussion, solicit feedback on my suggested solutions, and pointedly make space for quieter teammates to have their voices heard. This was continually called out as one of the best parts of our team in our regular anonymous feedback surveys.
Regularly sync with key stakeholders across the company
One of my biggest mistakes, and one that I still struggle with, is syncing with key stakeholders across the company. Sitting down and chatting with people across the company has innumerable benefits. Other leaders get clarity on work that you're doing and how you're impacting the firm, and are able to more easily make key decisions with you and your team in mind. At the same time, you get to toss ideas off of extremely smart people and learn from their experiences. When you finally make decisions and long term plans that have been guided by discussions with other stakeholders, you inadvertantly bring them onboard as champions of your plan who can vouch for you and support you on your endeavors.
Protect the team
When the team was in its infancy, we were filling such a big demand at the company that there were so many things to do. On top of that, there were constant external forces rocking our team, such as the latest big platform migration, the super senior engineer asking us to take on tasks, or incident response follow ups that were assigned to our team. This nonstop flow of tasks to take on had our team running back and forth all the time, and we never had opportunities to work on projects that we were responsible for delivering on. At a certain point I realized that the buck had to stop somewhere, and it was supposed to stop at me. For our team to be effective, I had to run intercept, deferring incoming work for later, negotiating stop gap solutions, and sometimes just straight up rejecting work that was hoisted upon us.
Be intentional about feedback
I heavily focused on leveling up the engineers on my team and ensuring that they were set up for success. To do that, I needed to provide regular feedback on areas they were doing well in and areas in which they had room to grow. However, in my regular 1 on 1's, I always struggled to think of anything constructive on the spot. Conversely, when I had strong feedback to provide, bringing it up always felt incredibly awkward and painful. After several frustrating attempts, I finally found a framework that worked for me. I started out every single 1 on 1 by asking for feedback from my partner, and providing any feedback that I had. Doing so put the expectation of receiving feedback into my teammates' minds, making it easier to broach the subject and less of a surprise. In addition, every Friday I blocked out a chunk of my calendar and dedicated it to reflecting on feedback that I could provide my teammates to help them improve.
Documentation is invaluable to scaling
The first engineer to join my team was a documentation evangelist, and was popularly known for always asking "is this written down somewhere?". I didn't truly appreciate the value of documentation and his obsession with it until my team started to scale out, adding 4 new engineers within the time span of a few months. It was amazingly efficient to be able to point new engineers to documentation that explained historical context, rationale for design decisions, and instructions on how to interact with systems. When in doubt, write it out!
This exercise of reflecting and writing down my progress so far gave me a brief moment to appreciate how far I've come. At the same time though, I, more than anyone, know how much more there still is to learn. Here's to diving back into the trenches and searching for the next "oh shit" moment. 💩
