return to list of articles

Slack ghosts and work questions

Why asking ex-employees for work related help on Slack is a bad thing

Does your Slack team have ghosts?

The company I work for, Unboxed Consulting, uses Slack for internal communication. We use it so much that even people that have left the company hang around in our social channels. These folks are either single channel guests or have restricted accounts, and sometimes they like to join in on our conversations. It’s awesome because they’re awesome. They’re also easily identifiable thanks to the ghost emoji appended to their usernames.

An observation about work questions

Today I noticed something. A question popped up in one of the project channels and an ex-employee was invited to help shed some light on a situation of uncertainty. Nobody saw this as problematic, including the ghost in question. The thing is… I think that it’s fundamentally problematic.

During a short discussion about this scenario, a suggestion was offered. If nobody that works at the company has the answer and the ghost that may have the answer is online then it’s alright to invite them into the conversation.

I’d like to build up my thoughts on why this is wrong, even if you limit this behaviour to once a month, before I explain why I think it’s so problematic. The general sentiment was that if the person wants to reject the channel invitation or the conversation invitation then they are free to do so. They won’t even have to face any negative implications for rejecting the request. This line of thought was agreed on by several people, including multiple ghosts.

Questions are tit for tat, right?

Some additional rationalising was that because ghosts sometimes ask questions and seek help, that they should reciprocate when asked in kind. Apart from my upcoming reason for why I think this is wrong, let me state my counter-argument to this line of thinking.

If you’re a ghost and you’re asking for help then your questions will be non-domain specific. That is, the questions will likely be technical in nature. They can’t be domain based since nobody will understand the context of the ghost’s new company or projects.

Inversely, any questions asked of ghosts will almost certainly be domain based rather than being technical questions - otherwise there’d be no need to drag them into the conversation (there’s a lot of technically smart people working at Unboxed).

Technical questions are great to help answer and discuss because we are always looking to sharpen our axes and this type of practice helps. Domain related discussions and problems do nothing to further this skill growth. That’s why I believe this specific reasoning is flawed. Sorry ghosts whom I disagreed with.

Why I believe this is all so wrong

So here’s my argument. If your policy allows for one ghost to be asked a question, the default expectation is that any ghost can be asked a client related question in future. The problem here is that the vocal and willing are also speaking out for the polite and unwilling. In a pool of 10 ghosts, if you’re the only one politely declining to help, a stigma will be attached to you. This will happen despite the assertions that there are no negative consequences. We cannot control our own biases.

Some ghosts don’t mind helping. But that’s the problem. Some is not the same as all. I’d help in this scenario, sure. But then again I’m a remote employee so any communication with humans is awesome. But by allowing this to happen, the burden is also placed on those that do not choose to carry it.

But what about…

What if it’s an emergency and the ghost is the only person with knowledge about the problem in question? Then you’ve just been illuminated about a huge problem in your handover process. When an employee leaves a company, it’s the responsibility of the company to extract as much domain knowledge out of them as possible. It’s the bus factor problem without the bus.

Your turn

Is this post a storm in a teacup? Probably. But first they came… Anyway, does your company have alumni and ex-employees on your Slack team? How do you handle situations like this? Tweet me.


Get notified when Pawel releases new posts, guides, or projects