Work in the network era needs to be both cooperative and collaborative, meaning that organizations have to support both types of activities. This may not be an easy transition for companies based almost uniquely on command and control leadership. But in this emerging network era, cooperative innovation trumps collaborative innovation, writes Stowe Boyd.
My experience is that communities of practice can help make the transition from hierarchies to networks, or as Jon Husband describes the resulting structure; wirearchy. Communities of practice, both internal and external; can be safe places between highly focused work and potentially chaotic social networking. The Community Roundtable has a Community Maturity Model that describes this transition, in four stages. The model makes it relatively easy to see where your organization stands and where it should go.
The CMM aligns with my own way of looking at the need to balance structured work and the sharing of complex knowledge, with the concurrent requirement for unstructured social networking which can increase innovation through a diversity of ideas. I have added in the four CMM stages to the image below. Communities of practice can link collaboration and cooperation, and help weave the organization and its people into a wirearchy.
Wirearchy – “a dynamic two-way flow of power and authority based on knowledge, trust, credibility and a focus on results, enabled by interconnected people and technology.” - Jon Husband
Getting there may not be easy, but the evidence is showing that it is necessary. For example, here is how Yammer builds its products, according to Kris Gale, VP of Engineering:
Yammer’s biggest rule of thumb is 2 to 10 people, 2 to 10 weeks – which means they generally don’t do projects that are larger or more complicated. There is a non-linear relationship between the complexity of a project and the wrap-up integration phase at the end. If you go anywhere beyond ten weeks, the percentage of time in the wrap-up phase becomes disproportionate. - First Round Capital
This sounds like it’s aligned with the general rules of dealing with complexity, developed by Dave Snowden. Each project at Yammer is a probe. It’s also small enough so that the potential ROI does not drive the company off the rails. A small project failure is much easier to deal with than a large one. Yammer understands that working in a hyper-connected economy makes complex work less predictable, so project cycles are kept short. As Gale goes on to explain:
I don’t think you should be building a product. I think you should be building an organization that builds a product.
Be very wary of only trusting managers with engineering decisions; in fact, you should delegate these all the way down to individual contributors. If managers are the only ones making decisions as you grow past thirty to forty people, this should be a red flag. - First Round Capital
Becoming a wirearchy requires new organizational structures that incorporate communities and networks. In addition, they require new ways of doing work, like thinking in terms of perpetual Beta and doing manageable probes to test complex problems. It’s a new way of doing work, within a new work structure. Both are required.