Balancing Multiple Assignments: Determine What Is "Important" in Each of Them
3 August, 2020
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.
This problem troubled me as we were building a new feature that spanned multiple teams while I was simultaneously immersed in my regular day-to-day responsibilities.
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 a 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 definition are things they own. 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 defining the scope 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 other 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 weekly, but I have been able to step back a bit more and focus on other initiatives.
- 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 great 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 on 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Krishanu Sengupta, Product Lead, AI & ML at Compass, offers insight on how to develop into a role you are passionate about by obtaining experience in roles that build relevant skills.
Product Lead, AI & ML at Compass
Dursun Mert Akkaya, Software Development Manager at Product Madness, encourages a change in mindset for heavily technical individuals as he explains the importance of communication skills.
Software Development Manager at Product Madness
Tommy Morgan, VP Engineering at Crystal Knows, recalls a time in his career when his values didn’t align with his superiors and shares his insights on preventing this outcome when taking on a new role.
VP Engineering at Crystal Knows
Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.
Head of Product at ROI Hunter
Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.
Head of Software Quality Assurance at FICO
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.