Transparent Office

Social Training for Social Tools

Socialtext product adoption is way, way up--over 300% YTD. There are many reasons for the phenomenal growth, but in this post I'll focus on one specific factor: our training approach.

Some time ago, I had one of those forehead-smacking Ah-Hah moments about the way we were trying to train customers to use Socialtext: Traditional IT training doesn't work for social software. Social software requires social training.

When I talk about social training, I'm not talking about charm school, or teaching your collie how to play nice with the local poodles. I'm talking about a unique method of teaching employees to use social software at work.

In traditional training, you interact with technology. In social training, you interact with other people by means of technology. The technology becomes a medium, like a telephone or a videoconference room, rather than the object of your interaction, like an MRI machine or a Boeing 777.

Suppose you were trying to train someone who had never seen a telephone before. You could teach them how to dial, how to put someone on hold, how to work the mute button. But until they actually made a call and speak to another human being, they won't get the point. And that's exactly what happens when you use traditional training methods for social tools: they learn how to push the buttons, but they don't get the point.

Embracing a social approach for Socialtext training caused us to radically rethink the way we introduce new users to the system. In a Socialtext training, you don't get told all the features of the system. You don't walk through hypothetical use cases. You don't get to sit back and watch a trainer walk through a system demo.

Instead, you interact with your colleagues, in real time, using Socialtext. We cram lots of users on a conference call at the same time. Everyone logs in to the system.  We walk participants through basic functions like creating a profile, tagging themselves, posting Signals, editing workspace pages. We encourage them to ask questions--then answer questions that others have asked. We encourage them to tag not only themselves, but also their colleagues. We noodge everyone to upload a profile photo. We kibbitz, we cajole, we encourage people to step outside their comfort zones.

The results are amazing. We can jump-start an implementation within a couple weeks, and engage even the most skeptical, change-resistant employees within an organization in a very short time.

Why does it work? Four simple reasons:

• It creates a social dynamic from the start. The worst failure a social software tool can make is the sin of "crickets": a user tries to engage the community and there's no immediate reply. By getting many users on the system all at the same time, we guarantee that each of those users is experiencing a vibrant, active community at scale.

• It answers the "why" question. For most business users, the big question in social software isn't the "how". The mechanics of social software are simple. Users don't need a training course to know that they tag their profiles by clicking the "Add Tag" button, or post a Signal by clicking "Post". However, many users do need help in understanding *why* they would want to tag a profile or post a signal. For those users, the whole thing suddenly makes sense when they see their colleagues tagging and posting in real time, and in response to each other.

• It scales. The ideal size for a training session is anywhere between 25 and 100 simultaneous participants. They don't have to be in a room together. In fact, it's almost better when they're *not* in a room together. That way the software becomes their exclusive mode of interaction.

• It's fun. When these trainings go well, they're more like cocktail parties than training sessions. People meet new people, discuss interesting topics, and crack jokes all in the course of the hour. Many participants comment that it's the most fun they've ever had at a training.

So whether you're using Socialtext or some other social software tool...give social training a try. The results will delight you. More important, they'll delight your users.

In-the-Flow with American Hospital Association

At last week's E2.0 conference in Boston, I was surprised and pleased by the way my "in-the-flow" phrase has gained common currency. I was also surprised, but less pleased, by some of the "best practices" I heard flying around. Whether in keynotes, sessions, or just hallway conversations, I heard a lot of claims of dubious merit, claims like:

• Start with a small pilot and let it grow virally
• Invest heavily in community management, because a community is only as successful as its managers
• Workers won't use social software without personal incentives
• Workers who don't belong to the Facebook Generation don't "get" social software.
• Social software adoption requires a culture of collaboration
• You shouldn't launch collaborative tools without a collaboration strategy

There's a common theme behind all this advice: You should be scared of launching enterprise social software, because achieving adoption is really hard, really time-consuming, and really expensive. Sorry friends, but I'm calling Bullshit. In the hands-down best session I saw at the show, Karthik Chakkarapani from American Hospital Association described how AHA achieved phenomenal adoption. Here's the video Karthik's team put together. It's a must-watch for anyone interested in this topic. And for those of you with ADHD, here's the Cliff Notes version:

• Made Socialtext their Intranet (so there's one place to go).
• Integrated all mission-critical work tools into that very same Intranet (so there's one place to go)
• Implemented Single Sign-On to remove the barrier of extra logins for the different applications (so it's easy to get there)

AHA launched with a project team of 2 FTEs working for 3 months. Six months out they're getting over 95% active adoption. Karthik's success makes me think that a lot of E2.0 experts don't really understand what "in the flow" means. If your company is using social software in the flow of work, that means that the social software is where people work. It's not a side-room where happy people take time out to brainstorm, swap ideas, or post random tweets. It's where people go to work. Every day. And it ain't that hard.

Enterprise Social Software Adoption: Now Available in Prescription Strength!

When companies ask me how to deliver enterprise social software adoption, my advice is simple: Go to your local drugstore.

I'm not kidding.

Walk into any drugstore in America and whether it's Walgreen's, Wal-Mart, Rite-Aid, CVS, or an independent, I can guarantee you it's laid out the same way: The pharmacy is in the back of the store.

The marketers who develop drugstore planograms know that the pharmacy customer is a captive customer. If you walk into Walgreen's for Zoloft, Zyrtec, or Zyprexa, you will fill that prescription. By locating the pharmacy far from the entrance, drugstores force you to walk past a vast array of other items that you may not have come in for: magazines, candy bars, greeting cards, shampoo, toothpaste, and even groceries. While you're in the store, why not pick up AAA batteries and a few chocolate easter eggs for the kids?

The same principle applies to enterprise social software.

If you want your colleagues to try enterprise social software, you must get them in the door. Every organization has its "prescriptions", information or transactions which employees need on a regular basis. If you make your social software implementation a place--better yet, the place--to fill those prescriptions, you greatly increase the likelihood of its adoption long after the hype and hoopla of the initial launch has faded.

What prescriptions do your colleagues need to fill on a regular basis? The answer depends on the nature of your business. Here are a few good, generalizable  examples:

• Product information. Elsevier and Getty Images post product specs, FAQs, pricing, and marketing collateral that their Sales Reps need to sell a rapidly changing product line
• Transactional systems. American Hospital Association and NYU Stern School of Business have integrated transactional systems and forms into their Social Intranets
• Ongoing operations. Epitaph Records and Meredith Publishing manage marketing and promotional campaigns in collaborative workspaces
• Customer solutions. OSISoft and GT Nexus maintain the technical knowledgebases required to support their enterprise customers

These are very different use cases in very different businesses, but they have two things in common. First, they fill prescriptions. They deliver must-have content and functionality that a broad cross-section of staff need on a regular basis. Second, they lead to other "purchases". Users who initially show up to submit a Help Desk ticket or look up a price quote often find themselves staying to post an idea or upload a slide deck.

Once social software fills your colleagues' prescriptions, they'll use it...again and again.

Warning: Side-effects may include euphoria, cross-silo collaboration, engagement, ideation, decreased frustration, increased productivity, and intermittent feelings of interpersonal connectedness.

Vision for the Social Enterprise

When I talk with CIOs these days, there's one question that comes up again and again: How does it all fit together? How does Social play with my Intranet? How does Social play with my document management system? How does Social play with my ERP system? How do Social profiles play with our HR directory? How does Social play with my CRM system?

CIOs are asking these questions at level of both technical integration and user experience. They want to understand implications for the technology stack, and they want to understand how it all forms a coherent experience for their users--especially their non-power business users.

These questions represent a big change in CIO thinking. As recently as 12-18 months ago, CIOs were still peppering me with questions about business value, use cases, and ROI. That has subsided. When it comes to enterprise social software, CIOs are no longer asking Why. They're asking How.

Maybe it's my McKinsey training, maybe it's my Meyers-Briggs type (feel free to guess), but when I see complex, interconnected questions like these, I look for a simple framework or picture that tells the whole story.

So here goes. Tell me what you think. 

 

 

 

Collaborative Spaces: One or Many?

A new Socialtext customer, a government organization, is in the process of launching Socialtext for collaboration within and across project teams implementing a major set of environmental initiatives. Today they asked me a fundamental question: "Should we create a separate collaborative space for each project team, or have everyone collaborate in a single, shared space"?

I call this the "one-or-many" question. It comes up all the time. I don't think I've ever blogged my answer, so I will remedy that now.

There's no right or wrong answer. Both approaches have pros and cons, but there are very clear criteria for when you should take which approach.

Good reasons to have multiple workspaces (e.g., one for each project):

• There's confidential material that's not shareable within the organization
• Employees are intensely risk-averse and won't participate honestly if their contributions are broadly accessible outside the immediate team
• People work in disparate areas, and will view updates from other areas as spam

Good reasons to have one workspace:

• You want to support and encourage cross-silo collaboration and coordination
• You want colleagues to have greater visibility into what's happening in other parts of the organization
• You have a small implementation and don't want to dilute the network effects by splitting the cocktail party up into multiple private rooms

In general, I find that very small implementations (<100 participants) almost always benefit from working in one big workspace. The group is small, confidentiality is rarely an issue, and business processes are so fluid that everyone needs to be in everyone else's business. Once you get over 100 people, however, business processes and accountabilities become more formal, and you want to augment that one big workspace with smaller workspaces that are specific to teams, geographies, projects, etc.

Companies aren't communities

Companies aren't communities. They aren't forums.

Companies are companies.

Of course company life has a community aspect, but a lot of social software folks seem to forget that there's a lot more to a company than community. They treat companies as if they were consumer communities or forums that all just happen to have their paychecks signed by the same person.

Why does the difference matter? The answer is in the numbers. Online communities and forums typically attract very small audiences relative to the total target population: Less than 1% adoption is typical, and 5% adoption would be a grand-slam. That's fine for the consumer web, but those numbers inside the enterprise aren't exactly a ringing endorsement.

Successful enterprise implementations of social software have orders-of-magnitude higher adoption rates. For example, yesterday I was in New York meeting with Getty Images. Getty's Socialtext implementation is seeing 95% active adoption. Those are the numbers we're looking for inside the enterprise!

So how do we get there?

Companies, by very definition, have reporting structures, established workflows, shared systems and processes, defined roles and responsibilities, and closely managed performance. Those are assets we don't have in communities and forums, which are typically ad-hoc groups of individuals--mostly volunteers--in a collective endeavor without clearly defined roles, processes, reporting, deliverables, or metrics.

Getty and others achieve the adoption rates they do by integrating their social software into all those structures, workflows, systems, processes, roles, and responsiblities. As Getty's Director of Learning and Development, Jennifer Fox, told me today, "We no longer going to teach people how to use Socialtext. We are going to teach them how to do their jobs...which happen to require the use of Socialtext."

I've been saying for a few years now that companies achieve adoption and business value when they place social software in the flow of work. The tools achieve real benefit when people do their jobs--not their evenings-and-weekends jobs, but their actual "day" jobs in social software. That's when it becomes woven into the fabric of a company's business processes. Adoption is almost a foregone conclusion, because that's where you do your work. Business impact is demonstrable because business processes are measurable.

What, specifically, does this mean? It depends on your business, but it's things like:

• Marketing and Product post sales collateral in your social software tool (not in email!)
• Customer Support's knowledgebase is collaboratively maintained in social software (again, not in email!)
• The executive team and other key teams keep meeting agendas and notes in social software
• CRM, ERP, and Enterprise Learning systems automatically post major events in social software
• Quick links to important resources are available--and maintained--in social software
• Technical Help Desks and other internal support functions field requests via social software

Contrast that with an online community, like a gaming group or a technical forum. In communities, there is no flow of work. That's because most people don't come to communities to do work. They come to get support help, to swap tips, to praise, to complain, to socialize. Even those people who come for professional reasons are casual, sporadic visitors. The only person who really works there day-in-day-out is the forum/community manager.

There are three groups of people who cling to the "company as community" concept: the "kumbayeros" who wish that companies were as open and democratic as communities, public community managers whose consumer-facing experience has shaped the way they view all online social interaction, and community software vendors who are looking to repurpose their consumer-oriented products for the internal market.

In the enterprise, we need to take a more pragmatic approach. As Milton Friedman famously said, "The business of business is business." Social software fails when it tries to turn businesses into communities. It succeeds when it turns businesses into better businesses.

If a document falls in Sharepoint...

If a document falls in Sharepoint, and nobody hears it...does it make a sound?

That play on the old tree/forest cliche popped into my head this week while some Socialtext colleagues and I were meeting with senior IT staff of a Fortune 100 manufacturing customer of ours. They're a big Sharepoint shop, and mid-way through the meeting we had a revealing exchange:

IT Executive: We're a heavy Sharepoint shop
Us: Cool. How's adoption?
Executive: Frankly, it's pretty awful.
Us: Why?
Executive: No one goes to Sharepoint on their own. If you email them a link to a document, they'll click on it, but they won't go in by themselves.
Us: Suppose someone adds a document to Sharepoint of potential interest to me. How would I know it was there?
Executive: Someone would have to email you the link.

I've had this conversation several times now, almost verbatim. People don't go into Sharepoint because they don't know what's in Sharepoint.

The problem here is lack of transparency. If you can't see what other people are doing, you can't very well collaborate with them. It's not enough to have access to valuable content; you have to know that the content is there.

Sharepoint makes me think of a cocktail party where you can see the names and faces of the other guests, but you can't hear what they're saying. That party would quickly face an attendance problem, just as Sharepoint has an adoption problem.

Social software adoption requires collaboration. Collaboration requires transparency. You can do all the change management and attend all the conference break-out sessions you want, but you won't get adoption until you deliver transparency.

The good news is that there's an answer to this problem: activity streams. Twitter and Facebook have proven that activity streams are the most effective tool we have for letting folks know who is doing what and where. And they're the only effective tool we have for making those events social, by enabling others to comment, like, tag, re-tweet, etc.

Of course Twitter and Facebook didn't have nearly the traction they do today when Sharepoint 2010 was being scoped and coded. So while there are glimmers of transparency and activity streams in Sharepoint 2010, they are incomplete features at the margins of the user experience.

The social software world evolves faster than Sharepoint does, which is why it's good to have smaller, nimbler players like my own Socialtext around. We're smaller, our development cycles are shorter, and we're more sensitive to firehose of learnings from the exploding world of social software.

Socialtext's Sharepoint integration pulls Sharepoint events into the Socialtext activities feed. And it "socializes" those events by enabling colleagues to comment, tag, link, etc. Further integrate these evens with feeds from other systems like a CRM or ERP system, and you've really got something transformational  . And we can send the resulting integrated feed wherever it needs to go: Sharepoint, mobile, Adobe Air, iFrame, you name it.

That document falling in Sharepoint will finally make a sound.

Veterans Day Blog at Hospira

Usually I use this space to advocate use of social software "in the flow" of work. I write a lot about business processes, workflows, incentives, and IT integration. Today I want to talk about something
completely different.

Yesterday, medical devices and specialty pharmaceuticals leader Hospira created a Veterans Day Blog on their internal Socialtext implementation. It was something of a departure for Hospira, who typically uses Socialtext for "in-the-flow" things like IT collaboration, HR information, and professional development. The Veterans Day Blog wasn't "in the flow" at all. Whoever set it up was simply creating a space for colleagues to share their thoughts and feelings on Veterans Day. No workflow, metrics, no ROI. The blog was active for one day.

What a simple concept. What a powerful result.

Dozens of Hospira colleagues contributed. Parents sent wishes to children deployed overseas. Ex-soldiers gave shout-outs to comrades still in the service. People remembered parents who had served. Veterans explained when and where they had served. People recognized Hospira colleagues working with the armed forces overseas.

Most posts came from first-time contributors. All were personal. The cumulative impact was deeply moving.

In this age, especially in the technology business, it's easy to get swept up and carried away by the flow of work. I'm personally grateful to Hospira's Veterans Day Blog for reminding me once again that work is all about people.

 

(Photo credit: http://blisstree.com)

The Grassroots Myth

Call me crazy, but I'm going to attack another another social software orthodoxy: the Grassroots Myth.

The Grassroots Myth is my name for the notion that the most effective way to bring a new social software platform into an enterprise is through bottoms-up, viral introduction.

Like all good myths, this one is based around a central story. The details of the story vary from one company to the next, but the central elements are almost universal. It all begins with a single, junior-level employee who I'll call "Joe" (after Joe the Plumber, the "common man" immortalized by a bizarre moment in John McCain's presidential campaign). Joe is hard at work on a project or task that requires exchanging lots of ideas and content with colleagues across the organization. Joe sports an iPad and reads Tech Crunch daily. He's tech-savvy, but doesn't actually work in the IT department. Late one night it occurs to him that some sort of Facebook-, Wikipedia-, or Twitter-like collaboration tool could really help. So Joe does a little Internet research, finds a cheap or free hosted service, and --Voila!-- that very night he is up and running. He posts some content and invites a few colleagues. Then, as the commercial goes, he tells two friends ... and they tell two friends, and so on, and so on. Six months later, the whole company has adopted the tools and Joe is a hero.

It's a wonderful story: the little guy who transforms his company through the power of a great idea.

I wish it were that simple.

There are certainly Grassroots success stories out there, but they're the exception not the rule. The more common Grassroots experience is less rosy. Joe is working on his project, finds and sets up some collaboration software, and invites his colleagues on the project. His colleagues use the software to collaborate, and really like it. They tell a couple friends, but the friends are busy and not as tech-friendly as Joe. They like the concept, but can't quite visualize it. They ask Joe to show them, but somehow the meeting keeps getting postponed. Joe launches the tool with another project he's working on, and the same thing happens: the tool works great for the project, but goes no further. Joe demos the collaboration tool for his manager, Jane. Jane loves it and invites Joe to demo for the entire department. A few people ask Joe to set up accounts for them, but after a few days they misplace the login information and never go back. Joe continues to push the tool for his projects, and people continue to like it ... as long as Joe is leading the charge. IT gets wind of the project and expresses concern that company data is being hosted externally by an unapproved vendor. Joe gets accepted to Harvard Business School (having impressed the Admissions Committee with his essay on collaboration). Joe leaves the company, and the collaboration tool fades into irrelevance.

This does not mean that Grassroots adoption has no role to play. It does. It has a very important role. But not the one that people usually think of.

Let me distinguish between two types of Grassroots activity: Technology Grassroots and Content Grassroots.

Technology Grassroots -- sourcing a new technology, platform, tool, or application -- via the Grassroots is an exercise in confusion and frustration. You end up with multiple solutions, all competing for attention. End users are sent to lots of different destinations, apparently for no good reason. There's little or no integration with existing applications or data flows. Users don't know which tools will survive and which will die. IT is concerned about security, performance, and stability. Organizational silos are reinforced, not diminished. Worst of all from a social networks standpoint, the company's attention is fragmented across multiple tools, each of which struggles to achieve critical mass.

That's why most "Grassroots efforts" fail inside the enterprise. When it comes to social software, your technology can't be driven from the grassroots.

What you really want inside the enterprise is what I call "Content Grassroots." This is what happens when you have distributed content creation from the ground up. This is the community that spontaneously forms around a shared interest in pediatric medicine, the engineering team that decides a wiki is the best place to manage project deliverables, the sales manager who posts a photo in order to show a new demo booth to colleagues in other regions, the virtual conference that attracts hundreds of colleagues to a real-time brainstorming "tweet-up" on improving the customer experience.

This is the power of social software in the enterprise.

Ironically, the most effective way to empower your Content Grassroots activity is to provide a single, unified, integrated technology. Invite everyone in. Integrate with company Directory and Single Sign-On. Integrate with other enterprise applications. Make sure everyone knows that it's secure and it's not going away.

Then let them blast away.

Here's a simple way to say it: IT owns IT, and content owners own content.

Social Software Adoption: Why Good Companies do Bad Things

Why do good companies do bad things to social software adoption?

In my previous post, I listed 6 things that companies can do to stimulate adoption of enterprise social software. This advice ain't exactly rocket science.

• Make it your Intranet
• Make it the primary destination for must-have information
• Integrate with your company directory and, ideally, Single Sign-On (SSO) 
• Integrate with enterprise search
• Integrate with existing enterprise applications
• Launch to your whole company (i.e., skip the pilot)

And yet, few companies do them--even companies that are working very, very hard to stimulate social software adoption. Why is that?

One thing I learned as a McKinsey consultant is that organizational dysfunction is most frequently what causes good companies do bad things. So in order to understand why companies aren't doing the most 
basic things to stimulate social software adoption, I went looking for an organizational explanation.

I didn't have to look very far.

With a little digging, I identified three fundamental organizational failures that explain why companies are sabotaging their own efforts to roll out social software.

1) Technology under-investment. Many companies got into enterprise social software with cheap or free wikis, blogs, or other social software thingies that were thin on functionality, integration capabilities, and administrative tools. "This isn't about the technology," people told themselves, "it's about organizational behavior." That's true...but only up to a point. If you're rolling out to more than a hundred people, you need technology that can stand up to the needs of your organization. I don't mean just the "social" needs of the organization, but the business, administrative, and usability needs as well. That includes a comprehensive feature set like blogs, wikis, microblogging, corporate directories, groups, and social networking. It also includes back-end stuff like Directory and Single Sign-On integration, data security, technical scalability, and reporting metrics. Isolated point solutions without deep integration capabilities may be cool and fun to launch, but they won't take you far.

2) IT-Business Misalignment. With the trend towards Software as a Service (SaaS) and hosted solutions, many line executives think they can do this "without IT". I've even seen examples where an individual department or business unit launched a "secret" social software project that they kept hidden from IT. That may help "the business" get up and running quickly, but it's a sure path to adoption failure. You can't integrate with LDAP, make social software your Intranet, integrate with enterprise apps, or integrate with search without bringing IT to the table. Try to hide social software from IT, and you'll end up hiding it from your end users, too--no matter how hard you try to promote it on the down-low. Even if IT isn't driving the effort--even if IT isn't managing the service--they still need to be at the table, and committed to the project's success.

3) Innovation Marginalization. Because social software is innovative, companies sometimes think and talk about it in ways which marginalize it as a mere experiment. "This is a cool, crazy experiment. We're just going to put it out there and see what happens. In a few months we'll decide what to do with it." This messaging appeals to innovators and early adopters, but it turns off everyone else. Why should they invest time learning a system that might not stick around? Why should they build content and processes around something that could be gone next quarter? When you position social software as a core part of your company's technology capabilities, that's when your colleagues in the mainstream will pay attention and start to use it.

Taken as a group these organizational factors explain why companies set themselves up for social software failure. Are you having trouble achieving social software adoption? If so, take a hard look in the mirror. Which of these organizational failures apply to you and your company? And how can you fix them?