Blog beginnings
Addleshaw Goddard started using social software over three years ago by using WordPress to run two blogs for a couple of our business services teams. The IT team replaced a traditional weekly email newsletter with a blog. This covered reports on the various activities they were engaged in, together with more informal posts on new arrivals, social activities and so on. At the same time, the firm created a Knowledge and Learning (K&L) directorate, combining the central KM function, Information Services and Learning & Development. We used a blog as part of the work we did to draw the three teams together into a more coherent whole. The aim with the K&L blog was to help people in the team feel more comfortable with each other – to have a better understanding of the work that everyone did.
We learnt a lot from this experiment. The IT blog is still in regular use, but the K&L one fell into disuse some time ago – group blogging never really caught on in the same way as it did in IT. I think there are a few reasons for this difference. One important reason is that the purpose of the IT blog was much clearer, whereas ours in K&L was more intangible. The IT team could also use their existing management structures and information flows to ensure that there was a steady stream of content. The extent to which people commented on the blogs also varied significantly. There are some things you can do to make it much more likely that people will comment. The most obvious is keeping things light-hearted. One of the IT teams does a weekly activity report, but unlike most of the others it isn’t presented in a flat descriptive form. Instead, they combine the report with a caption competition and interesting quotations. Responses to the caption competition alone account for a huge proportion of comments on the blog. Similarly, people respond well to posts with a human interest (new arrivals or departures, for example).
Wiki development
For the last couple of years we have been using Socialtext to provide wikis within the firm. This project started when one of our Corporate partners, who is very interested in new technology, asked if we could create a wiki for him to store and develop a well-used know-how document. Over the years he had created a Word document covering some frequently-encountered issues in M&A transactions. Whenever a trainee or junior lawyer asked him about one of these issues, he would direct them to that document. He wanted to put it in a wiki for two reasons: to allow people to develop the content without having to rely on him; and to ensure that it was easy to find, without being hidden away in the document management system. Both have been achieved. We started with ten key issues in the Word document, but there are now 18 in the wiki. It is also much more visible as part of the wiki – people in the Corporate group have a desktop link to the wiki along with other key information resources.
As we were exploring the use of a wiki in Corporate, our business development team independently expressed an interest in seeing how wikis could support knowledge sharing within key client teams. We therefore extended the Socialtext platform to include a wiki for each of these client teams. A template was created for those wikis, to help people decide what to include, some basic training was provided, and they were then largely left to their own devices.
Wiki success
Comparing these two use-cases, I think they have been successful in different ways. Some of the key client wikis are still unused: perhaps mainly because those client teams are already quite close-knit – working in the same office or on the same corridor – so there is less need for them to have a central virtual location for information about the client. Alternatively, they may have existing processes and tools that work well outside the wiki. However, other key client wikis have developed into really useful hubs for all the crucial information that fee-earners need to know when working for those clients. They all include the obvious things like copies of terms of engagement and the client’s rules about who is permitted to instruct us, but the better wikis have also built up a body of information about the team’s business development activities with the client – meetings, presentations, and so on. We also use RSS feeds from client websites (such as press releases and the like) to add content to wiki pages, so there is more dynamic content than would be possible if we depended on a more traditional approach.
On the legal knowledge front we now have wikis covering the Employment, Projects and Pensions practices in addition to Corporate. These have also developed in different ways, but there are some common themes. The Projects team essentially started from scratch – although they had been using another product, it had fallen into disuse, and the content was simply left there when they started using the wiki. With that clean sheet approach, they were able to create a structure for their content that suited the way they worked. They sketched out a framework within which people can add content, reflecting the different sectors that they work on (such as waste, schools, health, etc), as well as the legal topics that are common to a variety of projects (funding, public procurement, TUPE, and so on). Rather than start with existing material, as the Corporate group did, they have created spaces for the content they need and worked with people in the team to create material to fill those spaces. By contrast, the Employment group has adopted an approach that fits somewhere between Corporate and Projects. Like Corporate they had a huge amount of existing material that has been transferred into their wiki (with the result that it can now be amended by anyone, rather than being the specific responsibility of one or two people). However, they have also used a very structured approach, so that it is easy for people to see where to place new pages.
One of the things that all the successful wikis have in common is a clear set of responsibilities. The most successful wikis have clear leadership: for the knowledge-related wikis this is usually a partner or PSL. This entails a number of tasks. In the first place there is a need to define the purpose and structure of the wiki: where it is not clear to people exactly what the function of the wiki is, they will not use it – whether as an information source or to provide new content. The wiki leader also needs to promote the wiki as a useful tool. This presents the usual challenges, but we have found that novelty has not been a problem – people have readily adapted to editing the wiki. In the knowledge-related wikis, we have also seen that it helps the wiki leader to have a group of people who take responsibility for encouraging contributions in defined areas. These roles reflect the work of existing know-how champions or business stream managers – it has helped not to have to create new ways of thinking about information or workflows.
Blog development
Once we had wikis widely available, we returned to look at the benefits that blogging might offer. One of the things that we learned from our initial blogging experiment was that blogs work well to allow people to share information, links, thoughts and ideas openly. Since email became ubiquitous in law firms, people have used it to capture information related, but not immediately applicable, to their work. Whilst this process of sharing is good in principle, the use of email has unfortunate repercussions. By default email is a private, closed system. Messages exchanged between people are effectively locked in the repositories of their email accounts. It is therefore difficult to ensure that people who might have an interest in a matter in the future can get access to information about it. By contrast, a blog allows people to publish material openly (we have chosen not to restrict access to blogs, although it might be possible) and in a way that encourages future discovery and serendipity.
Using WordPress MU – a version of WordPress that allows a multiplicity of blogs to be run from one installation, with common users – as the foundation for a more coherent system of blogs, we started with a newsletter-style blog for our Facilities directorate, along the lines of the original IT blog.
Since then, we have seen a steady and careful growth in the number of blogs. They now cover a range of uses, including knowledge sharing within legal teams, informal learning support for our Partner Development Programme (PDP), mini-blogs for a couple of our client teams (complementing their wikis), and activity tracking for one of our business development teams. People generally find the editing interface straightforward, even though it is different from what many of them have seen previously. They also appreciate the fact that we have provided access to a variety of different WordPress themes and plugins, so that they can make their blog fit their needs.
One of the plugins that we use allows tags to be used across the whole of the blog system. As people begin to tag their content, it becomes possible to track activity wherever it appears. So, for example, the BD team might write about an opportunity they are pursuing with a particular company and tag it with the name of the company. At the same time, a post on the PDP blog might also mention the company and be tagged as well. The tag collection allows readers to click on a tag and read all the blog posts with that tag, so the BD and PDP posts would appear together, even though they exist on separate blogs. Another plugin that we have found indispensable has allowed us to integrate WordPress MU with the firm’s Active Directory system. This means that people do not need to log into their blogs – it picks up their credentials from Active Directory and ensures that their blogging activity is tracked effectively. We do something similar with the wikis – it is an essential part of making these technologies pervasive that there are no security obstacles.
Conclusions
Beyond the obviously different experience for our lawyers of knowledge sharing using blogs and wikis, these developments have taken our IT people into new areas. They had traditionally used standard enterprise technologies: Microsoft, .Net, SQL Server, and so on. WordPress MU and Socialtext use a different approach – Linux based, MySQL, PHP. The challenges provided by those differences were significant. However, I think it was worthwhile being open to these new technologies, rather than restricting ourselves to Sharepoint and similar tools. That said, things like single sign-on are essential and are undoubtedly harder to achieve with the tools we have chosen.
Away from the technology, I think it is essential to monitor these systems closely. This is not simply a question of reading the logs from time to time, but actively reading what people are writing. This is the only way successful practices can be identified and spread around to others. Related to this, one has to be careful not to allow people to demand a blog or a wiki just because they would like a new toy. It is important to work with them to identify what they want to achieve and then decide what kind of tool (or non-technology practice) would best meet their purposes.
Mark Gould has been Head of Knowledge Management at Addleshaw Goddard since 2006. Prior to that he was a PSL in the firm’s Competition and Commercial Group. He blogs at blog.tarn.org.