For many remote-first engineering organizations, Slack has become our headquarters. It’s not the only place to collaborate, nor the best — but by default, it’s where collaboration starts.
Slack-as-headquarters has advantages, and each one has a flip side.
| Advantage | Flip side | |
|---|---|---|
| 1 | When I don’t want to be distracted by conversations around me, snoozing notifications is easier and more effective than putting on noise-cancelling headphones or finding an empty meeting room. | When I do need to talk, it’s hard to stay in just one conversation. An entire HQ worth of conversations threaten to pull me off task, even if I just had a quick question. |
| 2 | Searchability makes institutional knowledge easier to find. | Easier access to institutional knowledge can create the illusion that real documentation is less important. |
| 3 | Messages left in public channels tend to find the right eyes. Questions can be answered quickly, and awareness can be raised quickly. | Unread indicators give me a constant sense of FOMO and loose end-y-ness that I wouldn’t have in a physical HQ. All unreads look equally important until I read them. |
I don’t have easy solutions to the flip sides, but I’m advocating for leaning harder on advantage #3, and how that will mitigate some of the flip sides. My suggestion is simple:
If you have a work-related question or discussion, default to public channels. If you’re about to send a work-related DM or use a private channel, make sure there’s a good reason.
Good reasons to use DMs for actual work topics include:
- You just want to vent, or it’s a mentoring thing, etc.
- You want to give work-related feedback privately so it’s non-confrontational.
- You plan on sharing something in a public channel or another medium, but you want a safe space to sound out the idea first, or pre-empt bikeshedding / too-many-cooks issues.
- A security/legal concern requires limiting knowledge, or you think this might be the case.
Those are all legit cases for DMing, and I’m sure there are others too.
That said, here are some bad reasons I’ve seen to use DMs, and why a public channel would be better in each case.
Bad reasons to DM
1. I have a “stupid” question and I don’t want everyone to see it.
Personally, it took me a long time to shed my impostor syndrome at my current company, but it’s not because I have fewer questions; if anything I ask more questions, more publicly, since I’ve accepted that I’ll never know everything.
If you need to know something to do your job, and you’ve already searched Slack / your department wiki / wherever your org keeps docs, then your question can’t be stupid, and you’re unlikely to be the only one asking it. In a decent engineering culture, asking for help after spending 20 minutes on your own just shows that you’re serious about getting your work done and growing your knowledge.
On that note, in a toxic company culture that punishes admitting ignorance, this may not be true. Ideally I would say leave that company, but that is not feasible for everyone, depending whether the company controls your visa, or whether you’re not very experienced yet and it’s an employer’s market. If this is you, I’m sorry that the rest of this article won’t really speak to you, because I don’t have that experience.
Otherwise, if you’re new to a given Slack HQ, get to know the public channels that are relevant to your work. My company is of a size that the “all engineering” channel is often the right place for any technical question that is even slightly cross-cutting. And if it’s even slightly non-technical, “all product development” also works well. The ability to quickly get an answer or at least find out whom to ask is one huge advantage of the Slack HQ that a physical HQ can’t match, and it’s done wonders for my own ability to ramp up on things.
Most companies have some amount of siloed knowledge and gaps in their documentation. By asking your “stupid” question in public, you’re helping your department to see these holes so they can be prioritized and filled. If you DM instead, this type of awareness is not raised. One interrupted individual won’t be able to integrate the knowledge about what gaps exist and advocate for them to be filled.
Of course, this is easy for me to say, in my current position as one of the longest-tenured members of an engineering department. It’s natural to be more afraid of looking stupid when you’re newer. My suggestion is, at least use your team channel rather than a DM, but if the question is not team-specific, considering going wider. Also briefly mention the places you already searched for an answer, and any partial answers or red herrings you found so far. Not only can this boost your confidence to justify asking the question, but it’s even more useful information for leaders who are trying to improve documentation or processes.
2. I don’t know what channel to use, but I know that <individual’s name> usually knows about this topic or can get this stuff done.
This won’t be the last time you ask for help, so it’s worth your while to make a list — whether mental, digital, or even physical (taped to the monitor?) — of your go-to public help channels. Know ahead of time where to ask for help with each of the following topics, so you don’t have to figure it out at a moment when your mental energy is already absorbed by a puzzle.
- Dev tooling/setup issues
- General front-end questions
- General back-end questions
- Any special topics relevant to your work (async code, data pipelines, AI stuff…)
- Architectural questions
- Unowned/cross-cutting technical questions
- Unowned/cross-cutting product-level questions
Alternatively, if you know that <individual’s name> usually knows about a given topic, you can also just go to their team channel (I list my team channel in my Slack profile) and ask there.
If this sounds like too much trouble, ask yourself
- What you’ll do when <individual’s name> eventually leaves the company.
- Why there isn’t a better process for your request (hint: maybe because you’re hiding the problem in DMs).
- Why there isn’t documentation to answer your question (same hint).
3. I need a fast response / already tried a public channel and no one responded.
Depending on the individual’s time management and your department culture, DMing may actually result in a slower resolution to your issue. Here are some non-DM ways to make a helpful, timely response more likely.
Follow team processes
If posting in a team channel, look for clues as to how that team prefers to receive interruptions. This may be in the channel description at the top of the window, or in a Canvas that opens automatically on your first visit to the channel (my new favourite Slack feature). Some may have a special Slack handle connected to a rotation, or a Slack workflow to automatically triage requests, or they may prefer that you file a ticket, etc.
If you do this and still get no response in a reasonable time frame, you could either try a general channel, escalate the blockage to your manager, or speak directly to the other team’s manager, according to your comfort level and your company’s culture.
Make a clear request
Especially when posting in a large channel, be concise and make sure 3 things are made clear in the first couple of sentences: (1) your desired outcome, (2) the level of urgency, and (3) the subject matter you need help with (at least as far as you can tell). Examples:
- I’m working on a new feature (indicating normal urgency) and am having trouble with input validation (indicating desired outcome) using ABC REST framework (indicating subject matter). [More detail comes after.]
- My team has 5 support cases this week (urgency) related to timeouts on XYZ service (subject matter). Is anyone available to help troubleshoot (desired outcome)? [More detail comes after.]
- I’ve been stuck since yesterday (urgency) with a frontend unit test that always fails no matter what with [insert error message] (subject matter / desired outcome). Here’s a link to the draft PR, can anyone spot the issue? [More detail, what you’ve tried so far, comes after.]
Tag the right person/handle
If you know that <individual’s name> is likely to be able to help and others are unlikely, you could just tag that person in your public-channel message.
If you hesitate to do so, consider why. Is it because you know that person is too busy already? If possible, tag a relevant group handle instead of the individual.
Depending on your department culture, a public message tagging that individual for help may or may not be kinder than a DM. In some contexts, it may cause an increased sense of pressure on the individual, because everyone can see how long it takes them to respond, how well they respond, etc. On the other hand, for me, I’d much prefer a public tag to a DM, because (a) it allows others to respond if they can, and (b) if I’m getting more requests than I can handle, I want that problem to be visible to my leaders. A DM makes me feel more pressure, because it’s a context where no one else can help me respond or even see the demand on me.
It comes down again to how healthy your department’s culture is. How is it perceived if an individual is seen to get 10 interruptive requests per day and falls behind on responses? (By interruptive requests, I mean requests of a kind that are not their primary job responsibility.)
If it reflects badly on them, that seems like an unhealthy culture, and that’s a hard thing to change. Perhaps a DM is the best you can do in the short term.
In a healthier culture, that situation reflects a need for change in the department, so the more visible, the better. Consider what kind of culture you have.
Summary
I said my suggestion was simple, but as we are used to as software developers, the details are complex. To put it as briefly as possible:
- Default to public channels for work-related requests, questions, and discussions, unless there’s a reason not to.
- Consider what will be most effective for you, both short-term (getting the best help on your issue) and long-term (building connections in your company).
- Consider also your department culture, and which choice will minimize stress from interruptions. In a healthy culture, the short-term and long-term are aligned. In an unhealthy culture, they are harder to reconcile. Do what you can to make systemic issues visible to your leadership.