Week 39 Day 3: Stack Ranking Your Priorities Forces Honest Decisions

Five priorities listed as equal means zero decisions have been made. Five priorities in a numbered stack rank means four decisions have been made -- which is more important than which. Those four decisions are what the team needs from leadership: clarity about what matters most when everything matters.

Here is the stack ranking process and why it works. Step one: list all current priorities. Write down every active initiative, project, or workstream the team is pursuing. Include everything -- the official priorities and the 'oh and also' items that consume time but are not on the official list. Most leaders discover 2-3 additional items they were not consciously tracking. Step two: force a strict order. No ties. No 'both are equally important.' For each pair of priorities, ask: 'If I could only make progress on one of these this week, which one would I choose?' The answer reveals the true ranking. Step three: apply the 'resource constraint test.' Assume your team has 30% less capacity than you think (because they do -- meetings, on-call, bug fixes, and overhead consume more time than most leaders account for). With 30% less capacity, which priorities still get resources? The ones that survive the constraint test are the real priorities. The ones that do not survive are wishes, not priorities. Step four: communicate the stack rank to the team and stakeholders. This is the hard part. Tell the team: 'Here is our priority order. Items 1-3 receive dedicated resources. Items 4-5 receive time only after 1-3 are on track. Items 6 and below are explicitly paused until further notice.' Tell the stakeholders whose items are ranked 4 and below: 'We have decided to focus on these three items this quarter. Your item is important but is ranked fourth. We will address it when capacity allows, or we can discuss whether it should displace one of the top three.' Step five: use the stack rank for daily decisions. When a decision point arises -- 'should we fix this bug or build this feature?' -- the stack rank provides the answer. The item ranked higher wins. No meeting needed. No debate required. The decision was already made when the ranking was set. The stack rank is not permanent. Review and update it monthly, or whenever a significant change in business context occurs. But between reviews, the ranking is the team's decision-making framework -- it replaces the daily negotiation about priorities with a pre-made decision.

Stack ranking implements what decision theory calls 'ordinal preference ordering' (von Neumann and Morgenstern, 1944) -- the principle that rational decision-making requires not just identifying the options but ordering them by preference. Research by Tversky (1972) on 'elimination by aspects' demonstrates that when decision-makers are asked to evaluate options as a set (without ordering), they use different -- and less effective -- decision strategies than when asked to rank options ordinally. Set evaluation produces compromise effects (choosing the middle option) and status quo bias (choosing the current allocation), while ordinal ranking produces discriminative evaluation (genuinely assessing which option contributes more). The 'no ties' constraint implements what Saaty (1980) formalized in the 'Analytical Hierarchy Process' -- the finding that forced pairwise comparison produces more accurate preference elicitation than holistic evaluation, because pairwise comparison reduces the cognitive load of evaluation (comparing two items is easier than evaluating five simultaneously) and eliminates the aggregation biases that occur when evaluating multiple items at once. The 30% capacity reduction heuristic is consistent with research by Putnam and Myers (2003) on software project scheduling, which found that productive coding time in professional software teams averaged 60-70% of total work hours, with the remainder consumed by meetings, communication, context-switching, and administrative tasks. Teams that planned at 100% capacity systematically overcommitted, while teams that planned at 65-70% capacity achieved commitment reliability above 80%.