Gift outcompetes exchange in design too

I just fin­ished Eric Steven Raymond’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 wouldn’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 com­pe­ti­tion.

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.

Published by

Kars Alfrink

Kars is a designer, researcher and educator focused on emerging technologies, social progress and the built environment.

2 thoughts on “Gift outcompetes exchange in design too”

  1. In stead, to real­ly keep them moti­vat­ed, they’d be giv­en a large amount of auton­o­my”. Ja dat geloof ik ook wel, maar er zijn natu­urlijk ook andere doe­len dan gemo­tiveerde medew­erk­ers ;-) Zoals je het hier stelt lijkt de gemo­tiveerde medew­erk­er pri­mair voor het suc­ces van het project. Daar denkt een klant wellicht anders over.

    Maar goed, ik vind het wel een inter­es­sante benader­ing. Ik geloof ook wel in het principe. Maar ik ben wel benieuwd of je dan ook niet nog iets moet toevoe­gen: meer ver­ant­wo­ordelijkheid voor het ‘verkopen’ van het ein­dresul­taat aan de klant. Want zo’n benader­ing hanteren bij pro­jecten met klanten heeft natu­urlijk nog wel wat hak­en en ogen. Het vraagt veel vertrouwen van de klant in een goede afloop, iets dat je moet bewi­jzen.

    Ik ben wel benieuwd hoe je daar tege­naan kijkt.

  2. Ja dat geloof ik ook wel, maar er zijn natu­urlijk ook andere doe­len dan gemo­tiveerde medew­erk­ers

    Ik bedoelde niet te zeggen dat dat het doel is, maar juist een mid­del om te komen tot daad­w­erke­lijk suc­cesvol werk. Dat is ook een beet­je het argu­ment van Eric Steven Ray­mond:

    if you want the most effi­cient pro­duc­tion, you must give up try­ing to make pro­gram­mers pro­duce.

    Je hebt gelijk als je zegt dat dit natu­urlijk een heel ander ver­haal wordt als je werkt in opdracht van klanten. De open source wereld heeft de ‘luxe’ (zou je kun­nen zeggen) dat ze niet voor klanten werken, maar voor zichzelf, wat ook al vroeg in Raymond’s andere essay The Cathe­dral and the Bazaar voor­bij komt:

    1. Every good work of soft­ware starts by scratch­ing a developer’s per­son­al itch.

    Een les die 37signals e.a. natu­urlijk ook ter harte hebben genomen in hun design­werk.

    Hoe doe je dat met klanten? Het antwo­ord heb ik niet, maar ik denk dat een voor­waarde is dat ze bij wijze van spreke ‘part­ner in crime’ wor­den van de lever­anci­er (of eigen­lijk omge­keerd). Dat is nog niet zo een­voudig, zo blijkt de laat­ste tijd maar weer!

Comments are closed.