Gift outcompetes exchange in design too

I just fin­ished Eric Steven Ray­mond’s Home­steading the Noos­phere. It’s a ter­rif­ic read for any­one look­ing for a thor­ough look at the inner work­ings of the open source soft­ware devel­op­ment com­mu­ni­ty. Like oth­ers, when­ev­er read­ing this kind of stuff soon­er or lat­er apophe­nia hits and I try to tie bits to my own dis­ci­pline, which isn’t pro­gram­ming but design.

In one of the last chap­ters of the essay (titled Gift Out­com­petes Exchange). Ray­mond offers some tan­ta­lis­ing insights into the rela­tion­ships between doing com­plex cre­ative work, moti­va­tion, and reward. While read­ing it I recog­nised a lot of ideas that I’ve long felt are impor­tant but could nev­er real­ly artic­u­late. Now I final­ly have some great quotes, and (over 10 year old) research to back it up!

Psy­chol­o­gist There­sa Ama­bile of Bran­deis Uni­ver­si­ty, cau­tious­ly sum­ma­riz­ing the results of a 1984 study of moti­va­tion and reward, observed “It may be that com­mis­sioned work will, in gen­er­al, be less cre­ative than work that is done out of pure inter­est.”. Ama­bile goes on to observe that “The more com­plex the activ­i­ty, the more it’s hurt by extrin­sic reward.” Inter­est­ing­ly, the stud­ies sug­gest that flat salaries don’t demo­ti­vate, but piece­work rates and bonus­es do.

Thus, it may be eco­nom­i­cal­ly smart to give per­for­mance bonus­es to peo­ple who flip burg­ers or dug ditch­es, but it’s prob­a­bly smarter to decou­ple salary from per­for­mance in a pro­gram­ming shop and let peo­ple choose their own projects (both trends that the open-source world takes to their log­i­cal con­clu­sions). Indeed, these results sug­gest that the only time it is a good idea to reward per­for­mance in pro­gram­ming is when the pro­gram­mer is so moti­vat­ed that he or she would have worked with­out the reward!

Oth­er researchers in the field are will­ing to point a fin­ger straight at the issues of auton­o­my and cre­ative con­trol that so pre­oc­cu­py hack­ers. “To the extent one’s expe­ri­ence of being self-deter­mined is lim­it­ed,” said Richard Ryan, asso­ciate psy­chol­o­gy pro­fes­sor at the Uni­ver­si­ty of Rochester, “one’s cre­ativ­i­ty will be reduced as well.”

So a team of design­ers work­ing in the mode Ray­mond describes would choose their own projects and not be reward­ed for their per­for­mance on projects (which is usu­al­ly mea­sured in effi­cien­cy and client sat­is­fac­tion). In stead, to real­ly keep them moti­vat­ed, they’d be giv­en a large amount of auton­o­my (and would­n’t be instruct­ed on which prob­lems to solve and how to go about it). Of course, this only works with skilled work­ers, but I don’t think that’s the rea­son these philoso­phies haven’t been applied to design work on the scale they have been in pro­gram­ming. I think a lot of resis­tance for actu­al­ly allow­ing design­ers work like this in a com­mer­cial set­ting are relat­ed to a fear of giv­ing up con­trol. Lat­er on Ray­mond fin­ish­es the chap­ter with:

Indeed, it seems the pre­scrip­tion for high­est soft­ware pro­duc­tiv­i­ty is almost a Zen para­dox; if you want the most effi­cient pro­duc­tion, you must give up try­ing to make pro­gram­mers pro­duce. Han­dle their sub­sis­tence, give them their heads, and for­get about dead­lines. To a con­ven­tion­al man­ag­er this sounds crazi­ly indul­gent and doomed—but it is exact­ly the recipe with which the open-source cul­ture is now clob­ber­ing its competition.

When will the first exam­ples appear of design done in this way? When will the first projects pop up that out­com­pete the cathe­dral style designs process (or are they already among us)? Are there any design­ers out there actu­al­ly work­ing in this way? I’d love to hear from you.

Update: I changed the link to Flickr into one point­ing to a post by Tom Coates on how Flickr was built.