Sometimes you should do the small stuff first

 1 year ago
source link: http://rachelbythebay.com/w/2012/01/20/response/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Sometimes you should do the small stuff first

Let's talk about response times. I originally thought about this in a support organization context, but it could apply to other ventures as well. It might even work in software. Essentially, think of any place where there might be multiple outstanding requests at any given time and a limited number of resources to handle them. Then it becomes important.

I put forth the following example: let's say you are the only tech working on tickets for a given type of customer. This really happened in the evening and overnight hours for some of the "enterprise" level customers. Other techs weren't allowed to touch those machines unless there was something dreadfully wrong with the normal person.

During one of your lonely shifts, two different customers open two different requests at the same time. Both customers are of equal importance. Neither of them is a friend of the CEO or other high-up person who can lean on you to do them first. Neither customer has a contact who is especially pushy. They are just normal customers in that regard.

The difference here is that request #1 is going to take 60 minutes of uninterrupted work to finish, and request #2 is only going to take 5 minutes of uninterrupted work. There's no way around it.

That's the scenario. #1 at 60 and #2 at 5. Which one do you do first?

My position is that if everything else is equal, you do #2 first. You spend the 5 minutes, get it done, and put it away. Then you do #1, spend the 60 minutes, and finish it as well.

Here's why. In this scenario, ticket #2 is a 5 minute job which took 5 minutes to do, so it used 100% of its time. Ticket #1 is a 60 minute job which took 65 minutes to do (since 5 minutes were spent waiting for you), so it used about 108% of its time. Not too bad.

Now spin it around and look what happens if you do it the other way.

#1 takes 60 minutes to do and uses 60 minutes, or 100%. Okay. But now look at #2. It took 5 minutes to do and used 65 minutes, or 1300%. Oh dear.

This is a problem because customers get a sense of what is a small task and what is a big task. If they ask for something huge and it takes 5 minutes more, it's probably not a big deal. However, if they ask for something tiny and it takes 13 times as long to get it done, they probably won't be happy with you.

Now, in a perfect world, you'd never be stuck working on things alone, and tasks would never be atomic blocks of time. This would let you slice up requests into their constituent parts, so you could do 15 minutes of #1, then finish #2, then come back to #1 again and keep going. Some tasks do allow you to do this.

Other tasks, like "spend an hour on the phone with this customer to walk them through VPN configuration" tend to be atomic. You can't slice them up into smaller bits. Odds are, you won't be able to do anything else while you are talking to them.

Strangely, this idea seemed controversial when I brought it up. I guess too many people are married to the notion of always doing the long or difficult one first and don't always see the big picture.

About Joyk

Aggregate valuable and interesting links.
Joyk means Joy of geeK