Enterprise 2.0: Culture Is as Culture Does

We get frustrated when we hear “motherhood and apple-pie” lessons about E2.0. I would have screamed had I heard one more speaker or seen one more tweet telling me “it’s not about the tools, you know. It’s about culture.” Yes, we heard. We agree. But we are past this. Let’s now talk about the nature of effective culture change. Let’s get some Org-behaviorists in the community to help us. Not the ones who just tell us “it’s about culture” – the geeky ones with real data, real insight, and specific advice we can take to understand what culture change really means.

Gil Yehuda, Post #e2conf thoughts – installment 1

If only I had a nickel for every time an Enterprise 2.0 stakeholder used the word “culture”. The industry uses the word “culture” constantly in terms of describing when an organization is ready to implement social software. It has become something of a shibboleth, as Gil wryly notes above.

At a high level, it is indeed about culture. As in, if management has an attitude of “when I want your opinion, I’ll give it to you”, they’re culturally not ready for social software. But the vast majority of companies are beyond that attitude, with nearly all embracing the concept of employees as their most important asset.

So in that context, what exactly does “culture” mean? There are degrees of readiness, to be sure. Do employees horde information to maintain a career advantage? Is the workplace style competitive, not collaborative?

The question of what exactly is meant by “Culture” got me to thinking about my own experiences thus far in the Enterprise 2.0 field. I’m by no means an organizational behaviorist, and I somewhat question what they can really overcome in terms of entrenched company cultures.

I put together the graphic below as a framework for thinking about things like culture and adoption. It’s a process flow for pilot deployments of social software, based on some of my experiences. There are actually several different points included in it.

I’ll start with this observation: unlike societies, culture inside companies can be changed in a relatively quick way. Senior executive mandates, the need for a paycheck and the fact that employees’ work, where they put their personal skills on the line, is rated, provide powerful levers to alter practices in the workplace.

I won’t say that it’s right to consistently rely on these measures. But I don’t think relying exclusively on emergent, viral adoption is right either. Employees’ activities can be re-directed for the right reasons.

The use case

In the process flow, notice the opening decision: “Defined use case?” Answering this question is a vital part of determining the impact of culture on the uptake of Enterprise 2.0. If the software has a place in helping specific tactical tasks, the cultural issue is less of a hurdle.

Take wikis for example. If a wiki has to compete against a portal, SharePoint, a shared drive, and/or email, and no one has defined a use case, it will likely fail. For a pilot deployment, a use case might be a specific project involving multiple people that will be executed exclusively through the wiki. It gets people using the wiki, and they know why. Then they can start to understand the benefits.

The goal is for a use case that’s “real”, not some made-up activity for the sake of testing the software.

Company cultures are going to be more open to social software when there are defined use cases. Of course, that’s not always the case. I’ve had experience with experimental deployments. They are harder, and are much more likely to run into “cultural issues”.

Who inside the companies cares about this deployment?

The answer to this question varies by the use case scenario. Where there is a well-defined use case, someone inside the company has signed off on using the software. Generally a manager at a more senior level. This means the deployment gets attention, and benefits from a greater range of resources. Its visibility is higher. The boss is tracking this.

In the experimental deployment, it takes a cadre of evangelists to push things forward. These are the early adopters, who see the opportunities of the social software. They are enthusiastic, and are the ambassadors for the pilot inside the company. What they lack in management attention they make up for in words and actions.

How does word spread?

When a deployment has senior management attention, the internal communications infrastructure becomes available. This is incredibly valuable. Announcements come through via email, and on the intranet. Posters go up, videos get made. Managers hold meetings. Contests are set up. It’s a thing of beauty when the organizational infrastructure roars to life.

In the experimental deployments, without specific in-the-flow use cases, awareness is a bit tougher to come by. Often, there is a pilot group of employees that are designated to participate. The project lead and her fellow evangelists hold meetings, and send around their own emails announcing it. They may leverage tricks from the consumer web, such as exclusive invitations to drive up demand for participation. There is precedent for viral adoption strategies to work. Here’s a case noted by Rachel Happe:

I heard two interesting use cases – one was that a company I spoke with introduced Yammer under the radar and had seen significant adoption (thousands of people)

Is culture a barrier?

So word is spreading, employees are trying out the new software. Are they sticking with it? Are they using it to help them with their jobs?

If they are, move on the evaluation tasks.

But culture as an impediment is too high level a reason. I wonder how much of “culture” is really a case of people continuing to use the same software and processes they always have. Why would they change? I like the way Microsoft’s John Westworth put it in a LinkedIn discussion:

I have to ask where the motivation is. People use things like Facebook because there’s an intrinsic motivation to do so. People go to work because there’s an extrinsic motivation. Altruism doesn’t pay the mortgage.

John puts his finger on it. Employees need a compelling reason to switch from their current habits.

Tactics for overcoming culture

When culture is proving to be an impediment, there are various tactics one can use to try to overcome it. The tactics vary for experimental deployments versus those with defined use cases. Their effectiveness is also quite different.

If the deployment has a defined use case and senior management sponsorship, the tactics available are quite wide and diverse. I’ve included a few of them in the process flow:

Remove alternatives: This is a heavy-handed, quite effective way to approach the culture issue. Banish the old applications and processes that employees have been using. Force them to work with the social software. Sameer Patel wrote about just such a case. A chip company forced its workers to use the company wiki by setting a policy of deleting all emails after 45 days. Want to keep that information? Put it on the wiki.

Storytelling: Senior executives outline their vision for what the workplace of tomorrow will be. They talk of efficiencies, growth, and new opportunities for career paths. In a recent Wharton knowledge article, BP’s Fiona MacLeod said:

“Develop your killer slide to make your business case whenever you give a presentation. It’s not only why you’re changing, but what it’s going to look like when you’re done. People need to have a sense of what the future looks like, so be very clear on that.”

Incentives: Drive usage of the social software by directing employee motivations with recognition and rewards. Maintain a leaderboard of top contributors. Celebrate breakthroughs that were expected to occur via the social software. Braden Kelley’s review of The Carrot Principle includes explains the value of incentives in effecting change. Or companies could take it even further, following Andrew McAfee’s suggestion that social software participation be baked into performance reviews.

Executive reminders: Timely, forceful reminders from managers are also effective. They are the mechanisms by which culture does indeed change. If employee usage is not at the desired level, executives make sure it’s known what is expected. Anyone who has worked in large companies knows about these missives. Sometimes you’ve got to crack some skulls.

For the experimental deployments, employee inertia is harder to overcome. The internal levers to drive changes in behavior are not available. I’ve been in this situation with a previous job. Here are some tactics for overcoming culture in experimental deployments:

Model behavior: Project leaders and evangelists model the behavior they want to see. Need to send information to others? Write it in the wiki, and email the wiki page link. People want to reach you via IM? Turn your IM off and communicate via Yammer. In some ways, this is the bottom-up version of “Remove alternatives” described above. But it’s a persuasion approach, because that’s all that’s available.

New use cases: The experimental deployments don’t start with a crisp, in-the-flow “real” business case. That doesn’t mean there aren’t use cases. It just may take some hustle to figure out some, and they are likely tangential to the needs of employees. For one experimental deployment at a previous company, I came up with 10 separate ways to use the platform. At the launch of the deployment, a software vendor and the internal advocates will come up with these use cases. Reminding people of these and creating new ones are tactics for overcoming culture.

Senior sponsor: After the launch, the pilot team attracts the interest of a senior manager. Someone who did not push actively for adoption initially. This person sees something “there”, and decides to promote it. This does not open up the panoply of all organizational levers. But it does provide a boost in awareness and increase motivations for adoption.

Get the results

After the employees have (or have not) used the social software, it’s time to look at the results. Again, there is a fork in the road for this activity.

The great thing about a defined use case is that you have a framework for evaluating the results. There was a specific job the software was hired to do. How’d it perform? Even better, the defined use case likely replaced some other process and (maybe) applications. So there will be results from the regular process against which to benchmark the deployment.

For the experimental deployments, collecting the wins is how results are measured. These are the stories of how the software helped someone. The information someone found that helped get a task completed. The turnaround time that was much faster than expected. The connections made with someone previously unknown in the organization. These anecdotes are the building blocks of an ROI.

What do employees think?

If the results are positive – either compared against the use case or via anecdotes – then getting employee perceptions of the software is next. If the results are negative, this is a step that’s relay not needed.

Employees are asked their opinions of:

• The user experience
• What they liked about the software
• The software’s general usefulness
• Their interest in using the software in the future
• The vendor
• What could be improved?

This feedback is valuable from a cultural perspective. What’s the main opinion of employees?

From all of this, the decision about whether to go with the software is made.

Culture is self-selecting

At a high level, culture is a self-selecting determinant of whether a company even pilots social software. If a company has a heavy command-and-control, execution-oriented culture, they aren’t trialing social software. In that sense, it is all about culture.

But if a company feels it’s ready to give social software a try, the culture-as-impediment argument loses steam. More likely, failure is a case of no defined use cases for the software. Stop laying the blame on culture.

Or as Yoda said in Star Wars: “Do. Or do not. There is no try.”

Tactics for overcoming culture

When culture is proving to be an impediment, there are various tactics one can use to try to overcome it. The tactics vary for experimental deployments versus those with defined use cases. Their effectiveness is also quite different.

If the deployment has a defined use case and senior management sponsorship, the tactics available are quite wide and diverse. I’ve included a few of them in the process flow:

Remove alternatives: This is a heavy-handed, quite effective way to approach the culture issue. Banish the old applications and processes that employees have been using. Force them to work with the social software. Sameer Patel wrote about just such a case. A chip company forced its workers to use the company wiki by setting a policy of deleting all emails after 45 days. Want to keep that information? Put it on the wiki.

Storytelling: Senior executives outline their vision for what the workplace of tomorrow will be. They talk of efficiencies, growth, and new opportunities for career paths. In a recent Harvard Business Publishing blog, […]

Incentives: Drive usage of the social software by directing employee motivations with recognition and rewards. Maintain a leaderboard of top contributors. Celebrate breakthroughs that were expected to occur via the social software. Braden Kelly talked with […]. Or companies could take it even further, following Andrew McAfee’s suggestion that social software participation be baked into performance reviews.

Executive reminders: Timely, forceful reminders from managers are also effective. They are the mechanisms by which culture does indeed change. If employee usage is not at the desired level, executives make sure it’s known what is expected. Anyone who has worked in large companies knows about these missives. Sometimes you’ve got to crack some skulls.

For the experimental deployments, employee inertia is harder to overcome. The internal levers to drive changes in behavior are not available. I’ve been in this situation with a previous job. Here are some tactics for overcoming culture in experimental deployments:

Model behavior: Project leaders and evangelists model the behavior they want to see. Need to send information to others? Write it in the wiki, and email the wiki page link. People want to reach you via IM? Turn your IM off and communicate via Yammer. In some ways, this is the bottom-up version of “Remove alternatives” described above. But it’s a persuasion approach, because that’s all that’s available.

New use cases: The experimental deployments don’t start with a crisp, in-the-flow “real” business case. That doesn’t mean there aren’t use cases. It just may take some hustle to figure out some, and they are likely tangential to the needs of employees. For one experimental deployment at a previous company, I came up with 10 separate ways to use the platform. At the launch of the deployment, a software vendor and the internal advocates will come up with these use cases. Reminding people of these and creating new ones are tactics for overcoming culture.

Senior sponsor: After the launch, the pilot team attracts the interest of a senior manager. Someone who did not push actively for adoption initially. This person sees something “there”, and decides to promote it. This does not open up the panoply of all organizational levers. But it does provide a boost in awareness and increase motivations for adoption.

Get the results

After the employees have (or have not) used the social software, it’s time to look at the results. Again, there is a fork in the road for this activity.

The great thing about a defined use case is that you have a framework for evaluating the results. There was a specific job the software was hired to do. How’d it perform? Even better, the defined use case likely replaced some other process and (maybe) applications. So there will be results from the regular process against which to benchmark the deployment.

For the experimental deployments, collecting the wins is how results are measured. These are the stories of how the software helped someone. The information someone found that helped get a task completed. The turnaround time that was much faster than expected. The connections made with someone previously unknown in the organization. These anecdotes are the building blocks of an ROI.

What do employees think?

If the results are positive – either compared against the use case or via anecdotes – then getting employee perceptions of the software is next. If the results are negative, this is a step that’s relay not needed.

Employees are asked their opinions of:

· The user experience

· What they liked about the software

· The software’s general usefulness

· Their interest in using the software in the future

· The vendor

· What could be improved?

This feedback is valuable from a cultural perspective. What’s the main opinion of employees?

From all of this, the decision about whether to go with the software is made.

Culture is self-selecting

At a high level, culture is a self-selecting determinant of whether a company even pilots social software. If a company has a heavy command-and-control, execution-oriented culture, they aren’t trialing social software. In that sense, it is all about culture.

But if a company feels it’s ready to give social software a try, the culture-as-impediment argument loses steam. More likely, failure is a case of no defined use cases for the software. Stop laying the blame on culture.

Or as Yoda said in Star Wars: “Do. Or do not. There is no try.”