By: Alon Cohen
I keep hearing the word prioritization. We need to prioritize and focus. But do we really? Is taking a sip of coffee while driving considered a change of priority on the road?
Many employees in different organizations find themselves in a situation where they need to perform simultaneous tasks. If you find yourself in this situation you face the usual dilemma of what to do first. Most people in this situation go to their boss and ask the boss to set priorities for each task. The boss prioritizes your tasks, and you are happily working on your top priority task.
You can now focus on your single task and do not need to consider the company or other people in the organization. If someone asks why you are working on A and not B, your ass is covered.
Your boss is happy since you are out of his/her hair, and most importantly, you are working on what’s essential for your boss’s career advancement.
However, contrary to common thinking, you will find that prioritization, although it seems the right thing to do, must be done correctly. Doing this incorrectly will harm the organization rather than help it.
Why is that?
Extra tasks you were asked to perform while you work on your top priority are not getting done and, in many cases, block other people from doing their job until you can provide them with that missing piece they need from you. In essence, you are crippling your company by blocking other resources from being productive.
Now, say a new fancier task for a larger customer comes along. It is now given the highest priority; you drop everything and start working on the new, more lucrative task. All that until the next highest priority task comes along, causing you to drop the task you’re now on. Before you notice, you have spent a whole year starting new tasks but never finishing any of them.
Not only that you cripple others by not performing tasks they need from you, you yourself have become a complete waste of resources for the company by doing all you were asked but not finishing any task you were given.
Our standard prioritization tends to starve all other tasks but the top one. Exclusively working on your top priority task will render many otherwise effective employees that need your input worthless and hence can and will bog down the whole company.
The analogy is that every time you take a picture on your smartphone or update an APP, your music will stop until the smartphone finish’s storing, installing, or updating the picture or APP. In fact, maybe the music will never start until you restart it. Clearly, if your phone behaves that way, it is not as "smart" as you want it to be.
The issue is that the people, who prioritize tasks, need to consider the length or complexity of the interrupting task. They also seldom consider the people dependent on those tasks as a prioritization factor.
In most cases, the prioritizers see only their own KPIs or global company priority list as the main factor in the prioritization process. As I have shown, operating in the above fashion, in most cases, yields terrible results.
Here is what I propose:
Start thinking like a Smartphone! Look at the global picture!
While you work on your highest priority task, an interrupting task may come and require your attention. If that interrupting task is relatively short and blocks other resources in the company, you should give that task higher priority. In reality, if you save your current context, perform an organized fast context switch, and work on the interrupting task to enable other resources in the company to be productive, you are doing the correct thing.
Once that interrupting task is done, recall your saved context, switch back to your main task, and work faster to recover lost time.
The company and management can keep all of its priorities the same. You should not consider that as the general complaint of "my priorities keep changing." This mode of operation is called Interrupt Handling. As an analogy, think that when driving your car, you do not stop on every sip you take from your coffee.
For SW developers: any event-driven software or code that handles interrupts works that way. This is why the ability to perform asynchronous API calls (vs. blocking API calls) in any code is critical to achieving higher performance.
Suppose you consider yourself ambitious and aspire to climb fast in your organization. In that case, you should master the art of Interrupt-Handling and fast Context-Switching, even in cases where one interrupting task happens inside another (recursively). The key is to be able to maintain the integrity of the context of your work at each level, “inception style,” and be able to come back to it and finish the interrupted tasks.
In fact, if you are a programmer working on a big complex project while bugs are discovered in your currently published SAAS (Service) product, and you still think like a single-core, single-threaded, non-real-time operating system with a simple task priority list, there are probably more suitable jobs than programming for you.
After all, if you need help understanding how to handle interrupts correctly, how can you program your APP or SAAS to handle those situations. And if you have already launched your SAAS, how would you be able to handle the ongoing customers’ requests for bug fixes or integrations without being able to handle Interrupts?
As an employee, if you find yourself saying to your boss or co-worker, “I know you need this, but do you want me to drop A and work on B?” or if you say, "I can only help you in two weeks because my first priority is my sprint ticket list," you just defined yourself, for your co-worker who needs your help and tomorrow might be your boss, as an undependable, non-ambitious, non-coperative employee who should be looked over in the next round of promotions.
The good news is that interrupts happen all the time. You might have another chance to redeem yourself. If you see an Interruption coming, do yourself and your company a favor and handle it!
Thoughts?
