I once interviewed for a job where the interviewer asked how I decided to work on tasks. He said, “There are two kinds of workers. The first concentrates on a task and does nothing else until it is completed. They can only do one thing at a time. Then, there are the jugglers. Which one are you?” When I responded that I tended toward the latter, the interviewer smiled. That was obviously the answer he was looking for.
IT is very much defined by focus. Being able to work on a project until it is totally finished is a very admirable quality to be desired. In my experience, especially in the VAR world, it is equally as important to be able to shift your focus quickly to other tasks that require attention. As indicated above, it’s not unlike juggling. Being able to focus on a project for a few hours or days and then move to a different project for a few hours can be a very critical skill for high level engineers.
Technology has been doing this for years. Think about a preemptive multitasking CPU. It appears to be many things at once. It’s really executing instructions for a given process for a period of time (a timeslice). Because you can process enough instructions in that time to accomplish a function it all appears to work like magic. The key is to tune the processor to use the right timeslices. If the timeslice is too long the processor will sit idle waiting for the program to generate new instructions. If the time slice is too short the program won’t be able to execute enough instructions during the window and the program will appear unresponsive. Just like a juggler, it’s all about the timing.
Choosing what to juggle in IT is almost as important as knowing how to do it. When you are just starting out with juggling, you use safe, soft objects to contain the damage. You don’t start off with chainsaws and molotov cocktails. When juggling IT projects, be sure to juggle those that don’t have hard deadlines or require critical path updates on a regular basis. If you’re required to provide a weekly update on an installation, be sure you’ve allocated enough time during the week to do something. Otherwise, that weekly installation report is going to look pretty thin.
When learning to juggle, most people spend entirely too much time worrying about the ball in their hand. They tend to lose focus of all the other objects floating in the air. That’s why they tend to start dropping them. In the same way, you can’t be so dialed in on one project that you completely neglect all the other things going on. Finding a good point to stop one task and start working on another is a very fine art.
This isn’t for everyone. If you’re a person that can’t shift focus fast enough to keep all the balls (or projects) in the air without dropping something, you should avoid working on many things at once. There’s no shame in having laser focus on something. It works well for a lot of folks. It gets hard things done right. It’s just another way to do get the job done.
Tom’s Take
I’m a juggler. I try to keep everything going at once while I wrap up what I can. I do my best to avoid dropping things, but something slips through from time to time. I also taught myself to juggle in real life. I can keep three tennis balls going with no issues. I realize my limitations, though. I know that more than that is too many. In the project space, I know that having more than I can handle is bad for everything, so I try to keep my focus on a manageable about of juggled things. It’s better to juggle a few things well than juggle an impressive number of things poorly. I’ll let you know when I work my way up to the chainsaws.
I liked your post, but I did want to say I never did see a juggler do more than 10 items at a time.
I see the jugglers at work never complete some tasks because there are always new ones thrown in. The shear volume is too great. Important tasks, like network down emergencies, really need all the focus until resolved.
you juggle what you can…
if I were in IT as a profession and employed to do a job other than the job was employed for to do, I would start a complete audit on what’s in service is it still usable in context of the job at hand due to open scope of job migration of services and servers where needed then go through and tackle the jobs i was employed for to do, nothing worse getting 1/3-1/2 through a project to find out someone fucked up in the order process to find out you’re something vital to complete the totem that was failed to be sourced at the start of said project.. nothing worse than walking into a cluster fuck because someone prior didn’t do their JOB properly I wouldn’t leave things in a shit heap leaving a job not even half done, i would rather see when i hold the reigns no oversight happens as at the end the day you pick up a rep on something outside of your/my control prior to a company hiring me to do a job..
as undersight on oversight always happens and you get the wringer position when the issue was someone else’s fault to begin with..