Link it All Together

When thinking about the power of virtual collaboration, the emphasis is usually on creating opportunities for collaboration between geographically dispersed groups. And rightly so: virtual collaboration’s most significant asset is that it enables groups that would not be able to collaborate (at least without re-locating) to work together.

However, there is another feature of virtual collaboration that is also empowering, even for teams that are co-located: the ability to hyperlink content, enabling the fusion of information in a meaningful sense. Think about Wikipedia, and why it’s so much easier to browse than a traditional encyclopedia: it’s because there’s just so many available links in a given article (so many in fact that you rarely have to use to the back and forward buttons on your browser). And there are clear lessons to be drawn for collaboration in a professional environment from this practice.

More than Search Engine Optimization

Links do more than provide “Google juice” (admittedly, however, this is important, especially as more and more organizations are turning to Google to power internal enterprise search).

• Links provide context: Links have the distinct benefit of allowing people to read more information if they choose and/or need to do so. So again, thinking about Wikipedia, if I want to get some quick background about a given topic, I can go there and read just that article. However, if I want to get a bit more context, I can read through the given article, as well as a few other key articles that are linked to the main article that I’m interested in.

• Links assist in the analysis of data: Given all of the hubbub around link analysis (and social network analysis), hyperlinking content together helps to further analysis. Again turning to Wikipedia for an example, you can look at all of the articles that link to a given article. I can see the hundreds of articles that link to the article about Steve Jobs, for example: on that list are a number of connections that I never would have thought of that I can explore: Why does the “Walt Disney Company” link there? What’s the relationship between Jobs and Larry Ellison?

• Links help to bridge gaps: An especially valuable use of hyperlinks is to bridge gaps between collaborative constituencies (a topic that will be the topic of the next post…). In the professional world, collaborative environments are usually segmented and walled off by specific job functions/types (i.e. different Sharepoint sites or team rooms). It’s true in almost all organizations: accountants work in a different collaborative environment than consultants; developers use different collaborative tools than marketers; and, FBI agents don’t work in the same environment as intelligence officers. However, links can help to break through these walls, primarily by linking to content outside of the walled confines of more limited environments. Linking to this content makes it helps people think more strategically and enables more collaborative thought, while also being a strong alternative to pulling content into closed environments (making content more discoverable).

Tying it all together

Linking is a simple, yet under-utilized tool/technique: most times, out of laziness, constrained time, or other reasons, we produce digital content (be it an email, document, or other) and don’t use the power of linking to it’s full extent. Linking gives us the power to enable our audiences to be as smart as they want to be, while also enabling us to demonstrate diligence in research and knowledge of key sources. Put simply, linking is, in many ways, what drives discoverability and integration of information in a digital environment.

Part 3: What’s in the workflow is what gets used

Note: this is the third blog in a series reviewing each of the 6 pieces of the McKinsey Article “Six Ways to Make Web 2.0 Work.”

McKinsey’s third recommendations is “Participatory technologies have the highest chance of success when incorporated into a user’s daily workflow. ” Of all of the recommendations delivered in this report, this one I believe is the most important, yet most often overlooked recommendations that one can give regarding the implementation of Web 2.0 in the workplace. Web 2.0 in the enterprise already suffers from a stigma: “it’s not real work”. And, quite frankly, people have enough work to do without adding wiki contributions and writing blogs to the equation.  If you are going to deploy new tools (at least successfully), it is crucial that they be connected back to “real work” and not just added to the pile.

The Stigma

While most new tools have the difficult task of having to prove their worth over the tools that they replace, Web 2.0 tools in the enterprise have the added weight of being associated with the tools on the open Internet, knowing only horror stories and that these tools are largely by employees’ children. When you add this stigma to the fact that it’s just seen as another thing to do in a long busy day, it’s hard to escape the illusion that Web 2.0 is just a new way to distract employees from their job.

It’s about replacing processes

In order to fully realize the value of Web 2.0 tools in the workplace, people have to use the new tools to actually do their work. If you just impose the wiki as another duty, adoption’s going to be low. This is the classic problem for knowledge management platforms: It’s easy enough to contribute, but it still requires people to do extra work, so you get less than ideal adoption.

This means during the roll out, the benefits of a wiki need to be communicated to the workforce: How can it help them do their job significantly better and/or faster? How can social bookmarking help reduce email and improve people’s access to information?  How is wiki collaboration better than collaborating via email?  While the previous recommendation stated that organizations should let users decide the best way to use the new tools, organizations will need to communicate the realm of the possible to the potential audiences. The goal should be to inspire users to change the way they do their jobs.

McKinsey’s take on Web 2.0 – The first in a Series

Perhaps the most read, circulated, and probably influential Web 2.0 publication of 2009 so far has been McKinsey‘s article “Six ways to make Web 2.0 work“, by Michael Chuil, Andy Miller, and Roger P. Roberts. I have read this piece with great interest and feel that I needed to organize my thoughts on this paper. Hence, a blog series is born: Over the next few posts, I will muse about each of the six techniques suggested by the author as important to making Web 2.0 work in the enterprise. First up: Leadership.

The transformation to a bottom-up culture needs help from the top.

I find that this is one of the more hotly debated topics around change management: does change come from the bottom or from the top? Of course the answer is that change really comes from both the top and the bottom. In my mind, change often comes via pressure and innovation from the bottom, eventually requires buy in from the higher levels of leadership. The opposite happens as well: leaders have innovative ideas or see strategic opportunity and begin to sow the seeds of change in the base. Put simply, change needs champions at all levels.

Change, leadership, and Web 2.0

In this case, the article is right on. “Build it and they will come” in Web 2.0 is almost always a failure. And leaders who are willing to be champions for Web 2.0–especially with other senior leaders–are also key to the success of a Web 2.0 implementation. Similarly, the first step towards Web 2.0 implementation is almost always a small, bottom-up effort: everybody needs proof of concept and pilots before jumping in with two feet.

Indeed, a lack of perceived leadership support is often cited (in my experience) as a key hurdle for adoption. However, while the article talks about how senior leadership is important, I think that perhaps leadership at other places in the organization is equally important. This includes everyone’s favorite villain, the middle manager: leaders need to ensure that these folks are in the know about social media initiatives and understand where they fit into flatter organization.

Perhaps surprisingly, I think that Web 2.0 implementations are most dependent on leaders and champions at the working level. Web 2.0 requires that working level people, who are likely to benefit most from collaboration and working transparently, clearly understand and talk about the benefits of Web 2.0 amongst themselves. And for this to manifest itself effectively, working level folks have to take it upon themselves to champion Web 2.0 and share their lessons with their peers. This is mainly due to the inherent credibility with the working level, which senior leadership might not have.

The takeaway is this: success in Web 2.0 in the enterprise is dependent on having leadership through all levels of an organization. It’s not about the top, it’s not about the bottom. It’s about the whole organization.

Technical Solutions to Management Problems

Another of the most common issues I hear as a collaboration consultant is that managers are worried about people wasting their time with social software, effectively implying that their workers will be less productive because they will be gardening, blogging, or messing around with social networking sites. However, to me, this issue is closely related to the issues highlighted by Chris Rasmussen over at Brian Drake’s blog:

If someone posts an inappropriate poster on the wall, you don’t ban the wall. You discipline the person.”

To me (as I commented on Brian’s blog when it was reposted), I think that the issues of inappropriate content and “time wasting” are unfairly associated with social software, as if they are new problems. Instead, people are just hiding behind these issues instead of engaging in actual conversation about the costs and benefits of social software.

Not a New Problem

Here comes a shocker: people wasting time at work is  not a new problem.  People have been reading the paper, playing office sports, making personal calls, etc for a very long time.  The Internet has long been the target of all sorts of campaigns as a time waster… but there’s really no conclusive studies on the internet and productivity.  But lots of stuff like this …

Not only are these problems not new, they are actually better handled in social software environments, because of the transparency. So while someone might spend all their time doing crossword puzzles or reading sports news or sending personal emails, it can be hard to detect that activity. However, social software makes it easier: if someone’s playing on Facebook all day, you can take a look at their profile and activity and see that they wrote on 24 different people’s wall this afternoon. Likewise, if productivity is falling and you notice they are working in the wiki a lot, you can look at the contributions to see that he/she isn’t just gardening or creating frivolous content.

The Bottom Line

At the end of the day, managers should not fear social software applications; they should learn about them and work to understand how they can help their employees qualitatively improve their work using these new tools. After all, I advocate social software as a better way to do something, not as a cure all (so if it’s not gonna help you, don’t force it…) . It’s important that leaders understand benefits (not just the risks!) of social software and how it can improve productivity and quality of work.

Are people already rewarded for collaboration?

One of the most interesting and debated topics in my line of work is how to reward people for collaboration and/or participation in Web 2.0 efforts. This topic is worth books in itself (and many, many individual posts that perhaps I will write in the future…), but I want to explore whether this whole problem could be avoided. This is crazy, you say: you have to incentivize workers in order to actually get them to collaborate or use Web 2.0 technology. Or you have to write it into their performance objectives.

Or do you? My theory, I submit to you, is that this is unnecessary. Why? Because collaboration is a means, not an end.

Craziness?

You have to incentivize collaboration and participation in Web 2.0 in order to get people to play, right? NSFMF! There’s gotta be a benefit in collaboration that is self-evident to the people participating. Blogging, using a wiki, or social bookmarking may be inherently public/crowd-sourcing activities; but participation by good will is not sustainable. There has to be a return on investment. This is why collaboration by mandate often doesn’t work well, because people see it as “another duty as assigned” and more work, rather than part of their actual job.

Perhaps think of it this way: prior to Web 2.0 technologies, did you really write into your performance reviews that you drafted products in Microsoft Word or worked with your colleagues via email, instant, messaging, and face-to-face meetings? Not so much. Likewise, a communications professional shouldn’t get rewarded for blogging; he should get rewarded for communicating. An intelligence analyst shouldn’t rewarded for making wiki edits; she should get rewarded for high quality intelligence analysis. Collaboration and Web 2.0 are just two ways that help her get to a higher level analysis. Collaboration is a skill, like writing, research, and presenting: it’s to be developed and honed.

The Ends Justify the Means

Take a moment to think about why you work with others. Ideally, it’s not to check a box. It’s to search for new ideas, get sanity checks, and find different points of view on my work and thoughts (or provide such services out of reciprocity or sense of mission). I do these things because I want to produce something that’s better than I could do alone. No matter how smart I [may think I] am, I’m not smarter than my network. Let’s face it, nobody’s smarter than all of their network. Isn’t that the whole point of this Web 2.0 thing?

Collaboration is an input. It is one of many. At the end of the day, people in knowledge work are rewarded (in a perfect world) for the quality outputs. The point of this entry is not to say that collaboration shouldn’t be rewarded: it’s that collaboration is already rewarded. It’s rewarded because the final output should be that much better if you’ve collaborated with outside peers.*

*Granted, this is of course dependent on having managers who are able to account for said improvement in quality of output…

Social Media and Knowledge Management

I’ve been thinking about social media in terms of knowledge management as of late (a common theme when discussing Web 2.0 in a business/organizational setting). In a seemingly only tangentially note, I awoke yesterday morning and this was one of the first Tweets that I saw from @RichardDennison:

“Social media is people telling their stories” – Steve Crescenzo (@crescenzo)

My response was “I like that characterization of social media. I would also say that social media is about adding context”. Seeing Richard’s quote helped me think in a different way about what knowledge management looks like leveraging Web 2.0 technologies.

I think what distinguishes Web 2.0 technologies from traditional hosted knowledge management repositories is that Web 2.0 platforms over a greater window into process. In other words, Web 2.0 offers context, while KM repositories generally only store finished products.

Knowledge Management as a Byproduct

The advantage of working in a web 2.0 environment is that knowledge management comes at no additional cost. However, “working in a web 2.0 environment” is a difficult concept: in an ideal case, this actually requires transferring processes out of closed channels like email, Word, PowerPoint, etc (i.e. comfort applications) into the web environment. If you build your knowledge in the wiki, you can trace a product from the earliest stages to “finished” product.

Conversely, traditional repositories depend on users taking the additional step of submitting finished products for approval and inclusion in an officially vetted database. These products will exist with perhaps only a paragraph of context and a line of contact information (though probably the information of someone 2-3 working levels above the individual who actually produced the product).

An Example: Wikipedia and Knowledge Management

As a bit of a concrete example–that may require only a bit of imagination–we can take a look at the Luc Bourdon article on Wikipedia. Imagine that this article is a finished product sitting in a KM database: it’s a Word document probably accompanied by the opening paragraph as context/summary.

Now, let’s take a look at what we learn because this product is NOT actually in a KM database. You get the same content: that same finished product that can be read in a hurry if you don’t care (or don’t have time to care) about the process. However, there’s just so much more available. For example, I can see how this article started. I can also see it on landmark dates, like the day that Bourdon tragically died. And I can see what’s changed in the month of March. On top of all this, I can also see what was addressed during the Wikipedia Featured Article process by taking a look at the discussion page.

The takeaway

Asking a guy who’s a year away from retirement to sit in front of a computer entering his knowledge into a wiki is not an optimal solution (though apparently does work sometimes). Building products in a wiki is a fantastic way to capture institutional knowledge and a great amount of context around it. Web 2.0 tools–not just wikis of course–are a fantastic tool that allows knowledge capture, public thinking, and tracking the evolution of ideas over time when the work is done in public.

WikiCities

One of the things I’ve learned over the last two years is that how to spot a wiki effort that isn’t going to have any real transformative effects. This is not to say that these uses aren’t “successful” on a micro-level, as ultimately client/implementing organization may just be looking for a simplified way to get content to the intra or Internet. However, I have learned–from others and through my own experience–that groups that see a wiki as a way to get their content out–i.e. build a website–simply aren’t likely to achieve any change that is remotely transformative.

Hosting Organizational Pages

One of the people who has written about this topic before is Chris Rasmussen, a social software evangelist and trainer/knowledge management professional at the National Geospatial-Intelligence Agency. Ultimately, it boils down to an organization wanting to use Web 2.0 primarily as a way to publicize their activities. So one common variety of this is to build an organizational website in a wiki. This can be useful of course, but let’s face it: you aren’t trying to collaborate or engage people, you are using the wiki as a geocities service, and if your organization had a geocities-like service, the word wiki probably wouldn’t be in their vocabulary.

So What’s Wrong With This?

At the micro-level, nothing is wrong with this. Websites fulfill a very real need of making information available and searchable. One group’s wiki-website isn’t going to cause any real issues. However, this is precisely the tragedy of the commons: one violation (or bad example) doesn’t hurt anybody, but when every group and team has their own wiki-webpage, the wiki starts to look a lot like the rest of an organization’s intranet: compartmented sites that are siloed from the rest of the organization, which nobody is going to traffic because people don’t know how to look for it.

I think we all know how useful most people find their corporate intranets.

Missing the Boat

The other problem with the proliferation of organizational wiki-webpages is that it makes it much harder to use the wiki for mass collaboration: people won’t often stray from their own turf, instead inviting users to check out their organizational page. As a result, information remains–for all intents purposes–compartmentalized and unintegrated.

The other half of this effect is that groups end up seeing the wiki in the wrong way: As a a faster horse rather than a car. Yes some of the power of the wiki is that it’s web-based, but the real transformative piece of it is that it simplifies mass collaboration for the purpose of creating an integrated network of knowledge. And when groups decide to reproduce a 90s era websites (and that’s really all you can do with a wiki), what it does is suffocate loosely organized, large scale efforts at knowledge creation in the wiki by obscuring real innovation and collaboration . In my mind, this is a tragic outcome.

The Right Tool for the Job

In my experience working with social media and collaboration tools, people often claim—perhaps fairly, perhaps not so—to be overwhelmed and confused by the tools available to get the job done. “First you wanted me to contribute to the knowledge management system, then you wanted me contribute to the wiki and start a team blog. Now you are asking me to participate in (insert x technology, platform, or initiative here).” Get it all the time. Without fail.

But to twist a phrase a bit, I’d prefer having enough tools in my toolbox to do a wide variety of tasks. You can’t really use a screwdriver to hammer a nail, nor can you use a saw to drill a hole. So why do we insist on thinking that just one collaboration tool is enough to fit every problem? Rather, it comes down to helping people understand how to select the proper tool or tools (yes it often takes more than one) to succeed. I think there are three key factors to question when considering collaboration venues:

Where’s your audience? Readers of this blog will know that I think that rallying participants is key to collaboration. But, you can’t organize a party without picking a venue that people can actually get to, right? Considering the proper environment is absolutely crucial for tool selection for this reason. Working in an eRoom on your corporate intranet doesn’t really work if you want to work with people outside of your organization who aren’t going to be able to get to the site.

What’s your goal? A second and equally important question when considering what collaboration tool to use is to determine what your goal is. Are you building a house or digging a hole? Are you drafting a document with 10 other people in 5 time zones or is your team creating a library for new hires? Different tools have different strengths, period.

How open can I be? Privacy and security are key concerns in this age; everyone knows that (though often people will hide unnecessarily…).  So for a lot of collaborative projects, there are real issues that need to be considered when selecting the venue. Just like the CIA isn’t going to collaborate on Wikipedia (that’s why there’s Intellipedia…), organizations have real reasons not to work in the open, even behind their own firewall. Personal Identifiable Information, legal concerns, etc are real and need to be considered when selecting a venue.

So What’s the Best Tool for the Job?
I think that equipped with these key questions to consider and a technology-agnostic approach to tool selection (come on, at least TRY to be objective) paired with a decent knowledge of the available tools, can help collaborators make informed decisions about where and how to collaborate.  Short of that, it’s just not possible to make a blanket recommendation: after all, you know what you do better than I ever could!

Dude Where’s Your Crowd?

A colleague of mine posted a Facebook status update that got me thinking:

Kristen is appreciating the difference between “crowd sourcing” and “crowd building.”

Now I’ve thought about this idea before–frequently, actually–but had as yet not gotten down to putting some of my thoughts down on digital paper.  However, I think that it hits on a key problem that most people ignore when they are trying to collaborate inside a large organization, even with an open collaboration environment like a wiki.  I think one of the things that gets lost in the Web 2.0/Enterprise 2.0/Social software movement, especially in the enterprise, is the social networking aspect of open collaboration.

Preparing for Battle

A quick, generic example: a person gets often get energize by the idea of “crowd sourcing” or working in the open.  Perhaps they read Wikinomics or had a discussion with a blogger or heard about Twitter.  In my own experience, it’s someone that’s heard about another group who has successfully collaborated using a wiki.  However, people will too often try to charge forward into the execution phase of a project without properly preparing a social network or rallying their collaborative constituency.

The best practice, in my experience at least, is that there needs to be a distinct “rallying” phase of any collaborative project.  During this phase, project leaders and facilitators have to get the social network in place to support the effort.  This can mean building a new social network where there was none before–a challenging feat–or “activating” a latent social network that was built previously–the preferable option.

Comparing the two approaches to rallying for some reason reminds me of buidling alliance in War Strategy games like Civilization III:  it’s much easier to build alliances with others when you are at peace than when you are war.  Translated into collaborative projects, it’s much easier to connect with new people based on potential common benefit than by trying to get them to do extra work.

Enough with your Rambling and Nerdery!

The underlying point of this post is to point out that when trying to build a collaborative constituency around a given problem, hope is not a strategy (a subject of a future post perhaps).  It takes work to get a collaborative project together.  It may take kickoff meetings, phone calls, parish calls, blog posts, emails, tweets, etc to get the word out to your community; however, successfully tackling a collaborative challenge should make all of this extra leg work worth while.

A Converted Skeptic is a Powerful Thing

Pre-S: I am at training this week for my firm.  I hope to post daily, but I unfortunately can’t make any promises.

I would think that most people who have actively fought the social-software-in-the-enterprise battle will tell you that we are really in the business of evangelizing.  It’s sad to say, but really what we are doing is akin to building a religion, winning over one convert at a time.

So last might, I heard a motivational speaker-type and he said something that caught my ear: A converted skeptic is a powerful thing.  And I don’t think that this applies to anything in business more than it does for social software in the enterprise.  As a trainer/blogger, I like to think that part of my job is to win converts; and yes, I often get people in my trainings that are just there because they are told to show up, not because they want to learn or perhaps change the way they work.  However, and I think many will agree, if you can manage to convince just 1 in 10 or so of these folks that social software is worth a shot, I believe that I’ve had a successful session.

So, I suppose Lipkin did his job.  I’m now motivated to take these people on in a conscious way.  Bring on the skeptics and I’ll try to send you away an enthusiastic believer.  Nobody tells a better story than the guy who can start, “Now I’m a major convert and I thought this stuff was all crap”.  Because in the end, I’m not going to be able to talk to everybody about social software (and since probably only about 10 people read this blog, none of which are in my organization), so I need to train an army of social software believers to do the evangelizing for me.