Six ways to make Six ways to make Web 2.0 work work

Occasionally I indulge in Mckinsey’s publication, not only because it pulls me back to the center of discussion globally on the latest business and technology trends, it also reaffirms some on-going stereotypes that people tend to nod their head vigorously to, which is important when you’re trying to sell some ideas to people.

So when I read Six ways to make Web 2.0 work, I thought, even though they are “right” in the most cliche sense of the word, there are specific ways that would make the Web 2.0 pill easier to swallow.

Here are the infographics from the site so that you get some context in case you don’t want to read the article:

Exhibit 1:

Exhibit 2:

Exhibit 3:

The article noted that many of the dissenters cite impediments such as organizational structure, the inability of managers to understand the new levers of change, and a lack of understanding about how value is created using Web 2.0 tools. It also generalized that Web 2.0 technologies are a relatively lightweight overlay to the existing infrastructure and do not necessarily require complex technology integration.

The article then gave 6 advices:

1. The transformation to a bottom-up culture needs help from the top. Senior executives often become role models and lead through informal channels.
2. The best uses come from users – but they require help to scale. Management needs to support the experimentation to find the winner, not rely on their expectations.
3. What’s in the workflow is what gets used. Participatory technologies have the highest chance of success when incorporated into a user’s daily workflow.
4. Appeal to the participants’ egos and needs – not just their wallets. Management needs to bolster the reputation of participants in relevant communities, rewarding enthusiasm, or acknowledging the quality and usefulness of contributions.
5. The right solution comes from the right participants. To select users who will help drive a self-sustaining effort, focus on experts, early adopters, and opinion leaders.
6. Balance the top-down and self-management of risk. Potential repercussions of content, fear of failure, white elephants, lack of management control in maintaining the right balance of freedom and control needs to be overcomed at the policy level.

Although these are important points at the strategy level, I thought I’d share some operational rule of thumbs as well, which would perhaps help bring you, hopefully the champion of Web 2.0 technologies in your company, a tad closer to seeing some success. In summary, they are:

1. Lend more weight on offense – don’t just think about participation, think whether you can make money out of it.
2. Don’t implement a Web 2.0 “technology” – implement a Web 2.0 “culture”, “workflow”, or “capability”.
3. Continuously upgrade to meet the expectations of your users – pick a platform that allows for continuous innovation and quick changes.
4. Be patient when engaging your anchor users (the early adopters, experts, opinion leaders) as they need time to find their niche, settle in, contribute, before there’s any sign of vibrancy.
5. Hire the culture you need – ensure that Web 2.0 dinosaurs don’t creep into your organizations.
6. Put in the right infrastructure to support Web 2.0.

Since I’m not Mckinsey, I’ll just use anecdotes to illustrate the above unsubstantiated points 🙂

1. Lend more weight on offense – don’t just think about participation, think whether you can make money out of it.

Perhaps what’s most unfortunate in this article is to limit Web 2.0 technologies to “participatory technologies”. I know many companies who uses Web 2.0 as an offensive rather than an internal get-everyone-excited, tap-cognitive-surplus tool. When Web 2.0 is a “tool”, it will be treated as such. When Web 2.0 is a way of life to differentiate one’s business from another, it takes on a whole new dimension.

Case in point: Web 2.0 technologies actually enabled a lot of smaller business in the world who cannot afford the ERPs/CRMs etc. (there’s an equivalent sentiment in one of the comments) While it’s possible to see Web 2.0 as a “thin layer” on top of the “heavy duty” enterprise applications, Web 2.0 technologies could also be seen as a gradual adoption of technology sophistication in a growing small-medium business (SMB) to achieve the agility that large enterprises don’t have.

And what better way to slowly adopt such technologies by using it to serve your customers better? Or manage your vendors better? If such adoption of Web 2.0 is taken up not at the CIO level, but the COO or even the CEO level, then it should simply ask the question – how can we create new revenue streams by amplifying our core competencies with Web 2.0?

A publication based advertising company once asked me how to adopt Web 2.0 since everyone in town is talking about it. They did have a website but it wasn’t making them dough. I asked them what they wished they could do when competing with other competitors, to which they predictably said: need new ability to get more quality eyeballs. Baring in mind that they don’t really have a sophisticated IT team, I suggested that they quickly identify a web-savvy advertising company overseas and partner them to develop the local market. They could have adopted the Web 2.0 technologies themselves, experimenting along the way, especially internally, but getting a good partner in this case was a winner as they could quickly expand their reach and help their customers to advertise more effectively through blog networks, etc.

Even if the implementation is internal, one can still think of it as a business. Try to create its own “business model” (perhaps budgeted with social capital, with ROI measured on morale etc.) which has a clear outcome and measurable success parameters. More importantly, after you launch the “business”, you need to continuously keep abreast of the “customer” usage patterns of the system, and make changes to meet their needs (see point 3).

2. Don’t implement a Web 2.0 “technology” – implement a Web 2.0 “culture”, “workflow”, or “capability”.

Somewhat related to Mckinsey’s point about ensuring that the technology is adopted within the workflow, I’d contend that one should take one extra step and first ask whether there’s a need to have a Web 2.0 culture; if so, which particular business process would benefit from such a technology most, and which particular business capability would be enhanced with Web 2.0 technologies.

For example, if you go upstairs and tell your boss that the company needs a wiki to do “knowledge management”, or blogs to “better reach out to the employees”, watch out, your project might materialize while no knowledge is managed and employees ignore the blogs. However, if you approach it from the perspective that, say, the subsidiary in another country is not adopting the best practices in HQ, or that the turnover of a company is too high to effectively maintain knowledge in a tribal manner, then the heat would be turned on at the subsidiary management and HR level respectively, and each would then have to figure out a way to disseminate and collect information in a better way, and they would be the ones who would need to champion and institute the culture. You as the Web 2.0 champion in the HQ can then just provide the infrastructure (see point 6 below) and sit back.

Once upon a time, I was awarded an alarm radio for posting a few lines onto an “idea” forum. When I was collecting the “prize”, the secretary smiled and asked if my “idea” was attended to. I told her, I forgot what I wrote. Web 2.0 technologies can be useful is pulling in information, lots of them, but it’s only meaningful if there’s a feedback loop, which sometimes fall outside the implemented technology. This is another way of looking at implementing a Web 2.0 “workflow”, which can consist of a potpourri of Web 2.0 technologies, vanilla Web 1.0, and all the other corporate tricks like awarding the highest contributor during a company event.

3. Continuously upgrade to meet the expectations of your users – pick a platform that allows for continuous innovation and quick changes.

Very commonly I see greenhorn CIOs flying the Web 2.0 flag in C-level meetings to secure the budget for, say, a MS SharePoint implementation. That’s all and well, with operational staff happily creating accounts for many employees, middle level management happily starting to moderate and claiming credit for being more in-tune with the company’s Web 2.0 ambitions, etc. After some time, user habits shifted, people demand more of some feature than others (e.g. very commonly, search is considered “broken” in SharePoint unless you implement the indexing servers) but the CIO is not about to fight another battle to get extra budget for the indexing servers, and was advised by MS not to put them on virtual servers. The attraction to the platform falls apart, and people move on to other things.

If you buy Mckinsey’s argument that it’s a thin layer on some “heavy duty” SAP/Oracle systems that cannot be changed without a minimally 6 figure fee, then you should also agree that since it’s thin, it should be easily configurable to achieve different business goals as it changes over time. During this whole hype about SOA earlier, the likes of SAP/Oracle etc. came up with nice enterprise bus architectures and composite applications but even those are too heavy duty for migration. Compare it with this simple experience:

When we implemented a wiki for a manufacturing company, we thought it’s was going to be useful as a way to capture institutional knowledge, which was the original spec anyway. As time goes by, we noticed that the operational staff did not have any other way to schedule, assign tasks, trace job completion but to use the wiki, and voila, management told us that they need a scheduling engine behind the wiki. Think about this, an ERP/CRM that never had any UI other than a free form wiki front end! So, without touching their core SAP systems, we quietly inserted a few tables to capture the usage patterns of users on the wiki such that certain types of tables created in wikis are mirrored into the databases suitable to be then fed into the SAP systems for accounting. The cost isn’t really that high (granted it’s not out of the box) but it was a simple shift that respected the user’s need to use the wiki (they prefer free flow text to text boxes and drop-down selectors). What’s more exciting now is that we’re trying to introduce them basic semantic search that would allow them to search through common spelling mistakes and give context to their interaction with their unstructured data, all within the same wiki.

4. Be patient when engaging your anchor users (the early adopters, experts, opinion leaders) as they need time to find their niche, settle in, contribute, before there’s any sign of vibrancy.

No matter how early an early adopter is, he or she needs to find a space in the new system of which his or her ego is maximized. Creating a new internal or external facing Web 2.0 space is like creating a new building – I like to think of is as the extra-curricular activity building in a school. You can formalize the relationship between certain tenants, e.g. assign a band room, call that the sports corner, provide furniture in the gym etc. but after that, you need to give the students some time to figure out what they can do with this building. Some bright kid might realize that the row of benches along some corridor is an excellent place to play chess and sets up a chess club around it. The place you thought would be used by the school band might be fought over by chinese orchestra, guitar and harmonica club, string ensemble, etc.

Some experts require some coaching not in using the technology, but in terms of being convinced of the reach of the platform. In some sense a Web 2.0 platform resembles a two-sided market. Readers will flock to the space only if many experts are posting to this space. Similarly, experts would bother to post only if they know their egos are stroked with a large readership. To break such cyclical effect, one has to start with the contribution end, over and above providing basic HR/legal info, to have some of the experts posting and giving them an indication that readers are reading their posts. Comments, Likes, Stars, etc. are simple ways to achieve this effect, referring to such entries in major intranets or external communications is another. Again, big carrot to the experts, then wait.

A related story on adoption: I recalled once when I was a team lead of a development group, my team members was apprehensive of the wiki, basically because most of the content created by other senior employees was impeccable and thus they felt that they would “dirty” the wiki if they start putting up their own thing. I turned the issue around, asking them to use the wiki as a notepad – basically prepending all the articles with your own initials so that it doesn’t seem important. Now asking a junior programmer to write and contribute to a wiki entry entitled “OrderManagementSystem” might be quite intimidating, full of fear of rejection, but asking him to create a new entry called “OJJOrderManagementSystem” doesn’t sound that bad. Nevertheless, the information that needs to be captured is captured, even if it’s not on the same page, but as long as it can be retrieved and it’s important, someone’s going to pick it up and merge it into the main “OrderManagementSystem” page.

5. Hire the culture you need – ensuring that Web 2.0 dinosaurs don’t creep into your organizations.

This is definitely not trying to discriminate older workers, especially when you realize that many of your major contributors will be older members of the company. What I meant by Web 2.0 dinosaurs are basically selfish people. These are people who define level of prowess as amount of proprietary knowledge held. Baring some sensitive information that cannot be shared, I think modern workers should share as much as possible not just in the coffee shop with their close colleagues, but also on the company’s favorite Web 2.0 platform of choice. Personally, I felt irresponsible if I left my job without all the knowledge acquired to do the job being left behind in an easily retrievable place; in some companies who are laggards in technology adoption it can be just a shared drive, while others it’s chiefly wikis, forums and websites.

One simple observation is that it’s easy to change people’s habits on technologies, especially if the UI is built right, but it’s hard to change a person’s character. And therefore it’s important that even during the hiring phase, that one watch out for traits of keeping information secret. Perhaps group interviews which includes activities that require teamwork is the best way to see this. Pass knowledge to one of the team member that would advantage the person and see if he or she would share the knowledge with others so that as a whole the team is better off maybe.

If you’re unfortunate in that you already inherited a team/company where no amount of technology implemented would make these people share information, then one have to formally employ some form of carrot and stick, e.g. have each worker be mirrored by another person under the pretext of ensuring BAU during his or her absence, and force that the information be shared through the designated platform. Or if the work has some 24/7 element and on-call rotation, then ensuring that information the on-call person requires is available to avoid being woken up at 3 in the morning to ask simple questions on restarting a dead application might do the trick.

6. Put in the right infrastructure to support Web 2.0.

I put this last even though this is probably the first thing you’ll be looking at, because it’s really not the core part of the problem, especially for the vast majority of the SMB looking for some open source or low end Web 2.0 silver bullet. Yes it’s possible to download some of these open source projects, try it out, do feature comparisons, make a purchase if necessary, and install / run the system, but one has to be careful when choosing the right infrastructure all the way down.

For example, if you take Mckinsey’s case of Pixar where video clips can be included, be sure that your internal network architecture can support it. I had one case where someone decided to allow video on Sharepoint, then send an email to the entire company with a link to the latest quarterly results video during prime email checking time in the morning, and that just literally created a man made DDOS. In another case, the media server and the wiki server was separate instance, but the VPN for the company was such that only the wiki could be accessed from home and not the media server, rendering a large part of the wiki incomplete.

For external facing technologies, a lot more would have to be considered as you’ll start feeling like running a full fledged wikipedia or blogspot. In such cases, seriously consider leveraging existing services instead of building your own. There are many sites that allows you to create your own branded wikis, blogs, and other such tools, while promising the sky that they will keep your information safe, and they probably do. You just have to make a decision on how much you want to trust them.

Final word

One more story: A company once told me that they don’t really need a website anymore. All they needed was a facebook fan page to engage externally. They might be right in that staying in a Web 2.0 social network wall garden is all they need to achieve their aim. Once you have right sized your problem, finding the right technology to solve your problem should be a piece of cake. So don’t come searching for the one Web 2.0 technology and make it work for your company. Find out when you really really need first (or engage someone to help you find out, with reference to exhibit 3 above), then refer to exhibit 2 above to find your solution.

Any other stories of successful implementations of Web 2.0 @ your workplace?