About these ads

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.

E20 pilot deployment flow

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.”

About these ads

About Hutch Carpenter
Senior Consultant for HYPE Innovation (hypeinnovation.com)

12 Responses to Enterprise 2.0: Culture Is as Culture Does

  1. Use cases are a bad leftover from a linear-focused discipline — methods that force real world complexity into the linear reality of ‘code’.

    Of all of the change that has to occur, development has to change to. There’s no need for use cases in a 2.0 world — the collaborative work does not include ‘throwing stuff over the wall’. It’s all realtime.

    If the people doing the work have not been intimately involved in the conversations — the results will be sub-optimal.

    Even developers are not machine parts.

    Stop the madness at the very core. It all has to change.

  2. Sameer Patel says:

    Love it, Hutch. Excellent practitioner-ready tips here.

    I’m of the strong belief that strategy without an execution plan is one of the leading causes of failure in the enterprise.

    Successful senior managers/execs are very good at not just laying out strategy but getting the organization to believe in the chosen direction. Those very senior managers need to also illustrate the right approach to executing this strategy (key success factors, risk mitigators etc). Part of this is exposing glaring differences in a status quo approach vs. using social software to radically increase chances of project success, when appropriate. If done correctly, it’s not altruistic any more – rather its casted as a key ingredient towards realizing that very strategy that the organization bought into.

    It’s the project managers, e2.0 evangelists and enthusiasts that need to articulate this to those setting strategy if they don’t already have the knowledge to think of it themselves.

  3. Excellent summary of the corporate adoption process – it quite accurately reflects my experiences in the last ten years. The “use-case/no use case” dichotomy is a very good idea – I had fuzzily thought about that, but you make the process very clear !

  4. Pingback: Links for July 12 2009 | Eric D. Brown - Technology, Strategy, People & Projects

  5. Pingback: The ‘un peachy’ side of Enterprise 2.0 SaaS | Pretzel Logic - Enterprise 2.0

  6. Lawrence Liu says:

    Excellent points, Hutch. Love the flowchart! I posted more of my thoughts (w/ a ref back to here) at http://bit.ly/sEEre

  7. Pingback: What is culture? bhc3.wordpress.com as culture does in sweet piece on real #e2adoption issues from @bhc3 via @ITSinsider - Twitoaster

  8. Karyn German says:

    Excellent post, Hutch. I shared a number of these points in my Roadmap to Successful Adoption whitepaper released last month and couldn’t agree more with the points. I’ve also had an interesting observation that social computing behind the firewall will often reveal cultural issues that may never have been openly discussed. I wrote about this several months ago, here: http://blogs.newsgator.com/daily/2009/02/what-will-socia.html

    As usual, great insights from you!

  9. Pingback: Lessons from “Why Software Sucks”

  10. Pingback: links for 2009-08-31 « Ex Orbite

  11. Pingback: “Do. Or do not. There is no try” « sueduran

  12. Pingback: Barriers to Internal Collaboration | Norman Macleod's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 660 other followers

%d bloggers like this: