Some collected notes and references with regards to "when everything is urgent, nothing is"; in terms of project management, prioritisation, engineering work, etc.
Something worth keeping in mind: "when everything is urgent, nothing is"
When everything is urgent, the very meaning of the term becomes moot. Suddenly, the point of priority disappears. We tend to expect this from (some) contractors, but this hyper-prioritization also unfolds within design teams, leaving staff overwhelmed, stressed, and frustrated.
I had to work over time, the managers were unhappy with the work, and we are all stressed out.
the leadership had failed me.
staff members need structure, especially in high pressure situations.
By definition, everything can't be done "asap." We know that means as soon as possible, but if we're honest, that's not what some managers mean when they say it. They mean, "do it right now." Leaders need to establish very clear priorities for team members. What is truly urgent? That should be communicated to the team.
I've heard "highest priority" so many times since joining XXX that it's meaningless tbh.
I'd caution against blindly reacting to things user's raise as 'highest priority'. Users will always have something to complain about, that's what they do. If we want to be a structured engineering lead organisation, we need to filter that noise for the true signal and priority beneath it. Otherwise we just because blind sheep reacting to every new fire that finds it's way onto the top of the pile because it's the 'newest thing' and thus the 'highest priority'. We should be dictating what is actually high priority, not users.
To me, right now, based on what i've experience here so far, "highest priority" is a tale of the boy who cried wolf. It's used so freely and often that it no longer means anything to me; and so practically fades into the "ignore the noise" bucket, while taking extra cognitive effort/mental reasoning/stress to try and filter/decipher if it's actually more 'noise', or if it really actually means something this time
In high level terms, dev team has the sprint scope, and things are added to that as part of sprint planning. Once that is set, it should be considered a MAJOR thing to need to change that scope of work, and needs to have a REALLY good reason for doing so. Sometimes there will be TRULY urgent things that need to jump the priority, that's fine, it's life and it happens.
As to the backlog of things to tackle 'soon but not immediately', generally at past places we would sort of do that as part of a separate backlog grooming task, that usually involved the more senior engineers/team lead/product people/etc. That's sort of where the 'bottom up' of engineering's needs/desires meet the 'top down' of the product direction.
As a default though, I would say it sort of fits in the scope of the 'product' role, and IMO is a large part of that role, weighing/balancing the pro's/con's (with specific technical feedback from engineering as required), and largely keeping the need to consider that complexity away from the engineers so they can focus on the technical specifics they need to focus on to get the tasks they're doing done. When that's not kept away from us, and we have to individually assess each new "highest priority" that hits our feeds, it has major context switching and decision fatigue costs.
Further feedback on the subject via a friend, and how they handle similar where they are at:
Didn't read the article but we deal with this a lot. Every pillar of the business needs our time and to them everything is top priority. We have a priority spreadsheet that the business says is useless because nothing gets done but nothing gets done because every department has 10 items each in highest priority.
Particularly when the need is driven by users you need frame the reactive vs proactive side of things. Immediacy bias is the king of highest priority and we tend to use RICE analysis or similar simple tools to decide what really is important in a given sprint.
So for the RICE example i'm talking reach, impact, confidence, and effort. You can form a very simple matrix that brings value to the equation.
Reach - How many users does this help, affect, etc
Impact - What is the impact, will it help them a little, is this bug blocking critical flows etc
Confidence - How confident are you in the analysis
Effort - Engineering effort required
If something is low impact but high effort, it probably shouldn't take priority over something that is low effort and high impact. So on so forth.
I also agree wholeheartedly the leaders / managers / product team should be shielding the devs from all of that noise. It shouldn't enter a functional kanban or sprint until it has been weighed up against the other priorities so that focus can be maintained. Context switching is very costly.
I also like to focus on the mantra 'Stop starting, start finishing'.
Often a new highest priority leaves a project half complete. Switching to a new priority without finishing in progress work should be reserved for the highest and most critical things only. To assist in this in a high pace environment all of our scopes start with MVP but also include the 'nice to haves'. If we need to switch we get to the MVP and park the nice to haves.
And a little more feedback on the subject via another friend, who's in the engineering manager/etc space:
What you said is correct. I think an easy way to respond to priority things is
Have a high level plan of what the priorities are for the year so you have your 'regular' work prioritized in order. Changes to high level items are fine as long as it shifts something. Of course you commit to it. Whether that commitment is quarterly, yearly, monthly whatever. It could be at an item level as well
When a high priority unexpected item comes, you just ask the question, can what we are doing be delayed? If not, then can the roadmap be changed? whats going to get removed to add this new thing in
I think that helps people really think of what is priority, when you are taking away something
Some collected notes and references with regards to "when everything is urgent, nothing is"; in terms of project management, prioritisation, engineering work, etc.