• All Posts
  • Application Development
  • Customer Success
  • Enterprise 2.0
  • News & Events
  • Product Updates
  • Tips & Tricks
  • Posts tagged ‘adoption’

    Companies Aren’t Communities

    Companies aren’t communities. They aren’t forums.

    Companies are companies.

    Of course company life has community aspects, and those community aspects can be quite important in getting the job done. 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? Let’s look at 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:

    • Your company Intranet is social (i.e., built and/or integrated with social software tools like wiki workspaces, microblogging, and social networking)
    • 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 re-purpose their consumer-oriented products for the internal market.

    In the enterprise, we need to take a more pragmatic approach. As the old saying goes, “The business of business is business.” Social software fails when it tries to turn businesses into consumer-style communities. It succeeds when it turns businesses into better businesses.

    If a document falls in Sharepoint, and nobody hears it…

    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, with lots of different Sharepoint shops. People don’t go into Sharepoint because they don’t know what’s in Sharepoint. And when they do go into Sharepoint, it’s to retrieve not to collaborate.

    There are two problems here: lack of transparency, and lack of agency.

    First, transparency. If you can’t see what other people are doing, you can’t very well collaborate with them. Second, agency. Collaboration has many dimensions. It’s not just co-authoring a document (though that’s a good start). It’s a whole range of social activities around sharing, liking, tagging, rebroadcasting, etc.

    Sharepoint makes me think of a cocktail party where you can’t overhear guests who aren’t speaking directly to you, and can’t tell other guests about the conversations you’ve just had. 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 and agency.

    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 in the ecosystem like Socialtext. 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 make a sound–a sound which can be answered, amplified, harmonized, rebroadcast and, yes, very much heard.

    The Social Software 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.

    There’s something very right about the Grassroots myth, but also something very mistaken.

    Like all good myths, this is based on a heroic legend. 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. I’ll call him Joe, after Joe the Plumber, the “common man” immortalized by a

    Joe the Plumber, Grassroots Myth Icon Extraordinaire (Credit http://www.flickr.com/photos/38729188@N00/2987725752)

    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.

    It’s not quite that simple.

    There are certainly Grassroots success stories out there, but they’re the exception not the rule. The more common 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, and the company settles back into its (inefficient) email-based collaboration habits.

    What happened to Joe, and why do so many social software innovators cling to his myth in the face of real-world experience?

    I said before that there’s something very right about the Grassroots myth. That’s the content part. What you really want inside the enterprise is what I call “Content Grassroots.” This is 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 workspace 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 social software in action. This is where Joe really shines.

    A lot of people confuse Content Grassroots with another type of Grassroots effort which is less benign: 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 where our mythical Joe usually fails in reality. When it comes to social software, your technology can’t be driven from the grassroots.

    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 one way to put it: Content grassroots good, technology grassroots bad.

    Here’s an even simpler way to say it: IT owns IT, and content owners own content.

    Crazy? Obvious? Accurate? Stupid? Tell me what you think…

    Social Software Adoption: When 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.

    • 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 sear
    • Integrate with existing enterprise applications
    • Launch to your whole company (i.e., skip the pilot)

    This advice ain’t exactly rocket science. 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. I have met the enemy and, once again, he is us.

    Looking across  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 page from Pogo‘s book. Look hard look in the mirror. Which of these organizational failures apply to you and your company? What can you do to address them?

    How to Beat those Social Software Adoption Blues

    Does social software adoption have you singing the blues? If so, you’re not alone.

    In the enterprise social software world, everyone’s talking about adoption. There are breakouts on it at Enterprise 2.0. Lots of smart people are blogging about it. There’s a LinkedIn forum. Heck, there’s even a whole Council dedicated to it.

    Why is adoption such an issue?

    Most people blame their adoption blues on organizational culture. Eavesdrop on adoption conversations and you’ll hear things like this:

    • “Our culture rewards people for hoarding, not sharing.”
    • “People over 30 just don’t get social networking. Unfortunately, that’s exactly who we need for this to succeed”
    • “Middle management isn’t comfortable with transparency.”
    • “We have a culture of email that’s hard to change.”

    To borrow a phrase from always-quotable Dennis Howlett: What a crock.

    To borrow another phrase from the also-quotable Pogo: We have met the enemy and he is us.

    Social software adoption becomes an issue when companies impose their own barriers to adoption. Not cultural barriers, but operational barriers. They sabotage their own social software aspirations by making the tools available in ways that are guaranteed to frustrate all but the most determined users.

    I’ve said it before and I’ll say it again: enterprise social software gets adopted when it’s placed in the flow of work, rather than above the flow of work.

    I get a lot of nods when I say that, but most enterprise social software tools live very much outside the flow of work. It’s almost as though the company is trying to keep them as far away from the flow of work as possible. I’m not talking about complex workflows or business process engineering. I’m talking about dead-simple, nuts-and-bolts usability barriers that stand between a typical employee and enterprise social software adoption. Take a clear-eyed look at most social software implementations and you will likely find that:

    • It’s yet another place to go for information
    • It’s not required to get any job done
    • It requires an additional login and password
    • It’s positioned as a pilot, so everyone sees it as temporary

    Given these barriers, it’s no wonder companies are disappointed with enterprise social software adoption. It’s almost as though they’re going out of their way to prevent their employees from using social software as a real work tool. It’s like they’ve invited their company to a fantastic party with great food, fantastic drinks, and a killer band. But they’re throwing the party miles away from the office in a place no one has heard of. They’re not providing transportation, nobody has a map, and there’s no GPS coverage. No wonder people aren’t coming.

    If your social software implementation isn’t getting widespread adoption, ask yourself which of these applies. You’ll probably find that at least half of them do, maybe even more.

    The good news is that these things are pretty easy to change. They’re not big, abstruse, concepts like culture, psychology, generational mindsets. They are straightforward implementation decisions, many of which may be under your control.

    Let’s get specific. When I compare Socialtext customers who struggle for adoption to those who achieve mind-blowing success, the difference comes down to a few simple, actionable best practices:

    • Make it your Intranet. This is the single biggest thing you can do to drive adoption.
    • Make it the primary destination for must-have information: HR Forms,
      the company directory, new hire information, IT support requests, C-level blogs. That’s honey which attracts people to your site–even
      people who aren’t tech early adopters.
    • Integrate with your company directory and, ideally, Single Sign-On (SSO). People are busy. If you require an extra login prompt or worse yet an extra password to manage, you’ll lose a lot of them–upwards of
      50%, according to some Socialtext customers
    • Integrate with enterprise search. This one’s pretty clear, but it’s remarkable how few companies actually do it
    • Integrate with existing enterprise applications. When social software provides a window into other enterprise applications, it moves
      to the center of your company’s flow of work.
    • Launch to your whole company, not a small subset. Take a look at my earlier post on why you should Skip the Pilot.

    Companies that follow these steps are doing everything they can to drive their employees to social software, rather than away from it. The results are striking. I predict–and this is probably conservative–that you’ll see a 2x – 5x increase in adoption when you implement these changes.

    So which category are you in? Are you driving employees to social software, or are you driving them away?

    About This Blog

    Weblog on gaining business results from social software.

    On this blog, Socialtext staffers and customers explore how companies can gain the most business value from their use of enterprise social software, including microblogging, social networking, filtered activity streams, widget-based dashboards, blogs and wikis.


    Find us on Facebook


    Recent Posts

    Recent Tweets