Problems With Prioritization: A Glass Jar Metaphor
7 July, 2021
Superhuman is in hyper-growth. Our customer base is growing quickly, and so is our team. That means we can — and must — execute more than one project in parallel.
Our most important priority for the quarter was to build the ability to create calendar events. We staffed as many engineers as we could on the project but knew that past a certain point, increasing team size does not accelerate a project’s progress, per the mythical man-month theory.
Our next most important project was bulk actions— an equally big and challenging feature. If we worked on 2 large projects in parallel, bottlenecks would close us down. Both required shared resources like product and design or senior technical architecture.
Around the same time, a new engineer joined our team. We wanted to strike a balance between launching him into an impactful project and giving him space to understand Superhuman’s product and codebase.
Two options were obvious to consider and each had its own tradeoffs:
- To add the new engineer to the ongoing top priority project, though it was already well-staffed. a. Pro: People were already working on it, and the new engineer would quickly ramp up.
b. Con: There was a hard deadline associated with it, and the urgency it entailed made it not the best learning environment. As a beginner, it was questionable if they would be able to make a meaningful contribution. Also, adding more people to a well-staffed team could make it less effective.
- To add the new engineer to the second-highest priority that was not started and not staffed. a. Pro: It was the next highest priority project on our roadmap.
b. Con: Working on this project in parallel could slow down the first project due to shared resources of product, design, and senior technical architecture.
We decided to go a third route. We took a self-contained customer-facing feature of less priority which didn’t require the same amount of architecture or design effort but was nevertheless useful and valuable to customers. The more relaxed environment would also allow the new engineer to become familiar with the codebase at his own pace.
As it turned out, prioritization is much more than working on the most important projects first. Instead, prioritization is all about balancing resources, knowing where the gaps and extra capacity are and how those can be filled. To better explain this thinking, consider a glass jar:
A glass jar represents your team’s overall capacity. Big rocks are your strategic projects of the highest priority, pebbles are nice-to-have enhancements, and particles of sand are minor tweaks that wouldn’t make a big difference individually but add to the overall experience.
The order that you fill in the jar is critical. If you put particles of sand first, you will not be able to put big rocks. If you cram it with big rocks only, you will have a lot of unused space. We wanted to start with big rocks, add some pebbles, and pour in the sand in the space between the two. By doing so, we could maximize the capacity of the jar. Therefore, we put our calendar feature first, but instead of the next big rock, we added a pebble that could fill the gap - a web application feature called quick quote.
- Prioritization is not just about rigidly following a stack ranked list, but it also requires appropriate balancing resources and managing dependencies. It requires creativity and flexibility.
- Staffing projects can be a game of Tetris: not all pieces fit together well, and some configurations leave unnecessary gaps. Ensure your product backlog includes items of various sizes to enable the team to work efficiently.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he diligently managed a product in one of the biggest eCommerce companies by being an individual contributor.
Adi Purwanto Sujarwadi
VP of Product at Evermos
James Engelbert, Head of Product at BT, recalls when he had to battle imposter syndrome when managing a new team.
Head of Product at BT
Albert Lie, former Founding Engineer and Tech Lead at Xendit, didn’t know what it takes to become an early engineering hire and not a lot of people around him experienced this unknown and arcane path. He had to learn it the hard way from the pitfalls he encountered along the way and he has been creating numerous frameworks to measure his growth and keep burgeoning in this role since then. He codifies and expresses the systems he put in place surrounding the balance of customer inquiry to product building and growing the engineering team.
Former Tech Lead at Xendit
Matt Anger, Senior Staff Engineer at DoorDash, shares how he took the risk and shipped features in a startup.
Senior Staff Engineer at DoorDash
Richard Maraschi, VP of Data Products & Insights at WarnerMedia, shares his insight on incorporating data science, AI, and product management to overcome slowing growth of the company.
VP Data Product Management at WarnerMedia
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.