Through your career, your work and tasks start simple and evolve. While working on software projects, you first begin with smaller tasks with the goal is finishing the job and learning. After gaining experience, you start taking more responsibilities. By becoming a senior or staff engineer, you also become more autonomous and free. Instead of someone else planning your work, this autonomy brings prioritization to your shoulders.
When I talked about prioritization for senior and staff engineers, I left out the decision moment specifically. While two are closely related, they are separate things. In this article, I will close that gap and discuss how to decide what to focus on next.
In software projects, level-based prioritization is the most common technique currently in use. Assigning tasks and stories high, medium, low priorities make it clear what to work on next. In real life, this priority strategy is not used a lot. While it's working for software projects, it's abstract for personal work prioritization. That's why I think the Moscow analysis technique is more suitable.
Moscow is an acronym for Must, Should, Could, Won't. Using plain English words makes it more understandable. When we compare them with more abstract terms such as high, medium, low, we see more clearly what is more important.
Before using the techniques that I discuss here, first set yourself some time and bring all your tasks, projects, or whatever you have. It doesn't matter how many of them; even more than a hundred is okay. Write each one of them in (virtual) post-its.
Now you have all the work under your hands, start separating these tasks according to the Moscow technique:
- Must have/do: Critical tasks, projects you have to complete or work on.
- Should have/do: Important tasks, projects that should be done if possible but not mandatory for the time being, or postponing doesn't cause many problems.
- Could have/do: Tasks that are desirable but not necessary. Tasks that you wish to do but not entirely required.
- Won't have/do (this time): Tasks are neither essential nor appropriate for the time being. Tasks that you will not do at all.
After separating, you should have a clear picture of what is more important and what's not—seeing all the work that needs to be done without any prioritization gives the false impression that you have to work on all of them and even try to finish them all. One thing we need to clear out is that you will never have time to finish all. Now at least, you know what you can do and what you won't do as well.
While Moscow provides us a model to prioritize, deciding which tasks to start is still missing. Now, each section that you put tasks in doesn't have any order in them. That's why we will include one more small step and apply a scale to all sections.
Taking a look at the dependencies, ambiguity and details of the tasks enables us to see more clearly what to choose next. Most of them have levels, and they are relative to each other. They are not "do," or "don't," not 1 or 0. That's why we use a scale instead of giving levels (high, medium, low) to them. Our brain needs the exact frame and minimum ambiguity to make a better decision. Unambiguity causes stress and affects our choices.
Now, go over all your tasks in each section and put them into the scale, one by one. While doing so, consider how a task relates to another one. Is it easier from task X or more challenging to implement?
After placing all the tasks, pick the easiest one to implement from the must-have list and gradually go to the difficult ones.
The work is not always will be on the "must-have" list. Sometimes you will need to juggle between must, should, and could. It's possible that you will have some slack time and want to take one task —such as the minor refactoring you always wanted to do—from the could-have-list. If you can, go ahead. You might also be blocked in all of your must-have tasks. Don't stop yourself. That's inevitable, and juggling between sections is okay. You can always come back to must-have ones because you know what to work on next and what not to work on.
Prioritization and taking time to decide on something are often neglected and forgotten throughout careers. Although they are the crucial parts of software projects, they are not used while planning individual work. Now, you have one new method to try. This method might not be 100% suitable for your work or needs. Feel free to adjust however you feel more comfortable. If you want to learn more about prioritization for senior and staff engineers, check out the podcast episode that Dennis and I talked about prioritization.