Over on the Enterprise 2.0 Blog, Venkatesh Rao of the Xerox Innovation Group makes a compelling case that “there is no such thing as culture change”. He goes on to list five ways to get out of the culture change argument, summarized below:
- Culture change naturally takes place because “nay-sayers retire or die out and get replaced by others. Resistance ceases because the resisters leave, and because the adopters are younger and are clearly producing more value using their ideas.”
- Inefficient or more difficult user experiences that make the transition from old to new more difficult.
- Careful alignment of incentives for those moving from old to new systems.
- Given that “people self-select into cultures containing people they want to be socially connected with” make HR needs to compete to hire those that are likely to fit into the culture your trying to grow into.
- Start at the periphery of inefficient processes and systems. In other words, start circling injured systems and be ready to step in when they cease to exist.
The 2.0 philosophies of openness, sharing, flattened hierarchies, emergent outcomes, transparency and unfettered collaboration are anathema to nearly 100% of the large organizations I’ve encountered in my zeal to evangelize e2.0.
Realistic roadblocks are presented by management with invested power/influence, governance (regulation) and legal concerns, and yes, the 9x factor that McAfee pointed out early on, which you’ve also alluded to. I do agree with you regarding the user experience and likelihood of adoption, however.
A command and control corporate culture that spawns fear, protectionism, and paranoia will never be a good candidate for e2.0. When we say it’s more about the people than the technology, this is what we’re referring to. The technology is liberating, but unless every vested member in the org chart is willing to be freed from industrial age convention, it’s unlikely change will come soon. These are corporate culture issues and they’re pervasive in the adoption story. I covered this in a post about a year ago on ITSinsider.
So whose wrong and whose right? Can you overcome the culture argument if you follow Venkats’ antidotes? Or is Susan pouring a solid dose of reality on what happens when the decision makers get in a room together.
They’re both right. From a macro, organization wide perspective, both buyers and sellers of the social computing promise will need to address and respond to shifts in the organization that Venkat brings up. Likewise, as Susan correctly says, fill a room with LOB executives, HR and IT and sell them on using software that makes the organization social, and you’re going to see some serious push back for all of the legitimate reasons she enlists.
The problem (and opportunity) here is the underlying premise:
Collaboration, Wikis, social networking or some other form of social computing technology is positioned as a better way to work, discover, save costs, etc. LOB Executives, HR and IT get in a room and try to ascertain the opportunity and risks of company wide adoption. They may reach different conclusions but you can pretty much guarantee that the weakest link (read: parts of the organization where culture can in fact be a serious impediment) will get extrapolated to estimate enterprise wide success or failure.
The most simple culture busting argument IMO is focusing on how social computing exponentially accelerates individual business activity. Prove that you can accelerate performance in a particular area and few decision makers are going to care if the execution involves social computing, hula hoops or whatever else.
So what’s required to tactically execute the justification of a social computing transformation and busting the dreaded culture roadblock? There’s obviously a few approaches but this one has worked for me. Heads Up: This is somewhat of a long story so please bear with me as I set the context and result.
The Backdrop – A primer on Hi Tech Partner (SI) Sales
I’ve been facilitating a strategy session with the EVP of Global Marketing of a F500 Hi-tech technology provider and his direct reports.
The organization depends heavily on the System Integrator (SI) partner ecosystem to push product. If you’re not familiar with the channel business, a good number of technology providers rely on SIs to reach their target market. It’s the SI that often gets the RFP from prospects and it’s up to them to propose the necessary strategy and technology solutions required to solve a problem. For those technology vendors that want to get their technology solutions on an SI’s proposal, the onus is on them to not only provide product details but to also provide all the supporting proof points that shows how their solution is in fact better than that of their competitors.
It’s a bit of a cynical statement but after conducting needs assessments for well over a 120 channel sales reps, partner development managers and LOB channel execs at different clients (as a precursor to design, sourcing and ‘operationalizing’ of collaborative extranets), the general consensus I’ve seen is that the vendor has to back fill strategic technology thought leadership elements of the SIs proposal. The more perceived/real commoditized nature of your offering, the higher the chances that the SI picks the provider that makes it easiest for them to improve the probability of sale. What’s more, it’s the SI who’s regularly playing golf with the CXO at the customer and formally pitching or informally educating the customer on what’s hot and what’s not in the evolving technology landscape. So as a technology provider, you better make it dead simple for the SI to have access to the latest information, proof points, reference architectures, experts and so on. Reliable and timely data and expert access is as much of a competitive advantage as is the long string of product differentiators you can cook up.
The Social Computing Context
Back to the client discussion. We investigated a seemingly crazy hypothesis that there needs to be a way for the technology vendor to provide a guarantee to SI partners that all supporting product documentation and access to known and unknown subject matter experts (SME) will be made available either in real time or one communication instance away. No hunting within stale portals, partner directories or extranets, emailing account teams, risking reliance on outdated pre sales material, or chasing the account manager for the answer to time sensitive questions. Convince the partner that if the data and resources come from this technology provider, its legit.
We agreed on primary pain points in the SI partner collaboration process, folded in anecdotal field data and got partners to chime in on an optimal collaboration model. We then came up with a blueprint of the what the new interaction model needs to look like to successfully grow their share of partner wallet.
It was about 70% into the process that we really started talking about the required mix of technologies needed, to realize such a business objective. Low and behold, the resulting recommendations for collaborative, micro-messaging and alerting architecture, candidate solutions providers and operational design centered around so called Enterprise 2.0 solutions. But no one really cared what label was slapped on to this ‘nirvana’ after-state.
By the time the words “culture”, “risk”, “feasibility” and “switching cost” came up, they were well into identifying which partners to approach for a very contained pilot. At this stage, the impediments I list above were not seen as deal breakers, rather, as obstacles that needed to be addressed. Think about it: What new program, whether timid or bold, doesn’t have obstacles? This was no different. Clearly identified participant incentives, the attractive cost structure of social software and business value, provided the necessary chutzpah to take this on.
It’s a huge disservice to the promise of social computing when you’re advocating the software and not the benefit. The best case outcome is an average benefit emerges across the organization. The worst case is the you encounter the risk of individual department-centric apprehensions getting blown up and being presented as organizational wide toll gates.
So is culture a serious issue? Yes, it can be. In fact when you consider enterprise wide deployments, culture could be a much larger issue for E2.0 software when compared to ERP and CRM roll outs of the late 1990s. The latter was far more expensive but wasn’t dependent on the network effects that E2.0 so desperately needs to be a success. But by focusing on pointed business acceleration opportunities, culture can be turned into a hurdle that you can systematically glide over, as opposed to a brick wall that you slam into.
I’m sure enterprises, customer success teams from social software vendors and consultants are sitting on some really good experiences. If you have successfully glided past the culture discussion (or hit the proverbial brick wall), pipe in, in the comments.