One heuristic for ranking work as a Staff engineer

It’s hard to know what’s the right thing to take on when there’s a lot of possible work available. It’s an essential skill for growing as an engineer, particularly if you want to keep being a key leader in a growing business.

The heuristic I’ve used (to a lot of success) as a Staff engineer is to rank work by the number of affected teams then individuals.

This means company bets/priorities first (usually very complex with a large number of teams involved), then strategic cross-team working groups that produce painkillers not vitamins, then code that helps feature engineers, then code for the customer.

It seems strange to have code for paying customers last, but the goal is to allow for a larger number of engineers to produce code for the customer.

Taming the chaos of complex future initiatives provides more work, headcount, and direction; working groups aggregate pain and create and coordinate decisions across teams; and writing code to help engineers (tools) reduces friction for more efficient delivery.