Social Software Adoption: Why Law Firms Get It Wrong (and How to Get It Right)

I had a great conversation recently with Headshift's  Penny Edwards and Jon Mell. We were talking about social software adoption patterns in law firms--a topic over which a lot of digital ink has been spilled lately. Our conversation helped me connect some dots. I've blogged them here, and I also encourage you to check out the musings of Penny and Jon, both of whom are active on Twitter and their own blogs.

So here's my perspective on social software in law firms: Most law firms take exactly the wrong approach to social software rollout. They try to "chip away" at social software implementation by starting with "easy" use cases like know-how. In my experience, however, firms are most successful when they introduce social software right into the heart of their business: Client-specific collaboration.

Social software can deliver 3 main patterns of use and value to firms:

• At the most abstract level, there is general legal know-how: how to be an effective lawyer, how to serve clients, etc.
• At a mid-level of abstraction, there is practice-specific legal know-how: deal templates, legal opinions and perspectives, standard processes for due diligence, strategic perspectives on client industries and/or functional topics
• At the most concrete level, there is client-specific collaboration: collaborating within legal teams (internally, with clients, or with co-counsel) on specific projects and deliverables.

Most law firms introduce social software beginning with general legal know-how. The first decision-makers in a firm to "get religion" on social software are usually in firm-wide knowledge roles: CKOs, directors of know-how. They pursue general legal know-how because that's their organizational jurisdiction. It's the aspect of the firm's activity for which they are responsible. The more enterprising among them will partner with a specific practice or two, usually by tapping an obliging Professional Support Lawyers (PSL), to launch a social software pilot within a specific practice or two.

From an adoption standpoint, however, general know-how is usually a bad place to start. Lawyers are incredibly busy, and general know-how lies squarely above-the-flow of their daily work. Because lawyers lack incentives to contribute their knowledge to the rest of the firm, invitations to participate in social software implementations are often greeted with a polite "Thanks but no thanks."

A more effective place to introduce social software into law firms is at the most concrete level, with client-specific collaboration. We've seen this take a number of forms. One firm we've worked with is collaborating with co-counsel on a major piece of anti-trust litigation. Another is using social software to create information hubs for their largest and most strategic corporate clients. Still another is using social software to power lightweight virtual deal rooms which are more user-friendly than the virtual deal rooms retrofitted on top of their document management system.

These client-specific use cases are generating real, sustained adoption from the same busy lawyers who won't share know-how on blogs or wikis. What explains the difference?  Collaboration use cases appeal to the self-interest of the firm's partners. Partners are inundated with emails containing document iterations. Reconstructing a document's history from email threads is much more difficult than going to a single place where the history is laid it for you. Once partners see the value, associates and paralegals are easy converts as well. We're even starting to see clients getting in on the act by asking counsel to deliver documents via secure extranets.

Successful law firms will ultimately realize all three patterns of value: general legal know-how, practice-specific know-how, and client-specific collaboration. But it's client-specific collaboration, not know-how sharing, that is the lead "bowling pin" on adoption. When a firm starts using social software for its client-specific collaboration, its lawyers become comfortable with a new set of processes and behavioral norms: distributed publishing, linking, tagging, blogging, etc. These new behaviors open the door for these same lawyers to share their know-how at both the general and practice-specific level.

If you're a legal CIO or Director of Know-How, I'm advocating an approach that's probably different from the one you've been pursuing. To introduce social software in a way that will stick, you need to start by convincing your most daunting audience: the partnership. It doesn't need to be the entire partnership. What you need are a few partners willing to try social software because they recognize the personal value of streamlining client-specific collaboration. Recruiting those partners may cost you time in the short term, but it's the surest way to transform your firm.

Comments

[Penny Edwards]

Great post Michael. The (anti-)patterns you describe go along way to explain why many knowledge intensive organisations (not just law firms) stumble during the adoption process. Whilst there can be a level of formality within each of the levels you describe, the higher the level of abstraction the greater the barriers to participation in the form of perfectionism, authority, sign-off and lack of time.

These stumbling blocks bring to mind the story of Wikipedia's false start (i.e. Nupedia). In a nutshell, Nupedia was hamstrung by efforts to formalise the contribution processes to ensure quality, which included establishing editorial policy guidelines and processes for the creation, review, revision, and publication of articles. Once the stringent levels of control were lifted contributions flowed.

Wikipedia is often used as a prime example of a 'knowledge base'. But I wonder how often people reflect on its origins and how processes and controls had to be altered to encourage contributions.

For instance, looking at the client-specific collaboration level, we see that people are using the tools to help them get their jobs done, and are doing so at a more informal, conversational level. It is from those daily interactions and exchanges of information, ideas and expertise that people also learn. I think this has clear implications for engagement and contributions at the other levels, and the amount of control that is exercised over the process in general.

[Chris Rasmussen]

the US Intelligence Community is struggling to get past the wiki as knowledge base too. Intellipedia is mostly used at the margins. "Finish intelligence" (a report with a logo on it) is still king. How long can we "think out loud" and continue to paste social tool conversations into agency-specific production system?

One of the most tiresome counter-arguments is "our customers" demand X so we can't change. Follow-up with the question, name 10 people, and you get crickets. This caricature of what people want is often a projection of their likes and dislikes of how to receive information and control of the process.

We need to cut to the heart of the business and use a "living intelligence" model. There are several units working similarly to the examples of client-specific collaboration you listed but at the 50,000 level most social tools are viewed as adjunct to the "official" process.

[Doug Cornelius]

Michael –

I both agree and disagree with you.

I agree that the general know-how ends up as an encyclopedia that requires updating “above-the-flow” and is less likely to get lawyers engaged.

I agree that incorporating social software “in-the-flow” is the best use and the better way for law firms to operate. (Actually, I whole-heartedly agree with this).

I disagree that know-how is a bad place to start. I think starting with know-how offers a few advantages and starting with a client relationship has some disadvantages.

First, by getting the know-how in the platform, that information, that knowledge now becomes much more findable. The number one complaint I hear at law firms is that they cannot find the information they need. When we started “wiki-fying” our know-how and other content, you could now find that stuff very quickly. That gives you a quick win and an easy 10 second demonstration of the power of social software.

Second, know-how is less mission critical. Essentially it can be a sandbox for the lawyers to learn how to use the tools. I have lawyers less likely to try something new in front of clients. By injecting it into a mission-critical place as a shared resource with a client, failure now has severe consequences.

Third, lawyers do not really collaborate with clients. They work closely with clients, but they do want to share interim drafts that come along with wikis and social software. (I wrote some about the behaviors in this published article: http://dougcornelius.com/files/Wikis_and_Document_Management_Systems.pdf)

Fourth, lawyer-client extranets are largely unsuccessful. I championed them for years, but they rarely worked. Perhaps using a social software platform would change that, but I am skeptical. The challenge is getting both the lawyer team AND the client team to learn the tool and change the way they communicate. That is a big challenge.

Now I am not saying that these are set in concrete and will never change. I think we are just ahead of the adoption curve.

I found a great use of the social software was managing an internal legal team. Instead of running the transaction process through a word-based agenda that gets emailed to the internal team, I moved that process to a wiki. It collapses three processes. Before, it was find the word document, edit the document, and then email the document. With a wiki, finding it is easier. Editing and emailing is collapsed into one process since the wiki automatically sends out the update to subscribers. The other benefit is that the wiki is kept more up to date than waiting for the next email to come around.

The plan, before I left Goodwin, was to eventually roll this process into an extranet. But only after the internal team got very comfortable with using the tool and could explain it to the client.

Your proposal makes adoption twice as hard, requiring a CIO to convince the lawyers to use the tool AND convince the client to use the tool.

[Michael Idinopulos]

Doug, great comments. I agree with you that collaborating directly with clients is probably not the place to start. By "Client-Specific Collaboration" I didn't necessarily mean that the client would be directly participating (though that is the most extreme form), but just that legal teams would collaborate directly on the delivery of billable client work. Your internal legal team example reveals a great step-up use case: In-the-flow collaboration on work that's less high-stakes than direct client service.

[Michael Idinopulos]

Chris,
That's a really insightful point about Intellipedia. We experienced the same dynamic when we introduced wikis to McKinsey & Company. The natural next step for the intelligence community would be to launch small-scale "grassroots" collaborative workspaces at the project, team, and/or department levels. The only catch is, "Intellipedia" isn't the right brand and the folks who live for Intellipedia's openness may cry foul. They need to understand that team collaboration and public knowledge-sharing are very different use cases. Both are valuable uses of social software, but they require different norms and processes.

[Gordon Vala-Webb]

I would suggest that collaboration between team members (including from the client side) is different than social computing / networking. In collaboration you have a defined, limited, group of people who are told to work each other and are working on some sort of shared outcome. In social computing anyone (largely) can participate, people can come and go as they will, and there is no shared outcome (only the sum of the individual outcomes). Different contexts, different outcomes, different kinds of value.

[Sean_mcdonald]

These are some brilliant points and very well articulated.

Another use case for information management, inside of law firms, is the management of "network intelligence." In other words, "who knows whom and how."

An example of where this goes wrong is the business development manager in a law firm spends days, sometimes weeks, trying to figure out who can make an introduction to a specific company -- a potential client. What he or she didn't know is that one of the firms' partners is on the board of a local non-profit with a founding partner of that company that is the potential client and can make a meaningful introduction.

This is the problematic, social process that my company works to convert into a fast, technology-driven social process.

You can see a case study of how we do it here: http://jutenetworks.com/2010/01/independent-sector-a-quick-case-study/

If you or any of your readers are interested, I'm happy to do a demo.

-Sean

[Gaurab Banerji]

Very interesting points Michael. As a community manager for an enterprise social software platform (tibbr.com), it is part of my responsibility to identify key use cases for clients to succeed in their adoption. I think what you mention here is very similar to what i preach to my clients about deeply integrating the business process into the social software tool at the core business level. The deeper into the core you start (e.g.: Client-Specific Collaboration) the more direction and investment users will have in such a platform.

I've found, as you mention, without clear purpose on what the collaboration platform is supposed to be used for, users will maintain a 'Thanks, but no thanks' approach. If you give users a very specific use case to follow, in which they will almost instantly see value in, they will do it. Eventually, the more peripheral use cases will emerge as adoption spreads.

Thanks again.

[Michael Idinopulos]

Beautifully said, Gaurab. Good luck at Tibbr!