Corante

Check out the The AppGap - a group blog on the tools and trends that are changing the way we work.

Future Tense

« The Power of the X Chromosome in the Workplace (Part )II: Women Really Are Different than Men | Main | Work at Home Moms »

July 19, 2005

Productivity Measurement - Part 1

Email This Entry

Posted by Dave Desforges

So I promised in my last entry to give my 2 cents on how to measure productivity of knowledge workers. Wouldn't it be great if we had some magic metric that we could apply to see if it actually improves when people are allowed to leave the cubicle farm and work from anywhere? I'll tell you the bottom line right now: I don't have the answer. But I have learned a few things, and I can tell you about that.
1. Gil Gordon wrote a great summary 8 years ago called The Last Word on Productivity and Telecommuting and I think it's just as relevant today. If you don't have time to read the whole thing, be sure to at least read Section 3 on using Effectiveness instead of Productivity.
2. We've tried to find an answer at Sun, too - both to convince ourselves that the investment was worth it and to be able to show our customers what it could do for them (especially as we offer a consulting practice designed to help other companies learn from Sun's scar tissue in establishing its internal iWork program and to more quickly establish their own alternative workplace program with the help of our knowledge, processes, and tools). The tough part is: for knowledge workers, there is no standard measure that can be applied to everyone, so you end up wanting to measure something that's relevant to certain job functions. Sounds great in theory - let's measure all the software engineers the same way or all the sales people in a same but different way. In reality, though, there is no agreement on whether those metrics are even valid. A couple good examples of functions and metrics that we have looked at:

-Software engineers and lines of code written: Seems simple enough, but when you delve into it, you start to realize the the number of lines of code expected to be written is based on the complexity of the project and the stage of it (more lines are written at the beginning of the project than when you are doing bug fixes). Also, in many cases, one person's 2 lines of excellent code may actually be better than another person's 10 lines of sloppy code. As Gordon states about this, goaling SW engineers on lines of code written may not bring about the intended result.
-Sales people and deals closed (by enabling them to spend more face time with customers): Is 1 strategic account deal more important than 5 general territory deals? Did closing the deal have anything to do with changing the employee environment or had it been in the works since before the change? Yes, I can measure the number of customer contacts made before and after going remote, but do customer contacts themselves lead to sales, or is there more value in only contacting the customer when you have a solution to their business problem?

I'm sure others can add a bunch of other questions/issues to both of the above examples that would make people question the validity of the metric. And if you (and/or others) believe the measurement is suspect, why would you spend the time/resources measuring it?

So, how do we measure "productivity" at Sun to know whether the company's getting more bang for its buck by enabling people to work from multiple locations? I'll tell you in Part 2.

Comments (1) + TrackBacks (0) | Category: Distributed Work


COMMENTS

1. John Niles on July 23, 2005 4:28 PM writes...

Gil Gordon is very perceptive on performance measurement of remote workers. I also commented on the teleworker performance question in a paper I wrote for Hudson Institute in late 1998, URL above, scan down for "productivity."
John

Permalink to Comment


EMAIL THIS ENTRY TO A FRIEND

Email this entry to:

Your email address:

Message (optional):




RELATED ENTRIES
Bob Sutton on Crappy People versus Crappy Systems
New bloggers on the future of work
Circles of knowledge and boundaries of ignorance
Tool-and-Die Makers in a Knowledge Economy
Wikiwise 50: #45 -- Yahoo!
Knowledge management, reinvention, and innovation
Balancing diligence and laziness
Wikiwise 50: #46 -- Microsoft