Cookies, Kernels, Wikipedia

The annoyingly insightful Malcolm Gladwell has written another terrific "New Yorker" piece entitled, "The Bakeoff" (not online, September 5th issue). 

We all know Gladwell's m.o. by now: search out some little corner of the universe, often one of those "overlooked in plain sight" patches, and illuminate it with sharp, incisive, deceptively simple prose.  This time, he takes on a project to create "the healthy cookie."  Along the way, he explicates three distinctly different approaches to innovation, to boot!

The article follows the work of Steve Gundrum who, in Gladwell's words, "runs Mattson, one of the country's foremost food research-and development firms."  Gundrum's assignment: re-invent the cookie, "make something both nutritious and [as] 'indulgent' as the premium cookies on the supermarket shelf." 

Using a familiarity with software development as a starting point, (with encouraging words from Mitch Kapor) Gundrum decided to set up three teams to test three product development philosophies.  The first team would be modeled on Kent Beck's "extreme programming" (XP) approach, in which pairs of programmers tackle coding projects which are broken down into their smallest possible increments, "[proceeding] as simply and modestly as possible."  The second team would use a hierarchical, hub-and-spoke model, with one of Mattson's brightest stars, Barb Stuckey, at the helm.  The third team was an open source "dream team," comprised of fifteen or so food industry luminaries, as Gladwell puts it, "quite [possibly] the most talented group of people ever to work together in the food industry," with Carol Borba, Mattson's "innovation manager" in the role of "Linus Torvald."

What's your guess; who won?

Hang on, we'll get there.

The piece follows the teams' progress, describing their work at various stages.  The Dream Team came out of the gate an overwhelming favorite, and, "sure enough, in the early going, [they] were on fire."  Instead of fixing on a single idea, as the XP team did, or jumping around between three, as did the hub-and-spoke group, the open sourcers  came up with thirty-four different cookie ideas, "representing an astonishing range of cookie philosophies."  Ah, but therein lay the seeds of their demise!  Too much idea generation, too many chefs in the kitchen, too much "friction" within the team.  The Stuckey-led hub-and-spokers resolved their uncertainty when the leader had a genuine aha! moment: why not use the same methods that create the explosive taste sensation of a flavored tortilla chip on a cookie?  The XPers, meanwhile, plodded along.

Final result, as voted by real-world tasters: 14% voted for the XP team's oatmeal-chocolate-chip cookie, 41% for the Dream Team's oatmeal-caramel effort, and 44% for Team Stuckey's strawberry cobbler.  Close, but the smaller, more efficient and economical hub-and-spoke innovation model had won the day.

As I was reading the article, I was reminded of two relevant TEDGlobal presentations, and another talk by one of those presenters.  Charles Leadbeater was terrific at TED.  Speaking at the Creative Capital Conference in March, (which I wrote about here) addressed the differences between innovation carried out by "swarms" and that undertaken by "pipelines."  In Gladwell's example, the Dream Team was swarm-like, while the other two groups were more pipeliney.  The key to a swarm's success, according to Leadbeater, is the establishment of a strong kernel: a central theme, idea, mission or purpose, often presented as the vision of an originator.  Given that kernel, swarms elaborate vigorously, especially when presented with a set of simple guidelines for self-organization.

Which is exactly what Jimmy Wales did in establishing the Wikipedia project.  In his TEDGlobal presentation, Wales discussed the Wikipedia "kernel" ("to create and distribute a free encyclopedia of the highest possible quality to every single person on the planet in their own language"), and its governance model.  In ascending order, the group resolved differences via concensus, democracy, aristocracy (as determined by natural hierarchies) and, ultimately monarchy (Wales himself.) 

Unlike the cookie Dream Team, highly effective swarms adopt or evolve methods for decision-making and conflict resolution.  Gladwell addresses this issue: 

Because there are so many individual voices involved in an open-source project, no one can agree on the right way to do things.   And,  because no one can agree, every possible option is built into the software, thereby frustrating the central goal of good design, which is, after all, to understand what to leave out.

And, obliquely speaking to the need for a "kernel," Gladwell writes:

Had [the cookie competition] been...an exercise in chasing tail-lights [improving on things which had gone before], the Dream Team would easily win.  But if you want to design a truly innovative software program--or a truly innovative cookie--the costs of bigness can become overwhelming.

But, this does not appear to always be the case.  Wikipedia has established very successful methods for managing differences.  They have a very effective process for determining what to leave in and what to leave out.

Meanwhile, user-driven changes in open-source games such as World of Warcraft are reported to be every bit as innovative as those produced by "pipelines."

As open-source matures, and leaders become more expert at leading in what is still a brand-new innovation methodology, we are very likely to develop better methods for using swarms for all manner of product development.

And, what would have happened on the next project?  Stuckey's team had worked together before, while the Dream Team was on iteration one.  No doubt they'd improve over time. (Well, maybe there is some doubt, but the chances are they would.)

And at the end of the day, open-sourcers, can certainly take heart: the final score was only 44-41! 

All in all, another fine piece of work by Malcolm Gladwell.

Tags:  Malcolm Gladwell New Yorker Innovation Design

Comments

[Michael Wagner]

Tom, thank you for kicking open the doors once again with this thought provoking post! This conversation about "kernels and open source" and innovation and all the rest is much appreciated!

I have a client that does not want to be the lone genius nor does he want to create an organization with lots of emloyees. I've suggested we explore some variation on the innovation models you have been writing on. He keeps saying "tell me more about the kernel". This is one "kernel" without a secret recipe!

[Tom]

No doubt about it in my mind: this is the wave of the future. Creating the right kernel does seem like a big part of the "secret sauce," but getting the right culture, like Wales did with Wikipedia, is even more crucial.

Good luck with your client on this, Mike.

[Jason Yip]

I'm slightly annoyed that the XP team doesn't get to test with tasters early. Was the success criteria (i.e., beat other teams in taste test) provided in the beginning?

[Tom]

Yes, all teams knew the results would be tested by consumers. The teams also submitted their efforts to Gundrum during the process of development and got feedback from him. Are you suggesting early user testing, er, tasting, would have been particularly more beneficial to XP team? I'm not familiar enough with the XP process to know.

[Evelyn Rodriguez]

I've got to read this article myself, but having software engineering roots, I'm a big fan of agile development (of which XP is only one style). Few people know how to actually implement and carry out an XP project, however. Inherent in the process is frequent and iterative customer feedback. "Release early, release often" is one mantra which means to get it out there asap so that a customer feedback advisory circle can try it out. And then roll that feedback into the next iteration. (These aren't EXTERNAL releases, but internal releases for feedback.) But if I read your post right, the problem with XP and other agile methods is they start out with the WRONG initial project/idea. And that's been my own experience too. The team starts off with an incorrect goal or kernel if you will; course correction can only get one so far.

Linux, too, started with a strong kernel - in fact in operating systems the core code is actually known as the kernel - and someone at the helm that's more like a "benevolent dictator", Linux Torvalds. Open source programming and development is NOT as all-holds-barred swarmy and consensus-driven as folks outside the hackers believe.

[Tom]

You're right about the initial XP team kernel, Evelyn. The article made it sound like they got off on the wrong foot and never really recovered. Interested in your thoughts after reading the piece.