Twitter and the Search Barrier

I am currently reading Collaboration: How Leaders Avoid the Traps, Create Unity, and Reap Big Benefits, a book by Morten T. Hansen of Harvard Business School. It is an interesting read so far: he has laid out some of the key benefits and risks to collaboration, a number of which are quite interesting and potentially useful. However, what I have found most interesting thus far is his take on the four most significant barriers to collaboration. His list:

1. The Not Invented Here Barrier: People not willing to seek input from others outside their unit;
2. The Hoarding Barrier: People not willing to provide information for others outside their unit;
3. The Search Barrier: People are not able to find people, expertise, or information easily, and;
4. The Transfer Barrier: People are not able to transfer complicated knowledge from one unit to another.

All of these points have some validity, and are definitely important and significant barriers to collaboration in the workplace; however, I want to spend some time with the third barrier, the search barrier.

As a side note, I have as yet not read how Hansen proposes to overcome said barriers; I’m only halfway through the book.

What is the Search Barrier?

According to Hansen, the search barrier is the inability of a company or organization to “know what it knows”. This can be due to a number of factors: company size, physical distance, information overload, and poverty of networks are the ones that Hansen cites. The search barrier is one of the most significant hurdles facing large organizations: think about all the expertise and experience that exist in most organizations, and how hard it really is to tap that knowledge (specifically the tacit knowledge). Basically, it’s too hard or too much work to search through your organization to find the support/input that you need; consequently, organizations are inefficient because they are continuously solving the same problems.

So what does this have to do with Twitter?

It's about finding the RIGHT person, not just people.

In the spirit of continuing to treat Twitter as a solution searching for a problem, I think that this is a very real business problem that can be greatly helped by microblogging. After all, this is one of the most appealing, at least for me, uses of Twitter on the open internet.

Twitter actually addresses many of the key problems cited by Hansen as components of the search barrier.

• Company size could be less of an issue, if only because the network of followers (a.k.a. the target audience) serves as the filter of information. So you aren’t searching all the units of an organization for an answer; you are asking people to serve as a filter and pass on information and/or people that they already know.

• It’s clear that microblogging helps with bridging distances. However, it’s also important to note that microblogging enables “weak ties“, allowing for people to maintain relationships that may become more important in the future.

• Though relatively counter-intuitive, microblogging can help with information overload, because your network serves as a collaborative filter. For the same reason, microblogging can help solve the problem of poverty of networks by making it easier to keep in touch with colleagues.

But microblogging is just a technology

In much contrast to the rest of this entry, I do want to emphasize that simply having the technical capability for microblogging does not ensure success: effective deployment also entails organizational and process challenges in order to achieve the desired results. Social media success is only sometimes about tools; most times it’s more about changing behaviors and inculcating more collaborative mindsets.

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.

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.