Problems With Prioritization: A Glass Jar Metaphor

Problem

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.

Actions taken

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.

Lessons learned

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