Managing Message App Overload, Part 2

In my previous No Jitter post, I talked about ways companies are addressing the overload of messaging apps threatening to plague employees... Orange Business customers putting voicemail out to pasture, mainly as a cost-cutting measure but also out of recognition that employees have more effective ways of messaging each other; and Atos, The Zero Email Company that is Zero Email Certified to have Zero Email, perhaps not completely replacing internal email with persistent messaging and enterprise social, but seeming to have put a goodly sized dent in it.

Another way of managing the glut of messaging apps getting thrust upon us is to take aim at the app variously called persistent messaging, team collaboration, and workstream communications. Slack is the top dog in this particular kennel, and Atlassian, Cisco, Microsoft, and a dozen or two others are vying for the unclaimed number two and number three spots.

I know for a fact that I've got accounts with Slack, Cisco Spark (or rather, as of this week, Webex Teams) Microsoft Teams, Alcatel-Lucent Enterprise Rainbow, Unify Circuit, and RingCentral Glip. I'm less certain about Amazon Chime, Mitel MiTeam, and Atlassian Stride, but I kinda suspect I have logins for those too. I'm likely to soon add IBM Watson Workspace to the mix. And I may have to do the same with 8x8's upcoming Groups app, which will be part of the new X Series service when it's launched in a few months.

The problem isn't just with the sheer number of persistent messaging apps, but the fact they all have slightly different UIs, slightly different feature sets, and very different sets of colleagues and clients using them. I get around this by rarely using most of them on a regular basis, and I've seen others do the same.

Purging Persistent Messaging

In fact, I've seen others take it to the extreme... and watched it backfire in a way both spectacular and ludicrous. This happened while working on a project in which I needed to draft a number of documents that incorporated a regular stream of feedback from a larger group. Persistent messaging, in this case Spark, provided the perfect way for the five or six of us to discuss the project, track the constantly changing requirements, and update each other on where things stood.

Everything went swimmingly until one executive-level guy (not from my company!) got involved and refused to use Spark or any other kind of persistent messaging app. Instead he emailed directions to his underling, who then copied the directions into Spark. We all discussed the directions in Spark, with the underling copying our various comments and questions into emails back to the exec. The executive then either replied to the underling or -- this is where it got completely nutso -- left voicemails or sent emails to others in the group. Now we all got to paste the executive's messages into Spark so that everyone understood his thoughts on the project.

I can't recall if the "Create Cisco Spark messages from inbound emails" Zapier integration was available back then, but if so it would only have solved part of the problem. The exec would have been able to send messages into the Spark room from his email client. But without logging into the room himself he wouldn't know where things stood with the project or how we were responding to his directions.

By steadfastly refusing to use Spark, the executive successfully stemmed the tide of messaging apps threatening to overwhelm him personally. But in so doing he undermined the productivity of his team. Any time we saved using a collaboration app we lost by managing a separate, redundant, and time-consuming workflow to interact with one rogue team member.

Curbing Collaboration Apps

Of course, trimming down the number of messaging and collaboration apps isn't just the responsibility of the end users. IT should be actively involved in reining them in. Standardizing on a single persistent messaging app is not only good for security, compliance, and cost control, but also for ensuring most everyone in the company can use a single app to message and collaborate with most anyone else.

For some companies, choosing the team collaboration app to deploy companywide will be a no-brainer. Microsoft shops, for instance, will favor Teams, which will supplant Skype for Business as the combined instant and persistent messaging app for Office 365. Ditto for RingCentral clients, since Glip is free with their UCaaS subscriptions.

Other companies will favor the app that aligns with other IT purchases, such as Webex Teams (Spark) for Cisco customers and Stride or HipChat for those with existing investments in Atlassian software. It may not be feasible, of course, to completely stamp out all other messaging apps... particularly Slack, which is extremely popular among developers. But in such cases, it can make sense to keep developers on Slack while standardizing on a separate team collaboration app for the rest of the company.

Earlier this year at IBM Think I spoke with an IT services director at a large financial institution that had longstanding investments in Domino, Notes, Sametime, and Connections. So when seeking a team collaboration app, Watson Workspace was the obvious choice. However, software developers in his department had long used Slack and had no intention of giving it up. Instead of trying (and probably not succeeding) to pry Slack away from them, the company instead deployed Workspace to everyone else. It then integrated the two apps, adding a Slack channel to Workspace so that employees using one app can message those using the other.

In this way, the company could set up a single app for employees who could benefit from persistent messaging, but didn't prefer one app over another. And it kept a group of power users happy by not taking away a valued tool, and at the same time ensured their use of an alternative app didn't isolate them from the rest of the company.

Follow Brian Riggs on Twitter and Google+!