How to Balance Responsibilities: Prioritizing Personal Work vs. 'Glue Work' in a New Team Environment.

First, I want to acknowledge that this is actually very common! I personally faced this when I was transitioning into a TLM (tech lead manager) role at Meta. The classic story arc is:

• You are a good engineer and develop lots of context after several months or years on the team.
• As older people leave the team and newer ones come in, you find more of your time going into mentorship, helping others, and on-call support.
• You find it increasingly harder to do your own job given the additional demands on your time.

There is actually a healthy tension where you feel like you're doing multiple jobs -- that's the point where it's valuable to re-assess your job and ask for help. I have a few thoughts:

• Document where your time is going in a given 1 or 2 week period. Then categorize it in 2 ways and have a discussion with your manager.
  • Time you enjoyed vs didn't enjoy
  • Time you thought was well-spent (e.g. 1:1 time) vs wasted (e.g. asking the same question over chat)
• Try to move a lot of your knowledge sharing in more public forums, and encourage others to jump in as well.
  • For example, if you find yourself saying the same thing 3 or more times, ensure that it lives in a wiki somewhere, and be diligent about sending the wiki link to people instead of repeating yourself again.
  • Create a forum/chat for questions so they don't all go through you. Provide an opportunity to the others on your team to answer questions before you jump in.
• Write down what work you'd do if you didn't have the tax of all the glue work that you're doing today, and how much impact that would drive. Doing this should make it clear that it would be the highest leverage thing.

Once you have this buy-in from your manager, you hopefully have a strong ally in empowering the others on the team. Also, keep in mind that the benefit is not simply your ability to do higher-leverage work, but also that it creates a more resilient team.

Here's some related content:

• Giving feedback (part of the Effective Communication series)
• Improving on-call systems

Rahul already hit on most of the high points I’d suggest myself. One thing I’d state slightly differently, which is: If you take on the “personal projects” or “initiatives” and devote X% of your time (whatever you and your manager decide) and shrink enough glue work to do that, what gets dropped and who is going to pick up that slack?

Ideally you’re working your way out of a job in as many ways as possible. Don’t do anything for an extended period of time that no one else can do, be partnering and passing things over. Run one book club, then pass MCing/organizing to someone more junior for whom this team impact actually moves the needle. Run a knowledge transfer then have it recorded and good documentation, and let someone else take on being the point of contact for this. Whatever you are good at that others aren’t, it is your job to teach and transfer.

From there, recognize that you are growing and evolving, and as Rahul recommended, make sure that growth is in a direction you actually like. You shouldn’t be coding more, but coding critical things very efficiently. You shouldn’t be designing all of your teams modules, you should have best practices and a review process that puts guardrails on everyone else doing that. Eventually you should be working to spread this to other orgs if it’s effective, or find how to adapt your process into a common framework. It’s a scaling game now, and you don’t scale by coding 10x as much.

Lots of great stuff here - Thank you so much for such a detailed question with thorough context! I have a lot of resources in mind that are hopefully helpful.

Upskilling Others

As a senior engineer, it is crucial that you work through others, but you have to be ultra-efficient about it. A failure mode that you seem to be dipping into is that you're spending too much time training mentees, and the "gains" aren't landing fast enough.

• Session #5 - Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta
• "How do you answer questions effectively?"
• "How to ramp up a slow learner?"

Improving Oncall

Oncall is one of the most important processes on any engineering team, and its quality will play a huge factor in whether the team's tech leads like yourself will be able to scale themselves. If you haven't already, you should add my upcoming event to your calendar: Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project

• "How to form a healthy on-call rotation?"
• "How can I improve the unstructured, chaotic oncall rotation I'm on?"

Managing Time And Pressure

This is going to be covered in the linked resources, but something I want to make crystal clear is that as a tech lead, you need to be 100% okay with dropping things. It sounds counterintuitive, but you will need to drop things a lot in order to maximize your impact and contribution to the team.

• "Who do you help, given there are only so many hours in the day?"
• "How does one effectively handle pressure especially when the stakes are high?"

Appreciate the detailed response and sharing your perspective, Rahul, Lee, and Alex. I agree with the points made above and have personally witnessed several ways to apply this in the recent month(s) working with the new engineering manager in a new team.

Will keep you posted on this thread.