A key to making a team highly effective, be that in software development or elsewhere, is focus. As an engineer, focus is about being productive: understanding the code that’s already there, learning hotkeys, and refactoring. For teams, focus is about ensuring the largest, riskiest obstacles get the attention they deserve. On paper, that’s super easy. The main problem is that, in the real world, there’s often too much work and not enough time. Prioritising those tasks is a necessity.
Highly effective teams prioritise well, and prioritise religiously. For most teams, however, it is avoided, or poorly done.
Teams that avoid prioritising still need to get things done. This means piling unnecessary pressure onto individuals to work late, or cut corners, to get everything finished. For teams that get this far, the cycle repeats, but the team is exhausted and is now expected to build on an ever more fragile system.
Even teams that do prioritise often miss the point. While the amount of work might be manageable, it’s not connected to any higher goals. Disengaged teams make poor decisions: they invest in the wrong improvements, and cut the wrong corners.
The goal of prioritising is simple: figure out what to do next. This means it really boils down to two things:
- You should prioritise as frequently as you complete tasks.
- Prioritisation is (almost) always relative.
When to prioritise
If you re-assess your priorities too infrequently, your plans are always out-of-date. What’s worse yet, by the time you get to apply what you’ve learned, six months have passed. Your team has changed and you’ve forgotten how you built things the first time around.
Before you know it, you’ve stop solving customer’s problems and started executing plans.
Prioritising too frequently can also be overly burdensome. Ideally, you should only be prioritising after you’ve shipped something and learned from that. Anything more frequently than that, and you’re re-hashing the same old conversations.
I’ve found this is more difficult to avoid. People who ask to re-hash priorities often quote the sunken cost fallacy, mainly how we shouldn’t avoid talking about this just because we’ve started the work. Focus has to be underpinned by execution. If you never ship anything, you aren’t really learning anything.
How to prioritise
The key to prioritising is understanding that it’s mostly all relative. You likely only need to discover the most important thing to work on, and then you get on with doing it.
Avoid spreadsheets
The worst examples I’ve seen have been score-based systems. You plug in customer impact, number of users, and some kind of estimate into a spreadsheet and it spits out a sorted list of things to do.
Firstly, it destroys a lot of the nuance that goes into how products are built. They often don’t quite capture how annoyed a customer is, or the fact it’s affecting the CEO. This means, in the best case, the numbers are often fudged to get the order you want anyway.
Secondly, it’s a poor attempt to automate leadership, which will be reflected in how the team approaches the work. Leaders are there to set the direction and motivate the team. A team that understands why that shoddy error message is so confusing for customers will not only be more motivated to fix it, but also fix it more effectively. A task handed to them because it has an ImportanceScore of 6.6 rather than a 6.5 does not come close.
Rank and compare
Since the objective is to figure out what’s most important, you can’t avoid comparing tasks with each other.
Don’t waste time thinking about groupings or number-based systems. If the goal is to decide what to do next, thinking about what makes something a High or a Medium impact is a detraction.
Take the first item as your base line, and decide whether each subsequent task is more or less important. The goal here is to get to a ranked list of your most important tasks. If you have a large number of things to do, you needn’t rank them all. You just need to decide whether it’s important enough to consider ranking in the first place.