This is one engineer’s experience in a very specific role in a very specific environment (fast paced, high growth tech company). Your mileage will almost certainly vary. I’ve tried to balance this with perspectives from other tech leads in my company. The target audience is tech leads and managers who want to partner better with their tech leads, as well as engineers who are looking to operate at a staff level in a tech lead archetype.
Tech Lead for a group of three infrastructure teams (~20 ICs)
The tech lead for my broader org suggested that I “identify and work towards specific outcomes for my team, rather than processes.” This helped me understand that process that works for other people in the company does not necessarily help me achieve the outcomes my team needs.
I work approximately 6.5 hours of structured time during US business hours every day, shifted slightly earlier or later if I’m working with someone in Europe or APAC. The relatively short duration is always surprising to folks but I know that I’ll end up doing half an hour or one hour of Slack / email / docs outside business hours which costs me roughly twice as much. If I get paged outside business hours I’ll come in late the next day. If I’m woken up[0] I’ll take half a day off because my health issues require good sleep. I’ll use this time for a balance of sleeping in plus a recharging activity like sitting by the beach or in nature. I try to end my work days with a run by the bay (the office is right next to it) and a quiet moment under the trees.
I’ve taken three trips in the last year with a focus on family and close friends in India as I didn’t get to see them for the first two years of the pandemic and I typically take two weeks off each time. In the past I’ve found three weeks to be ideal for my personal recharging, usually resulting in wanting to program personal projects by the third week. Unfortunately this makes getting back into work harder as my company moves pretty fast and there’s a lot to catch up on when I’m back. I balance this by taking vacation more often.
I use these breaks as an opportunity to hand off work or responsibilities to people who I think can grow through it. A fellow tech lead recommended I “provide opportunities for folks on the team to grow in their leadership skills, for example by identifying projects they can drive.” Excitingly, I sometimes find that I do not need to pick the work back up as the person who was temporarily responsible is thriving in the new role.
A tech lead in a peer org encouraged me to “identify work that you[1] and your manager are energized about and strike a balance around who does what for the team.”
I’ve blocked off about three and a half hours of focus time on my calendar every day because the nature of my work results in my calendar filling up otherwise. Some people thrive in meetings (e.g., my manager), some have a higher tolerance for them (the tech lead for my org) and some people hate them and strive to minimize them (primarily engineers, some managers). I find doing more than three hours of meetings draining to the point where I’m unhappy and not effective. If a meeting is scheduled in my focus time I usually ask the organizer to move it (if they really need me), point them to someone else who can help them or in certain situations (e.g., it’s something that can’t wait and involves folks busier than me) I’ll attend it and move my focus time around.
A peer tech lead explained that “technical leadership for multiple teams requires careful prioritization of where your time is spent because you cannot be everywhere at once” and I put a lot of effort into getting good at figuring out the priority of work that comes my way.
My rough model is to figure out if it is a company-ending issue (security risks leading to loss of reputation or highest severity incidents) or work that saves or prevents additional expenditure of $XX millions annually. If not, I look to see if this would help the team increase its impact by improving its culture, shielding in-flight projects or helping engineers grow in their career. Finally, I evaluate the impact of the work to my personal growth. This could look like learning something new, becoming the expert at the company at X or an opportunity to work with a new team or in a new role.
When in doubt I default to finding someone else to do work and help them if necessary. This helps folks around me grow and lets me spend my time on urgent work that no one else can do. My tech lead’s approach is to “make a list of priorities for the team and make sure everyone is working on something important”.
My tech lead also has a viewpoint that “tech leads have the opportunity to take on work that can fail”. If it fails, there’s limited impact to my career due to the various successes that balance it. If it succeeds, our bet paid off.
The flip side of prioritization is also valuable. I was chatting with an engineer who is earlier in their career and they mentioned feeling unproductive. They shared a spreadsheet of everything they wanted to do that week and I was surprised to see eight things on their todo list. A tech lead in a related team had recently reminded me to “protect my team and make sure folks earlier in their career or less-tenured at the company do not get overloaded.” I helped them get a couple of things off their plate and coached them to work with their manager and team on addressing the remaining work in a sustainable manner.
I explained that I literally had one thing I needed to do that week and if something more important came my way I would drop it. That particular week I had an example where my main priority was a specific task on my primary project but a more important project (saving $XX millions annually) needed urgent assistance. I put down my work until I was able to unblock the other project. I would much rather plan to do one thing and end up doing six tightly scoped things than aim for eight broad things that are almost certainly mis-estimated.
As a rule of thumb I shared that I estimate any work I do (however small) to take three days given my meetings and other responsibilities. That’s roughly one day for me to learn how to do it, one day to do it and get feedback and one day to incorporate feedback and roll it out. There are engineers who are far more effective[2] but I’ve learned to be honest (with myself) with what I can get done especially within the constraints of my role. A tech lead in a sister org frames this as “defaulting to saying no allows for others on the team to grow”.
If something is a lower priority e.g., not the main focus of a project but a nice-to-have, I don’t work to a specific timeframe. If this has impact to the asker or a timeframe is unavoidable I will try to find someone else to do it instead. My tech lead encouraged me to be frank and “be upfront when your team does not have the time or resources to do something”. To balance that out, the tech lead for the broader org said “if there are folks who are very unhappy about something, make it your problem”.
Another gap I see in contrast with other engineers is how frequently I ask for help whether it is large or small. My threshold is spending under five minutes being blocked. I respect folk’s time by spending those minutes diving as deep as I can, typically reading the actual code that I’m trying to understand or if it’s beyond my knowledge, reading the documentation. Similar to the previous point, I’m brutally honest about my limitations and am not shy about sharing this. A few minutes of someone else’s time can save the organization hours of mine, in effect multiplying their impact dramatically. I highlight their contributions to the project and document official feedback that they can use for their performance review.
This approach extends to projects or meetings - I’m always happy to point folks to the right technical expert, only stepping in if there’s a disparity in power or a gap in technical alignment. A peer tech lead framed this as “technical leadership is a collection of opportunities; while there may not be someone on an individual team who can take on all of them, it’s quite likely that there are folks who are interested and capable of taking on some of them”[3].
My surrounding org values the following (in priority order) in tech leads:
I try to pick up small pieces of work that will help folks on other teams wherever I can. On a purely selfish note, this makes it easier for them to prioritize helping me or my team when we need assistance. It’s easier for tech leads to value this work because even if it’s a temporary hit to productivity it helps the broader org and has far-reaching consequences for our teams. A technical leader in a sister org advised me to “make it really easy to cargo cult the right thing”[4]. By doing this every time someone needs my help I often never need to do that work again.
This approach extends to helping folks in my teams. The same leader had reminded me to “remember that we’re dealing with people, not systems”. I chose to mentor a mid-level and an entry-level engineer this year. Focusing on them resulted in a noticeable second order effect on the systems they were working on and their increased impact resulted in successful promotions.
I prioritize reading a high percentage of emails (even if it’s just the subject) in my part of the company especially notes and project announcements. I also try to read most docs[5] authored in my org and where possible I provide feedback. As the scope of my role has expanded information has started to flow to me and I’ve had the opportunity to redirect it to the right folks. The tech lead for the broader org told me “figure out where the need is for you to solve a problem vs. where you are needed to connect folks”.
My tech lead encouraged me to “try to understand what everyone is working on, enough to be able to represent them if necessary”. Along with the other strategies above this helped me turn around a project to help them surpass their goals amidst challenging constraints.
I’ve made it a habit to privately estimate the progress and impact of projects, whether I’m personally involved or not. I view my opinions as conservative or even pessimistic but I’ve often found that when I’m asked to help out the situation is even worse than I had perceived from the outside[6]. I’ve learned to privately assume the worst and enjoy being pleasantly surprised. If I see signs that my assumptions are being validated I flag the issues I see and offer my help, typically by helping them unblock themselves. The tech lead for my broader org pointed out that “it’s not necessary to be the person who does all the things, even if you can do them”.
Understanding the progress of external projects helps me prioritize asks that come into the team and schedule them appropriately. Having an intuition for the progress of projects within my group of teams helps me understand which ones need support. As a peer tech lead in my org pointed out, “tech leads have a perspective on the ground that managers may not - it’s useful to triangulate and give managers pointers to where to dig in”.
The tech lead for my broader org encouraged me to “be aligned with the manager of your team on a running list of priorities and figure out who will do what”. I do this in a weekly meeting with my manager that recently began to include the managers in my group of teams. A tech lead elsewhere in the broader org went further and said “it’s important to make sure you’re aligned with your skip manager (and potentially higher) through regular 1-1s”. These steps provide me with a critical feedback loop on my intuition.
If you’ve made it this far, congratulations! I encourage you to work sustainably, recharge often and set and enforce clear boundaries. Ruthless prioritization, doing one thing at a time and getting as much help as you need are valuable tools in being effective. My perspective of being a tech lead involves helping others, growing an awareness of the broader organization and building an intuition for impact and progress. Stripe is hiring and I’m always happy to chat.
0: I hate being woken up in the middle of the night, so any time a system or team wakes me up I make it my immediate priority to address the situation so that I’m never woken up for that issue again. This could look like addressing reliability issues with a system or improving the investment on that system by handing it off to a team that’s a better fit or providing the folks who woke me up with the tools they need to self-serve in the future.
1: I love helping folks technically, building technical alignment especially between conflicting viewpoints, making sure various architectures and plans are heading in the same direction and getting to work on impactful, ambiguous and technically challenging problems.
2: I am fortunate to work with a 10x engineer who effectively multiplies his impact by doubling or tripling the impact of the rest of the team. He does this while reviewing ~all their PRs with extremely detailed feedback that helps them grow, answering ~every question that comes into our team and tackling the hardest challenges in the shortest time with the most well-built code. That’s not all, he mentors his team mates to help them become experts on the codebase. Over the past few years I’ve seen him go from being a complete newbie to the org’s expert on various systems and technologies multiple times. I know that when my code passes his review I will have learned something and become a better programmer.
3: Interestingly, there are folks who are adamant that they do not want to be a tech lead but are actually providing excellent technical leadership to their teams. I’ve learned to limit my assistance to the parts of being a tech lead that they have an aversion to.
4: Whenever I see someone who ran into a foot gun I try to track down where this came from and update their unofficial runbook that points to another unofficial runbook that has a typo or whatever.
5: Speed reading is a secret power - I read enough to have a rough understanding of what’s going on and remember the title and author, prioritizing breadth over depth in the first pass. When it’s time to actually dive in I will hunt down and actually read the relevant doc.
6: I recently heard a delightful name of “watermelons” for these kinds of projects, green on the outside but red within.