[HN Gopher] The Magic Prioritization Trick
___________________________________________________________________
The Magic Prioritization Trick
Author : BerislavLopac
Score : 80 points
Date : 2023-10-09 09:38 UTC (13 hours ago)
(HTM) web link (cutlefish.substack.com)
(TXT) w3m dump (cutlefish.substack.com)
| skapadia wrote:
| Way too complex.
|
| Just have ChatGPT figure this out for you, given a nicely
| engineered prompt :)
| mjfisher wrote:
| I think some of the comments that are writing this off as not
| very useful are missing a point. Almost all businesses
| prioritising finite resource should be using some form of
| CD3/WSJF; but it's very hard to communicate _why_ to stakeholders
| without diving into some math and graphs that some people have a
| hard time understanding.
|
| 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.
| imbusy111 wrote:
| Sounds like a variation of the typical urgent vs. important
| matrix.
| tarboreus wrote:
| I knew it was going to be that when I saw the headline.
| jholman wrote:
| Of _course_ it 's a variation on that. Quite explicitly.
|
| The _interesting_ part is that it 's allegedly a trick to get
| people to stop conflating the two, or cheating.
| felixyz wrote:
| This is good, but unless you're a minimal team of one or two (or
| even if you are), sometimes the best thing is to get a bunch of
| tweaks (say 5-10) done in a week or two, because it makes users
| feel like you care, and they might add up to a considerable
| improvement in satisfaction/delight although individually each is
| insignificant. In other words: polish can't wait forever.
| BerislavLopac wrote:
| I think that the boxes on the "importance" scale are not very
| well named. I would personally use something like Critical,
| Important and Nice-to-have; or maybe a variation of the good
| old MoSCoW (Must, Should, Could; the "Won'ts" can be omitted
| for obvious reasons.
|
| 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.
| alexpotato wrote:
| 100% agree.
|
| 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.
| closed wrote:
| It seems like this is a lot of the strategy behind pitching
| things as epics. If tweaks interact to produce considerable
| satisfaction / delight, then bundling them together keeps focus
| on what big thing happens when they're all completed..!
| schneems wrote:
| I did something like this at my last offsite.
|
| 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.
| lazyant wrote:
| https://en.wikipedia.org/wiki/Time_management#The_Eisenhower...
| jroseattle wrote:
| Most of these processes are garbage-in-garbage out.
|
| 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.
| alexpotato wrote:
| As someone pointed out, this is a variation of the
| Urgent/Important matrix.
|
| 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."
| bryanrasmussen wrote:
| I find it difficult to understand the opposition between Urgent
| and important, I could understand for example an opposition
| between difficult and beneficial.
|
| But urgent and important sound somewhat like synonyms.
| Something urgent must be the most important.
| sokoloff wrote:
| > 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.
| bryanrasmussen wrote:
| >* 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.
| Closi wrote:
| Something can be urgent, but it doesn't matter if you don't
| do it.
|
| 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.
| Smaug123 wrote:
| Here's a very urgent but entirely unimportant task: buy a
| ticket for tonight's lottery.
| svat wrote:
| Exercise is important. It's never(?) urgent.
| euroderf wrote:
| "Important (but not Urgent)" is most people's weak quadrant.
|
| 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.
| aidenn0 wrote:
| Everyone's given you examples of urgent/unimportant. Here's
| an example of Important/not-urgent:
|
| 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_.
| bryanrasmussen wrote:
| right if you fix that problem 5 years down the road - wait
| a second, that means we lose a lot of money?!?
| aidenn0 wrote:
| It means you make a lot less money. Urgent usually
| implies a nonlinearity in the cost of not doing it.
| Important means a large absolute cost of not doing it.
| farrellm23 wrote:
| A couple more examples of urgent but not important:
|
| - 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.
| marcosdumay wrote:
| They are not opposite at all. The insight is that they are
| not synonyms either. They are just not related at all.
| harperlee wrote:
| You are right that urgency is related to value (same as
| important), but also to time.
|
| 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).
| bryanrasmussen wrote:
| ok this seems the most sensible - from a project management
| / IT viewpoint - expression of the issue.
|
| 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.
| BerislavLopac wrote:
| > Something urgent must be the most important.
|
| 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.
| TehShrike wrote:
| Based on other people's responses I'm guessing that they
| interpret the distinction as "time sensitive" versus "useful"
| CaffeinatedDev wrote:
| This system makes sense on a fundamentals level, but something to
| also consider is the synergy principle (1+1=3) where some tasks,
| when coupled together, could potentially be bumped from optimizer
| to game changer (or bumped from tweak).
|
| Great visuals though, made the system super easy to comprehend.
| steveBK123 wrote:
| The magic trick is to have a singular queue, and/or a singular
| stakeholder representative.
|
| 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.
| em-bee wrote:
| the solution is obviously to always work on multiple tasks
| simultaneously. how often you need to switch depends on the
| granularity of the report. if your report is daily you touch
| each task once a day. if it is hourly, you switch through all
| tasks every hour. the pomodoro method has you taking a break
| every 30 minutes, so two tasks each hour are possible without
| cutting time on each task to short.
|
| 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.
| postexitus wrote:
| There should be a special place in hell for people who come up
| with 2-axis, 4 quadrant categorization of things and a VIP
| entrance for those making trivial modifications on them and
| branding it the Magic Way (TM).
| simplify wrote:
| Not sure what you're saying here, can you explain the negative
| effects you're implicitly suggesting exist?
| [deleted]
| nattaylor wrote:
| Whoever came up with the 1-3 month game changer oughta get a
| promotion
| saulpw wrote:
| I come up with these all day long. They come along with a bunch
| of whenever tweaks. The trick is identifying which is which and
| making a strong case so that other people buy into the same
| prioritization. And then being right...
___________________________________________________________________
(page generated 2023-10-09 23:02 UTC)