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.
3 Comments