Some of the most common questions we encounter from prospective customers involve mergers and acquisitions: what happens to established non-email collaboration pathways at two companies once they are required to combine?
"Small big" companies—a couple of hundred people on the acquirer side—don't have much of a problem: the acquiree either gets fully absorbed into the internal real-time collaboration system of the acquirer, or a Sameroom-like service is used to establish bridges between the rooms or channels of corresponding departments at both firms.
The reason why "small big" companies don't have much of a problem with this is because they tend to be young enough to have adopted team-centric collaboration tools, like IRC, HipChat, or Campfire at inception (so, they actually have rooms or channels to bridge, and know how to use them), instead of older one-to-one IM services, like AOL, Yahoo, or Microsoft Communicator.
It's the "big big" companies, at least a couple of decades old and with thousands of employees, that tend to run into issues. At such companies, it's common to see heavy reliance on email and phones for nearly all business communication, with "IM" being nothing more than a lightweight interrupt — "hey, you available?", or "what's he talking about" (during a conference call) sort of stuff.
(With plenty of team chat used by small groups in shadow IT mode, but for the purposes of this discussion, we'll pretend that isn't happening.)
At the "big big" companies, equally important to sending these lightweight messages is the concept of presence—color-coded status showing a user as online, away, busy, or offline.
The reason for this is historical: traditional instant messaging and presence systems—IM&P for short—attempt to mimic in software the idea of a factory-type environment where everyone is co-located within the same physical space and one can glance at a chair and see the "presence" status of its occupant.
The presence indicator approach worked reasonably well because when most of these now-"big big" companies hit success and began scaling, they scaled "vertically": to new floors and adjacent buildings, as oppose to "horizontally": across cities and time zones.
Because of this history, when "big big" company IT staff consider the technical aspects of merging two collaboration systems to establish a merger task force involving subgroups from parallel business units at each company, they often envision something like this:
(We didn't connect all the dots, but the idea is that everyone is connected to everyone else individually.)
This is called federation—a way to merge user "rosters" in IM&P systems of two companies.
It's a functionality that exists out-of-the-box in common "big big" company IM&P systems: Cisco Jabber, Skype for Business Server (not Cloud), IBM Sametime, and a few others.
Quite often, federation suffers from an intention-solution conflict: the M&A stakeholders view federation as a way to foster efficient collaboration between related groups at both companies to ease a traditionally-painful and time-consuming integration process, but instead all they get is the old one-to-one instant messaging and presence.
One-to-one communication contradicts the goal of connecting groups not only in the most obvious way—it's one-to-one as oppose to many-to-many—but also by offering diminishing, or even harmful returns in scenarios where openness and transparency of information is pivotal to successful integration of business processes between two companies, each with unique culture, history, and belief system.
Additionally, a traditional federation solution may disappoint because M&A scenarios usually exhibit a dramatic departure from the factory-centric assumption of traditional IM&P: companies tend to be in different geographies and time zones, rendering the concept of "presence" largely irrelevant.
An alternative approach involves another out-of-the-box feature of most IM&P systems: persistent chat rooms.
Persistent chat rooms are available in most "big big" company collaboration systems, like Skype for Business Server (not Cloud) and Cisco Jabber, but are disabled by default in both.
Enabling the feature involves a similar amount of work as enabling federation, but the results—with a little help from Sameroom—would potentially be more aligned with the original requirements:
Setting this up between Cisco Jabber and Skype for Business Server would require using a Sameroom Proxy for each, with the high-level architecture of the integration looking something like this:
The result can be powerful. For example, it becomes trivial to replicate a source code repository event feed in Jabber and Skype for Business. Here is an example of us doing just this, with a Jabber client running on Mac and a Lync/SFB client running on a Windows 8 VM:
The actual data is coming from a Fleep room with GitLab integration enabled:
Anyone with access to one of these rooms can see what's going on.
In this model, users don't see the membership or presence of users in connected rooms—all focus is on content. It's implied that membership will change over time, that occasionally experts may join on a short-term basis, and that third, or even fourth parties—such as agencies or contractors—may be invited to connect rooms from their collaboration environments.
This idea is revolutionary in a way that three-way calling was revolutionary—as in not very, but kind of.
If you're interested in exploring an M&A collaboration environment that uses persistent chat rooms and Sameroom, we can help—reach out to email@example.com or call us at (415) 483-7743. We can also walk you through enabling persistent chat rooms in your collaboration system.
For information about Sameroom Enterprise, see https://sameroom.io/enterprise-admins.pdf.
For Sameroom Security Overview, see https://sameroom.io/blog/sameroom-security-overview.