Prioritization is a skill, not an assumption

Why your team might be doing the “wrong” thing for the “right” reasons and what you can do about it.

Is the concept of priority shared within your team? I mean, are each team member’s priorities aligned with those of the team as a whole? When looking at the big picture, the answer is most likely yes. But if you take a closer look at the day-to-day, you might discover that what you consider a high priority isn’t always seen that way by everyone.

Let's try an exercise together. I'll introduce a couple of examples to better explain what I mean, and I'll ask you to form your own opinion on them.

A release introduced a bug into production. Users are affected by the issue and start opening support tickets. Your (unspoken) expectation is to minimize user exposure to the problem, most likely by reverting the release to calmly analyze the issue and potential fixes. However, it might happen that the other person instead tries to fix the bug directly, thereby increasing the time users are exposed to the issue. In your opinion, who is right?

Here’s another one: a member of your team is working on a task that has significant business impact, when at some point, for some reason, they get stuck. Your expectation (not initially shared) is that they do everything they can to unblock the task. However, it might happen that the person, while waiting for the next sync meeting to raise the issue and move things forward, starts working on another task in the meantime to avoid sitting idle. In your opinion, who is right in this case?

Priorities are not just a label on your PM tool

Who was right?

If your answer to the previous questions was “the leader”, I’m sorry for you but the answer is wrong 🙅.
If the answer, instead, was “the teammate”, I’m sorry again but the answer is wrong too 🙅, although it's slightly less wrong than the first.

In my opinion, the right answer is that, muck like to Schröedinger’s cat, both are simultaneously right and wrong, depending on the POV.

From the teammate POV, they were doing the right thing in both cases: they promptly tried to fix the bug, as well as they didn't waste time on the blocked task by either going down potentially wrong paths or stopping work altogether while waiting to speak with someone.

From the leader POV, the expectations were correct: reducing the user exposure to the bug is crucial to avoid side effects for Customer Support and, above all, to prevent overloading the support team. At the same way, expecting from a teammate to focus on a single task at a time, doing everything within their power to close it as soon as possible is the first rule to avoid waste and rework. Even more so when the task is business-sensitive.

Where am I going with this? I simply mean that these behaviors don’t arise out of malice or negligence. Often they are just the result of something easier: there is no real shared clarity on what it means to prioritize something.

Saying something is a priority isn’t enough. Without a culture that turns that priority into concrete actions, it remains just another word among many.

A bug in production isn’t just a glitch, it’s a breach of the pact with the user. It demands immediate attention. Not «I’ll look into it when I’m done», but now. If the person who introduced it knows this but doesn’t act, it’s a behavioral issue. But if they don’t know, then the issue is on us as we haven’t taught what it truly means to prioritize.

Similarly, if someone gets stuck on a task and, instead of doing everything possible to unblock themselves (eg. asking for help, pinging the right people) decides to switch to another task, we’re facing a different kind of misalignment.
It’s a sign that there’s no shared understanding of the damage caused by multitasking and context switching. In these cases, issues tend to pile up rather than get resolved. The team may look active, but in reality, it’s not making progress.

It’s our responsibility, as leaders, to teach that working on too many things in parallel isn’t a sign of efficiency but it’s a sign of dispersion. And that especially when a task is business-sensitive, we must clearly communicate the context and the consequences. Saying “this is important” isn’t enough: we need to explain why it’s important now, and what happens if it isn’t addressed immediately.

What can you do to build this culture?

Reacting promptly to a problem doesn’t mean being impulsive. It means recognizing the responsibility and acting accordingly. Whether it’s a production bug that needs immediate fixing or a blocker on a task that must be resolved before starting another, the point is the same: take ownership of the problem instead of working around it.
If the team doesn’t do it, it doesn’t necessarily mean they’re unwilling. There may be other reasons behind it, and often they have to do with us as leaders. Maybe they haven’t understood that it’s their responsibility, or they don’t have all the tools to act in the way we expect.

Some pieces of advice are easy to imagine:

Lead by example
The most obvious, probably, but if you're the first to ignore bugs, slowdowns, or blocked situations, the team will understand that these things aren't that important.

Be explicit
It's not enough to say «this is urgent». You need to clarify what’s expected: who will take ownership, when, and how this task is prioritized compared to others.
When someone is blocked, what should they do before switching tasks? Ask for support? Escalate? Only then consider whether it makes sense to move on?
Well, make this explicit. Don’t take anything for granted and set this expectation.

Some others come from my experience:

Introduce Kanban principles
Make sure that the principles behind Kanban are understood and shared by everyone on the team — especially the concept of limiting work in process:

By limiting how much unfinished work is in process, you can reduce the time it takes an item to reach production. You can also avoid problems caused by task switching and reduce the need to constantly reprioritize items. WIP limits enables teams to deliver quality work faster than ever in a healthier, more sustainable environment.

Adapted from https://www.planview.com/resources/guide/introduction-to-kanban/

I’m not stating that Kanban is the solution to each problem. I just mean that reducing waste, context-switch and limiting the WIP is one of the most important mindset switch you should introduce in your team, regardless of your workflow.

There's a simple and fun exercise I've used with some of my teams and students during training sessions called the Dot Game. In short, it's a hands-on simulation using post-its and stickers to represent a company's workflow. With each new round, new rules are introduced showing how limiting work in process (WIP) can significantly improve a team's productivity. I highly recommend trying it out with your team.
For more details: https://www.leansimulations.org/2011/10/lean-dot-game-stick-it-to-man.html

Encourage regular priority check-ins
Sometimes people work on autopilot. They pick up the next ticket or continue working on something without stopping to ask «Is this still the most important thing I should be doing?». Especially in long-running projects, asking ourselves (and other stakeholders) if we are still all on the same page trains people to challenge assumptions and recalibrate when necessary. It also makes it safer to raise doubts without sounding like they’re complaining or disengaged.

TL;DR

Prioritization is a skill. We often expect everyone to have a sense of priority “by default” to instinctively know what should come first. But that’s not how it works.
Prioritization is a skill that needs to be learned. And if you don’t teach it, you’ll keep seeing behaviors that make you roll your eyes, without realizing that the main responsibility is actually yours.

Credits: Illustration 1