About a month ago, the editorial groups at InfoWorld's parent company adopted Slack as our departmental messaging system, after a bake-off with Atlassian's (competent) HipChat and Microsoft's (really bad) Yammer. Already, we have a 95 percent participation rate, versus 5 percent in Yammer even after two years.
Slack is deservedly a poster child for the new breed of business services, and it's a good representative of the new world of computing IT will increasingly face -- and have to adapt to.
Billing doesn't understand the complexity of accounting
On the frustrating side was the billing. Like so many cloud services, Slack bills primarily to credit cards, although it has an option (available on request) for direct debit from a bank account. That may be easy to set up, but it's not what accounting departments like or expect. There is a paper billing option, but it requires a minimum bill of $10,000.
Our assessment was not to implement Slack as a single corporate-wide account but to set up multiple accounts, one per department. That way, the open channels could still be truly open, without worry about other departments seeing the candid, often in-process communications needed to truly collaborate. Slack makes it easy for people to move among Slack accounts, so you still can have people message across departments and even be invited to specific chats in other departments.
We believe we made the right decision, but our per-department account approach meant that we didn't meet the threshold for paper billing, though our total user count across departments would likely have.
No matter how you're billed, Slack has no concept of allocation, such as to handle proper accounting chargeback for specific budget lines. Our editorial Slack account's users cover five budget lines. As a result, we had to create a shared spreadsheet in Excel to keep track of which group each user was from and when they joined so that we could then let accounting know how to allocate the charges.
It's not a horrible solution, but when you multiply that effort across multiple cloud services, it can get problematic to manage.
Really powerful tools need upfront attention
One reason we picked Slack was that it is not only a very easy tool with great clients on every platform of note -- it's also a very capable platform for all sorts of collaboration beyond standard messaging. You can pin files, invite guests, do custom programming, and integrate third-party services.
And people did!
Files were no problem, especially as we use a retention period so that archives don't live forever on third-party services.
Slack restricts new-user invites so that they can be sent only by admins. That's great on one level because it means users can't mistakenly invite guests (who are free) as users (who are paid), which would then result in a charge -- charges that could add up very fast by accident. (Slack doesn't rebate closed accounts, but credits them to future invoices.)
But that restriction meant an admin has to invite all new members, even the free single-channel guests. And to invite someone to a channel, you have to be a member of that channel -- even if you are an admin (more on that in a bit). In turn, this means a user has to invite an admin to a channel so that the admin can then invite a guest. Yikes!
Most of Slack's user programming capabilities are benign, though some can be a used. For example, users can set custom loading messages that Slack displays randomly when the service is loading slowly, to amuse users in the interim. A demented soul could add some very inappropriate messages, so we blocked that capability. (Admins can see who added specific loading messages, to know whom to punish, and of course they can delete them. You might leave this personalization capability on.)
Then there are integrations, a very powerful capability we love. But so did users, who without asking began integrating all sorts of things -- not cool, especially because some of the services available for integration, namely cloud services, go against our corporate data management policy by using personal accounts.
Worse, the integration is all or nothing, so if you have some users with authorized cloud (or whatever) accounts but not others, you can't integrate only the authorized users' accounts. As a result, we disabled integration permissions for everyone but admins and a few superusers trusted to work with third-party code and services.
The truth is that we didn't understand the power of Slack fully when we deployed it, and as we discovered some of that power put to use in unwanted ways, we had to quickly play catchup.
Privacy is taken very seriously
For me, Slack's emphasis on honoring privacy is a good thing -- even though it adds some burden to my admin work. But for many in IT, it will be a major issue because IT is used to having the keys to every door for security, compliance, and governance reasons. In Slack, an admin can't even see what doors exist.
For example, private channels in Slack -- the ones we use the most so that groups can communicate freely, without fear of Big Brother -- are seriously private. You can't even get a list of the ones that exist (such as to ask to join), much less see who's a member or see the communications. The only way to know a private channel exists is to be invited to it; then and only then can you see the members and the messages. (That's why to invite a person not in your Slack account to a private channel as a single-channel guest, an admin first has to be invited to that private channel.)
A company that believes it must be able to monitor all employee communications will have to disable users from creating channels (public and private), and therefore be the gateway to all discussion channels. That's not going to encourage collaboration or communication.
When I discussed this issue with the Slack team, its responses indicated that IT customers regularly ask for the ability to see everything, including private communications -- and the Slack team doesn't want to do that. I support that reluctance because I believe open, safe communications is a prerequisite to real collaboration.
But I have suggested to Slack a couple options to make things easier without violating user privacy. One is that it give those who create private channels the option to expose the fact that the channel exists so that other users can know it exists and ask to join; the members and contents would remain private. The other: There should be a permission to let users invite free guests (that maximally honors privacy) -- after all, admins can see who's joined -- or admins should be able to see private channels in the list of channels when they invite free guests.
The lesson: Don't remake tools like Slack into traditional enterprise apps
As I said at the beginning, we love Slack. It's been a real boon to our business. And the issues we've encountered -- especially those related to users' direct access to capabilities and privacy -- are ones I'm glad companies like Slack are making us face.
User privacy should be respected more than it is at most companies. And users should be entrusted more than they are at most companies. IT needs to adapt to that reality, even if it's uncomfortable or lawyers suggest otherwise. After all, users will go to these tools whether or not you sanction them.
But providers like Slack need to bend a little, too -- enough so that IT can do reasonable management and have appropriate guardrails for users. Too many cloud tools have none at all.
Tools like Slack should not become traditional enterprise-style apps, with a million micromanagement controls and infinite customization that makes them expensive, hard to manage, hard to integrate, and breakage-prone during upgrades -- that would kill them.
But they need to become a little more sophisticated about the businesses whose users they seek. Yes, they will have to charge enterprises a little more to pay for the extra controls that are truly needed -- but enterprises have long been willing to pay for that.