Working Off the Clock

Recently, I read Ben Nadel's post of his thoughts stimulated by a book that we both seem to be reading, Drive by Daniel Pink. Ben is thinking about the best way of compensating workers. It's a great read with lots of comments. It reminded me of how I stumbled into something that I had pretty much forgotten about -- and I wonder if it would work in a different context.

Years ago, I was suddenly given the job of foreman in a woodworking company. Having so recently been "just" a worker, and free from any ideas of management theory, I thought I'd try something I thought I would like as a worker. I asked the owner what percent of income went to direct labor. I forget now what it was; let's just say it was 30%. So, on a $50,000 job, $15,000 would typically go to pay wages.

Hmmm..., I thought. I called in Dan, my go-to guy, and said, "Dan, we have this job that needs to be done. What if you pick someone to help you and I'll give you a flat $15,000 to do the job. You'll be off the clock and you can work whenever you want."

Dan was tantalized by the idea of making a lump $15K. He talked with a couple of other employees and chose one, having agreed with him on a fair split. Now, normally, the job would have taken perhaps 2 months to complete. But Dan and his partner did it in 3 weeks.

Now, Sam came up to me. "So, how do I get a contract?" You can guess where this headed. Within a short time, everyone was working purely on contract. Now, the interesting thing (to me) was that not only was the work getting done faster, but the employees were MUCH more creative.

"Hey, we can sub this part of the job to a big shop that has a CNC machine and save ourselves a lot of time." "We can get my sister in here to help with this part of the job and we can finish earlier and get another contract." That sort of thing. Gee, they never thought of that when they were working on the clock!

This happened in the first quarter of the year.By year's end, we had tripled our production -- and all the employees were making more than they ever had. And they were thinking like entrepreneurs.

Software development is different than woodworking. But it makes me wonder whether this approach could be adapted to software. One way to think about business is that the owner/manager is a speculator. Not in corn or cotton, but in labor. I think I can find a way to keep my labor costs low enough to keep on the lights and generate a profit. But what if EVERYONE were a speculator? What if they had skin in the game -- and the better we played the game, the more everyone would benefit?

The way most companies run, developers really get no benefit by thinking outside the box. In fact, they're running a risk. The safest, sanest thing to do is bury yourself in your code. Take the practice of pair programming. In my own experience, pair programming is amazingly productive -- and it produces better code. But many developers hate the idea. Fine, it's more productive, the code's better -- but it's not as enjoyable for many programmers. So they find excuses not to do it.

But what if software development were a game in which, the more productive the company is, the higher I score? Might I not be willing to create some tools that might speed up production -- if I "scored" higher? Would I be more interested in trying new things -- if, by so doing, I advanced in the game? And if the score happens to be real money that I can actually buy stuff with, or save for retirement, or give to charity, or invest -- wouldn't that be the coolest way of keeping score?

I'm going to start thinking how to implement something like this. The biggest thing I learned from my woodworking experiment was the power of turning work into play. Not just for an individual developer, but for the entire team. To do that, the player has to know where they are in the game. There must be a measurement system -- perhaps several -- that tell the player how they're doing.

There are some aspects of all work that are drudgery. But the tedium associated with that work is happily undertaken by game players for the benefit of advancement in the game. Can we figure out a way to make software development that fun?