When teams—or entire companies—adopt team chat, they quickly forget how any other form of communication is even possible. It’s like trying to figure how to operate a covered wagon instead of getting on a jet plane.
Dependence on team chat is a wonderful thing—you want it to happen. For distributed teams, it’s not even an option: it’s the only way to get stuff done. The more workflows, notifications, and processes you’ve got tied up in team chat, the merrier.
However, the more dependent you are on team chat, the more painful it is to deal with service malfunctions. When chat goes down, your company’s main circuit breaker is tripped. It’s a Category 4 digital disaster! And, as luck tends to have it, chat goes down when your own stuff is down, too (that’s Category 5).
What do you do? Skype? Email? Did you know that millenials don’t know how to use email?
Have a Contingency Plan
What you should do is have a contingency plan—a reserve parachute.
When your main chat service goes down, everyone on your team should know to transition to a secondary chat system. It should be on hot standby—preconfigured and ready to go.
Your company calendar should also have a monthly reserve chat training exercise, in which everyone logs into the secondary system. (They should do so from both desktop and mobile.) Any new team members can be added to the reserve system at that time, or—even better—during initial onboarding.
And, to cover all bases, if your main service runs on AWS, your reserve one really shouldn’t.
For additional synchronization, you can also set up a Sameroom Tube between War Rooms in primary and secondary chat systems. This way you can orchestrate a switchover without losing context—IP addresses, usernames, lines of SQL.
One More Thing
If you found this post useful, please tell your friends!