I’ve had to think about prioritization a lot over the past few years. A few things make prioritization hard, even if you know you need to do it:
If you’re a manager in a busy place with a lot of customers or partners, you might have lost track of all the things you’ve committed to. If you don’t have a good practice of recording outcomes and next actions in meetings, you’ll find things creeping around behind your back.
If you don’t maintain boundaries with customers or partners, it’s going to be an issue for you, too. If you’re the type who’s open to being grabbed in the hall and put up to something on the basis of a nodding agreement, or if you regularly let people outside your team head straight to people who report to you without checking in on the interaction later, you’re not really maintaining boundaries.
If you and your manager or you and your team don’t have a culture of requiring a conversation about priorities with each new commitment, prioritization will be difficult.
If these patterns look familiar to you, you probably also know some of what comes next:
Your team will start to run hot as they struggle under the load of an undifferentiated (and possibly incomplete) list of their deliverables. That will take the form of stressed out behavior and guilt over what’s not being done. The folks with a workaholic streak will double down on their effort and become frustrated with people on the team who don’t follow suit. The ones who aren’t going to be pushed into working past reasonable hours will go into a defensive crouch.
Lacking a way to talk about your priorities with customers or partners, it’ll become easier and easier to flip from a posture of relative openness and helpfulness to one where it’s simpler to just say “get back to me in six months” (or never, if you’re being honest).
You’ll begin to focus on headcount as the cure to your problems: You know enough to know you’ve got a ton on your plate, and that your team’s morale is beginning to suffer, and that a few extra hands could at least take some of the pressure off.
Looking back, I don’t think I’ve ever worked anywhere that was doing a great job with prioritization, to the extent “great” would mean you’d be able to get affirmative answers to all these questions:
- Do the managers have a list of everything they've committed to?
- Is that list prioritized to at least the level of high/medium/low/not, and is it shared with everyone on the team?
- Do managers periodically reassess the list and clearly identify things that can fall down into the "not a priority" bucket?
- Do people on the team feel empowered to ask about the relative priority of new things as they come in without being made to feel like that's an insubordinate or unfair/gotcha question?
- Does everyone on the team treat those priorities as real?
Consequently, just about everywhere I’ve worked has shown some of the symptoms of poor prioritization, too. The ones that bother me the most are guilt and recrimination.
Guilt affects peoples' ability to be open and honest about their work, and it erodes a team’s ability to celebrate what it has accomplished. Guilt also eventually blocks people from being able to ask for what they need from others, because the person feeling the guilt worries that they’ll be viewed as a hypocrite when they have their own impossible list of unfulfilled obligations.
Recrimination – anger turned on teammates for not doing enough – destroys trust, makes it hard to get people to pull together, and creates a toxic environment.
Taken together, guilt and recrimination from poor prioritization will grind a team down.
A Prioritization Exercise
I don’t think I’ve ever felt the challenges around prioritization more acutely than at a startup, where there’s a huge amount of energy, a massive appetite to solve big problems, and a desire to buckle down and become profitable (which means the “toss a few more bodies on the problem” solution to poor prioritization is losing its currency).
After some painful and frustrating conversations around the work my team was doing and the hands we had available to do it, I did an exercise that helped a lot.
The goal of the exercise is to get everything you’ve got going into a list, figure out how important each of those things is to you, describe how much effort you’re putting into it, and then start figuring out what really matters and what needs to come off.
The exercise uses a very simple model that helps you see the gaps between the priorities you think you have, and the work you’re actually doing.
Once you’ve completed the initial steps, you’ll have something that can serve as the foundation of a conversation with your team and your manager, as well as a tool to build an ongoing practice of thinking about what’s important and how what you’re actually doing lines up with that.
There’s no real magic here. The thing that strikes me about this process, however, is that when I describe it to people and show them the tools I use, it strikes a nerve. I think a lot of people are used to carrying their priorities in their heads, or expect their manager or some other leader to let them know what their priorities are (and steer them back when their actions don’t line up with priorities). So I’m writing about it in the hopes that people who are struggling with the stuff they have to do will see something they can use (or modify, or at least get some inspiration from).
This is also written from the perspective of someone managing one or more teams. If you don’t manage anybody, you can still run through this exercise with the projects and tasks you’ve been given.
I’d recommend you do this using a spreadsheet: You’ll want ways to sort the information you gather for the exercise. I wrote an app to help me with it, and I’ll share a little about that in an upcoming entry.
1. Make Your List
If you’ve ever tried to do the Getting Things Done approach to task management, you know that one of the first things you’re supposed to do is get everything out of your head and into a list. That can go a long way to helping you feel less overwhelmed right away.
What goes onto the list is going to vary by the kind of work your team does. Since I manage services organizations, I tend to break the team’s work down into these areas:
- Customer commitments: The teams and projects we're supporting.
- Professional practices: The actions we layer on top of the basics. For a writing team, for instance, it might involve multi-stage editing.
- Team maintenance: Things the team does to maintain itself, e.g. professional development, maintaining and developing tools and processes, etc.
You definitely want to include the things you’re doing or have committed to do. You should also include the things you want to do but have no current plans for, and things you’ve recently refused to do.
It might be helpful to add a column listing who on your team is working on what. Who you’ve put on a given task is an implicit comment on its importance to you.
2. Prioritize Your List
Once you’ve got your list, prioritize it. That doesn’t mean you need to force rank everything. Aim for a simple high/medium/low/not scale. Don’t try to come up with some formula for how much of your list should be at a given priority: That’s overthinking it, and you’re going to address that soon enough, anyhow.
If you’re using a spreadsheet, using numbers for your priorities is a good idea. I’d recommend a 0 = none to 3 = high scale, because you can do math on this a little later on. For instance:
- 0 = No priority at all. You know it's a thing but you don't have any plans to do anything about it any time soon.
- 1 = Low priority. This is something that would be nice to have some day, and that isn't at all necessary now.
- 2 = Medium priority. This is something that requires at least some maintenance on your part as a secondary duty for someone, even if it doesn't warrant your full attention. If it slips for a little while, it won't cause too much pain, if any.
- 3 = High priority. You have to actively work on this, either to build it or to maintain it to a high standard.
3. Qualify the Effort You're Giving Each Priority
Once you have your prioritized list, you should take a look at each item and ask how much effort and attention you’re giving it. I’d recommend, once again, using a 0 = none to 3 = high scale.
There are a few ways to think about this number. Here’s a scale to consider:
- 0 = The item in question is getting no effort at all. Nobody's paying attention to it.
- 1 = The item is getting very little effort. Someone -- maybe not the same person every time -- checks in on it now and then, there's a long backlog of issues with it that are addressed irregularly. Quality may be relatively low.
- 2 = The item is getting some effort. It has a clear owner but it's not getting their full attention. Quality may be "best effort" as opposed to "high."
- 3 = The item is getting full effort. The person or people working on it are expected to prioritize it above other things, it consumes a significant portion of their time, and it's being completed to a high degree of quality.
4. Think About the Disconnect Between Priorities and Effort
At this point, if you’ve got everything in your list prioritized and if you’ve recorded how much effort you’re putting into everything, you can do a little math that will help you think about the health of your priorities list.
You can assess the relative health of everything on your list by looking at the disconnect between your priorities and your actual effort. I call this “risk,” but “health” is fine, too. The main point is that you want to capture how wide the delta is between your stated priorities and the actual work you’re putting toward them.
A quick formula in your spreadsheet will do it:
item priority - item effort = risk
- Risk > 1: High Risk
- Risk == 1: Medium Risk
- Risk <=0 : Low Risk
You can use conditional formatting to make the calculated “risk” column a little easier to parse, as I did in this simple spreadsheet:
I wrote a conditional formatting rule, btw, that catches things under ‘0’ and highlights them: That shows you where you might be putting more work than necessary into something of relatively low priority.
5. Talk About it With Your Team
At this point, you probably need to sit down with your team, put the spreadsheet up on the screen, and start talking through the work you’ve done so far.
This conversation is going to require a baseline of trust between you and the people on your team. If you’ve been having problems with poor prioritization, you’ll probably find that there’s a certain amount of guilt and defensiveness. Some people might be worried that you’re doing this work to document blame.
You need to make clear that you’re not using this exercise to place blame or judge people for what they’ve been doing. Rather, if prioritization has been a challenge for you, you need to own your own leadership gaps in this area. Explain that you’re looking for help to get a good picture of everything your team thinks it’s supposed to be doing, and to make sure you understand where relative levels of effort are going.
If you’ve got a few layers of management, you might want to keep this initial conversation to leads or managers, especially if you’re dealing with a demoralized team or one with a poor performer. You don’t want the “effort” question to devolve into one of individual performance. Rather, you want to have a clear idea of how much work is being done around a thing, good or bad.
For that reason, I’ve taken a stab at modeling and then shied away from things that look like story points. They just make people nervous and it slows down the conversation.
Things to ask the team include:
- Is the list complete? Make sure you haven't missed something, or mistakenly lumped a few things in together in a way that hides effort or complexity.
- Is the amount of effort you recorded accurate? Sometimes you find that someone on the team has been putting a lot more into something than you realized. Alternately, you may discover something has been allowed to slide for months. Note those, move on, and if they represent a performance issue deal with them in a 1:1.
Once you’re done with this, you’ve got a snapshot of the team’s state you can use to drive conversations with your own manager.
6. Take It To Your Manager
Once your team has vetted your snapshot, it’s time to take it to your own manager for review. If you’ve got everything in a spreadsheet and have a little conditional formatting to help make it easier to scan, the conversation can go line-by-line:
- Describe the item in question.
- Explain why it has the priority it does.
- Explain why it's getting the level of effort it does.
- Point to the calculated risk/health field and ask if it reflects an acceptable outcome for the item in question.
Your manager probably won’t agree with all your priorities, or the amount of work you’re expending on a given item. That’s great! You did all the work up to this point to make it easy to find those disconnects.
The thing you need to do, though, is think in terms of tradeoffs. If your manager wants to bump something up in priority or apply more effort to it, you should press them to explain which items you can back off on to shift capacity accordingly.
As you work through the list and make adjustments, take advantage of the spreadsheet: Sort by different columns to offer a picture of the things with the highest priority, or the things consuming the most time, or that are at most risk because of a disconnect between priorities and effort.
Once you’ve worked through the list, give it a final sort by the risk/health field, and take a hard look at the things you see as high risk/poor health. The questions you and your manager need to be asking at this point are:
- Is this in an acceptable state right now?
- Is there anything happening in the near term that might change this? (e.g. planned hiring that will provide more capacity)
- Is this something we can drop to a lower priority, deprioritize altogether, or actually drop from the list?
7. Take It Back to Your Team
Once you’ve run through the list with your manager, identified misaligned priorities, made adjustments to priorities, and identified a plan to correct misalignments, make sure to close the loop with your team.
For each item that changed, talk about an action plan to make the needed adjustment. That might involve communicating with stakeholders, shifting work around on the team, or simply resolving to quit thinking about something for a while.
The main thing you want to do, though, is communicate a clear sense of permission for each thing that ends up getting less priority or effort. If you’ve been having problems with prioritization and people on the team are dealing with guilt over what they haven’t been able to do, let them know it’s okay to put those things down, that you support them in doing so, and that you’ll defend the team’s priorities and effort to your manager and the rest of the company.
8. Support and Maintain Your Priorities
Once you’ve been through this process, you have to support the work you did.
Review your list periodically: Once a month give it a look and think about each item. Once a quarter, pull your team back in and review. If things change and you need to reassess, bring it back up with your manager.
If you have some sort of progress/status reporting routine, ask everyone on the team to specifically report against the priorities on that list. They might not be doing everything on that list every week, but a section of their report should include things from that list. Work that wasn’t done against any of your priorities needs to show up in its own area because you’ll need to assess whether it was truly a one-off, or something that needs to go onto the list.
Make priorities part of your weekly 1:1s. You don’t want 1:1s to devolve into tactical discussions or 30-minute readouts, but a snapshot of the week’s priorities delivered in the first few minutes keeps everyone thinking in terms of what’s important.
Build a healthy practice of discussing priorities both on your team and with your own manager. If a new piece of work turns up, talk about its relative priority, discuss how much work should go toward it, and add it to the list so you can assess it against everything else you’re working on.
I walked through a lot of this process earlier this year, after a bunch of frustrating conversations about headcount. My team had a long list of stuff accumulated over the years, with a section of that list simply falling off the bottom over and over, and we simply didn’t have the people we needed to do it all.
I’d already written an app that modeled who was on the team and the things they were working on at a low level (individual pages of documentation) so it was pretty easy to add a model for all the areas of concern we had and do a little work to make it present nicely.
I saw the benefits from taking this approach at several levels:
For myself, as the team’s manager, the act of getting everything into a list was so clarifying. I had other sources of truth for the work my team was doing, mostly in JIRA, but they weren’t as focused as the list.
For the conversation I had with my manager at the time, we had a way to interactively discuss our priorities and where the work was going. He ended up helping me find places where we’d been working to a higher standard than he felt was required, and provided me with some permission to offload some of that work to other teams. Some things came up in priority as a result of that shifted capacity, but we also ended up agreeing that more seniority on the team and an additional writer would help. Some things he’d put on me he realized he’d stopped caring about, and we dropped them.
For the team, it was helpful to see the results of that discussion. They could see that a constructive conversation was happening about their commitments, and that my manager and I had agreed some things weren’t sustainable at their current level of effort.
It gave me an opportunity to express to them in very clear terms that the snapshot we’d described was something of a contract I’d honor.
One of the more senior people on the team said the hour or so that went into the initial review of priorities and the ensuing followup were the most useful meetings he’d been in, because they helped him finally understand the things he could stop worrying about after years of having them on a mental list.
Services orgs get a lot of incoming tickets telling them what they “should” be doing, and the people filing those tickets aren’t always mindful of the things they’re piling onto someone else’s plate. Having a prioritized list published somewhere that was easy to point to also made it a lot easier to educate people around the company about our work and priorities.
Finally, the exercise has been useful for having headcount conversations both up and down. When we recently had to consider trading some eventual headcount away in favor of a big overhaul of an aging toolchain, we had a source of truth to turn to. In the absence of a new team member, we had some stuff that was in a state of marginal or poor health that might have to remain that way. Was it worth it? We had a way to validate our hunch that it probably would be, and even a way to see the ways in which some things in the “no time soon” backlog would probably be helped along more by better tools than more people.
I’ve recently turned my attention back to that app I was working on. I spent some time over the weekend isolating the priorities model from the pieces specific to a tech writing team, then nesting those priorities inside a team model. That has all resulted in a much smaller, easier to maintain prioritization tool that can account for multiple teams.
With a little more work and a few more models, it will be able to support a multi-level organization. The ideal end state to me would be recording something like OKRs at a high level, then associating team-level priorities to those OKRs and modeling in health metrics.
For now, I’ll be content to get it to a point where it can be shoved out onto something like Heroku, where anybody could set up a single team and step through the prioritization exercise.
If you’re interested in playing with it, drop a line and I’ll either show you how to run your own instance, or give you an account on a stable machine once I’ve pushed it up to one.