To solve problems, make mayonnaise

Running down the hill on Old Pittsboro Road in Carrboro on a recent morning before work, I saw a big moving truck stuck half-way in to a steep driveway.

The truck looked like a rental. Three people, frowning with arms crossed, stood on the road behind the truck. The tow-hitch was jammed into the crook between the road and the driveway, the hitch acting as a belt-prong that effectively buckled the truck in place.

As I approached, my vision telescoped in from the blurry big picture to granular details: first a house and yard, then a wedged truck, then a tilted intersection of driveway and road, then a hitch — the hitch! — mesmerizing three people.

I slowed, stopped, took a couple of breaths. I suggested grabbing two fireplace logs from the front porch and wedging them in front of the rear wheels. Maybe driving up over the logs might jack the truck a few inches, enough to free the tow hitch?

Jarred out of their own collective brain freeze, the group let out a small whoop. I jumped back into my run.

This wasn’t genius. I was a lucky outsider, someone with access to a range of perspectives that were unavailable to the three people trapped inside the snow globe of this particular problem. My advantages as an outsider:

  • Not having helped create the jam, I wasn’t focused on reversing back through the sequence of events that had created the problem.
  • Because the group was standing close to the hitch, they couldn’t see the entire truck angled up the hill, with an implicit invitation to use the rear wheels as a fulcrum to see-saw the hitch out of the hole.
  • I’d entered the scene looking first at the house and porch — a view that was invisible to anyone standing behind the truck staring down at its hitch.
  • Because I was new to the group’s conversation, I wasn’t hemmed in by the short list of assumptions and solutions that they’d already defined.
  • Finally, I was unaware of any blaming or ego clashes that had probably cropped up, so I wasn’t (consciously) taking sides with my blurted suggestion.

Continuing on my run down Old Pittsboro Road, I realized this mayonnaise strategy is one we often use in building out Racery’s virtual racing platform. Over time, we’ve found the strategy works for creating new features, improving processes, fixing bugs, forecasting and addressing crises.

If you’re not a business process geek, you probably don’t realize how many different theories exist about about how to optimize group interactions. A lot is at stake because, as Buzzfeed’s Cap Watkins notes, how we create often determines what we create.


Some examples of the spectrum of thinking about how to shape an organization’s new actions:

Here’s my take on the optimal group configuration for solving problems — first a thumbnail version, then a timeline of methods that our company has used for solving problems, then a full Encyclopedia Britannica exposition of the method.

Thumbnail: Starting in 1998, my company (at the time, serving European publishers with a SaaS CMS) was solving problems with small, dedicated hit teams. Most startups start here, since they’ve got just one or two staff. After we pivoted into selling ads on blogs, we grew bigger, and we started relying on big groups, whether cross functional or mono-team, to solve problems. In recent years and particularly in working on Racery, we’ve pretty much replaced both approaches with an stay-small-and-bring-in-an-outsider’s-views strategy that starts with a core team of two, then repeatedly folds in new individual’s perspectives.

Yes, it’s like making mayonnaise.

History: Before I give you the full blue-print of our mayonnaise strategy, I’ll quickly walk you through how the strategy came into being.

The strategy developed over time, inadvertently, developing in response to patterns that became evident when we did postmortems on various much-deliberated product launches and spur-of-the-moment crisis reactions.

Though the details were always different, all these situations were ruled by one remarkably consistent and frustrating pattern. Let’s illustrate the pattern with a hypothetical attempt to “fix” a confusing registration form.

  1. Based on conversations, one or more of us identify a problem in an existing registration form.
  2. A team of three people meet several times over the course of some weeks, using each meeting to refine their understanding of a problem and draft one or two possible solutions.
  3. A consensus solution emerges. Mockups of a new form become more coherent and beautiful. Everyone feels great about the progress and become increasingly invested in making it happen.
  4. Then, a few days before launch, an outsider notices the new registration form on an open screen in a conference room.
  5.  Put politely, the new viewer introduces a a different perspective that is, in retrospect, obvious to everyone.
  6. At first the alternative perspective seems only minutely different. Within minutes, though, everyone realizes some fundamental need or problem has been overlooked.
  7. Gasp. Questions. Concerns. Head shaking. More people join the impromptu meeting.
  8. “How could you have missed that?” someone asks.
  9. Back to the drawing board for another excruciating round.

This happened a number of times. Lots of energy, time and ideas got wasted.

One fix started to seem obvious. “Let’s make the committee bigger right from the get-go.”

This way all perspectives will be represented. Of course!

In fact, this approach corresponds to the ‘build consensus’ tenet of the famed Toyota Way, the foundation for Lean product management. The idea is that representatives of all stake holders — sales, customers, engineering, managers, QA, designers — should gather at a round table to work together on problems so nobody’s view is forgotten.

That’s the theory. Unfortunately, we quickly found that the entire scenario above — from step 1 to step 9 — would repeat itself no matter how big the team. We were always forgetting someone or something.

At the end of the process, after we’d ‘solved’ the problem, some new person — a customer or spouse or business peer who hadn’t been on the committee or team — would look at the solution briefly and notice a tiny hanging thread, give a tug and… whoosh, the whole carpet that we’d spent weeks or months weaving would unravel.

No matter how big the committee, some key details or perspective were always overlooked.

My hypothesis is that bigger groups don’t necessarily create bigger solutions. The reasons are myriad. First, worried about wasting the big group’s collective time, many committee participants stay silent, stifling their insights or qualms. Second, a few strong voices dominate.

Third and most importantly, group-think quickly settles in. Hypotheses harden into givens. Terminology that was initially offered tentatively to describe one aspect of the problem starts to crowd out fuzziness and comes to embody and define the full problem. Solutions that the group cooks up together seem increasingly obvious and beautiful. The group slowly takes on the mind of a 3-year-old, succumbing to what developmental psychologist Jean Piaget called “centration,” the tendency to focus on one explanation of a situation to the exclusion of all others.

The end game is always the same. A consensus emerges. Back patting ensues. We gotta do this! The new feature launches, the memo is sent, the pricing scheme unveiled.

The product meets reality.

Some outsider, using vocabulary we’ve forgotten or perhaps never heard before, asks: why didn’t you strim the altomotator? Have you considered regilotating the obviolamion?

And our answer was always the same: damn, you’re right, we didn’t think of that. Please explain more of what you’re thinking.

Oh, shit, you’re right.

Back to that oldest of business cliches — the drawing board.

The problem, I think, is almost never due to stupid people or processes. Rather, it arises from how our brains function. All our cognitive tools — words, theories, schema, tunes, canvasses —  are incomplete, each failing in its own way to capture some key aspect of reality. Truth is a 9 x 11 rug in a 10 x 14 room. We spot an uncovered gap on one side of the room and pull hard to drag the rug in that direction, only to look up and realize the floor on the other side is now bare. The problem is ultimately unfixable, particularly because our tugging is also changing the shape of the room. We can never achieve that ultimate synthesis of perspectives that will entirely cover the floor. (Sorry, Hegel!)

But sometimes, when individuals tug at all the rug’s edges, we can make it a little bigger, even if just for a little while. So, over the years, our company’s teams have stopped using big group meetings to either define problems or create solutions. Big groups pulling together in one direction just make bigger blind spots.

How we do things today. We’ve come to rely on a much more modest, interactive and iterative process. It takes longer but consumes fewer total staff hours. It involves far more individual meetings, but because only two or three people attend each meeting, far less aggregate time is invested. The iterative looping and folding in of new viewpoints keeps us from making decisions inside a snow globe.

Here’s what we do:

  1. When we identify a problem or opportunity, a couple of people (let’s call them Alpha Group) meet to draft a description of the problem and propose a solution. This can usually be done in one 30-60 minute meeting, but sometimes can be spread across a couple of weeks. Sleeping (or going for a long weekend run) with a hard problem in the back of your head usually produces some new insights.
  2. As the problem and potential solutions begin to firm up, Alpha invites a new person, usually from the same team within the company, to join the conversation. (Let’s call this group Beta Group.)
  3. When Beta meets, Alpha members are careful not to regale the invitee with previous debates and hypotheses.
  4. The outsider’s job is to try to look beyond the edges of the problem as its been conceived. Are we thinking big enough? Are there other resources at play? We thinking too big? What’s been forgotten?
  5. Occasionally, this prodding doesn’t alter the definition of the original problem, and Beta Group tweaks the previously proposed solutions OR adds new solutions.
  6. More often, though, the restated problem is significantly different than Alpha had defined it. The invitee often explodes a lot of baked-in assumptions and the problem has a new definition.
  7. In which case, she exits and Alpha goes back to the drawing board to solve the newly defined problem.
  8. Once that’s done, Beta Group reconvenes and the extra person is asked to test whether the new solutions fit the problem as redefined.  If not, we circle back and try again.
  9. Now one of the original Alpha Group leaves and a new person is introduced. This person is from outside the team — design, programming or sales, whichever.  This person’s job is to zoom out further and asks a new series of questions: what stakeholders will be effected by this action? What will big customers think? What will our partners think? Does this impact colleagues in our Budapest office? What about people using a different currency. These are questions Alpha Group might have considered, but because the team had quickly gotten locked within the bubble of their team and assumptions, they’ve probably failed.
  10. And so on.

Again, it’s like making mayonnaise. Watch Jamie Oliver again to whisk the idea straight into your brain. 🙂

This seems to take a lot of time, right? I’ll reiterate: it’s more time-efficient for various combinations of two or three people to meet for an hour four times than for seven people meet three times for 1.5 hours. And because same seven people aren’t repeatedly doing meetings, lots of aggregate brain cells, hours and passion are conserved.

In addition, everyone in the 2-3 person meetings is 100% accountable and focused on the problem at hand. They’re not quietly checking e-mail every 45 seconds because THIS part of the discussion doesn’t involve them.

Most importantly, this mayonnaise method slashes the odds that we slouch and scrum ourselves into group think.

We believe strongly that smaller groups, recombined regularly, produce bigger viewpoints and more nuanced solutions versus those produced by big-committee juggernauts.

Yes, we definitely move more slowly if you count elapsed calendar-time. But because our new product/decision/memo has gotten true 360-degree reviews while avoiding the grey mush of products designed by a committee, it doesn’t annoy a lot of customers or trigger question-avalanches and/or need to be scrapped three weeks after launch.

Though Apple’s product design process is famously hermetic, I have a feeling our mayonnaise methodology shares some important characteristics with Apple’s, in which– an eclectic group slowly, elastically and iteratively aggregates the ideas and impressions of its members — particularly when Jobs was parachuting in regularly to kibitz.

Soon we’ll see whether Apple’s team folded in enough viewpoints when they decided to scrap the headphone jack. But at least we know the mayonnaise strategy unplugs trucks. 🙂

[Thank you Tina Merrill for suggestions and recent Alpha-teaming a budgeting rethink; Kaley Credle for feedback AND leading one of our greatest (and longest) outside-in sequences; Michael Bassik for insights and lots of generous product prodding over the years.]