What is your “To do list”: A queue, a stack, or a priority queue?
In a collaborative environments, people send and receive requests from many people. Individuals should process incoming requests and add them to their priority queue. Individuals should send descriptive requests to others with a clear deadline and importance leveling.
What are Queues, Stacks, and Priority Queues?
A queue is a line. For example, we enter a queue when we wait to pay for groceries. The person who enters the cashier line first will checkout first. A queue follows a “First In Last Out” or FIFO process.
A stack is a pile of stuff. For example, our email inbox is a stack, the newest email (Last in) is always at the top, usually read, deleted or archived first (First Out). A stack follows a “Last in First Out” or LIFO process.
A priority queue is a line with a set of rules that allows people to ‘skip ahead of the line’. For example, we enter a priority queue when we wait to board an airplane. The flight attendant allows the highest priority customer in the queue to board first. For instance, a business passenger will board before an economy passenger even if the economy passenger got in line 30 minutes earlier. A priority queue, unlike a queue, requires a set of rules to decide what is the highest priority. For instance, who boards first when there are a handicap person, a passenger with a baby, and a business ticket passenger all in the queue?
What does our “to do list” look like?
Each morning there is a new set of requests waiting for our attention in different sources like (Facebook, Whatsapp, Asana, Email, etc.) in addition to our existing ‘to do list’. How we handle these requests is critical to our long term performance.
We can add the requests to the top of our to do list (stack), add them to the bottom (queue) and risk missing something critical, or process the requests and add them to our priority queue. After processing, we can resume working on our top priority. Seems simple enough?
Here’s where and why I think it gets tricky
How do I handle a request that does not include a priority level?
How do I handle a request that is pushed compared to a request that is pulled when I’m ready to process the request?
The concept of “pushed” and “pulled” requests was first introduced to me when I got my first iPhone. My iPhone asked if I want email to be pushed to me as they are received or to be hidden from my view. The latter avoids new emails constantly distracting me. I can decide when to ‘pull’ the emails.
We are better off “pulling requests” at set times throughout the day than having requests pushed to us at all hours. However, as employees or service providers, our managers or clients are, of course, entitled to be make requests ‘on their time’.
As managers, we make requests of our employees often so that we can focus on other tasks. We rely on our employees or service providers to process the request, assign it a priority and implement it when it’s the highest priority item left in their queue. We should assign it a priority when we make the request but assigning it a priority is a tiring and exhausting process that requires more time from us.
As employees, we often *mistakenly* assume that the newest request from our manager is the most important unless otherwise stated. We become confused. We think to ourselves – my manager knows I can’t complete the other 3 requests she made yesterday and this new one. Obviously, she wants this one done first or he would have told me its priority level was lower. Further, how my boss makes the request hints to the tasks level of priority:
- If my manager sent the request on Slack, then the task must be Urgent;
- If my manager sent the request via Email, then the task must be Urgent, but not as urgent as Slack.
- If my manager sent the request via Asana, he doesn’t think it’s as urgent.
Urgent does not imply Important
Further, as employees, we confuse urgent with important. Slack may mean urgent but it doesn’t mean important. When left to decide, we mistakenly may resolve do the newest request next; effectively changing our to do list from a priority queue into a stack – a stack in which the important projects get hidden at the bottom.
What should we do to make sure our to do lists remain priority queues?
When people send requests they should include a description explaining how important (and urgent) a request is to the receiver. This means there should always be a deadline to a request.
People should avoid pushing people requests that are not super urgent since there is no need to push a request that is not urgent. Managers may be better off adding the request to the meeting agenda for them or scheduling an email to send later in the day. For instance, managers can write an email at 6pm and schedule it to send at 7am so their employees can have a better work/life balance.
Employees should make it know when they ‘pull requests’ e.g. 10am in person scrum + email processing.
Employees should respond to a requestor with a recommended order of priorities (and other tasks they are working on so that a manager has transparency on how someone spends their time. This makes it easy for a manager to change priorities or juggle the other requests being made of their direct report.
 These terms are commonly used to refer to Data Structures. See here for more on the topic