Your open source management approach: Red Team or Blue Team?

No readers like this yet.
Three giant robots and a person

When I hear people in the technology industry talk about the benefits of open source software, one of things they mention often is their belief that open source software “gets better faster” than traditional software (David Wheeler has done a nice job collecting many of the proof points around the benefits of open source software here). While the speed of innovation in open source is in part due to the power of Linus’s Law (“Given enough eyes, all bugs are shallow”), I believe it also has a lot to do with the way open source projects are managed.

Many of the characteristics of this open source management style apply well beyond making software, and I’m always looking for examples showcasing this in action. A few weeks ago, I wrote briefly about the story in Malcolm Gladwell’s book Blink about (now retired) US General Paul Van Riper.

Gladwell tells the story of how, in an enormous military war game called the Millennium Challenge in 2002, Van Riper took command of the Red Team, playing the role of a rogue commander who broke away from the government of his Persian Gulf country and threatened US forces (the Blue Team). Rather than following standard military management protocol, Van Riper managed his team according to a philosophy he called “in command and out of control.” From the book:

By that, I mean that the overall guidance and the intent were provided by me and the senior leadership, but the forces in the field wouldn’t depend on intricate orders coming from the top. They were to use their own initiative and be innovative as they went forward.

Van Riper is the first to admit this decision-making process was less organized and, well, messy, but it had a crucial benefit: team members were able to operate without having to explain themselves to their superiors, get caught up in long meetings justifying their actions, create Power Point presentations detailing their strategy and approach, or complete other time-sucking tasks while battle was being waged. They could focus on doing the work at hand, not on explain what they were going to do.

End result? Van Riper’s rogue Red Team routinely outwitted and outmaneuvered the massive US military Blue Team (although who won in the exercise was very controversial). When asked to explain his advantage over the Blue Team, Van Riper said in Blink:

They were so focused on the mechanics and the process that they never looked at the problem holistically. In the act of tearing something apart, you lose its meaning.

In the open source world, I’ve seen projects use both the Red Team approach of Van Riper and the more traditional Blue Team approach of the US military. But I believe the best, most effective open source projects are usually managed as “in command, out of control” Red Team exercises.

These projects have a clear a vision or goal the entire project team shares. Rather than dissecting each decision related to the project in an endless stream of meetings and presentations, the “in command, out of control” project leaders trust project team members to make decisions quickly in their own areas of expertise. These leaders know members of their project team understand the overall goal, and they believe team members often can make the best informed decisions because they are closer to the issues, challenges, and opportunities and have better, more timely information.

Now think about the management process at your organization for a second. Does it sound more like the Red Team or the Blue Team?

The risk of the “in command, out of control” Red Team approach is decisions may get made that leaders don’t have a chance to weigh in on, and, based on differing interpretations of the project goals, these decisions may be in conflict (one hand doesn’t know what the other hand is doing).

The Red Team approach puts a great deal of trust in the intelligence and alignment of the team you have in place. Without smart decision-makers who share the project vision and goals and who can communicate well with each other, the results can be disastrous.

But if you have a great team in place, the "in command, out of control" approach will allow you to move incredibly fast and take advantage of opportunities more quickly, as I believe many open source projects have proven.

For me, it comes down to tradeoffs. The traditional “in command, in control” Blue Team approach may ensure great alignment and will often seem safer, but movement will be slow, and great opportunities may be missed.

The “in command, out of control” approach will ensure progress is swift and opportunities aren’t missed, but—if the team isn’t working together under a shared vision and communicating well—may result in misalignment or worse.

My preference is to work on teams with people who share a vision, communicate well, and are individually accountable for their own work. These teams can be extremely successful operating like the Red Team.

I believe the future of management will be filled with examples of Red Teams that achieve great results quickly. But don't jump in too fast—without alignment on goals, personal accountability, and good team communication, the Red Team approach may not get exactly the results you want.

User profile image.
Chris Grams is the Head of Marketing at Tidelift and author of The Ad-Free Brand: Secrets to Building Successful Brands in a Digital World. Twitter LinkedIn Email: chris(at)


A similar thing you see happen in the more traditional producing teams, like (proprietary) software development teams. Agile project managements practices wants multi-disciplinary engineers who are allowed to make decisions (self-organizing). For this people have to rely on trust and proven understanding/skillset to do their job. in open source projects this trust is gained by your contributions... this also shows why self-organizing comes naturally in these projects.

I definitely agree with your "Red Team" methodology. The way that I've often phrased it is that people need to have the authority to carry out their responsibility.


... but this is often where it goes wrong in a corporate environment. Empowerment or decision-making is often not fully granted as middle management is scared of 'lose of control'. In other words; 'to become irrelevant' or 'redundant'. I just think in that case they don't really understand their job; provide the tools and resources for your team to do their job. If this happens the team would have to result to something what I call; 'up-managing'. Up-managing is to package the decision-making up in a way that he decides and has control (and probably walks away with the results). It is a workaround... :-s Management needs to be re-invented, adapted to a 'new' way of working.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.