Slack Users: How does your company organize Slack Teams/Channels?

November 10, 2016 9:37 PM

I'd love to learn more about how companies of, say, ~2000 people have organized their Slack implementations. Do you have one large Team for the entire community? Do you create new Teams as requested by different departments/divisions? Do you let users create them as needed without any intervention from your IT group? A mix of the two? In either case, do you use the free version. Standard? Plus? Do you employ LDAP integration and user provisioning or do you require each user to sign up for and create an account for Slack individually for each Team?

Hi everyone,

I work at a small-medium sized university. My web development team has been using Slack for a few months and we used HipChat for about 1.5yrs before Slack.

We're considering deploying Slack to the entire community and I'd love to see how other Higher Ed institutions are using it. We are trying to decide between a single Team that IT creates and manages which contains as many channels as needed (e.g http://university-chat.slack.com).

VERSUS

multiple Teams that are created as needed and managed by the group of individuals that has decided they could use it(e.g. http://university-IT-chat.slack.com, http://university-marketing.slack.com, and http://university-computer-science.slack.com).

In either case, my team would provide documentation and guidance on how to create a Slack Team, how to use Slack, as well as host on-going training sessions on Slack usage.

Single team Method Pros:
- Cross functional team communication is easier. That is, as an IT employee, if I need to talk with someone in Marketing, I do not need to sign up for an additional Team.
- With a Plus account, we can implement LDAP integration and user provisioning.
- Without a Plus account, requires the user create only a single Slack account.
- All communication truly in one place.

Single Team Method Cons:
- Channel and user moderation will fall to IT. For one example, when a user is on-boarded to _any_ of our dozens (potentially hundreds) of different groups, IT may (likely, will) be asked to invite the user and then invite that user to any private channels to which they may need access.
- Slack App and Slack integrations will need to be configured by IT.
- Overlapping needs for the same integration. For example, two groups would like to use an integration that connects Slack to Project Management software. The integration can only be configured to connect to one instance of that PM software at a time -- who gets to use it?
- Need to enforce channel naming convention to maintain order
- Will lead to a huge set of channels and users
- Without a paid account, there is a limit of 10 integrations. If IT wants to use 7 distinct integrations and Marketing wants to use 8 distinct integrations, which group's get installed?

Multi-Team Method Pros:
- Channel and user moderation is not IT's responsibility. Sure, we will provide support when needed, but the creation and configuration as well as the user inviting and access provisioning is maintained by the Team owner and admins.
- An additional layer for information architecture and organization.That is, there will be a team for IT, Marketing, Computer Science, Business Course 101, etc. all of which have their own set of unique channels. Instead of having all these distinct unit's channels merged into one Team and only delineated by naming convention.
- Each team will have their own set of 10 integrations (with the free version)
- Each team will contain only the channels pertinent to its users.

Multi-team Method Cons:
- Requires users have the initiative to create their own Slack Team or at least come to IT with a request for a Slack Team (as well as create a Slack account).
- A Plus account for all Teams would be cost prohibitive. Since Slack charges based on the numbers of accounts, if a user is a member in 10 Teams, Slack charges for 10 accounts. This means no LDAP integration or user provisioning, so...
- Requires users to create multiple Slack accounts for all teams they wish to be a part of.
- Data compliance concerns. Yes, at this very moment in time, a user could create their own Slack team and share whatever they wish inside it. However, once we recommend and endorse Slack as _the_ collaboration tool for our institution but require users to manage their own Teams, we are then on the hook (at least, in part) for any violations of proper data compliance (for example, sharing confidential files). This "Con" also exists in the single team solution but because, in the single team solution, the Team is a "sanctioned" service managed by IT, the risk is (perhaps incorrectly) perceived as less significant.

Our main concerns with the Single Team method is the amount of custodial overhead it would add to IT's workload and the "clogging" up of the channels and users that would happen. We do not wish to be chat room moderators or managers. The lack of LDAP integration with the Multi-Team Method due to the cost of having multiple user accounts _may_ be solved by giving each Team Owner the _option_ to upgrade and pay for their _own_ team's Plus plan -- and, once upgraded, we can implement the connection to our LDAP. However, in my initial discussions with leadership, this would not work in our institution -- users would come back to IT to foot the bill for the upgrade.

In no way would we require users to use Slack and we're not marketing it as an "email killer" in any way. It would be "sold"/advertised to users simply as the chat and collaboration tool that we suggest but if you want to use it, you manage it. We can surely train you and your team(s) members, we provide guidance and advise, but each team is managed by the Team members themselves.

I know Vanberbilt uses Slack across their entire school and I know that they take the second of the formats above (that is, provide training, guidance, and documentation but if department X or Professor Y or Student Group Z wants to use Slack, they create their own team). That's what I'm pushing for at my institution, but like I said, that comes with its own issues. I'm going to try to contact Vanderbilt early next week but I'd love to get more feedback from anyone who has or has attempted to use Slack this way.

I also know that "Slack for Enterprise" is on the horizon and that may be the solution to most, if not all, of these questions and/or problems. However, it's been "on the horizon" for nearly a year now... if anyone knows of a place I can find more information about "Slack for Enterprise", that information would be appreciated as well.

Sorry! That's a lot of information for a relatively simple question:

I'm really trying to find out from other Slack users how they handle large(er) scale implementations across many different cross-functional teams. We know Slack is a great tool for small team collaboration and communication -- but can it be scaled up for an entire organization? If so, how?

posted by TimBridge to Computers & Internet (5 answers total)

Best answer: ~2000 person tech company here, lots of very fluid internal boundaries and general comfort with tech

- Paid so we can do an LDAP integration, control integrations, audit log, etc.
- Each group of individuals is responsible for creating their own channels as needed
- People who create channels are responsible for making sure the right people are in them
- Very basic naming standards - most channels that correspond to a meaningful organizational unit are prefixed with "team-". IT does not enforce this, just recommends it for ease of use.
- Miscellaneous/short lived/fun channels have no naming standards
- Integrations are managed by the IT team and are fairly limited by design. We launched with a set of key integrations for our workflows - Quip, bug tracker, Gify, and an impressively large set of emoji
posted by asphericalcow at 10:24 PM on November 10, 2016

I'm in a 1K+ member Slack, but not higher ed. You'd need to have a set of guidelines around creating new channels for discoverability, and you should probably create user groups to reduce the onboarding cost.

The answer is that it depends on how much communication happens between your teams, and whether that's something that you need to facilitate. If your teams are heavily siloed from each other, with only high level managers from different teams who need to talk to each other, then the benefits of a huge Slack are less important. Everyone will join their team's channels and ignore the rest.

On the other hand, if your IT and Marketing departments are regularly sending email to each other right now and getting frustrated with delays, then a more inclusive team would be beneficial.

One of Slack's key design decisions is that the product trusts the users. Users can always create channels at will and post inappropriate things, and Slack provides very few tools to deal with those channels and users. It's expected that people will behave themselves, and if they do not, it's something that has to be done outside of Slack, not enforced by it. Teams decide their own way of using Slack.
posted by meowzilla at 10:32 PM on November 10, 2016

Response by poster: @meowzilla,

Thanks for the reply. In your 1k+ member Slack,
* Is this one single team? If so, who manages it?
* Do you have a Plus subscription so you can use User groups?

Yes, there are many occurrences of emails between teams. One inclusive team would be great for that but the alternative with multi-team method is to invite the users from the other team.
posted by TimBridge at 6:15 AM on November 11, 2016

Response by poster: @asphericalcow,

Thanks for the reply. Have you ever had a user request a specific integration? How about two sets request the _same_ integration -- if so, how did you decide which user "gets" the integration since there cannot be two of the same integrations installed and configured.
posted by TimBridge at 6:21 AM on November 11, 2016

Side thought (heavy Slack user, not related to business.... Have tried and failed to bring 2 different companies to Slack):

If you go with separate teams, and have confidentiality and other laws to deal with, not just business policy, I'd recommend having at least one "official rep" with admin powers on each official Slack team, and just absorb that cost. That allows someone to remove confidential data in case of emergency, deal with chat complaints if they come up. You don't want to moderate, but someone is on the hook if slander or libel starts happening, so the university needs to have some type of official oversight to the communications.

This also allows a presence to re-explain the basics of Slack use the same way each time, because you're going to have a constant influx of, "I signed up for this six months ago, used it for three days and dropped out, and now my department is requiring it and I can't remember how to set up pings for official announcements."

This may mean hiring a person whose job it is to Be The Slack Person. (C'mon, you want your university to have an "Official Slacker" role, don't you?) Pitch that person and the additional expense as communications/IT costs that are offset by the time saved by having Slack active - if the teams save one hour a month per user, they've almost certainly paid for themselves. If they save an average of 2 hours/month per user--time not spent writing emails and waiting for responses, or printing documents and taking them over to a desk, or calling people and asking "when's a good meeting time for you" (and waiting for the response to the voicemail), then Slack has not only paid for itself but likely paid for a person to manage it full-time.
posted by ErisLordFreedom at 9:00 AM on November 11, 2016