Filtering in Social Software: Protective Bubble v. Serendipitous Awareness

There was an interesting conversation on Twitter yesterday about the personalization of information via algorithm-based filters. It was started by Megan Murray, and Thomas Vander Wal, Gordon Ross, and Susan Scrupski quickly joined in with their viewpoints. Rachel Happe and I were late to the conversation, but we were able to interact with some of the original participants.

.The gist of the conversation was that some consumer social services (i.e. Facebook, Google Search, Yahoo News) have gotten rather aggressive about applying algorithms to narrow what we see in our personal activity streams. As a result, we aren’t able to see other information that might be useful or entertaining in our default view; we may only digest what the algorithm “thinks” is important or relevant to us. Or we must switch to a different view to see additional information (e.g. Live Feed v. News Feed in Facebook). Even worse, in some cases, the other information is simply not available to us, because the service doesn’t provide a way to override the algorithm that excluded it.

It was also noted in the Twitter conversation that the current crop of enterprise social software lacks sophisticated personalization facilities. In fact, it works the opposite way of consumer social services; the entire activity stream is usually exposed to an individual, who then has to narrow it by manually selecting and applying pre-defined filters. IBM, Jive, NewsGator, and others are beginning to use algorithms to include certain status events and updates in the stream, and to exclude others, but their efforts will require fine tuning after organizations have experimented with these nascent (or yet-to-be released) personalization features.

The default view of an enterprise activity stream should be highly personalized to the context in which an individual is working (e.g. role, business process, location, time, etc.) Optional views should allow individuals to override the algorithmically chosen results and see information relevant to a specific parameter (e.g. person, group, application, task, tag, etc.) Finally, an individual should be able to view the entire stream, if he or she so desires.

Why is the latter important? It introduces serendipity into the mix. Highly personalized information views can increase productivity for an individual as they do their job, but at the expense of awareness of what else is occurring around them (I wrote about this earlier this week, in this post.) This condition of overly-personalized information presentation has been called a “filter bubble”. The bubble is a virtual, protective barrier against information overload that is analogous to a plastic enclosure used in hospitals to shield highly vulnerable patients from potential infections.

Organizations must consciously balance the need to protect (and maximize the productivity of) their constituents from information overload with the desire to encourage and increase innovation (through serendipitous connection of individuals, their knowledge and ideas, and information they produce and consume.) That balance point is different for every organization and every individual who works in or with it.

Enterprise social software must be designed to accommodate the varying needs of organizations with respect to the productivity versus awareness issue. Personalization algorithms should be easily tunable, so an organization can configure an appropriate level of personalization (for example, InMagic’s core Presto technology features a “Social Volume Knob” that allows an an administrator to control what and how content is affected by social media. Different kinds of social content from certain people can carry different weight or influence.) More discrete, granular filters should be built into social software so individuals can customize their activity stream view on the fly (I made that case, just over a year ago, in this post.) A contextually personalized view should be the default, but enterprise social software must be designed so individuals can quickly and easily switch to a different (highly specific or broader) view of organizational activity.

What do you think? Should personalization be the default, or applied only when desired? What specific filters would you like to see in enterprise social software that aren’t currently available? What role does/could portal technology play in the personalization of organizational information and activity flows? What other concerns do you have about information overload, filter bubbles, and missed opportunities for serendipity and innovation? Please weigh in with a comment below.

This entry was cross-posted from Meanders: The Dow Brook Blog

Image © 2003 Texas Children’s Hospital

You Are Your Organization’s Chief Collaboration Officer

There have been a couple of interesting blog posts about organizational collaboration leadership penned recently by respected, influential thinkers. Last week, Morten Hansen and Scott Tapp published Who Should Be Your Chief Collaboration Officer? on the Harvard Business Review site. Yesterday, Dion Hinchcliffe posted Who should be in charge of Enterprise 2.0? on Enterprise Irregulars.

It is logical that the question of the proper seat of ownership for enterprise collaboration efforts is being raised frequently at this moment. Many organizations are starting the process of rationalizing numerous, small collaboration projects supported by enterprise social software. Those social pilots not only need to be reconciled with each other, but with legacy collaboration efforts as well. That effort requires leadership and accountability.

Both of the posts cited above – as well as the comments made on them – add valuable ideas to the debate about who should be responsible for stimulating and guiding collaboration efforts within organizations. However, both discussions miss a critical conclusion, which I will make below. First, allow me to share my thoughts on the leadership models suggested in the posts and comments.

While it is critical to have collaboration leadership articulated and demonstrated at the senior executive level, the responsibility for enterprise collaboration cannot rest on one person, especially one who is already extremely busy and most likely does not have the nurturing and coaching skills needed for the job. Besides, any function that is so widely distributed as collaboration cannot be owned by one individual; organizations proved that long ago when they unsuccessfully appointed Chief Knowledge Officers.

Governance of enterprise collaboration can (and should) be provided by a Collaboration Board. That body can offer and prescribe tools, and establish and communicate policy, as well as good practices. However, they cannot compel others in the organization to collaborate more or better. Yes, Human Resources can measure and reward collaboration efforts of individuals, but they can only dangle the carrot; I have never seen an organization punish an employee for not collaborating when they are meeting other goals and objectives that are given higher value by the organization.

There is only one person (or many, depending on your perspective) for the job of actively collaborating – YOU! Ultimately, each individual in the organization is responsible for collaboration. He can be encouraged and incented to collaborate, but the will to work with others must come from the individual.

Collaboration in the enterprise is similar in this regard to knowledge management, where the notion of Personal Knowledge Management (PKM) has been gaining acceptance. PKM advocates believe that having each member of the organization capture, share, and reuse knowledge, in ways that benefit them personally, is far more effective than corporate mandated knowledge management efforts, which generally produce benefits for the enterprise, but not the individuals of which it is comprised.

So it is with collaboration. If an individual does not see any direct benefit from working with others, they will not do so. Conversely, if every employee is empowered to collaborate and rewarded in ways that make their job easier, they will.

The Enterprise 2.0 movement has correctly emphasized the emergent nature of collaboration. Individuals must be given collaboration tools and guidance by the organization, but then must be trusted to work together to meet personal goals that roll-up into measures of organizational success. The only individual that can “own” collaboration is each of us.

Enterprise Social Software and Portals: A Brief Comparison of Deployment Patterns

In my last post, I examined whether or not Enterprise Social Software (ESS) is the functional equivalent of enterprise portal applications as they existed ten years ago. My conclusion was:

From a functional perspective, ESS is quite similar to enterprise portal software in the way that it presents information, but that does not tell the whole story. ESS lacks critical personalization capabilities, but provides better collaboration, process, publication and distribution, categorization, and integration functionality than portals. In my judgment, ESS is somewhat similar to portal software, but mainly in appearance. It makes more functionality available than portals did, but needs to add a key missing piece – personalization.

In this post, I will focus on the observation that ESS resembles enterprise portals in another regard – how and why it is deployed.

Enterprise v. Smaller Deployments

Portals were initially marketed as a tool for enterprise-wide communication and interaction, with each internal or external user role having its own personalized set of resources available in the user interface. While there were some early enterprise-wide deployments, portal software was deployed far more often at the functional level to support specific business processes (e.g. sales, procurement, and research portals) or at the departmental level to support operations.

Enterprise social software has also been touted as most valuable when deployed across an organization. However, like portal software, ESS has most often been deployed at the functional level in support of activities such as marketing, customer service, and competitive intelligence. As a result, the promised network effects of enterprise-wide deployments have not been realized to-date, just as they were not with most portal deployments.

Internal- v. External-Facing Deployments

Most early portal deployments were internally-focused, as shown in this InformationWeek summary of market research conducted in 2001. Not only was there a smaller number of externally-focused deployments, mixed-audience deployments did not begin to appear until the portal market was extremely mature. ESS deployments have followed this same pattern, and we are just now seeing early efforts to blend inward- and outward-facing business activity in common ESS environments.

Internal Use Cases

Portal software was often deployed in response to a specific business need. Among the most common were:

• intranet replacement/updgrade
• self-service HR
• application aggregation
• document/content management
• expertise location
• knowledge sharing
• executive dashboards

ESS has been deployed for many of the same reasons, especially intranet replacement, application aggregation, expertise location, and knowledge sharing.

External Use Cases

Portal software was deployed externally to provide self-service access to corporate information. In some cases, access to selected application functionality was also provided to key business partners. Retail and B2B portals enabled customers to purchase goods and services online. Process acceleration, revenue growth, and cost reduction were the key business drivers behind nearly all external portal uses.

ESS doesn’t seem to have the same goals. I have seen some, but little, evidence that external communities are being leveraged to accelerate business processes or reduce costs. Peer support communities are a good example of cost reduction via ESS. The goal of most outward-facing ESS deployments seems to be customer engagement that translates (eventually) into increased innovation and revenue for the deploying organization.

Conclusions

ESS deployments today strongly resemble portal projects that were undertaken ten years ago. Few, if any, ESS deployments have been enterprise-wide. Instead, ESS is deployed to many of the same department and functional groups, to support the same business processes, and to drive many of the same business results as portals were a decade ago (and still are.)

What does this commonality with early portal deployments mean for ESS? I will examine that in my next post. Until then, I would love to hear your reaction to what I have presented here.