It feels like this kind of dismisses prioritization. But that's only if you're not doing proper prioritization.
In reality prioritization is important, but it is affected by dependencies, effort, and "inspiration."
Dependencies: obviously if a P0 task requires a P2 task to complete, the latter is now a P0.
Effort: if a P2 can be done in an hour, it's probably higher impact than a "P0" that will take a quarter. So really what you need is some cost/benefit framework or RICE framework.
Inspiration: sometimes, someone on the team will just see a path to getting something done. They will be irrationally excited about it. You can't prioritize purely based on inspiration of the moment, but I've found leaving some flexibility in the system for capturing that inspiration can be very powerful.
> Effort: if a P2 can be done in an hour, it's probably higher impact than a "P0" that will take a quarter.
A "P0" that far out sounds to me like something with a tight (calendar vs estimated effort) deadline and some sort of fairly serious contractual or regulatory penalties for missing it.
It's amazing to me how many people struggle with the first issue she describes. If a task is blocked it doesn't matter that it's high priority, there is zero point in doing it because you can't actually do it. If it's blocked by a lower priority task, then elevate that task's priority and do it first (or earlier). This is project management 101, also called common sense.
I don't know these people but my presumption is that Rachel's colleagues are smart cookies. I figure it's less likely that a bunch of smart engineers don't understand dependency resolution and priority propagation, and more that there are (maybe imagined, maybe not) organizational factors that make it a problem to pick up a nominal p2 when there's a p0 on the board, factors that she can ignore due to political capital or just sheer IDGAF-ness.
It depends on your issue management system, but most offer some system (labels, tags, flags) which you can use to identify a blocked issue to be passed over without tweaking the priority directly. I'd favour using such a system over priority adjustments in most cases, because presumably when the task gets unblocked it should be seen to sooner than the "While we have time" task you were doing in the meantime.
Not a straw man, it's a real thing. Some people really do not get that "high priority" doesn't equate with "can be done now". I have had to physically draw out dependencies to demonstrate why X should be put on the same priority as Y if they really want Y done, because X is blocking it (in some fashion).
I know Jira has support for linking tasks semantically (X blocks Y; is blocked by Z) but I wish more task managers had better support for this. A few do, but very few of those will actually show you a task graph.
I really wondered why this is not an explicit thing in most task / issue trackers. There should be some semantic relations between issues which are standardized and come with special feature support.
If we know the dependencies and the priorities, we could also backtrack the graph and assign an "implicit (virtual) priority" to all issues which block issues with higher prio. It would also be nice to mark if something is on a critical path (that has been defined).
The overhead to write down dependencies is imho well worth when you consider how much that information can help you prioritize and save time by not starting something that will end up being blocked later. This is an issue I see repeatedly, also in companies who use Jira.
It's a basic feature in project management tools like MS Project. If a tool doesn't even match what Project can do, that's a pretty bad sign about the utility of it.
In reality prioritization is important, but it is affected by dependencies, effort, and "inspiration."
Dependencies: obviously if a P0 task requires a P2 task to complete, the latter is now a P0.
Effort: if a P2 can be done in an hour, it's probably higher impact than a "P0" that will take a quarter. So really what you need is some cost/benefit framework or RICE framework.
Inspiration: sometimes, someone on the team will just see a path to getting something done. They will be irrationally excited about it. You can't prioritize purely based on inspiration of the moment, but I've found leaving some flexibility in the system for capturing that inspiration can be very powerful.