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.

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.

Leading and Owning Communities

Pre-S:  this post has taken me a bit of time to write.  This is half because I was having difficulty with what I wanted to say (and I’m still not sure that I’ve figured that part out…) and because I have been blessed with a flood of post ideas thanks to some interesting discussions that I’ve had, as well as the conference that I attended earlier this week.

So reading this got me thinking about a lot of issues.  The first section, I think is absolutely dead-on.  A colleague this week introduced me to some of the ideas in The Starfish and the Spider (I know, I’m terribly behind on my reading in general) that basically align with what Ross is saying here.  Leadership is definitely one of the more important challenges in working with a distributed group.  Ross explains the example of a start up spread across four countries; I can attest to this even in a small group working across the Washington Metro Area.  Focus is the key to successful collaboration: collaboration has to be working towards something, and it usually falls on the leader to set those priorities and guide groups towards them.  This is not to say that the leadership has to come from above, as horizontal leadership can often be just as effective in leading collaborative efforts.

So that part was easy.  It’s the second piece of Ross’s post that I’ve sort of been wrestling with over the past few days.  The lead in:

Who Should “Own” Community?

On the panel I answered with the always correct answer that “it depends.”  But also suggested that ownership of community will trend in two directions.  Social Software has made community a strategic imperative for many organizations.  Recalling when risk management became a strategic imperative in some industries about ten years ago, you saw the rise of the Chief Risk Officer.  While the emergence of a new CxO function is fleeting at best, I was provocative to make a point that we could see the rise of the Chief Community Officer to align and coordinate internal and external communities.

This got me thinking: “owning communities”.  How do you even go about doing this?  I think Ross is talking about owning the problem of communities (and establishing them),  but I wonder, how exactly can a CxO really go about owning a problem that is inherently personal, since it depends (almost) entirely on personal styles, social skills, and dedication to maintanance of a network.

I have been trying to think through the idea of what exactly this Chief Relationship Office might do.  On one hand, he/she could be the owner of things like internal and external involvement in social networking sites.  So this would be managing internal social network sites for large organizations, as well as coming up with new ways to use existing platforms like Facebook and LinkedIn for the benefit of the organization.  I can also see this role as being a big promoter/innovator of ways to establish relationships inside the company through cross-functional events, etc.

However, I tend to think that Charlene Li is right in her tweet:

Does having a “chief community officer” make sense? Initially, yes, but community *engagement* needs to be responsibility of every employee. –2:01 PM September 04, 2008 from web

Especially in a social software environment, the community is ultimately the responsibility of nobody and everybody all at the same time.  Social software requires social networks to succeed.  And though the software can help create social networks, ultimately the success of social software project is still almost completely dependent on either chance or effective use of one’s network.  This problem is ultimately about the health of the collaborative community, which ultimately cannot be the responsibility of one person or one team of people, because this community gardening must be the responsibility of all users in order to succeed in establishing a stable and enduring collaborative ecosystem.

So after re-reading Ross’s post again for the nth time, I guess this is all just a long way of saying, I agree.

The Michigan Wolverines and Organizational Change

One of my favorite things in the world is college football, and more specifically, the Michigan Wolverines. Indeed, you could say that my introduction to Web 2.0 was through a vibrant network of college football blogs that is far more entertaining (and probably more informative) than ESPN.

For those of you who aren’t familiar, Michigan hired a new coach this season; and for the first time in about 40 years, the new coach is a guy who is not a “Michigan Man”.  With this came a radically different offensive system, that requires different styles of players than Michigan’s historically recruited (most obviously having a quarterback with the ability to run the ball, where as Michigan has traditionally had QBs more known for being 6’5 statues with rocket arms).

So last week, in their first game under the new era, Michigan lost to Utah.  Utah isn’t a bad team (actually they’ve been picked as a BCS buster-type), but they are a team that Michigan had traditionally been able to beat handily. But alas, without the right players in the system, RichRod lost his first game as coach of the Wolverines.

This got me thinking.  Rich Rodriguez is forced to play his system, or, more accurately, an adaptation of his system,  with players that were mainly recruited to play in a different system.  This problem is quite similar to those facing managers and leaders all across the business world, especially in this time of rapid change in the business world.

The lesson that I take from this comparison is that leaders, be they in business or government, are often forced to run their systems with other people’s players.  This can of course have drastic consequences, if the skillsets don’t match up to the new leader’s visions and strategies.  Ultimately, the leader has a few choices: 1. Adapt the model, 2. Re-Train the players, or 3. Get a new team.  Probably more accurately, a combination of all three.

This has been rambling and barely coherent, but my take away is that, at least right now, for a Web 2.0 implementation, it is important to remember that you are trying to run a spread option offense with a three-yard and a cloud of dust workforce.  Models have to be adaptive, players have to be trained, and new recruits need to be brought in.