Skip to content

Deadlines Kill Productivity

April 26, 2016

Don’t rush me. You rush a miracle man, you get rotten miracles.

You know that scene in the movie where the bomb is about to explode? Our hero stands there with a pair of wire cutters watching the digital clock slowly count down to zero, trying to decide to cut the red wire or the blue wire. And, right before it blows up, he finally snips the red wire, and the clock stops at 00:00:01. 

Nothing like a deadline to motivate you, right? Deadlines, and objectives are almost always more trouble than they are worth. As a new manager, this might not make any sense. I mean, how are your employees going to know what they should be working on unless you tell them and then hold them accountable? 

They are going to do it, because you hired people who know what they were doing. Or, you hired people and then trained them to know what they are doing. I should make a distinction between goals and objectives. Goals are good. Goals should be set together with your employees. Goals should line up with the company’s mission statement. But, a goal and an objective are not the same thing. 

I once worked for a company where I was responsible for the email system. Everyday a report would run that showed the availability of the email system. If we had a server crash, or lost connection to the Internet, it would impact our availability. The “goal” was 96%. If the system was available for 96.1% of the time, my indicators were green and no one bothered me. If the system was only available for 95.9% of the time, the indicators turned red and I had people yelling at me to fix the system. 

In a 24 hour period, that 0.2% difference is 173 seconds. Just a little less than 3 minutes. So, three minutes were the difference between a “healthy” system and a “broken” system. Do you think anyone actually noticed that 3 minute difference? I mean anyone who was actually using the system? No. It wasn’t a goal. It was an objective. 

I set a different goal. My goal was to have the system up and running as much as possible. If we had a system outage, I wanted my engineers to figure out why and then fix things so it wouldn’t happen again. 

But Rodney, it only dropped out availability numbers by 3%. We’re still in the green. 

More than once I had to explain to my engineers, and my boss, that If our systems were unavailable for 4% of the day, that was unacceptable. That’s nearly an hour per day. It didn’t matter that we’d get a green indicator light. The purpose of our team was not to get green indicator lights. The purpose of our team was to make sure the email system was available for people to use. And being unavailable for an hour per day was simply not good enough. 

You’ve no doubt, heard that goals should be S.M.A.R.T

  • S-pecific
  • M-easurable
  • A-ttainable
  • R-ealistic
  • T-imebased

And I agree. But, I see those as more often describing objectives. My goal might be to become more healthy. The objectives might be to run a certain number of miles, three days per week. My goal might be to publish a novel. My objectives might include taking a creative writing class, and writing a certain number of hours per week. 

When you hire smart people, and you’ve properly trained them, you should be able to give them a goal and let them set the objectives. They will do it anyway. The danger of setting the objectives for them, is that they may start to perform to the objectives. In other words, they may decide to do just enough to satisfy the “goal” and no more. You might be getting 96% availabilty when you could be getting 99% if you had instead set the goal to “keep the system up and running as much as possible” and let the employees set their own objectives. 

Let’s go back to the bomb with its ticking clock. You’re going to risk getting blown up on the flip of a coin? In the movies, the hero always picks the right wire. But, in real life, you don’t want to rush through an important decision. The goal is don’t get blown up. The objective should be left up to the guy who actually knows how to defuse a bomb. 

Rodney M Bliss is an author, columnist and IT Consultant. His blog updates every weekday at 7:00 AM Mountain Time. He lives in Pleasant Grove, UT with his lovely wife, thirteen children and grandchildren. 

Follow him on
Twitter (@rodneymbliss
Facebook (www.facebook.com/rbliss
LinkedIn (www.LinkedIn.com/in/rbliss)
or email him at rbliss at msn dot com

(c) 2016 Rodney M Bliss, all rights reserved 

2 Comments
  1. Great post!

Leave a Reply