A Magic Prioritization Trick
cutlefish.substack.com
cutlefish.substack.com
I've found that there is a next step / additional dimension that can be very useful as well:
Once you have what's in the important row, ask people what they would want to work on.
Assuming everyone is qualified for the tasks, I've found that giving something urgent/important to someone who wants to work on it vs someone who doesn't DRAMATICALLY improves the odds of it getting done quickly.
This being HN, someone will say: "But what about things nobody wants to work on". Great question!
The answer is to either:
- Have everyone take turns e.g. doing support for the team on a rotation
- Make trades vs the future e.g. "I know you don't want to do this now. If you do it though, I guarantee you get first choice on what you want to work on next."
But urgent and important sound somewhat like synonyms. Something urgent must be the most important.
No. Answering a ringing phone is urgent. Answering a ringing phone is not important (usually*).
Opening a certified letter from the IRS is important. Opening a certified letter from the IRS is not urgent.
Urgency communicates the time-sensitivity of a task. Importance communicates the value of a task.
* Assuming you're not a 911 dispatcher or other on-duty call-center type of employee.
Or a programmer, or working on technical projects with some sort of scrum-like workflow in, in which case I believe an urgent issue is an issue that is important.
I believe a lot of people on HN fall into one of those two groups.
Sure theoretically you can still come up with issues that are urgent but not as important as less urgent issues but not in a way that really fits how the terms are used in a lot of our works.
It's important that we transition off the platform in a year or we will pay 50 thousand dollars a month in fines, but it's urgent we solve the login issue.
Yeah sure but we're going to work on the urgent issue because right now, in this moment in time, the urgent issue is more important than the issue that has a year to be fixed.
Not necessarily. Imagine a scenario where the team would like to submit their project to some kind of a competition, and the submission deadline is nearing. If they submit, they could win an award that could increase the project's visibility and potentially sales; but it's not guaranteed, and the project is already doing well enough on its own.
So, that task of submitting to the competition is definitely urgent, but at best nice-to-have.
One way to look at it is that urgent things are those whose value is soon going to be accelerating quite a lot (even infinitely), either up or down. Important things are things whose value is high, irrespective of rate of change.
Example: Fix the hole now or the boat sinks: urgent (currently you have a boat that is completely functional: that's going to change). Arrive to the intended port and not a wrong one: important (if you make a mistake, you may need to spend several days travelling back. Sure, the longer you keep navigating in a wrong direction the more fuel and time you lose, but it is not super-urgent).
I was going to say I still don't think I would find a x,y graph with x being urgency and y being importance useful for determining what I would work on but now I can theoreticaly see it, urgent issues that are more important get worked on sooner than urgent issues that are less important.
I do think however if someone told me that, as others having suggested here, winning a contest was urgent but 0 on importance than I would say it was also 0 on urgency.
All that said I think the graph would be not especially useful in practice, because in working on things we know the kind of urgency that determines what gets worked on and it almost forces us to prioritize issues higher.
Logins not working, people can't complete purchase, GDPR fines coming next week unless we fix.
Stuff that is urgent in almost every meaningful IT scenario is also, at the time, the most important.
Urgency and importance both affect prioritization. Something that is urgent and important should usually be done first. Something urgent and not important needs to be done soon or not at all --- and both are valid choices. Something important and not urgent is likely to be delayed, at least until it is urgent. Something neither important nor urgent may be delayed or dropped --- again, both are valid choices.
Urgent and a little important must be done now.
Urgent and unimportant must be dropped and it is a waste of time in endless meetings to even discuss it.
- Buying a pumpkin for Halloween: the stores are going to sell out of pumpkins and Halloween is going to pass, so it is urgent to buy a pumpkin while there are still pumpkins.
- Commenting on a controversy on social media: very quickly, the attention will move on to the next thing and you will lose the opportunity to comment on this thing.
You are successfully selling a product at a profit. You have identified an inefficiency in how the product is made; if you fix it, you increase your net margins by 50%.
That's super important, as you're leaving a lot of money on the table! However, whether that inefficiency is fixed immediately or somewhere down the road makes little difference in terms of the payout once it is fixed.
Buying food for dinner tonight is urgent, because without it I can’t eat tonight. It’s not important, however, in that even in the worst-case scenario where I miss a meal, nothing bad happens.
Paying my rent is both important and urgent, in that it’s time-sensitive and has substantial consequences if I fail to do so.
All those biggish things that you want to do some day, that you need to do some day, that might change your life... BUT right now (for looong values of "right now") there's something else to do.
This is where you want to break down hazy targets into multiple more-concrete steps, so that you can opportunistically make piecewise progress.
Funnily enough the solution is very simple, but you need to have a list of goals you want to reach. Everything that helps you get closer to fulfilling your goals is important, everything else is unimportant.
Something can be important but not urgent - it doesn't matter if you do it later, but it's important that you do it at some point (but you maybe don't need to do it right away).
Something can be urgent and important - if you don't do it now, bad stuff will happen.
When you have disparate independent stakeholders who each have their own value/urgency models, these things start to fall apart.
I've frequently worked in large orgs with far more internal stakeholders than devs, which meant that at any given time, only 50% of stakeholders were having any of their tasks actively worked on. You can play games to try and mask that, but end of the day it is reality.
So then the game they all play is making sure they are one of the stakeholders with active tasks at all times. Which then turns into competitive escalatory MAD. Which mostly turns into management by squeakiest wheel, because if you don't take care of badguyX, he is going to tell his bosses boss you are an idiot, so it's easier just to keep the queue of badguyX active then piss them off and then still have to do their work after all the fight. No manager wants to admit falling into this game, but they very very often do.
I'd also point out in these situations, the tie breaker / decision maker is far more senior of a person than someone who is going to go through some sort of quantitative process vs "using their judgement" (aka gut).
Not saying I have an answer, but am saying the post is solving a simpler version of the actual problem.
I always said that people were busy - there was a frenzy activity - but nothing ever got done until someone very senior (i.e the commanding general or one of his deputy commanders) stepped in, like you said, and made a decision from his gut that a particular thing needed to get done, and then everybody would actively work on that one thing and nobody's work would be blocked. Eventually I realized that the game for stakeholders was all about getting their things into a decision briefing for the commander to make that happen.
i am not entirely serious. but as an independent contractor with multiple customers, working on tasks for different clients every day or every week is not unrealistic.
so every task now takes 2 weeks duration because it will get approx 2 days of effort in that window.
then the next side effect is any remotely challenging task gets avoided because the duration of a 1 week task becomes 5 weeks and.... forget it.
the end result is the same. so it really doesn't matter.
the benefit if the queue system is that you get to focus on one project at a time. the benefit of the paralell system is that you don't waste waiting times that may occur when during the development you need something from someone else and have to wait for their response.
which is better depends on the specific project and how the stakeholders communicate.
That being said, I can imagine each team having their own definition and levels of importance, with the names that are meaningful within their particular context.
Another way to look at it:
if you deliver a couple of quick tweaks that the users want in the next week, that can buy you some time to do more behind the scenes refactoring/tech debt cleanup.
I also split the task into two sections, i think we traditionally use impact and cost/difficulty.
Then we stack ranked ideas using a horizontal wall. Once for impact. Once for difficulty. Then after the fact I correlated the outcome into a matrix.
It’s like the difference between having humans estimate volume (hard and error prone) versus estimating length (much more likely to be accurate).
The exercise was less painful to implement and the results seemed more accurate.
This looks like a really good way of getting people to practice cost-of-delay based prioritisation in a structured, reproducible way that doesn't involve formulas or maths.
Since these are designed to help a team deliver the best bang-for-the-buck at a given point in time, I've found proper assessment of actual urgency and importance are the biggest success factors.
Can't express the number of times that an urgent or important need that was identified was addressed by my team, with nary any impact.
Great visuals though, made the system super easy to comprehend.
The interesting part is that it's allegedly a trick to get people to stop conflating the two, or cheating.
Just have ChatGPT figure this out for you, given a nicely engineered prompt :)