About these ads

When Should Management Push Enterprise 2.0 Adoption?

After the Boston edition of the Enterprise 2.0 Conference, IBM’s Rawn Shah wrote a great follow-up post outlining ten observations from the event. A couple points that I found myself agreeing with wholeheartedly were:

Adoption is about transforming human behaviors at work – More folks are starting to recognize that it is not trivial to bring communities and other social environments to life.

‘Let’s get beyond “adoption”’ – This was another sentiment I heard several times, but I attribute it to short-attention span. The general statement was ‘adoption’ was last-year’s thing, and we needed a new ‘thing’.

The underlying philosophy of his post contrasts with that of Paula Thornton, who finds talk of driving adoption to be antithetical to the true nature of Enterprise 2.0. As she described in a post from several months ago:

If you have to “drive adoption” you’ve failed at 2.0 design and implementation. The fundamentals of 2.0 are based on design that is organic — meets the individual where they are and adapts based on feedback — it emerges. The ‘adoption’ comes from rigorous ‘adaptation’ — it continuously morphs based on involvement from the ‘masses’. If done right, you can’t keep them away…because you’ve brought the scratch for their itch.

While I empathize with her design-driven perspective, I personally find there to be more to people’s adoption patterns. Sometimes the superior design does not win. Existing network effects may prove a high barrier to adoption of something new. Embedded history makes the current approach valuable. And other reasons intrude.

In considering adoption, we have the push strategy (by management), and the pull strategy (viral, organically spreads). Both are viable approaches. The key factor is to determine when each needs to be employed.

A Decision Framework for Pushing Enterprise 2.0 Adoption

The graphic below outlines a basis for determining when Enterprise 2.0 adoption must be pushed, and when to let adoption be pulled:

The two key factors in the framework are user-centric and organization-centric.

The X-axis highlights a key reality. If a current approach/technology is working well enough for users, there is an inertia to making a switch of any kind. This principle is nicely captured in the “9x problem”, an explanation by Harvard professor John Gourville that was highlighted by Andrew McAfee. The 9x problem is this:

Users will overvalue existing products/solutions by 3 times, and undervalue the benefits of a new products/solutions by 3 times.

We’re for the most part risk-averse (e.g. technology adoption lifecycle is back-end loaded), and giving up existing ways presents a level of uncertainty. It’s the devil we know versus the devil we don’t. We place a value on the certainty of current methods, even if flawed.

The other part of the 9x equation is that users will place an uncertainty discount against new products/solutions enumerated benefits. Yes, it’s true. We don’t always buy everything we’re told.

The Y-axis speaks to the value of E2.0 to organizations. Certainly there will be use cases that can drive high value for the organization. And just as certainly, there will be those use cases that contribute little to organizational value.

Let’s run through the different approaches mapped on the graph, clockwise from top right.

Requires a Top-Down Push

Situation:

  • Existing ways are ‘good enough’ for employees
  • Executives see great potential for value from adoption

What might this be? Imagine management has seen too many examples of people missing key information and connecting the dots well with others are working on. An enlightened C-level type knows there is an opportunity to pick it up a level.

So some sort of social software – e.g. wiki, collaboration groups, etc. – is selected to make this a reality. But guess what? People keep emailing to one another and saving docs to the LAN.

Why? Because those are the tools they know, there is no learning curve and everyone operates on a shared set of processes and assumptions. Things work “as is”.

This is where management needs to wield its power, and come up with ways to influence employees to alter their entrenched behaviors that work “good enough”.

Mix a Push-Pull Strategy

Situation:

  • Existing ways are actually not “good enough”
  • There is high value in large-scale adoption

This is the home run of initiatives. Solves a “what’s in it for me” need of individuals, while also presenting a great chance to advance the value of the organization.

An innovation platform is a good example here. A place for individuals to express those ideas that fire them up or just plain solve annoyances. Which get lost in the email inbox.

But the opportunity for new ideas that deliver to the bottom line gets management’s attention.

Pull works here, as word spreads about the initiative. But management has an interest in making sure everyone is aware of the initiative, as soon as possible. Push tactics are good supplements.

Let It Grow Organically

Situation:

  • Existing ways are actually not “good enough”
  • There is low value in large-scale adoption

This is a tough one. Clearly the “Enterprise 2.0 way” can solve a problem for employees, but its adoption cannot be seen to lead to high impact on company value. An example here? Hmm…tough one. Enterprise bookmarking might be one area. Solves the, “how do I find things?” conundrum, for me personally and for others. But hard to see just how it will increase firm value. At least on a standalone basis.

Best to let these initiatives grow of their own accord. Let their value emerge, often with stories.

Don’t Waste Your Time

Situation:

  • Existing ways are ‘good enough’ for employees
  • There is low value in large-scale adoption

Suffice to say, this one should be killed before it ever starts.

About these ads

My Ten Favorite Tweets – Week Ending 010110

From the home office in the future, where I’m currently reviewing all these 2010 predictions with a skeptical eye…

#1: How Companies Increase Innovation – WSJ.com #innovation http://post.ly/GubP

#2: RT @chuckfrey Amazon’s Jeff Bezos on two ways to approach customer-focused innovation: http://ow.ly/QIbl #innovation #strategy

#3: RT @briansolis Ideas Connect Us More than Relationships (video interview) http://bit.ly/8wPTzf

#4: Outstanding, detailed post on Enterprise 2.0 adoption from @ITSinsider & the @20adoption council: http://bit.ly/516Cv4 #e20

#5: Designing For Social Traction by Joshua Porter #design http://post.ly/GoE6

#6: Intellipedia anyone? “Preventing the Terrorist Attack: Massive Failure in Collaboration” http://bit.ly/6AQgPV #e20 #gov20

#7: 2010 Predictions from @jkuramot of Oracle AppsLab: http://bit.ly/7ainDr “Reputation will be all the rage in 2010.” > Agree

#8: RT @matthewemay Six years ago this USAToday essay by Jim Collins changed my entire view of the world. http://is.gd/5HPPu

#9: RT @davewiner: Anil Dash, an upper-caste Twitterer, explains to low-life scum like you and I, what it’s like up there. :-) http://r2.ly/yxbt

#10: My 5 1/2 y.o. son on why he didn’t see a friend’s kindergarten girl from the sister school in his coed class: “All the girls look alike.”

Early Peek at Speaker Submissions for Enterprise 2.0 Boston 2010

The Enterprise 2.0 Conference Boston Call for Papers has been open for a little over a week now. While the final number of speaker proposals will number in the hundreds (450+ for SF 2009), the initial 29 submissions are a rich vein of current thinking about Enterprise 2.0.

As you can see in the tag cloud from the site, the top tags so far for the proposed sessions are:

  1. technology adoption
  2. social media
  3. best practices
  4. knowledge management
  5. getting started
  6. learning
  7. business case

Technology is the top tag. There’s no denying that technology enables Enterprise 2.0. Adoption is running strong so far. Which is a pretty fair characterization of a key issue in the field. Social media comes on strong. There are plenty of conferences devoted to that topic, and here even a conference primarily addressing to internal collaboration has its share.

A Few of the Proposals

Based on page views, here are the five most popular submissions early on:

Three Keys to a Successful SharePoint Deployment (Rich Blank):

There are 3 keys to deploying SharePoint successfully for a large enterprise: Platform, Governance, and Marketing. The first part involves a stable, available, easily accessible, secure, well performing global technology platform. If users can’t access the environment, they won’t trust it or won’t use it. Next is governance – all things related to the overall project as well as the operational and support involved. Finally there is marketing — you need to market the application to end users, provide quick introductions to get them started, best practices, conduct demos that demonstrate business value, create proof of concepts, and show people what’s possible. You shouldn’t have to provide formal training if you market the application right. Each of these 3 are not mutually exclusive — you can’t have marketing without the platform and good governance.

Driving Adoption is anti-2.0 (Paula Thornton):

There’s way too much 1.0-thinking being applied to the 2.0 era. “Driving adoption” is the antithesis of the fundamental premises of 2.0. Starting with 2.0 axioms is critical to guide any 2.0 initiative.

Connecting the Dots to Competitive Advantage (Jon Ingham):

Enterprise 2.0 can increase efficiencies and help meet business objectives but it can also generate competitive advantage.  To create higher levels of value, the use of social technologies needs to be linked to other organizational enablers, eg HR practices, OD interventions, facilities design etc.  This session will show how.

Lessons from Religion about Evangelizing Enterprise 2.0 (Gil Yehuda):

The E2.0 marketplace has evangelists, non-believers, and faith-based ROI models. But the workplace is modeled after the hierarchy of government and the meritocracy of the marketplace. Wherein lies community? As it turns out, religion can teach us about the nature of community in context of preparing the workplace for E2.0.

Moving Beyond Email — Barriers to Knowledge Management (James Rosen):

Email is fast, free, and easy to use, but it has many limitations, especially in an enterprise context. Yet many employees, especially baby-boomers, rely on it nearly exclusively. This talk examines the use cases for which email is the wrong tool, and how to move to better ones.

That’s just a few of them, check ‘em all out. And be ready to vote come January 2010.

Social Software 2.0: Enterprise Process Ubiquity

In the beginning, there were forums, blogs and wikis. And it was good.

In talking with people about the Enterprise 2.0 industry, I like to insert yet another versioning number scheme:

  • Social Software 1.0
  • Social Software 2.0

Social Software 1.0 was the era of actually creating these open, collaborative applications. The approach of these tools was groundbreaking. Apps for managing knowledge that are open, persistent, easy to create and accepting  contributions from many? This was groundbreaking. The tools of Social Software 1.0 are: blogs, wikis, forums, microblogging, activity streams, tags, social connections.

Social Software 1.0 is the “Tools Era”. Put these collaboration and information sharing tools in place, then let the benefits flow. And the benefits do flow.

But are they flowing fast enough? Will they assume core operational infrastructure status within enterprises? This is the crux of Dennis Howlett’s post, Enterprise 2.0 – the non-debate. It’s a fair question. Dennis notes this in his post:

I’ve also argued that I’ve never heard anyone ask for some Enterprise 2.0 though I’ve heard plenty ask for ERP, CRM etc.

Let’s examine that particular quote for a moment, on two fronts. First is the important point that CRM, ERP and other existing enterprise software address core company activities. Sales? No sales, no company. ERP? You can apply a thousand clerical workers for all the little things needed to manage resources, or organize information systematically to great benefit.

Second is the fact that markets demand these apps. Let’s take a ride in the time machine back to 2001. In the article, CRM Adoption Continues at an Aggressive Pace, this market growth was noted:

Spending on customer relationship management (CRM) applications will grow to $10.4 billion by the end of 2001, a 167 percent increase from the $3.9 billion spent in 2000, according to a report by eMarketer.

An industry on fire, with sales in the billions, that was started sometime in the mid-1990s, and Siebel Systems was started in 1993. So in the course of just a few years, CRM was a bona fide hit inside businesses. Enterprise 2.0 is at an earlier stage in its industry life cycle, but isn’t currently on track to be the size of the CRM market in the next few years.

This isn’t to say Enterprise 2.0 isn’t finding its footing with its tools focus. As Dion Hinchcliffe writes, there has been a significant pickup in corporations’ implementation of these applications: “Just as importantly, we are also starting to see customers implementing Enterprise 2.0 in scale. These typically include enterprise social networking, wikis, and social CRM.”

Look closely at the three types of implementations: wikis, social networking, and social CRM.

Social CRM?

That’s not part of the Social Software 1.0 canon. Rather social CRM is an example of the next generation of social software. Social Software 2.0.

Social Software 2.0: Addressing Existing Enterprise Workflows

Here’s how I define Social Software 2.0:

The integration of collaboration, increased findability, social networking and crowdsourcing into core enterprise activities requiring defined workflows, specific user sign-offs, results measurement and role-based access.

I’ll admit that comes across as a tall order. But it’s a worthy goal. Check out Ray Wang’s ten elements that define the next generation of enterprise business software solutions for a deeper look at these requirements.

The challenge is figuring out where social benefits traditional processes and systems. In Susan Scrupski’s great presentation, Enterprise 2.0 Demystified, there’s this slide:

Susan Scrupski - E2.0 Demystified

Credit: Susan Scrupski, SoCo Partners

There’s an aspirational component to the graphic. “Social ERP” includes a number of nuts-n-bolts activities that all of us can understand: order tracking, purchase orders, inventory management.

What we don’t yet understand is how social gets in there and improves these processes. But Nenshad Bardoliwalla starts us down that path in his post, Is Enterprise 2.0 a Savior or a Charlatan? In the graphic below, he fills in the white spaces of process flows with instances of social software applications (+ email/IM):

Nenshad - social software fills in process white spaces

The graphic starts to describe the way social software could integrate into existing activities of organizations. But it still leaves some questions. For instance, see that wiki in the Contact Center row, to the right of Campaign Management? It’s linked below to the Sales and Quotation Analysis process.

In Social Software 1.0, that’s a standalone wiki. I’m a fan of the notion that collaboration needs to occur in-the-flow of work. And having a separate wiki for collaborating on a customer quotation analysis makes it tougher to get usage.

In Social Software 2.0, that’s a collaborative space integrated into a sales force automation application. The customer quotation analysis occurs right where all the “action” occurs in the effort to win new business.

Some Examples of Social Software 2.0

With the luxury of a blank blog page, I’ve got the freedom to suggest a few examples where collaboration and crowdsourcing can be more integrated directly into corporate activities.

B2B Sales: The process of pulling together a proposal in the B2B market generally requires involvement of several parties. This is a process screaming for collaboration, visibility, searchability and persistence. It also has deadlines, and sign-offs by executives. Generally, tapping an existing database of customer information is required too. Embedding a wiki-like experience in CRM, along with the deep database access and project dimensions would be valuable.

Procurement: Enterprises buy mountains of things. Inevitably, some of it doesn’t work out as well as expected. As employees order and request items, allow them to rate and comment on existing contracts. By sharing their experiences, employees provide procurement managers with insight into the quality of suppliers. And employees can describe evolving needs. The workflow aspect of this occurs when the crowdsourced rating falls below some threshold, triggering a required review by the procurement manager.

Product Management: If you’ve ever done product management, you know that you’ll receive plenty of individual ideas on what’s needed. Business units, sales, marketing, engineering, customer service…all have strong opinions on what should be included. Putting all these internal constituencies together on a common platform to identify ideas and get crowdsourced input on the most pressing features would be a tremendously helpful. The process would need to include analytics to filter through them, and workflow to flesh out features and get sign-offs. Example: Spigit innovation management.

There are myriad corporate systems and processes where some elements of social can be leveraged to improve operations.

Sameer Patel, in his post Why Process Barfs on Social, includes this tweet by (now former) SAP EVP Zia Yusuf:

@dahowlett blog and wikis will not drive value alone, I think the trick here is to connect “crowd insight” directly into specific bizprocess

And Helpstream CEO Bob Warfield adds this thought:

What we’re lacking is simply a harmonious marriage of these two.  Social should be integrated into specific business processes, perhaps many if not most specific business processes.

What we’re seeing is the natural maturation of an industry. Tools were needed to establish the Enterprise 2.0 field in the first place. Now it’s time to apply these tools, and social computing concepts, to the mainstay activities that drive businesses.

What Form Will Social Software 2.0 Take?

The maturation of the social software industry beyond tools to deeper integration into existing business processes will have parallel development paths:

  • Established enterprise applications will add social elements to their offerings
  • General purpose collaboration and social network providers will develop features addressing specific types of traditional activities
  • Social software platforms focused on delivering value in a specific core business activity

Like most enterprise software markets, there will be room for all three types of offerings. I think it will be hard to dislodge best-of-breed for the biggest systems: ERP and CRM. Those vendors will add social elements as time allows, and nimble small companies will offer plug-ins that supplement their offerings. Most other systems in the enterprise will be up for grabs if there’s a better way.

I’ll close with another quote from Bob Warfield with regard to how the Social Software 2.0 landscape will play out:

No touchy feely stuff allowed.  You can’t just be about making things “better” or “empowering people.”  Passion is great, but call your shot, and if the ball doesn’t go into that pocket, you’ve scratched and forfeit the game.

My Ten Favorite Tweets – Week Ending 111309

From the home office in my watery swimming pool on the moon…

#1: RT @innovate: The 50 Best Inventions of 2009 http://ow.ly/BVB0 #innovation I like #40 Edible Race Car. #9 Tweeting by thinking?

#2: RT @lindegaard: Tough Questions and Great Answers: General Mills Steps Up to the Open Innovation Plate: http://bit.ly/2nEXSv

#3: Microsoft Bing team gets kudos for #innovation. First tweet search, now Wolfram|Alpha integration http://ow.ly/BrHC

#4: Is Twitter Trying to Lure You Back to Twitter.com? http://ow.ly/AfcU by @robdiana > Maybe a way to drive page views for ads?

#5: Regarding new Twitter retweet function, @stoweboyd has some good points about it http://ow.ly/AIl7 Inability to add text is a miss

#6: October was a slow traffic month for the social networks, in a detailed look by @louisgray http://ow.ly/BCgU Facebook still growing

#7: UK Guardian discusses how to deal when your boss is on Twitter (& links to my #cisco fatty blog post f/ March) http://ow.ly/Bkrf

#8: Check out: Driving Adoption is anti-2.0 http://bit.ly/1ksZAr #e2conf > Leave it to @rotkapchen!

#9: Do we create the world just by looking at it? http://bit.ly/1kdTOs “Human body is a just barely adequate measuring device” #quantumphysics

#10: Commentator on NPR this AM criticizes Californians for social liberal/fiscal conservative & not wanting taxes. Western libertarian strain!

My Ten Favorite Tweets – Week Ending 071709

From the home office in the U.S. Senate in Washington, D.C.

#1: Reading: Your Idea Sucks, Now Go Do It Anyway http://bit.ly/10Dwi0 Most important thing is to get started, not be right #innovation

#2: Love this quote: “Disruptive innovation has been held up as the Olympics of innovation sport.” http://bit.ly/15ypw6

#3: Google and Apple “are accidental competitors. They just don’t seem to know it yet.” http://bit.ly/4xjXCJ

#4: Reading: Adoption stories http://bit.ly/6hNJr by @panklam on The AppGap #e20 #e2adoption

#5: Social Computing Journal picks up my post – Enterprise 2.0: Culture Is as Culture Does http://bit.ly/eTA43 #e20

#6: P&G’s @JoeSchueller has a nice comment on Google Wave’s potential in the enterprise on Socialtext’s blog: http://bit.ly/xRkGj

#7: I like @fredwilson‘s take on customers. Active transactors vs. active users. http://bit.ly/WrHQ2

#8: RT @markivey Why BusinessWeek Matters (from a former BW writer) http://bit.ly/fe9GC Really GREAT post, why we *need* our news institutions

#9: An entrepreneur who has built companies in both Silicon Valley and NYC describes the issues w/NYC for startups: http://bit.ly/G2Hss

#10: I ♥ wikis

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

Follow

Get every new post delivered to your Inbox.

Join 668 other followers