DEV Community

Dylan Anthony
Dylan Anthony

Posted on

How do you prioritize?

Some engineers will have the luxury (and restriction) of having their work selected for them. However, when working on small teams (like mine), it’s up to the engineers to decide what to work on and when. What are the factors you or your company uses to prioritize work? How to you organize your backlog to make sure the important work is getting done first?

Top comments (16)

Collapse
 
flrnd profile image
Florian Rand • Edited

There are already very good answers!

I think communication and common sense are keys. I've work as a freelancer designer and art director for advertising agencies in the past with very tight deadlines. It's not the same industry but the core principles of team work are the same, just different workflows. Most of the time, I was my own task manager and decide what's important and what's expendable can be tricky.

So to be sure, if you have doubts don't be afraid to show your priority tasks list to more experienced team members.

Now about factors, @f3ltron and @vuild nailed it. Every business is about money. Quoting from Virgin:

Happy people make happy customers, which makes for happy shareholders

If you have doubts, always prioritise tasks with either impact in money returns / saving, or users / customers happiness.

Collapse
 
dbanty profile image
Dylan Anthony

Thanks for your response!

I love the emphasis on communication. I’ve been trying to think of an easy way to give internal stakeholders access to our priority list. We have meetings to discuss priorities with the rest of the company occasionally, but they always seem confused about what we’re working on or why we’re working on it.

We do definitely try to prioritize things that provide value to the customers (leading to more 💰) but that’s hard to determine for the engineers who never interact with the customers 😰.

So I think better communication with the rest of the company could help steer us in the right direction.

Collapse
 
flrnd profile image
Florian Rand • Edited

This is my personal opinion based on some of my past experiences, so please take that into consideration.

We have meetings to discuss priorities with the rest of the company occasionally, but they always seem confused about what we’re working on or why we’re working on it.

We do definitely try to prioritize things that provide value to the customers (leading to more 💰) but that’s hard to determine for the engineers who never interact with the customers 😰.

How big is the company you work with? I've seen similar pattern in companies that went from small to a reasonable size in a short period of time, but the usual workflow and communication channels are very similar to when they were a small company.

Anyway, I would give it some time and wait to see how things works there. I've learned to observe first, act later. There is always a reason about why things are the way they are. Are they opened to improvement? or Will you hit a wasps nest with your suggestions?

Sometimes is wiser wait and see, and if you don't like it, jump out of the boat, than trying to improve something that doesn't want to be improved :P

Collapse
 
vuild profile image
Vuild

Hire the people in this thread if they are not working (or are). 👍

Not me. I am an oddball.

Collapse
 
flrnd profile image
Florian Rand

When did this thread become a hiring process? I'm not dress today for the occasion! 😂

Thread Thread
 
vuild profile image
Vuild

Every thread is a hiring thread (or decompression). 😭

So take off your suit, throw out your razor, leave your socks on the floor, grab some snacks, turn on background GOT & let's remake a better Internet that the last bunch ruined.

I am available for really difficult tasks, maybe. Florian knows how to handle projects & teams with experience of delivering which is what almost everyone actually needs.

I'm mostly here for the bump. 👀

To deliver a lot of really good work, making it as fun as you can is the real secret to productivity.

Collapse
 
flozero profile image
florent giraud

for me:

  • What have the more impacth for the user and money. It can be unit test, bugs etc
  • And you should cut as small as possible and identify what is absolutely necessary and do it. After you can do other incrementally
Collapse
 
vuild profile image
Vuild

Agree.

"Prioritize profitable projects" is the solution to overload & one of the best ways to have a successful business as it always addresses the biggest issues first & cares nothing for your feelings. 👍

Collapse
 
dbanty profile image
Dylan Anthony

I like it, very simple. Prioritize not only the top level, but the small pieces that make it up. Thank you

Collapse
 
anwar_nairi profile image
Anwar • Edited

At my work we use a system of notation on our kanban tasks (from 0 to 4) with the higher priority task having the higher notation.

Even if on the same sprint we add more tasks, we only re-update the priorities once a week (preferably Monday to start with a progression review, and finish with a re-priorization).

Works pretty good for us now, as long as we keep in mind to have the least 4 priority tasks possible.

Collapse
 
vuild profile image
Vuild

This is the professional answer if you want to get on with stuff, ongoing with sensible progress to deliver quality.

👍 Khalyomede

As can be seen, each person has a way or twist on getting themselves into a productive zone.

Collapse
 
dbanty profile image
Dylan Anthony

Thanks for your response!

How do you choose which number to give a task? We have a similar system where I work but people (of course) tend to number their own tasks higher. We tried to define the priorities but it’s still very subjective (what’s the difference between improving and significantly improving? Depends on your perspective.)

Collapse
 
anwar_nairi profile image
Anwar

Good question! In our team, we have my director and a product Owner, and with the help of a consultant senior, they help keep priorities fair.

So actually we are managing our priority very well for the moment, because everyone is understanding the timing of each one. Obviously their knowledge of how many time does a task takes help a lot (and I am lucky to have my superiors know how many effort does it takes to get things done in programming).

Maybe once a month you will see that over prioritized tasks, but very quickly everything gets fixed because of our Monday sprints.

Collapse
 
vuild profile image
Vuild

Like Florent said in general. For go time:

  • Make lists of all items, on paper.
  • Prioritize the list by most important & doable (doable is important because undoable is demotivating & pointless). Rewrite neater.
  • Start at the top & knock out the list. Cross out with satisfaction. Put list in obvious place.
  • Spend the rest of the time doing whatever as reward (real incentive is better living not platitudes).
  • Ad new items, reorder or make more lists.
  • You can complete much more this way than checking commits, time tracking or whatever.
  • It's generally healthier as there is nothing to remember & your mind is clearer.
  • Simple, cheap, private, fast, anywhere, anytime, green (its not much paper for a lot of progress, there are sustainable options).
  • Helps focus on the stuff that matters.
  • Share by photo, typeout/ocr/email/hand/whatever.
  • Backups & stuff are not very important (a photo on a phone sent to yourself is an instant offsite digital backup).

Or trello, slack, gtd, build your own app (I have, didn't use), Evernote or one of millions of services. I use these if clients ask but it's all just overhead & distraction mostly if you actually measure. In certain (usually larger) use cases this stuff matters more but for the individual small team, the paper stuff works fast (immutable too, you can see edits).

Collapse
 
dbanty profile image
Dylan Anthony

Sounds like a very Kanban-ish way of managing work. I’ve been thinking about trying to move us in that direction. We’re a scrum shop but some of the structure actually gets in the way of picking the right tasks. Thank you

Collapse
 
vuild profile image
Vuild

Yw. I predate all those methodologies but different things work for different people/projects/
results/systems. Nothing is better really. A lot is overhead.

Test & measure outcomes or work across different tech.

Once you realize people who knew nothing made the things you think of as existing, you can make or use whatever you want, how you want. That tends to be what the next thing is, something odd now.

"what methodology do you use?"
"ninja fried cheese flips, kanban is so 2017"