Want to Improve Collaboration? Close Your Email.

One of the most serious problems in organizations today is our (ab)use of email. There’s no question that email has fundamentally changed the way people work and how people collaborate. However, now email is often thought of as a scourge: leave the office for a week, come back to 500 emails waiting for you, of which probably 50 require action and 10 are very important.

In terms of communication, Email is usually the first resort. Sadly, that means that email is now also most people’s primary means of collaboration. But here’s what email collaboration looks like:

Created by Manny Wilson

Not exactly the cleanest business process. Not pictured is the person in the middle of the process: the stuckee given the unenviable task of aggregating all of the changes made in the various silos into the “master document”.

Here’s an idea: Try Something Else!

So, as a first step towards improving collaboration: don’t use email. Sounds simple, but of course the difficulty is in the execution. I’ll start with the why. There are several reasons that you should move away from email for collaboration.

• People get enough email: If you can contribute to your colleague receiving less email, I will guarantee you that they will genuinely appreciate it. So, rather than sending out another email to lose in the email, try using another platform!
• Email is not discoverable: To me, this is the most important piece. Email conversations are by definition not discoverable. So if I have a question, I could email five people; unless they forward it on, I am limiting my potential sources of answers. However, if I ask the question in a online, discoverable forum, I can still get the same 5 people to answer the question, but also add everybody else with access to the platform to the potential sources of information. As an added bonus, the knowledge gleaned from the discussion is then captured in a discoverable venue, rather than trapped in an email box.
• Email won’t help you bump into others: One of the great benefits of working in the open is that you can actually bump into people with similar work focuses and similar experiences. Working in a more open environment allows for fortuitous opportunities in order to expand social networks. And given that workforces are becoming more dispersed, this will likely become more important as face-to-face opportunities dwindle.

Executing

Let’s face it, it’s hard to get out of email. It’s been too successful in penetrating the business world. How many times a day do you have a face-to-face or phone conversation that ends with “I’ll type up an email summarizing what we just said”? Well, there are some good ways to start:

• Signal: Rather than sending out questions via email, post the question online and send out the link. It’s still an email, but the discussion and answers will be more discoverable to others
• Do Point-to-Point in the Public: We have a lot more means to talk point-to-point in public nowadays:  Wiki User Pages, blogs, Facebook, Twitter etc. Communicating on these is a good first step because they are all more discoverable then email.
• Get out of your comfort zone a bit: Working in the open is a new, weird thing, so it’s not unusual that you would feel strange doing this instead of email. But sometimes you just have to make the leap. Give it a shot.  As a colleague tells me, “If you aren’t out of your comfort zone, you aren’t doing your job.”

PS. A note about email notifications. Email works well as a notification for these other tools.  Getting an email that says to check a wiki page because it’s changed is inherently different from getting a document in an email, because you can delete the notification and know you won’t be missing information later.  If you get a document in an email, you will likely keep that email/document combo because you just don’t know if you’ll need to refer back to it.

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.

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!

What You Can and Can’t Learn from an Open Collaborative Workspace

One of my favorite parts about open collaborative tools is the ability to observe the evolution of collaborative projects.  Platforms like wikis, blogs, social bookmarking, and even discussion forums enable any observer to come in and view the history of any given article, compare versions, and review the progress and process of that page.  But at the same time, it’s important to remember that there’s a lot of work that goes into a collaborative projects that can’t be gleaned from simply watching the changes to wiki pages. So in the name of getting my thoughts down, here’s an incomplete list of some things that you can learn and what you cannot learn from outsider observation (I see some follow up posts to this topic in the future).

What You Can Learn

Who’s literally made the change to the page: You can certainly measure raw, quantitative participation: i.e. Justin has made 20 edits or has posted 7 blogs or has tagged 14 items with 24 tags.  This has a place in evaluating collaborative projects, obviously: in most cases of open collaboration, more participation is better.

You can tell literally what–qualitatively–a user has contributed to the project. The transparency of contributions means that you can see exactly who and when an idea or contribution was made.  So I can see that Justin added 2 paragraphs of content to the wiki page and 3 blogs worth of ideas today.  While this in isoluation is not really important, these contributions can be qualitatively evaluated.  Likewise, you can see who is playing a more facilitative or leadership role in projects.

Social Networks. Certain elements of social networks become visible when you look at collaborative projects in open environments.  Social bookmarks reveal who is tagging content for a project, thereby linking those participants.  Blogs with comments clearly link people to their thoughts, but also to the people behind the contributions at some level.  Similarly, you can discern the strength and weakness of links by looking at actual participation.

What you can’t learn

However, there’s a lot of work that goes into collaborative projects that goes unnoticed and undetected, even in an open collaborative environment.

Triggers, positive and negative.  One of the most interesting aspects of projects that is simply not visible to the outside are triggers for participation.  You may be able to literally see that a person who should be a prolific contributor only contributed once to a big collaborative project; however, what’s not visible is why they haven’t paricipated.  Technical hurdles? Lost interest? Managerial interference? Too Busy?

Rallying. As I’ve said before, collaborative projects require a good amount of leg work behind the scene in order to get off the ground.  So while some of these are visible–blogs, announcements in the wiki, etc–many are not.  Without actually engaging the participants of the projects, you cannot, as an outsider, understand the work done behind the scenes.  So I can’t tell that the project’s leader called colleagues on the phone from 5 different organizations, visited 3 seperate offices to build the network, and spent 3 hours talking to leaders face to face.  All of this activity is important to the success of a project, but it’s not really visible from the outside.

Ghosting Participants. Technology is changing quickly and some folks just can’t or don’t want to keep up with the latest developments and newest tools.  So, from my experience, many times there ends up being one “stuckee” from an organization or office that ends up doing the lionshare of the actual posting of information.  In this case, what looks to be a single prolific contributer may be 5 people’s contributions via a single point of entry.

The Key

As a consultant, nothing’s asked of me more than to provide best practices.  And the best practice for advising clients is that quite simply, you have to look beyond the numbers so that you can actually tell the story of the collaboration. Evaluating and understanding a collaborative success or failure not only takes leg work to track participation and contributions, but also to talk to the contituency, both active and non.

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.