Enterprise 2.0: Culture Is as Culture Does

The Overuse of the Word “Culture”

• In Enterprise 2.0 discussions, the word “culture” is used constantly.

• It’s often cited as the key factor in determining whether a company is ready for social software.

• At a high level, this makes sense:

  • If leadership believes, “When I want your opinion, I’ll give it to you,” the company isn’t culturally ready.

• However:

  • Most modern companies already recognize employees as valuable assets.

  • So “culture” as an explanation is often too vague.

What Does “Culture” Actually Mean?

When people say culture is a barrier, they may really mean:

• Employees hoard information to protect career advantage.

• The workplace is competitive rather than collaborative.

• There are varying degrees of readiness across organizations.

The author questions:

• How much can entrenched company culture really be changed?

• Are cultural barriers overstated?

Culture Can Change Faster Than We Think

Unlike society, company culture can shift quickly because:

• Senior executives can mandate change.

• Employees depend on paychecks.

• Performance evaluations influence behavior.

Important point:

• Relying only on viral, organic adoption isn’t enough.

• But relying only on force isn’t ideal either.

• Employee behavior can be redirected for legitimate business reasons.

The Importance of a Defined Use Case

The first critical question:

Is there a defined use case?

Why this matters:

• If software supports specific tactical tasks → cultural resistance decreases.

• If it competes with existing tools (email, SharePoint, shared drives, portals) without a defined purpose → it likely fails.

Example (wikis):

• Success case:

  • A real project is run exclusively in the wiki.

  • People know why they’re using it.

  • They experience benefits firsthand.

• Failure case:

  • No clear purpose.

  • Just another tool in the stack.

Key takeaway:

• Use cases must be real, not artificial test scenarios.

Defined vs. Experimental Deployments

A) Defined Use Case Deployment

• Sponsored by a senior manager.

• High visibility.

• Access to resources.

• Leadership attention.

• Accountability exists.

B) Experimental Deployment

• No strong management sponsorship.

• Driven by evangelists and early adopters.

• Lower visibility.

• Harder to overcome inertia.

• More likely to run into “cultural” issues.

How Does Awareness Spread?

When Senior Management Is Involved

• Internal communications kick in:

  • Email announcements

  • Intranet posts

  • Posters

  • Videos

  • Meetings

  • Contests

• Organizational infrastructure amplifies visibility.

In Experimental Deployments

• Awareness spreads informally:

  • Small pilot groups

  • Evangelists sending emails

  • Meetings

  • Exclusive invitations

• Viral strategies may work (e.g., Yammer adoption examples).

• But momentum is harder to build.

Is Culture Really the Barrier?

Once people try the software, the real question is:

• Are they continuing to use it?

• Is it helping them do their jobs?

Often, “culture” may just mean:

• Employees prefer existing tools and habits.

• There’s no compelling reason to change.

Key insight:

• At work, motivation is extrinsic.

• Employees need a strong, practical reason to switch tools.

Tactics for Overcoming Cultural Resistance

A) For Deployments with Defined Use Cases & Executive Support

1. Remove Alternatives

• Eliminate old systems.

• Force use of the new platform.

• Example: Deleting emails after 45 days to push wiki adoption.

• Highly effective but heavy-handed.

2. Storytelling

• Leaders articulate:

  • The vision

  • The future state

  • Benefits and opportunities

• Employees need a clear picture of what success looks like.

3. Incentives

• Leaderboards

• Recognition

• Rewards

• Participation included in performance reviews

4. Executive Reminders

• Clear expectations.

• Strong follow-ups.

• Direct management pressure.

B) For Experimental Deployments

Harder because formal levers are limited.

1. Model Behavior

• Leaders use the platform consistently.

• Share wiki links instead of attachments.

• Turn off old channels when possible.

• Bottom-up version of “remove alternatives.”

2. Create & Reinforce Use Cases

• Identify practical ways the tool can be used.

• Continuously remind employees of these examples.

• Develop new ones over time.

3. Attract a Senior Sponsor

• Gain interest from a senior manager after launch.

• Increased awareness.

• Boost in credibility and motivation.

Measuring Results

A) With a Defined Use Case

• Easy to evaluate.

• Clear job the software was meant to do.

• Compare performance to the previous process.

• Benchmark measurable results.

B) In Experimental Deployments

• Results measured through:

  • Success stories

  • Faster turnaround times

  • Better connections

  • Problems solved

• Anecdotes become building blocks of ROI.

Gathering Employee Feedback

If results are positive, gather employee perceptions:

Employees are asked about:

• User experience

• What they liked

• Overall usefulness

• Interest in future use

• Vendor satisfaction

• Suggested improvements

This feedback:

• Reveals cultural attitudes.

• Helps determine whether to fully adopt the software.

Final Insight: Culture Is Self-Selecting

At a macro level:

• Command-and-control companies don’t pilot social software.

• In that sense, culture determines initial openness.

However:

• Once a company pilots social software,

• Blaming failure on “culture” is often misleading.

More likely causes of failure:

• No defined use case.

• No compelling reason to change.

• Lack of leadership support.

Core Conclusion

Stop blaming culture.

If the company is trying social software:

• Either define a real use case and commit,

• Or don’t try at all.

As Yoda said:

“Do. Or do not. There is no try.”