Over the past decade I have been on a journey from the world of development into customer-facing roles. In my job today, I am the focal point for most of my company's customer interaction. As a productivity freak I like to study the best ways to manage my time. And so, I turned back to my development roots and found some interesting parallels in the world of multiprogramming. In this post, I would like to share an analogy between personal time management and two common multitasking models.
Firstly let's paint a picture of multitasking. There are two primary models I would like to discuss:
- In cooperative multitasking, applications voluntarily cede time to each other. The application itself decides when the time is right to perform a context switch. Cooperative multitasking has all but disappeared from modern operating systems - it depended too upon the discipline of application developers.
- In preemptive multitasking, the operating system forces a context switch at regular intervals to guarantee that every application gets a slice of control. This means more context switches, so while their overhead means everything slows everything else down, the even distribution of cycles keeps things going at a steady pace. Preemptive multitasking is the prevalent model in today's operating systems.
Now let's look at people. In this case, each person is a "CPU" with many tasks to handle. As people, context switches are hugely expensive. It takes us time to pick up momentum after switching tasks. Indeed, one of the first rules of time management is to focus on one task and process your to-do list one item a time. Additionally, if you really must juggle several tasks, it's better switch between them only at comfortable exit points. Does this sound familiar? It is, because people are cooperative multitaskers! You work best when YOU decide when to switch.
Is this true for everyone? To find out, let's examine cooperative multitasking's Achilles heel: UI. Preemptive multitasking wins hands down when it comes to appearing more responsive to user input. This is important because no one likes a UI that responds slowly to input: you click a button and want it to respond - immediately. If it insists on lengthy processing, then you expect a progress bar to make sure you know what is going on.
In my analogy, the company's UI is its customer-facing workforce. My analogy's bottom line is this: if you are customer-facing, your time is best managed using preemptive multitasking.
This flies in the face of traditional time management. Keep your phone on and your email program open! Let emails, calls or service tickets interrupt you! Yes, this means less efficiency in terms of net work. But when working with customers - just like a UI - responsiveness trumps efficiency!
If a customer calls you (= clicks a UI button) then you must answer (= provide visual UI feedback). If you don't have an immediate response then acknowledge the request (= show a message box) and keep the customer informed on your progress (= show a progress bar). I'll take this further by proposing that if you are handling tasks for several different customers, it's preferable to make a little daily progress on each task and report back on that progress, rather than processing the tasks one by one and leaving your customers hanging.
For me, this parallel has helped resolve the contradition between sensible time management and the fact that I juggle too many balls in the air. Ironically, as a developer I was never particularly fond of UI programming. It seems that I myself have become something of a UI now! :-)
