Plato Elevate Winter Summit has been announced (Dec 7th-8th)


Back to resources

Balancing Multiple Assignments: Determine What Is "Important" in Each of Them

Managing Expectations

3 August, 2020

Damian Schenkelman
Damian Schenkelman

Principal Engineer at Auth0

Damian Schenkelman, Principal Engineer at Auth0, explains how to balance multiple assignments, particularly when leading large projects while at the same time handling other day-to-day responsibilities.


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.

Actions taken

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.

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 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

Improving Team Execution in a Remote Environment

29 November

Vadim Antonov, Engineering Manager at Meta, details his process of implementing an organized execution system for his cross-functional team.

Vadim Antonov

Vadim Antonov

Engineering Manager at Facebook

Delegate successfully as a first time manager of Product Managers

24 November

Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.

Scaling Team
Building A Team
Coaching / Training / Mentorship
Psychological Safety
Cross-Functional Collaboration
New Manager
Andrew Tsui

Andrew Tsui

Director of Product at Startup

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

How to Build Rapport With an Introverted Manager

17 November

Piyush Dubey, Senior Software Engineer at Microsoft, shares his journey of climbing up the career ladder through awkward times dealing with an introverted manager.

Managing Expectations
Internal Communication
Coaching / Training / Mentorship
Piyush Dubey

Piyush Dubey

Senior Software Engineer at Microsoft

How to Increase Engagement Using the Right Metrics

11 November

Richard Maraschi, VP of Data Products and Insights at WarnerMedia, speaks on how he increased user engagement using measurements and experimentation.

Mission / Vision / Charter
Conflict Solving
Team Processes
Data Team
Richard Maraschi

Richard Maraschi

VP Data Product Management at WarnerMedia

You're a great engineer.
Become a great engineering leader.

Plato ( 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.