In the early 1960s, the United States invaded Cuba in what later came to be known as the Bay of Pigs Fiasco. This was intensely embarrassing for the United States, and, worse, it led to one of the most terrifying moments in the history of the planet Earth.

Russia decided to send nuclear missiles to Cuba so that Cuba would be better equipped to defend itself against future U.S. military strikes (which is to say, so it could prevent all future military strikes by threatening to blow us the hell up).  The U.S. set up a naval blockade to prevent these missiles from reaching Cuba. Russia threatened to launch an all out nuclear attack on the U.S. And the U.S. prepared for the worst case scenario of Mutually Assured Destruction.  The world was about to be eradicated, leaving only cockroaches and mutated fish behind.

In 2008, XBMC suffered a near cataclysmic event in its development history. A number of XBMC for Mac developers decided they didn’t want to play by XBMC rules. Or they felt threatened by the Windows and Linux developers. Or everyone was really angry. Or nobody could agree on whether to develop using SVN or GIT.  To this day, the causes are hazy, but the outcome is not. The majority of XBMC for Mac developers decided to leave and form their own software team called Plex. Team XBMC was left knowing that it was time to take steps to prevent something so shattering from occurring again.

The causes of these two historical developments are, curiously enough, exactly opposite of each other. The Plex split occurred because team members could not agree.  The Bay of Pigs Fiasco and Cuban Missile Crisis occurred because the many voices of the federal gov’t felt incapable of DISagreeing.

Every team, every group, every organization the world over faces this struggle on an almost constant basis. If literally everyone agrees, then there’s probably something wrong with the project. If so many people disagree that no resolution can be reached, then there IS no project.  Every day and every conversation is a constant struggle to walk a tightrope between zombie-like conformity and calls for revolution.

So the question we must ask ourselves is a simple one. Why is this, and how can it be combated?

Groupthink – Groups eat brains!

Nearly everyone agrees that the chief cause of the Bay of Pigs Fiasco was Groupthink, which, put succinctly, is unanimous public agreement due to the human desire to not create waves. Chiefly, this is exhibited in the form of suppressing all ideas, regardless of whether they are good or bad.  This desire to not rock the boat can be fueled by many things, chief among them are fear of being bullied, fear of looking stupid, and fear of being cast out of the decision making group.

There are, of course, as many more causes as there are stars in the sky, and from an evolutionary perspective, they probably all stem from our backgrounds as social creatures that needed to move in packs for survival.  These evolutionary causes are not incredibly important for the discussion.

What is important is identifying methods to reduce the effect of our need to fit into our groups. Irving Janus identified key methods that would theoretically reduce GroupThink as it existed in the 1960s. These included:

  1. Leaders should assign each member the role of “critical evaluator”. This allows each member to freely air objections and doubts.
  2. Higher-ups should not express an opinion when assigning a task to a group.
  3. The organization should set up several independent groups, working on the same problem.
  4. All effective alternatives should be examined.
  5. Each member should discuss the group’s ideas with trusted people outside of the group.
  6. The group should invite outside experts into meetings. Group members should be allowed to discuss with and question the outside experts.
  7. At least one group member should be assigned the role of Devil’s advocate. This should be a different person for each meeting.

Needless to say, if a team followed this strategy, it’d be intensely difficult for GroupThink to form.  Unfortunately, a group following this strategy may well find itself in a constant state of stagnation. Each member will be heard, and all members will likely learn a great deal in the process, but quite probably nothing will actually get done.  So, while excellent in theory, Janus’s suggestions were not amazingly effective in actuality.

Kennedy famously attempted to avoid GroupThink during the Cuban Missile Crisis by following these steps.  While GroupThink was certainly avoided, absolutely nothing useful came out of the meetings.  In the end, the Crisis was avoided by back channel secret discussions held between Kennedy and Khrushchev in which they agreed to back down and dismantle various weapons systems in especially scary places.

Viva La Dissolution! – We hate each other and always will!

The other end of the spectrum from GroupThink is the impossibility of agreement among parties. Mediation is the art of resolving these disputes, and there seems little doubt, even to this day, that mediation is much more an art form than a science. Every dispute is different. Every pair of combatants wants something entirely unlike the pair before.  To find a resolution is exciting and intense and almost impossible to replicate in a scientific study.

The only thing that most mediators agree on is this: Whatever people are verbally arguing about is rarely the thing they are actually fighting for. A divorced couple may be arguing verbally about who gets the sofa, but in reality they are fighting to the death about who caused the most emotional pain six months ago.  The words themselves are almost always an afterthought to the war of emotions that are happening under the surface.

The Microsoft Kin was signed, sealed, and delivered, and then almost immediately withdrawn from the market. And why? Well, honestly, I have no idea. But from where I stood it certainly looked like a group who was pushing the Kin forward was experiencing GroupThink, while another group, upon discovering and discussing the release, was prepared to eat a $100 million loss in irritation at a branding error.

Microsoft is, without a doubt, a behemoth of an organization. It employs thousands upon thousands of engineers, developers, testers, sales people, managers, and janitors. To discover that two groups within its walls were talking over each other’s head is not shocking. Sure, it resulted in millions of dollars down the drain, but that happens all the time at Microsoft.  They’ve got a few dollars to spare.

Yet while it is not shocking, it is highly regrettable. A company with those kinds of resources, if firing on all cylinders, would be a force to be reckoned with, rather than a company that merely teases users with the Kin, the Courier, and the Surface.

The Software Development Tie-in

And so we return to XBMC. Since 2008, XBMC has seen steady growth, both in user base and in features and usability.  How?

I would argue that two totally unrelated organizational practices are taking place.

The 20% Model

First, XBMC Developers follow the 20% Model popularized by Google. Specifically, rather than a developer asking for group guidance on whether a new feature is a good idea, they just go ahead and make the new feature happen. Once coding has already begun and is in some kind of advanced state, it is presented to the group.  In this way, it is simply too late for the group to shoot the idea down as stupid. Instead, they are forced to grapple with an idea that is already demonstrably working.

Of course, many group members will still try to shoot the idea down, but the developer who originated the idea will undoubtedly fight back, which is totally unlike the typical behavior that is seen when the idea has never been acted upon.

Typically when people present ideas to a group that have no backing in reality, if even mild resistance is met, the idea is invariably dropped and wasted.  When the idea already exists and is in a semi-working state, the idea presenter fights hard to ensure the idea’s survival.

The most recent (and famous) example of an idea presented to Team XBMC in a nearly fully formed state was XBMC for iOS, which Scott Davilla presented in such an advanced state that it could already mostly decode 1080p video without difficulty.

Often in the XBMC forums, users become offended when an XBMC Team member suggests that a user code a feature he requested, thinking that the Team is blowing him off.

Incredibly, blowing the user off is almost never the point of the suggestion. Rather, we are uniformly promoting the 20% rule. If the user can make his idea happen in practice, rather than in theory, then we will have no choice but to acknowledge the feat and seriously consider adding the code to XBMC.

This first organizational practice is the THE reason that Open Source software development works so well.  While a great deal of development can result in splintering from the original source code (as has happened multiple times to XBMC), anyone can sit at his or her computer and think, “Today, I’m going to change the world,” and nobody will be able to tell them they are idiots for thinking so.  Who knows, that person might go on to create Android, XBMC, Linux, Ubuntu, or any of countless pieces of software that have done their part in changing the world.

Positive and Open Communication

Second, I would argue that Team XBMC maintains a practice of invariably positive and open communication. The Team members like what they are doing, they like each other, and they are rarely afraid to admit a failing, because almost every failing is temporary.  In coding, unlike life, success can almost always be ensured by learning just a little bit more than you knew a second ago.

This means if one Team member doesn’t know how to do something, he says so, and he does not fear the backlash of other members calling him an idiot, because everyone knows that we all started tabula rasa, knowing nothing. We do not stoop to the level of personal pissing matches, and we react swiftly and negatively to users who decide that the point of the game is to see who has the biggest geek glasses.

We accomplish this deep and continuously renewing method of communication in three ways.

  • First, almost all communication occurs via computer.

Organizational Psychological research exists that seems to suggest people are less likely to defend their positions in face to face confrontations, or, if they do defend their positions, they are less likely to be swayed to alter – in any way – the stance they have taken.  Face to face confrontations are too fast and too tricky to allow deep thinking on the issues, and so we resort to our baser instincts.

Online discussion, on the other hand, providers a powerful means to discuss the positives and negatives of an idea or project in a reasoned way without being forced to issue knee jerk pronouncements.  People still do, of course, devolve to the knee jerk argument, but in a controlled environment where everyone knows each other, certain social rules develop.

For the members of Team XBMC, the first unspoken social rule is this: “The ONLY black and white rule is the GPL (the License that keeps XBMC open source). Everything else is open for discussion and revision.”

Or, more simply, XBMC is more important than your pride.

  • Second, we maintain an open forum, where everyone – users, developers, support people, and even those who donate money to the cause can talk openly and on the same level.

In this way, we can keep record of active users, useful discussions, interesting challenges and suggestions, and anything else that catches our fancy.

  • Third, we keep a continuously running dialog in a private chatroom on IRC.

Think of this chatroom as a constant stream of communication among a minimum of 20 to 40 people at any given time. If someone is starting a fight in the forums, it comes to the attention of the team in a matter of moments, so we know to douse the fire.  If we are coordinating the release of a new version of the XBMC software or discussing other time sensitive plans, we can do so immediately and in real time. If somebody wants to tell a joke or if several people decide to jointly watch a live event from 400 (or 4000) miles away, they can do so and keep a conversation about the event running the entire time.

To make an already long story short, we avoid GroupThink AND revolution through exactly the same methods. Though both are totally separate functions, their base causes remain remarkably similar. Both appear to be caused by a lack of communication and a fear of being dismissed in some way or another.  We maintain tight and near constant communication, and not a single one of us fears dismissal for even the silliest of reasons, particularly not when A) we’ve already gone through with our idea, and B) we know that every single member is in a boat very similar to our own.


As you no doubt know, the Earth was not eradicated during the Cuban Missile Crisis. You might be less aware that Plex was one of the last two groups to splinter from XBMC. (The other group to splinter was Boxee, but that project fork was an agreed upon action that has been mutually beneficial for both Team Boxee and Team XBMC, and therefore somewhat outside the realm of this discussion.)

In the end, the it appears the tightrope walk is a little easier for a software organization that pushes its developers to act upon their ideas BEFORE they present them to the group and that pushes for communication to the degree that all the members feel more like family and friends than coworkers and staff.

A lack of communication, it seems, is the ultimate cause of both GroupThink and group dissolution. And the solution for any software development group, as seems only natural, is to make communication a central focus by making communicating easier, more frequent, and filled with more confidence.