Assumed Audience: Anyone considering social dynamics in team chat, but especially leaders with authority to shape team norms.
It’s common in some circles to treat private rooms or DM-heavy Slack teams as a sign and more importantly a cause of dysfunction, particularly in terms of team trust. In particular, folks are sometimes tempted to use the metrics Slack provides to measure the health of their organizations: a high value of the private-to-public messages ratio is seen as a fairly direct measure of mistrust. The corresponding assumption is that it also causes teams to silo from each other and mistrust each other in the first place. I disagree firmly with both parts of this, and always have.
First, a heavy use of private rooms and DMs might be a reflection of existing mistrust, but only a reflection, not a cause. If you ask around, you’ll find that many organizations with widely varying degrees of siloing, trust, collaboration, etc. have very similar ratios of private and public conversation.1 If two organizations with polar opposite degrees of trust and collaboration have the same ratio of private-to-public conversation, then siloing and mistrust can’t be caused by private chat. Second, this also means that the ratio of private to public chat isn’t even a reliable signal of whether an organization is healthy or not: it lacks any predictive power.
This is exactly what we should expect based on how people interact with each other in the analog world. Our offices have meeting rooms because having spaces for private conversation helps everyone do better in the public spaces. For one thing, even in the healthiest organization, there are going to be times when you’re frustrated with another person or team. When that happens, the most helpful thing is often to go talk to someone else you trust. That gives you space to blow off steam, to work it through mentally or emotionally so you can handle it well publicly.
For another, there are plenty of totally “positive” conversations which benefit from privacy.2 Sometimes you need to help someone avoid tripping over a political or personal landmine in a conversation. Sometimes you’re coaching someone through a difficult personal situation, or through their career considerations. Sometimes you’re working on a thorny problem, where having more input from people with less context would just be a distraction (even if just by way of having to give people enough context to contribute meaningfully). Sometimes you’re processing with your closest colleagues about changes to a company policy which affect you. Sometimes you’re responding privately to a public question about an HR policy based on your own experience. Sometimes you’re just hanging out with your team, talking about your weekend.
The list of things which should not be in public rooms in a healthy organization is long. Public rooms are good for public discussions, but we must be able to distinguish which discussions should be public. Most of us develop a reasonably good sense for what that looks like in an office, because it maps fairly directly to our existing social norms. Many fewer of us have had time to develop the same sense around chat, because we have used it far less. But in the same way as meeting rooms in an office, private chats serve a vital function in keeping public chat healthy, independent of the healthy trust level of an organization.
“Public” on chat is also very different from “public” in an office. If a group of four or five people are sitting around a table in a public area in an office, it’s true that anybody could happen along and join the conversation. There is no log of the conversation for someone to browse through, though, and the people at the table can modulate the conversation however is appropriate for the newcomer. A public conversation around a table is therefore much more like a chat room with no persistent logging — just the opposite of Slack.
Now, this doesn’t mean that there aren’t dangers around private chat. It simply means that the issues aren’t fundamentally matters of organizational trust, or the goodness or badness of private chat in a general sense. Rather, they come down to decision-making and inertia.
While there are real challenges for teams around decision-making, these challenges are much the same with chat as with in-office interactions. For example, people particularly worry about whether the chat history is available to others later for context around decisions: in a private chat, the answer is no, whereas in a public chat, the answer is at least in principle yes. If you’re reliant on a chat archive to let you know whether the decision was made well, though, you’ve discovered a problem with your decision-making process in general.
What matters is not that you have a record of every word spoken in a meeting but that the decision-making process is transparent enough that people can trust it, and open enough that if something got missed it can be flagged and reevaluated. Public chat doesn’t solve this very well, though. For one thing, public chat in a room which key people aren’t in can be nearly as much a problem as private chat. For another, a chat log is a terrible way to understand a decision, just as a video recording of a meeting around a table would be.
Accordingly, I recommend away from making significant decisions over chat at all. In place of ad hoc conversations for important decisions — chat or otherwise — use a clear decision-making framework (including clarifying the parties involved via RAPID, RACI, etc.) and use good meeting minutes for synchronous conversations (whether via video or chat or in person) and comment history for asynchronous decision-making (e.g. via RFCs). The resulting decisions will clearer and the document trail behind them will be far more accessible and useful over time.3
Another legitimate problem is people abusing private conversation as a way to do an end-around on the official channels. This is not specific to chat, either, though: people use private meetings as a way of getting around formal decision-making approaches in the office, too. Again, the key is that the reasons for decisions are clearly articulated and open to feedback from all relevant parties. If a decision suddenly changes and there isn’t a clearly-visible reason why, there is an organizational problem… but one that would have existed regardless of whether chat was involved at all.
The other real reason to encourage people to “default to public” is that private chat has inertia on its side. If a team defaults to private, even conversations which would benefit from being public are likely to end up remaining private. There isn’t a one-size-fits-all solution here, though, for all the reasons that private chat can be good. The best we can do here is have a habit — especially as leaders — of moving conversations to public whenever there is no reason for it to be private.
For example: I’m the lead for a large migration on the app I support, so people regularly DM me with questions about the migration. I have built a habit of moving those conversations to public forums with a gentle nudge: “Hey, do you mind reposting that question in <the dedicated Slack room for the migration>? That way everyone can benefit from our discussion!” What’s more, I try to direct it to the most public forum possible. That might be the Slack room for the migration, which I intentionally set up to support all teams working on the migration. It might be our internal Q&A board. It might be public Stack Overflow. The key is that to default to the most public channel possible. Leaders’ actions implicitly set norms just as much or more than explicit statements about what people should do.
Beyond that, I think we simply have to acknowledge that the challenge of getting the right degree of public-vs.-private is an “unsolved problem” — and that it’s a problem which is not amenable to technical solutions. The fundamental challenges are in human nature: both our tendency to manipulate systems to our own good, and our inability to judge these questions perfectly.
Finally, watch out for people weaponizing these dynamics: “Why wasn’t this handled privately?” and “Shouldn’t we be having this conversation in public?” are legitimate questions at times, but I have also seen people use them to manipulate instead. In particular, be wary of individuals who push loudly for decisions to be made in public, but themselves regularly use private channels for decision-making. That move is just abusing the stated norm for their own power and advantage. If you have the institutional clout, confront it directly when you see it happen. If you don’t have the clout to pull that off, try to raise it with someone who does. If it’s a pattern with multiple leaders around you, such that you don’t have anyone to raise it with safely, find another team as quickly as you can.
The legitimate problems that people worry about with private chat are not specific to private chat or indeed to chat at all. The other concerns people have about private chat — especially worries that private chat causes or even is a meaningful signal of organizational mistrust or dysfunction — are not only unfounded, but in fact misunderstand the deep human need for a whole range of privacy levels, from totally-private one-on-one conversation through semi-public group conversations to totally-public forums.
If you’re worried about mistrust between teams, dig into why you have that distrust in the first place. If you’re worried about decision-making, fix your organization’s decision-making process. Build good norms which allow room for the the whole range of private to public conversations. But don’t let people weaponize those norms, and don’t use chat statistics as a measure of organizational health.
That’s exactly what came out in the conversation that prompted this post, in fact. ↩︎
I scare-quote “positive” here because I think dealing with difficult situations in a healthy way is positive — but since it’s often in response to a negative or difficult circumstance, I think the distinction is still useful. ↩︎
That does not mean you need a heavy process here. Sometimes all you need is a 15-minute sync or a 1-day RFC cycle. Again: the key is the trustworthiness and openness of the process. Make it as lightweight as you possibly can! ↩︎