I’ve recently become a mentor at the plato network. As part of that I’ve worked with them to write down some stories about my experience at Auth0. I thought it’d be interesting to share those stories in my blog as well. Originally published this one here.

The Problem

As a senior engineer, you will likely technically lead one or more large initiative(s), while at the same time being entrusted with handling a great number of day-to-day responsibilities. As a result, you won’t be able to spend all of your time and give your undivided attention to that one large initiative. You will have to determine how much time to spend on each different task and how to streamline your focus.

I ran into this problem as I was tech leading a feature we were building across multiple teams, while I was simultaneously immersed in my regular day-to-day responsibilities.

What I did

The success of the large initiative was critical for us at Auth0, this was a new product.

First and foremost, I identified the skills and competencies of all team members working on the large initiative. I considered their seniority, how long they had been with the company, and how familiar they were with the product. That allowed me to understand their strengths and spot the areas they might need help with. I also identified the critical things to get right. From there, figuring out the focus areas is simple: the intersection between critical things and team skill gaps.

For new products, we typically ship an HTTP API first, before the UI. Also, when starting new products everyone is eager to contribute ideas and “solve all problems”. I decided to ensure that:

1. The HTTP APIs (our product interface) was aptly designed.
2. We wouldn’t fall for scope creep.

As a result, I decided to work very closely with the Product Manager (who was new to the company), as both scope and API priorities are things Product Managers own at Auth0. I met weekly with them to share context about the company and was available for questions.

From the very beginning, I was selective about what meetings to attend. If the team was working on scope definition I would make sure to attend, but if they would be discussing how to implement a particular feature, I would most likely not attend. The exception was meetings when we discussed functionalities that affected either the system as a whole or multiple teams. On the technical side, I did work a lot with the team on writing the design doc (RFC) after the proof of concepts were done, and also reviewing the implementation with them before our Early Access with customers started.

After a while, the initiative is progressing fairly well. The core parts of the implementation are in place, key decisions about scope and technology have been made, and scope and priorities are defined. I continue to work with the team and meet with them a couple of times a week, but I have been able to step back a bit more and focus on other initiatives.

Lessons learned

• As you grow you will have less and less time to entirely focus on a single project and soon you will spread thin. In general, this is a natural consequence of climbing up the ranks; be aware of it and optimize your time accordingly.
• When wearing a tech lead hat you are accountable for the technical solution, even when you are spread thin. Prioritize how you spend your time to make sure the most complex, hardest to change parts are solved correctly.
• Identify key inflection points in the project where your presence could make a difference. I had to be around the team when we did a product discovery phase and when a large number of different ideas were floating around. That’s a moment when people normally think they should try every idea and I had to help them differentiate what would be useful and what would not. I also helped a lot with HTTP API design decisions though it is something that a is closer to the Product Manager scope at Auth0
• Make sure teams know you are there for them. Even when I was working with multiple things simultaneously, I often checked in with the team leads —from both Engineering and Product. While I was not always present and involved in the tiniest of details, I was unequivocally clear that I was there for them, that I was listening to their feedback and that I would ensure that nothing was missing or delayed from my side.

Conclusion

Juggling multiple assignments is a crucial part of growing as a software engineer. Figuring out what is important, prioritizing and being strict about time management are key ways of being successful at this.