There are several important distinctions between cooperative and collaborative companies.
The pace of innovation in web software is dizzying. Everyday there are new applications, new releases of established products with very different features, and the disappearance of tools that we may have become dependent on. As just one boundary case, I was reading about a relatively new startup called Clip.It that was being courted by Melissa Meyer at Yahoo, so I signed up for an account, and used the service — a Pinterest-ish bookmarking and sharing tool — for a few minutes. An hour later, I tried to add an additional clip, and the company had been acquired by Yahoo and the service was now shut down, with a notice saying they the technology was going to be reconfigured into a social news curation service.
This is increasingly true in the enterprise software space, as well, one of the many ways that enterprise IT is being ‘consumerized’. (I use scare quotes because the term is wildly inaccurate, but will leave that argument for another day.) Some will argue that the enterprise has the option to adopt technology at a slower pace: to carefully evaluate new products or new releases, and to stage the rollout in a very careful and deliberate way. But I maintain that this is an attempt to optimize the wrong thing: namely, stability.
Looking at this a different way changes the approach completely. If social tools offer competitive advantage then experimenting with new tools and new approaches to tool-mediated sociality is a necessary aspect of corporate innovation. After all, innovation isn’t limited to the R&D group. Innovation can happen across the board: in how we work, how services are delivered, and how products are designed, delivered, and applied. One of the most fertile areas for innovation is the interplay of people in the business, and between company staff and people outside the business: clients, partners, and the broader marketplace.
Yes, experimentation carries risks, and costs. But these are a necessary part of innovation of all sorts, and a necessity in social innovation as well. Certainly, we want to bound risks, and to structure our experiments so that we can fail fast, but what we cannot do is optimize all risks out of the business at the expense of innovation.
Let’s consider one facet of this reasoning in the context of choosing applications. Who should get to pick what social tools will be used? Imagine the following scenario: a 500 person consulting company with offices in 5 cities: London, New York, San Francisco, Hong Kong, and Sydney. A few years ago, an enterprising partner learned about a ‘social intranet’ product, and rolled that out in San Francisco. A year later company leadership decided that the value of a uniform and global intranet was high, so they opted to adopt that social intranet out worldwide. However, a project team in the New York office has spontaneously started using an alternative, innovative task management tool that doesn’t operate like the social intranet: it’s not a central repository on company servers. Instead, the new application integrates with Dropbox so that files are shared-and-synced from people’s devices, and the app is cloud-based. The group using the new app have started to invite others on a project-by-project basis, and this has created some controversy.
How to proceed?
- One school of thought would be for management to shut down the use of the new tool, and double down on the existing solution. This is premised on the idea that things are working ok and that the company has more to gain from stability than looking at social technology every time something new pops up. Let’s call this ‘no immediate risk’, which sounds good, but really isn’t.
- A second approach might be to designate some group of people — including some from the New York rogues — to evaluate the company’s social collaborative tool needs analytically, and to then search out the best solution for the entire company. This would open up decision-making to a larger group, but is still going to be a slow roll, since the analysis could take months and selection and roll-out some unknown amount of time. Let’s call this ‘only one risk’, which again may sound positive, but it’s not, really. I’m attending the IBMConnect conference at present, and this morning I heard Bosch CIO Gerd Friedrich describe this approach as the one that Bosch is headed along.
- A third alternative is more like evolution: let new approaches be tried all the time, but work hard to kill off ones that don’t confer real advantages. Let’s call this ‘many risks, all the time’ which sounds terrible but is anything but.
Let’s return to the New York team’s use of the new work media tool and distributed document sharing model. Instead of shutting it down (‘no immediate risk’), or delaying near term experimentation in favor of a five year plan (‘one big risk’), the team is encouraged to try the new approach for a period of a few weeks or months. Others are organically pulled in to shared projects, although all short term projects. The team is asked to develop some criteria for validating whether the new approach ‘works better’ in the context of how they believe that work should be shared and managed. The team — along with others that had been brought into projects and using the new approach — could be surveyed or polled to establish a relatively baseline against the company’s social intranet. And if the new solution passes the test the company reaches a fork in the road, really: they might realize that this new solution — while measurably better in the context of its use in the experiment, might not be the perfect solution for every work niche in the company, and might not be the best solution even for the New York team six months in the future.
So this is a continuum of trade-offs, and a continuum of autonomy. In the graphic below, I have spread these out in a matrix.
In the lower left corner we have what I call ‘tight-and-slow’ companies. These Hold pretty tightly to centralized decisions about adoption, and the default modality is no risk allowed. At the other extreme we see, at the upper right corner, the ‘fast-and-loose’ model, where individuals are adopting new social tools based on their personal or small-team use cases. Smack in between falls the ‘group/gradual’, which is how I would characterize the Bosch case. The company was confronted with a number of independent initiatives in different countries, but decided collectively to identify a broad cross section of 27 use cases that cut across the entire company, and to roll-out a single solution internationally.
This sounds sensible, but as I mentioned before, it’s not an approach that is optimizing for innovation. The group/gradual modality is an intentional hedge, attempting to diminish the friction of many competing implementations in the company, at the expense of widespread experimentation. In fact, aside from the brief period of considering various alternatives — in lab settings — Bosch had no experimentation. They relied on the experimentation of other companies, distilled into best practices by IBM.
Every company has to determine their own appetite for risk, but the best balance for that — since we all would minimize risk if we can — is to determine the level of innovation necessary to compete in your market, your industry, and your business. Perhaps your company is a market leader in a slow-moving industry, if such industries exist anymore. My bet is that more companies will have to push their social business innovation as close to the edge as they can, and allow more risk than may be comfortable. That’s one of the reasons that courage is one of the most important factors in social business success.
The highest value of diversity is not that a wide range of option are surfaced to a small management team to make a decision during some brief period of allowed innovation. No, diversity’s biggest payoff comes from the resilience it imparts over time, so that the company is positioned to take advantage of the potential benefits of social business innovation continuously, not just when allowed by a five-year plan.