'Just Say No' to native social features: the gateway drug to enterprise information silos

We were all warned about the danger of gateway drugs.

Just one moment of indiscretion using Bad Thing X would undoubtedly lead you into a lifetime of abuse of Bad Thing Y, which would eventually ruin your life. After that, you might start skipping school, join a rock band, get a tattoo or drive off in a Volkswagen Beetle for the summer with no distinct purpose.

The same rule applies in enterprise software, where lightweight native social features inside purpose-built business applications are Bad Thing X. Today, there is a real problem threatening companies attempting to become a truly social business: lightweight social features baked into purpose-built software are the gateway drug to collaboration failure.

'Yes' to Collaboration with Purpose

Let me be clear: I am an advocate for the concept of Purposeful Collaboration as defined by Constellation Research Vice President and Principal Analyst, Alan Lepofsky — the concept that enterprise social software must be launched to meet specific business needs and must integrate seamlessly into existing business systems and employee workflows. An enterprise social network mustfacilitate the informal social connections that power corporate information flow outside of the tools that employees have been prescribed by IT. Social technology must be an enabler of both organic human interactions and learned behaviors required to operate within already-entrenched systems and processes.

I advocate that the only way to achieve this is by deploying one enterprise social networking tool and integrating it into all other business systems as the singular dialogue engine for commentary and collaboration enterprise-wide.

Vendors and the Social Bandwagon

What I do NOT support is the use of basic “social” features such as commenting, liking and status updates that now come baked-in to purpose-built software. As I define it, purpose-built business software is a system or tool deployed to a team, department or group for a highly specialized purpose. For example, bug tracking software used by engineering, a knowledge-base platform for call centers, learning and development training modules for HR, and SharePoint when it’s used as a corporate broadcast mechanism. These tools are launched for a defined activity or are only relevant to a certain function.

Purpose-built software vendors are jumping onto the “social” bandwagon and including lightweight collaboration features such as commenting, liking and sharing inside their tools. But there is a real danger in encouraging employees to use these features: one quick stroke of the keyboard could lead you down the rabbit-hole of keeping all of your work conversations off in a silo, hidden from the rest of your colleagues. This truly is a worrisome practice that has the possibility of destroying all of the gains being made inside a company seeking to become “social” — when the “social” features of multiple systems and tools are used, employees take a step backward and continue to silo their conversations at a team or function level.

The Manager’s Dilemma

We all know that deploying an enterprise social network is, well, work. And it can take time in big companies. Meanwhile, employees are demanding real time social and collaboration tools NOW. What’s a manager to do when there’s a need, and a solution, but the solution is completely out of their hands? The path of least resistance is now deploying purpose-built tools that include social features, but the slippery stepping stones on this path look something like this:

• Employees are clamoring for real time, social tools. Managers with purchasing power and a collaborative mindset want to deliver, but enterprise-wide efforts at launching a social network have stalled, are nonexistent, or are invisible to most of the organization.
• Managers approve the use of a purpose-built tool that includes seemingly harmless social features.
• As users are required to spend time in a purpose-built tool, they adopt the interface and start using the social features by default. Collaboration seems to be happening — it’s finally visible.
• As users may start to be measured by their performance in a tool, they will feel compelled to use it, further entrenching the tool in their workflow.
• As leaders are held accountable for the cost and adoption of this tool, and the data that they can pull out to justify the expense, they will promote use of the tool to show the impact they’re making on the organization.
• When an enterprise social network is finally deployed, employees are resistant to give up their legacy social features. Where will all of the information go? Why do we have to change what works? How will managers measure employee activity?

What You Have to Believe

Becoming a social business is an exercise in “what you have to believe.” If you truly want to become a social business, you must believe that the digital conversations and dialogues flowing between employees across geographies, offices and business systems serve a better purpose when aggregated together in one central location rather than dispersed amongst and rooted in disparate, purpose-built applications.

Employee conversations are the nucleus of the real corporate social network; providing a single tool that 1. captures all of these conversations, 2. disperses them into relevant business applications and 3. makes conversations and system updates available to as broad of a population as possible creates the most benefit for the most people.

It’s time for leaders and managers to put a stop to using social features inside function-specific tools. It’s time for leaders to give up a bit of power and unite under the common goal of opening up company-wide lines of communication. It’s time to stop questioning the ROI and KPI and TCO of an enterprise social network and just do it already. It’s time to Just Say No to the social feature gateway drugs that might make us feel good in the present, but that have destructive consequences down the road.

This post was originally published on February 20, 2014 on my CMSwire column.