Of my 12 years in the professional world, I’ve spent six working on enterprise communication and a hundred complaining about it. At issue, something that took me a long time to figure out is a failed model of how people in different functions want and need to interact. We think we want one final tool for all communication. Confounding this are hierarchical IT organisations and vendors attempting to find a one size fits all approach.
We need to create a new model for enterprise communication. Here’s mine:
Is the need for conversation real-time (synchronous)?
Or can/should the conversation be consumed over a longer span of time (asynchronous)?
Is the conversation most often between employees at the same company (internal)?
Or with press, customers, or partners (external)?
A tale of two teams
Using these questions, you can then map* the needs of various teams within your organisation.
As far as text-based communication goes, there’s a pretty clear separation here between business and tech teams:
- The work of tech teams is highly collaborative and synchronous, coordinating project work, deploys, or dealing with production issues.
- Business teams, meanwhile, are focused externally. And, while your reps might love to have a chat ever-open with their prospects, the prospects probably don’t. Further, a lot of business communication is exploratory, assessing interest or nurturing leads in a loosely-coupled way.
Your go-betweens, not surprisingly, are teams like product, marketing, and support. Product, because they work closely with the tech teams and the broader market. Marketing, because they have to coordinate and train internal resources as well as manage external communications. And support, because they have to coordinate internal responses through multiple external channels.
If you’re on one of these teams and picky about how you communicate, you might want to find another line of work.
Looking again at that graph, there’s a pretty clear zone of value from internal and synchronous to external and asynchronous.
You’ll see a proliferation of broad tools along the value line and a handful of niche single-use products elsewhere. Which is not to say that there isn’t money to be made in asynchronous internal or synchronous external communication, just that companies are likely to value those solutions differently.
Let’s go ahead and lay out a handful of common communication tools on this grid and see where they fall.
Building internal vs. external
When you think of internal vs. external communication, you have to think about two things:
1. The protocol the platform is using
2. The ubiquity of that protocol
Email is based on an open protocol, SMTP, designed in 1982 by a dude with a killer beard. It was meant to be used and expanded upon for a variety of uses. As boring as email has been for 33 years, it’s openness lead to an unrivalled ubiquity. Email remains the default of all electronic communication and defaults are incredibly powerful.
On the flip side, there are myriad vendors selling synchronous communication tools with completely proprietary protocols. These tools are useful in as much as:
– You know both parties have them (and wants to talk to you using them)
– Or they solve very narrow use cases (like support chat on your site)
Ubiquity, in the absence of a standard protocol, is synonymous with user growth. The market has long awaited the coming of a Facebook-like product to unify disparate protocols. Not Facebook-like in terms of UX, but in terms of scale, where we might yet see one platform become so popular that employees stop needing email addresses.
Prove me wrong, but I think it’ll be some time before this happens, if ever. IT still has a tight rein on the purse strings in the largest organisations and are quite happy paying their Microsoft and IBM bills, waiting for one of them to launch their version of Whatever Comes Next™.
When it comes to synchronous or asynchronous systems, the proof is in the design. Here I mean design in the broad sense, from the underlying systems to the UX itself.
Architecturally, synchronous systems are designed to prioritise speed and assurance of message delivery. Synchronous systems, therefore, must be centralised. Meaning that successful synchronous systems must be necessarily be single-vendor systems.
Despite Google’s social-feeling inbox view, the multi-vendor decentralised nature of email forces small lags that would be intolerable for synchronous communication.
UX-wise, asynchronous systems must provide two things:
1. Some underlying structure to messages. Threading is the most common example here, but things like following, addressing/@-mentioning, and topics/tags are on the same continuum (in as much as users understand them).
2. An increasingly sophisticated view of all “work” within the system, an inbox. Because work can show up at any time, relating to any thread, the user need a way of triaging it.
The state of the art in synchronous apps remains largely unthreaded and dependent upon a notification feed for prioritisation. Flowdock has threads, which begin to fit the bill for #1, and there’s some indication Slack will follow suit. But an inbox implies a shift in user behaviour that would take these apps and their priorities away from synchronous chat.
There was an interesting point in Yammer history, when the team had to make a choice between “Twitter for the enterprise,” which was fast becoming an enterprise chat tool, and “Facebook for the enterprise,” to compete on asynchronous footing with email. The team chose threading, the site UX trended ever more asynchronous, and the rest is history.
What everyone gets wrong
What everyone gets wrong about enterprise communication is that you will have one product, one vendor, or that that would even be desirable. Nothing is killing email any time soon, because synchronous tools don’t fit the user need, there’s no competing asynchronous protocol, and IT purchasing today stands in the way of consumer-like winner-take-all network effects. Nor is email enough with the proliferation of real-time tools in the hands of teams that have needed them for a long time.
What everyone gets wrong about enterprise communication is that you will have one product, one vendor, or that that would even be desirable.
Polyglot communication has always and will always be the case for companies. It’s ultimately what the people want, even if they bang their heads against a wall trying to shove all communication through a single solution.
* Omitted from this discussion: video chat, most portal software (most portal software is actually document/file management, rather than communication)
** Synchronous protocols, like jabber or xmpp, have been attempted, but largely fall apart when the largest supporting vendor finds the protocol stifling or the speed/assurance of delivery too low.
Follow Drew on Twitter @drewdil
Image: Flickr/Jim Pennucci