Management Communication: Priority Exceptions

Constantly-changing priorities and surprise projects erode team morale and leave everyone unsure of if they’re working on the most important thing, or if they’ll ever get to finish anything. While being adaptable and flexible is critical for most teams, it’s always important to have some kind of roadmap and approach to prioritization and planning work. There are many different ways to plan and prioritize your work; what’s important is that when priorities change — and they will change — you acknowledge that change and adapt quickly.

If you don’t clearly acknowledge the change in plans, your team can start to question the point of the plan in the first place. They’ll start to wonder if they are expected to do this new thing and the old thing, or just the new thing, or since the new thing is not in the plan, perhaps they should actually ignore it? Don’t leave room for interpretation. Clearly set expectations and make sure you communicate unambiguously what is being asked of them. Sometimes they need to be given clear “permission” to really work on this new thing, and delay or drop the old thing.

On my teams, we use a process we call a “Priority Exception” to clearly address a major change in our plans. This process is used when we had a plan of work, and for some reason something not on that plan jumps to the next most important thing for us to work on. The goal is to acknowledge the change, clearly communicate the impact this change will have on existing work, and critically; highlight why it is so important that it should disrupt our plan. We use this template to ensure the right information is always included, and distribute the details to everyone on the team (and any other relevant stakeholders).

What new thing is happening?

Right up front, we outline the new work at a high level so that we all know what we’re talking about. We link out to our project management system or code tracker for further details. This section includes which individuals or teams will be required for the new work.

What existing thing is being delayed?

Next we’ll specify what work we’re putting on hold or slowing down because of this new work, or how we’re creating capacity to work on it. We’ll try to include details on the expected impact of our delay; If we can put a number on it, this is where it goes. Lost revenue? Delayed launch? Losing more users? Be specific.

Why is the new thing more important?

This helps head off questions about why we had to “drop everything” to work on something unexpected. This should clearly demonstrate why the new work is more important or more urgent than the planned work. You should be able to clearly illustrate why it offsets the impact of the delayed work (as detailed above).

How did this come about?

As a form of mini-retrospective, this is a chance to highlight why this work was such a surprise. It’s an opportunity to learn and avoid surprises in the future, or come up with other mitigation strategies, depending on what happened.

Timeline

We set a clear timeline covering any wind-down of current work, transition to the new work, and expected completion or progress milestones. Since Priority Exceptions often come with an external deadline, we’ll make sure that is clearly communicated as well.

Priority Exceptions are a useful, lightweight tool for communicating changes in priorities, and for learning how to reduce priority-thrash over time. Teams have appreciated the clarity they bring to otherwise-potentially-confusing times, and the clear permission they give to delay work in favor of something more important.

Engineering Management Lessons From Mountain Biking

Since moving to Colorado, I’ve been lucky enough to get out mountain biking pretty frequently. I love it. On some rides you’re just trying to get up or down the mountain in one piece, but on some rides you get good time to think quite deeply. On a recent ride I was rolling around (pun intended, you’re welcome) some ideas about engineering management, and realized there are some good parallels between mountain biking and leading teams of engineers.

Look Out Ahead

When you’re riding single track, it’s really common to have your eyes glued to the trail right in front of your wheel. Big mistake. Not only does it mean that you’re going to be constantly reacting and trying to respond to things as they appear right in front of you, but it also means that you’re not going to have any advanced warning of big changes ahead. Like a tight turn. Or fast descent. Or a jump/drop-off.

Instead of staring right in front of your wheel, you should keep your eyes further out ahead. This gives you more time to react, some time to pick your line, and the ability to adjust your approach as needed by speeding up, slowing down, changing your stroke on the pedals, or even just bracing for impact 😉

With engineering teams, if you’re heads down responding to the things right in front of you, you’re going to be in that same reactive position, and things will constantly take you by surprise. Take some time to not only plan out ahead, but forecast and “game out” what the future might hold. Will you need to hire more people soon? Adjust team structure? Train your people up in some specific skill? Transfer knowledge between key people? If you’re not looking ahead, these things can catch you by surprise, and become a much bigger issue than they needed to be.

Build Momentum

When you’re on a really gnarly section of technical trail, it’s all too easy to slow right down and find yourself picking your way through rocks and bumping across things uncontrollably. As counter-intuitive as it sounds, it’s often better to speed up and keep moving than it is to slow down and try to delicately navigate every little obstacle. You can end up feeling like a bit of a steamroller, skimming over the top of everything, but you end up with a smoother ride, and it’s a whole lot more fun than bumping and grinding through every rock in your path. Instead of slowing down and being overly cautious, a common refrain is “let it roll”, meaning don’t brake, just roll through the obstacles using your momentum (and then quickly move on to the next one).

Something similar can be said for engineering teams, who benefit from building and maintaining momentum in their work. Get in the habit of shipping, and always protect that habit. Don’t slow right down and get stuck in the details. If you adopt an extremely slow and overly-cautious approach to shipping, then you can quickly find yourself in a state where you’re not shipping at all. Once shipping becomes a habit, that momentum is easier to maintain and build upon, to continue increasing your velocity.

Find Your Velocity

As a balancing point to the previous one, it’s also important to find the right velocity. On a mountain bike, if you go too slowly, you’ll have a rough ride, experience every bump and rock, and probably not enjoy yourself much. If you go too fast, well, there are plenty of YouTube videos to show you what happens. You need to find a pace where you’re making good progress, but you’re not completely out of control. It’s probably a little faster than you think it is, so you should push yourself and really find your limits.

If you’re moving too quickly as an engineering team, it probably means you’re shipping sloppy work, failing to validate ideas, accumulating a ton of technical debt, or just plain old rushing things. Find a sustainable pace where you can deliver quality work, without burning people out, and without shipping junk. That being said, moving too quickly is rarely a problem with engineering teams, so remember that speed matters, and always push to move as quickly, but sustainably, as possible.

I’m sure there are more parallels to be explored, but these were the only ones that came to me before I hit the more technical section of the trail, and had to really pay attention!