Damon Armstrong

Caffeine Induced Tirades about .NET and Life
And don't forget to check out my latest Simple-Talk articles
Add to Technorati Favorites      Add to Google     

Gauging Success by Results and not by your Work Hours

Published Tuesday, December 05, 2006 4:56 AM

As we gathered around the board room table everyone on the project team noticed a glaring bullet point on the agenda:  Project Hours.  Apparently a member of our management team had returned from a meeting at 4:30 one day and noticed that everyone had left for the day.  He was apparently none-to-happy about it, presumably because he was there working hard at 4:30 and figured everyone else should be in the same boat.  The exec mentioned it to the project manager, and the project manager was now facing us down, telling us that we had to be there from 8:00 to 5:00 p.m. every day at the behest of an unnamed executive. 

Now, some background on the situation.  We were in the middle of a six month long project that we had just gotten back on track.  A few weeks before we were way behind schedule, and an exec came into the weekly meeting to inform us of the severity of the scheduling issue.  His idea of leadership was to determine the route he wanted people to taken, then try manipulate an "open dialog" so the group thought it was coming up with the plan on its own.  The problem was that he sucked at it.  Basically he wanted us all to "do what was good for the company" and work 90 hours a weeks for the foreseeable future, using brute force to overcome the situation.  He came off looking like a complete wuss who couldn't just come out and say what it was that he wanted.  Anyway, we decided to shift some people around to focus on specific areas instead of being on a broader scope of items.  It worked, and the project ended up back on track and looking like it was going to stay that way for the foreseeable future.  That's when the project hours meeting came up.

We inquired who it was that had an issue with our work hours so we could determine the exact nature of his concerns, address them, and move on, but were met with fierce resistance that the person was going to remain anonymous.  I'm of the opinion if you have an issue with something you should address it personally.  I can understand if someone is timid about addressing an issue with a superior because they do hold the key to your success at a company.  But if you're an executive, you need to be able to directly address issues down the chain or you come off looking like a pretty ineffective leader.  We assumed it was the exec from the last meeting because the other execs (hey, there weren't that many of them in the company) were pretty sharp and presumably knew not to mess with a good thing.  So we voiced our issues to the project manager in hopes that they would reach upwards into the corporate structure.

Our biggest issues was that everything was running smoothly, people were happy, the project was on track, things were getting done, and now somebody wanted to change the dynamics of the environment.  We did not work with the execs.  Nor did the execs rely on us for information. Execs got their information from the project manager, and the project manager got her information from our status reports that we filled out on a seemly endless basis.  What was the point of setting up work hours?

I think the issue at hand is that people correlate effectiveness to hours worked.  It's assumed if you are present for 10 hours, that you got more done than someone who was there 8 hours.  Of course, nothing could be further from the truth.  There have been days when I've had a headache and sat staring at my screen and gotten nothing accomplished. There have been days when I've been hopped up on caffeine and done three days of work in four hours.  The reality is that every day you work, you have a bandwidth and an amount of time, and the product of those two is what you get done for the day.  Here's a bogus mathematical formula demonstrating the concept:

Bandwidth * Hours = Results

And of course, Bandwidth is a complex algorithm comprised of a variety of things like natural ability, education, experience, health, motivation, etc.  Then there is the issue that everyone does not have the same Bandwidth for a given situation.  At the beginning of the project mentioned above, I was tasked with Java development.  I'm not a Java developer.  I have no desire to be a Java developer.  So it should be no surprise that my bandwidth for Java development is pretty low.  Our Java guru at the time, however, was awesome at Java and had a very high Java development bandwidth.  And we had another guy who was average.  For the sake of comparison, let's say that my Java bandwidth is .2, the guru's was 1.75, and the average guy's was 1.0. 

  Bandwidth Hours Results (units)
Me (.Net Guy Doing Java) 0.20 8.0 1.6
Average Java Guy 1.00 8.0 8.0
Java Guru 1.75 8 14.0

From this table, you can see that from a time-perspective we would all be viewed as equal, but the end of the day results tell a different story. So, what do you do about it? 

I think we need to move away from the hourly mentality and move to a daily results mentality.  Most people go to their jobs each day faced with the prospect of having to work eight hours, and that seems pretty bleak.  Instead, I think we should go to work, set some goals outlining what we want done at the end of the day, then set out to make it happen.  Talk about motivation to work.  You've got a goal that you set and a tangible reward for reaching that goal: the earlier you get done, the earlier you get to leave.  I think it would do wonders for productivity and avoiding burn out.

Apparently Best Buy is giving this a shot:  http://www.msnbc.msn.com/id/16040492/

by Damon
Filed Under:
Attachment(s): clock.jpg

Comments

 

jtklopcic said:

Finding a shop that understands this is my life's dream.  The best I can settle for is a "Don't ask, don't tell" policy, in which my boss doesn't bring up my hours as long as I keep checking code in.
December 22, 2006 9:02 AM
You need to sign in to comment on this blog

















<December 2006>
SuMoTuWeThFrSa
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456
On the Trail of the Expanding Databases
 It is sometimes difficult for other IT people to understand the constraints that DBAs have to work... Read more...

SQL Server 2008: The New Data Types
 Brad continues his helicopter-level view of the most interesting new features of SQL Server 2008 with a... Read more...

Reporting on Mobile Device Activity Using Exchange 2007 ActiveSync Logs
 In this new column giving practical advice on all things Sys Admin related, Ben Lye takes on the often... Read more...

The Bejeweled Puzzle in SQL
 Alex Kozak provides another SQL puzzle to hone your SQL Skills with.  Read more...

Using Powershell to Generate Table-Creation Scripts
 For all of us who learn best by trying out examples, Bob Sheldon produces a PowerShell script file for... Read more...