The Uncarved Block

Should payment be by effort or by results?

Some companies and systems seek to pay people by effort, rather than by the results they achieve.

The first computer job I got when I moved to London was as a "Database operator" at a small, family owned company which supplied scientific equipment. They didn't make the equipment themselves, they were wholesalers. My predecessor in the job was leaving to travel the world and spent his last couple of weeks showing me the job, which entailed producing reports that the marketing manager could use to target specific products at the appropriate customers. The data came from an old Siemens/Nixdorf mainframe computer which ran the customer sales and invoicing system for the business, so the job involved importing the data onto a PC and producing reports using a spreadsheet package.

Every month my predecessor got the two floppy disks worth of data from the mainframe and spent about a week and a half importing the information into a Paradox database on the PC. The import procedure involved running a series of buggy QBasic programs (written for us by a contracting company), phoning the company when it didn't work, waiting a few days for a fix to arrive and inevitably giving up in disgust and importing the data by hand using cut and paste. Once the numbers were imported, he would be able to produce reports, which again was a laborious manual process. Every month he was able to do the import and produce about four or five reports in the remaining two or three weeks.

When I took over, I set about first fixing the bugs in the import program, and then rewriting it, using the built-in language which came with the database so I could put the floppies in and import the data straight into the database in a couple of hours with a single button press (It would have been faster but PCs were just very slow in those days). I gradually redesigned and normalised the database and made standard queries which answered all of my boss's usual reporting needs. Suddenly I could not only produce reports right from the beginning of the month, but I could produce more reports than my predecessor, with less work. All I did to produce a report was run a query, paste the results into a spreadsheet and apply the formatting. It would take about half an hour at the most to do a report. I could do more in a single day than my predecessor could in the entire month, so I used to get all my work done and then play a mindless first-person shoot-em-up game to fill my time.

Now the incentive for me to fix the software and write new software to improve my productivity in this job was that I was lazy and wanted to avoid the tedious manual labour that my predecessor did. My employers benefited hugely from this: not only did I do much more work than they expected, but I eliminated the need for support calls to the consultants to fix the import program. My boss, however, was always a bit grumpy when he saw me playing the game, thinking than I should be doing something better with the company's time.

Conversely, I once worked with a developer who checked in a truly extraordinary amount of code. He worked long hours, got paid very little and was continually frustrated. Why? Because his employer was principally concerned with the outcome of the code and wasn't seeing a whole lot of results they liked.

Lots of employers, consciously or otherwise, adopt a policy of payment by effort. It's not uncommon in the software jobs for people to measure "productivity" simply by looking at the number of lines of code checked in to the source code revision control system. As can be seen from this example, however, this can be enormously counter-productive as it provides an incentive for activity, rather than achievement. This is a big problem with so-called "alternative economic systems" such as parecon. They simply reward the wrong things.

permalink Updated: 2006-05-06