5 ms·

> As much as possible, encourage people to post anything of interest to the public channels. Notice that I’m saying public channels, and not private messages, b

> As much as possible, encourage people to post anything of interest to the public channels. Notice that I’m saying public channels, and not private messages, because we don’t ping anyone unless it’s necessary. We just want to make the information available. This. Every time you send a private message is Slack or send an email to just one other person, it's like taking a $100 bill and lighting it on fire. Just because only one other person needs that information right now doesn't mean that in a couple years some new hire won't spend six months just staring at their monitor and not writing code because they can't figure out wtf is going on.

smaddox 6y ago
Does posting it in a public channel really help solve that problem, though? With a powerful enough search method, maybe. But does Slack search qualify?
- munchbunny 6y ago
  From experience, no. The problem with team chat is that it has very low signal to noise ratio, which makes it hard to find structured info.
- noisem4ker 6y ago
  I've found Slack search to be impressive in a multi-thousand people workspace. Results came up very fast and well summarized.
CPLX 6y ago
As someone who is extremely supportive of the concept of creating a culture of written communication I have to say I've had a pretty hard time understanding why people think slack or other similar chat-style communication even qualifies. Don't get me wrong Slack is super useful, and I use it to communicate with my team all the time. But I don't think searching old chat messages is a good experience at all and I don't even think it even really qualifies as a solution to the concept in this article. To me a culture of written communication involves actually spending the necessary time to write down explanatory copy that helps inform other people. That could be things like comments in code, annotations or instructions for a commonly used document, detailed proposal or recommendation memos, FAQ's, guides to how processes work, and so on. There's this theory that this information already exists and the goal is to capture it. I'm not so sure, my suspicion is that you have to put in work to create it if you want to see real results.
MattGaiser 6y ago
Wouldn't that still need curating to be useful? Sure, you can dump a ton of stuff into the public Slack channel, but it turns into a mess of wrong stuff, disjointed ideas, hypothetical chatter, and unanswered questions. People are still going to ask someone else rather than trying to go through that hairball. My team probably has half our knowledge in our general dev chat on Teams. Nobody even tried to use that.
- munchbunny 6y ago
  My team probably has half our knowledge in our general dev chat on Teams. Nobody even tried to use that. Same, my team probably has most of our knowledge buried among the various document repos and wikis, but it's all at varying levels of out of date between a few days and a few years. The core of the problem, I think, is that the digesting and organizing of information has to happen somewhere. If you want to make it easy to dump info for the future, then you make it low friction to write it, but because nobody's taking time to organize it, it's going to be a pain for future readers to glean useful insight from it. On the other hand, if you require the writers to organize the info and occasionally update obsolete articles, it'll be much more useful for future readers, but it'll be much harder to contribute info in the first place. IMO the next big win on this problem will be whenever someone comes up with an actually good search engine to organize this sort of team info. Stack Overflow did a great job with public info by relying on Google for search, but there isn't really an equivalent for internal info. If we have this, we can rely a bit more on automation to reduce the amount of organizing the writers need to do in order to produce usable documentation.
- mattbk1 6y ago
  Posting public questions can be a very fast way to find the "someone else" to ask, in my experience.
Cthulhu_ 6y ago
You're assuming the new hire will be able to process all information and - if I'm reading your comment correctly - read all messages and / or e-mails sent to everyone. That's unlikely and unreasonable, nobody has the energy to trudge through all information when they join a new company. Instead, make sure you have a good onboarding procedure. Documentation is important, but categorize it in e.g. a wiki with a solid landing page, so that new hires can get up to speed quickly on the one hand, and know where to find information relevant to what they need to know on the other. I've been at my current company for nearly six months now and I feel like I've barely scratched the surface in the application (which was started eight years ago, but built on top of two more decades of domain specific knowledge and platforms).
- Alex3917 6y ago
  > You're assuming the new hire will be able to process all information and - if I'm reading your comment correctly - read all messages and / or e-mails sent to everyone. No, just that they'll search for whatever information they need to do their jobs within the company's archived email. The nice thing about email is that each message is dated and comes with the author and the author's contact info, so you know exactly who to ask if they're still at the company. (And if they're not at the company, you can ask if you're allowed to contact them depending on the context, or at least figure out who they worked with.)
dragonwriter 6y ago
> Every time you send a private message is Slack or send an email to just one other person, it's like taking a $100 bill and lighting it on fire. Maybe, but with a public channel, it's a stack of $100 bills, for the time of everyone who doesn't need it now and won't recall it or be able to find it when they do. “Spam everything to the public channel” is the equivalent of “send everything you find interesting to the All Staff email distribution list". There's good ways of preserving information that multiple people on a team are going to need at different points of time in the future, but posting them to a public Slack channel is pretty far from the target. A team wiki is among the many better options.
- seqastian 6y ago
  A wiki is only as good as the big picture and structure of the people feeding it. Maybe you could use the logs of a chat to feed into a wiki. Just having everyone edit away with that ever is on their plate today, sure sounds like a wiki I don't want to use.
  - dragonwriter 6y ago
    > A wiki is only as good as the big picture and structure of the people feeding it Yes, a wiki is very much imperfect. It's still much better than a public Slack channel, which faces the same limits plus additional ones as it cannot represent the knowledge of big picture structure held by the people feeding it.
    - zozbot234 6y ago
      A private Q&A facility might be a useful middle ground. Then use the most frequently referenced topics in the Q&A as a guide to structuring a wiki.
- Alex3917 6y ago
  > A team wiki is among the many better options. Wikis are generally useless unless you have people whose job responsibilities explicitly include creating content for them and keeping them up-to-date. In my experience, if you have your PMs do this then each PM can cover 8 - 12 developers. Whereas if your PMs are just creating and pointing tickets but not also spending a good percentage of their time on longterm documentation, they can cover more like 12 - 16 developers. Well maintained wikis are fantastic, but you almost never find them because for even a mid-size startup that costs hundreds of thousands or millions of dollars per year. That's the reason for public mailing lists and other email archival products, because you're getting most of the value a well-maintained wiki but with mainly only the nominal cost of paying for the software to keep it running. I've thought a lot about this (obviously, given FWD:Everyone is in this space), and figured out the actual reason why email is so much better than Slack for knowledge retention; it's because with email you're forced to create the metadata before having the discussion, and then the discussion keeps going until people no longer have anything to say that matches the metadata -- subject, participants, visibility level, etc. (Discussions occasionally go off the rails, but less than 5% of the time as long as the organization provides some basic guidance on expectations for communication.) This metadata is key though because not only does it help you find what you need to do your job, but it helps you figure out what you don't need to read, which is perhaps even more important. Whereas with Slack you just start talking, and their software tries to figure out what you were talking about after the fact. But despite having an AI team working on this and having invested millions and millions of dollars into the problem, their software doesn't really work at all, most likely because the problem is basically impossible to do a good job of solving from a computer science perspective. edit: Obligatory self-promotional link: https://www.fwdeveryone.com https://www.fwdeveryone.com
eitland 6y ago
> it's like taking a $100 bill and lighting it on fire. Interesting example, appreciated! Let me try to improve it: it's like taking an envelope that might or might not contain an $100 bill and lighting it on fire. Not everything is useful, but we don't know until later. Also, the company doesn't get that $100 bill right away, only if they can dig it out 2 years later. Still, good example.
- Alex3917 6y ago
  > the company doesn't get that $100 bill right away, only if they can dig it out 2 years later. There's a fundamental tradeoff between the percentage of communication that gets captured and the usefulness of search. We take the position that email threads shouldn't be archived unless someone flags them to be saved, on the assumption that for most employees there are only a couple dozen (if that) really important email threads being created per year. But the value preserving this knowledge can be extremely high. E.g. most SaaS startups are built in part by wiring together a few third-party APIs, and the process of partnering and integrating with those third parties often involves email threads with hundreds of messages back and forth. If those threads get lost because the person leaves the company then that becomes extremely problematic.
  - eitland 6y ago
    > We take the position that email threads shouldn't be archived unless someone flags them to be saved, on the assumption that for most employees there are only a couple dozen (if that) really important email threads being created per year. This probably differs from team to team I'm more or less sure I have been saved more than once by people who didn't tidy up after themselves and so left information behind even when they planned to remove it. Sometimes the reason seemed to be that people didn't care, on other cases it seemed like a way to try to keep knowledge for themselves. In those cases we would have been much better off if the default wasn't one-to-one. Not because they wouldn't have tried to circumvent it but because it would slip up more often. (Of course the real problem on such places is the culture though.)
benhurmarcel 6y ago
My company has been pushing for years the idea to limit the number of recipients to each email you send, simply because people spend so much time reading and managing email.

smaddox 6y ago

Does posting it in a public channel really help solve that problem, though? With a powerful enough search method, maybe. But does Slack search qualify?

munchbunny 6y ago
From experience, no. The problem with team chat is that it has very low signal to noise ratio, which makes it hard to find structured info.
noisem4ker 6y ago
I've found Slack search to be impressive in a multi-thousand people workspace. Results came up very fast and well summarized.

CPLX 6y ago

As someone who is extremely supportive of the concept of creating a culture of written communication I have to say I've had a pretty hard time understanding why people think slack or other similar chat-style communication even qualifies. Don't get me wrong Slack is super useful, and I use it to communicate with my team all the time. But I don't think searching old chat messages is a good experience at all and I don't even think it even really qualifies as a solution to the concept in this article. To me a culture of written communication involves actually spending the necessary time to write down explanatory copy that helps inform other people. That could be things like comments in code, annotations or instructions for a commonly used document, detailed proposal or recommendation memos, FAQ's, guides to how processes work, and so on. There's this theory that this information already exists and the goal is to capture it. I'm not so sure, my suspicion is that you have to put in work to create it if you want to see real results.

MattGaiser 6y ago

Wouldn't that still need curating to be useful? Sure, you can dump a ton of stuff into the public Slack channel, but it turns into a mess of wrong stuff, disjointed ideas, hypothetical chatter, and unanswered questions. People are still going to ask someone else rather than trying to go through that hairball. My team probably has half our knowledge in our general dev chat on Teams. Nobody even tried to use that.

munchbunny 6y ago
My team probably has half our knowledge in our general dev chat on Teams. Nobody even tried to use that. Same, my team probably has most of our knowledge buried among the various document repos and wikis, but it's all at varying levels of out of date between a few days and a few years. The core of the problem, I think, is that the digesting and organizing of information has to happen somewhere. If you want to make it easy to dump info for the future, then you make it low friction to write it, but because nobody's taking time to organize it, it's going to be a pain for future readers to glean useful insight from it. On the other hand, if you require the writers to organize the info and occasionally update obsolete articles, it'll be much more useful for future readers, but it'll be much harder to contribute info in the first place. IMO the next big win on this problem will be whenever someone comes up with an actually good search engine to organize this sort of team info. Stack Overflow did a great job with public info by relying on Google for search, but there isn't really an equivalent for internal info. If we have this, we can rely a bit more on automation to reduce the amount of organizing the writers need to do in order to produce usable documentation.
mattbk1 6y ago
Posting public questions can be a very fast way to find the "someone else" to ask, in my experience.

Cthulhu_ 6y ago

You're assuming the new hire will be able to process all information and - if I'm reading your comment correctly - read all messages and / or e-mails sent to everyone. That's unlikely and unreasonable, nobody has the energy to trudge through all information when they join a new company. Instead, make sure you have a good onboarding procedure. Documentation is important, but categorize it in e.g. a wiki with a solid landing page, so that new hires can get up to speed quickly on the one hand, and know where to find information relevant to what they need to know on the other. I've been at my current company for nearly six months now and I feel like I've barely scratched the surface in the application (which was started eight years ago, but built on top of two more decades of domain specific knowledge and platforms).

Alex3917 6y ago
> You're assuming the new hire will be able to process all information and - if I'm reading your comment correctly - read all messages and / or e-mails sent to everyone. No, just that they'll search for whatever information they need to do their jobs within the company's archived email. The nice thing about email is that each message is dated and comes with the author and the author's contact info, so you know exactly who to ask if they're still at the company. (And if they're not at the company, you can ask if you're allowed to contact them depending on the context, or at least figure out who they worked with.)

dragonwriter 6y ago

> Every time you send a private message is Slack or send an email to just one other person, it's like taking a $100 bill and lighting it on fire. Maybe, but with a public channel, it's a stack of $100 bills, for the time of everyone who doesn't need it now and won't recall it or be able to find it when they do. “Spam everything to the public channel” is the equivalent of “send everything you find interesting to the All Staff email distribution list". There's good ways of preserving information that multiple people on a team are going to need at different points of time in the future, but posting them to a public Slack channel is pretty far from the target. A team wiki is among the many better options.

seqastian 6y ago
A wiki is only as good as the big picture and structure of the people feeding it. Maybe you could use the logs of a chat to feed into a wiki. Just having everyone edit away with that ever is on their plate today, sure sounds like a wiki I don't want to use.
- dragonwriter 6y ago
  > A wiki is only as good as the big picture and structure of the people feeding it Yes, a wiki is very much imperfect. It's still much better than a public Slack channel, which faces the same limits plus additional ones as it cannot represent the knowledge of big picture structure held by the people feeding it.
  - zozbot234 6y ago
    A private Q&A facility might be a useful middle ground. Then use the most frequently referenced topics in the Q&A as a guide to structuring a wiki.
Alex3917 6y ago
> A team wiki is among the many better options. Wikis are generally useless unless you have people whose job responsibilities explicitly include creating content for them and keeping them up-to-date. In my experience, if you have your PMs do this then each PM can cover 8 - 12 developers. Whereas if your PMs are just creating and pointing tickets but not also spending a good percentage of their time on longterm documentation, they can cover more like 12 - 16 developers. Well maintained wikis are fantastic, but you almost never find them because for even a mid-size startup that costs hundreds of thousands or millions of dollars per year. That's the reason for public mailing lists and other email archival products, because you're getting most of the value a well-maintained wiki but with mainly only the nominal cost of paying for the software to keep it running. I've thought a lot about this (obviously, given FWD:Everyone is in this space), and figured out the actual reason why email is so much better than Slack for knowledge retention; it's because with email you're forced to create the metadata before having the discussion, and then the discussion keeps going until people no longer have anything to say that matches the metadata -- subject, participants, visibility level, etc. (Discussions occasionally go off the rails, but less than 5% of the time as long as the organization provides some basic guidance on expectations for communication.) This metadata is key though because not only does it help you find what you need to do your job, but it helps you figure out what you don't need to read, which is perhaps even more important. Whereas with Slack you just start talking, and their software tries to figure out what you were talking about after the fact. But despite having an AI team working on this and having invested millions and millions of dollars into the problem, their software doesn't really work at all, most likely because the problem is basically impossible to do a good job of solving from a computer science perspective. edit: Obligatory self-promotional link: https://www.fwdeveryone.com https://www.fwdeveryone.com

eitland 6y ago

> it's like taking a $100 bill and lighting it on fire. Interesting example, appreciated! Let me try to improve it: it's like taking an envelope that might or might not contain an $100 bill and lighting it on fire. Not everything is useful, but we don't know until later. Also, the company doesn't get that $100 bill right away, only if they can dig it out 2 years later. Still, good example.

Alex3917 6y ago
> the company doesn't get that $100 bill right away, only if they can dig it out 2 years later. There's a fundamental tradeoff between the percentage of communication that gets captured and the usefulness of search. We take the position that email threads shouldn't be archived unless someone flags them to be saved, on the assumption that for most employees there are only a couple dozen (if that) really important email threads being created per year. But the value preserving this knowledge can be extremely high. E.g. most SaaS startups are built in part by wiring together a few third-party APIs, and the process of partnering and integrating with those third parties often involves email threads with hundreds of messages back and forth. If those threads get lost because the person leaves the company then that becomes extremely problematic.
- eitland 6y ago
  > We take the position that email threads shouldn't be archived unless someone flags them to be saved, on the assumption that for most employees there are only a couple dozen (if that) really important email threads being created per year. This probably differs from team to team I'm more or less sure I have been saved more than once by people who didn't tidy up after themselves and so left information behind even when they planned to remove it. Sometimes the reason seemed to be that people didn't care, on other cases it seemed like a way to try to keep knowledge for themselves. In those cases we would have been much better off if the default wasn't one-to-one. Not because they wouldn't have tried to circumvent it but because it would slip up more often. (Of course the real problem on such places is the culture though.)

benhurmarcel 6y ago

My company has been pushing for years the idea to limit the number of recipients to each email you send, simply because people spend so much time reading and managing email.