Joel on HR
Who thought that Human Resources practitioners could learn a thing or two about HR from a software developer? Joel Spolsky, who writes a popular blog for engineers called Joel on Software has a few things to say to which we should listen up.
Two things caught my interest.
1) Joel does a good job of reminding us about reducing the irritations.
2) Joel warns how incentive programs can actually detract from employee productivity.
Regarding irritations, Joel gives a great example of corporate irritations:
"At my last job, the system administrator kept sending me automated spam complaints that I was using more than --get this-- 220 megabytes of hard drive space on the server. I pointed out that given the price of hard drives these days, the cost of this space was significantly less than the cost of the toilet paper I used. Spending even ten minutes cleaning up my directory would be a fabulous waste of productivity."
He goes on to say (with emphasis), "Top-notch development teams don't torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer."
He also hints that giving programmers "cool" new tools can be a great motivator even if your programmers are underpaid.
Well said.
Joel's comments on incentive programs are equally to the point. To Joel and countless other software engineers, incentive programs are demotivational. These techies are purists at heart and want to do a good job for the sake of doing a good job. It belittles their sensibilities to give them a plaque for their work, making them feel as if they did the good work solely for the plaque.
Here's a quote from Joel's book (which of course is titled none other than, Joel on Software): "Treating your rocket-scientist employees as if they were still in kindergarten is not an isolated phenomenon. Almost every company has some kind of incentive program that is insulting and demeaning."
He points to a Harvard Business Review article by Alfie Kohn in which Kohn states that dozens of studies over the years have shown that employees who receive a reward for a task do not perform as well as those who expect no reward at all.
All interesting points that should serve to remind those of us in HR that the things that motivate some of our employees actually undermine motivation in others. See my earlier post on the Fish philosophy for more details.
Beth C.
Two things caught my interest.
1) Joel does a good job of reminding us about reducing the irritations.
2) Joel warns how incentive programs can actually detract from employee productivity.
Regarding irritations, Joel gives a great example of corporate irritations:
"At my last job, the system administrator kept sending me automated spam complaints that I was using more than --get this-- 220 megabytes of hard drive space on the server. I pointed out that given the price of hard drives these days, the cost of this space was significantly less than the cost of the toilet paper I used. Spending even ten minutes cleaning up my directory would be a fabulous waste of productivity."
He goes on to say (with emphasis), "Top-notch development teams don't torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer."
He also hints that giving programmers "cool" new tools can be a great motivator even if your programmers are underpaid.
Well said.
Joel's comments on incentive programs are equally to the point. To Joel and countless other software engineers, incentive programs are demotivational. These techies are purists at heart and want to do a good job for the sake of doing a good job. It belittles their sensibilities to give them a plaque for their work, making them feel as if they did the good work solely for the plaque.
Here's a quote from Joel's book (which of course is titled none other than, Joel on Software): "Treating your rocket-scientist employees as if they were still in kindergarten is not an isolated phenomenon. Almost every company has some kind of incentive program that is insulting and demeaning."
He points to a Harvard Business Review article by Alfie Kohn in which Kohn states that dozens of studies over the years have shown that employees who receive a reward for a task do not perform as well as those who expect no reward at all.
All interesting points that should serve to remind those of us in HR that the things that motivate some of our employees actually undermine motivation in others. See my earlier post on the Fish philosophy for more details.
Beth C.
posted by Beth N. Carvin at 1:52 PM
3 Comments:
I ran into the same issue that Joel the programmer did -- and I was an instructional designer. I backed up key data (not programs, but files) onto my network account till I got scolded by IT. I asked a manager friend in IT whether, if I gave them $50 for a multi-gig drive, they'd shut up. My stored data was in the 220 megabyte neighborhood that Joel mentions. The auto-warnings stopped.
I wonder what the repercussions would have been had my drive failed.
Two further comments, the first on Joel's purist-at-heart approach. I've worked with programmers and tech types for most of my 20-plus year career in training and development. Like any specialized crew, programmers and software engineers can develop an us-versus-them mentality. After I made suggestions to one programmer on ways I thought the interface would be easier for the (non-technical) end users to work with, he said, "Anybody who can't figure this stuff out without explanation doesn't deserve the feature."
One other (potential) avenue for motivation or at least awareness is to get Joel out of the IT shop and onto an interdepartmental team where he meets the people who have to put his "rocket scientist" product to work. Even better, put duct tape over his mouth and make him sit through some user testing. As someone from Borland said of this years ago, it's like watching a horror movie. You want to say no, no, don't go in there, but they do.
The serious side of this is that Joel works ultimately for the customer, and that realization has to be part of how he defines "success" in his work.
Second comment: Joel's probably too young to remember DeMarco and Lister's 1987 work "Peopleware: Productive Projects and Teams," but he'd resonate with much of what they say.
For example, in a series of studies of programmers, they found the following to be NON-factors in improving performance: the language coders chose (when they had a choice), years of expreience, number of defects per line of code, salary. Things that WERE factors? Your partner (two-person teams). Amount of dedicated workspace you had, and whether it was quiet, private, and had a phone you could silence or divert.
"When the office environment is frustrating enough, people look for a place to hide out. They book the conference room or head for the library...and just don't come back....People are hiding out to get some work done. If this rings true to your organization, it's an indictment."
As lagniappe, their "seven false hopes of software management" --
There is some new trick you've missed that could send productivity soaring.
Other managers are getting gains of 100%, 200%, or more.
Technology is moving so swiftly you're being passed by.
Changing languages will give you huge gains.
Because of the backlog, you need to double productivity immediately.
You automate everything else; isn't it time to automate away the software development staff.
Your people will work better if you put them under a lot of pressure. (DeMarco and Lister: "They won't. They'll just enjoy it less.")
Language does matter for developer productivity, though.
As an extreme, take WordPerfect until sometime into the 90s -- everything had to be written in assembly! I know someone who worked there; he was on a team that wrote "compilers" to translate x86 assembly into assembly code for other architectures! You can't tell me that's not a huge waste of time vs using C (probably the best option for portability at the time).
More recently, it's been demonstrated over and over that environments that provide garbage collection are at least a factor of two more productive than those that don't. Even more recently, I personally would find it almost physically painful to go back to Java after coding in Python for the past six months.
C vs Pascal probably didn't matter much. Python vs assembly is several orders of magnitude of productivity. And there are obviously levels in between. Language is NOT a non-factor.
Now, rewriting a 750kloc codebase in the flavor of the month just because it's the new buzzwod is clearly foolish. But you're equally foolish to ignore the advances in the state of the art when evaluating options for new projects.
--Jonathan Ellis
Anonymous User 1,
You are so right on with this:
"One other (potential) avenue for motivation or at least awareness is to get Joel out of the IT shop and onto an interdepartmental team where he meets the people who have to put his "rocket scientist" product to work. Even better, put duct tape over his mouth and make him sit through some user testing. As someone from Borland said of this years ago, it's like watching a horror movie. You want to say no, no, don't go in there, but they do."
I'm reading a book about entrepreneurship and starting a successful tech business and the author talks about doing market validation before you develop your product. He recommends that the entire team including the engineers get on the phones and participate in this process. The result? Engineers develop a customer focused perspective. Here's a quote from the book:
"First of all, they (engineers) realize hw hard it is to get through to people in the first place, much less find people who want the product. They quickly forsake the "if you build it they will come" mind set when they discover it takes ten phone calls for every single interview they actually get to conduct. Mike B____ says the engineers on his team were "shocked when it sometimes took two full days on the phone to obtain one interview" Imagine, then, what it takes to get people to shell out money to buy a product. Most important, the engineers begin to connect on a gut level with how the product might affect people's day to day lives, giving them a customer-centered point of view that engineers tend to lack otherwise."
Ain't that the truth?
Beth C.
Post a Comment
<< Home