Hacker News new | ask | show | jobs
Ask HN: Internal Communication Tools for Startups?
2 points by warmstart 1260 days ago
As a startup with 2 full time founders & multiple part-time employees, we’re now facing some growing pains regarding our internal communication processes. What tools have you found useful for internal communication? We currently use google docs but are considering using some kind of internal wiki
1 comments

When you're saying internal communication, do you mean, sharing informations with the wider group? Or just daily communication with your peers?

A wiki is useful for capturing historical context, and for knowledge sharing. As the one stop shop to refer to. And honestly, kudos to you for thinking about that at an early stage, most companies only start to properly consider disseminating information once many habits have been established and it's harder to train people. There are multiple tools available for this, Discourse, MKDocs, GitBook, Notion, Confluence, MDBook. Some are open source, others are not. It just kind of depends on the set of features you need.

For daily communication, most places I've been in used Slack. I've seen a few use other IM chat options, some self hosted, some not. This is less important IMO, at an early stage, as it should never serve as your main historical communication lookup. As such, you should be free to switch over with relative ease.

Thank you & apologies for the ambiguity. Yes, by "internal communication" I'm referring to sharing information with the wider group; as you alluded, our main goal is to capture historical context & share knowledge. We'd like to ensure everyone understands HOW & WHY we're pursuing any particular strategy, employing a specific processes, going with a specific architecture, etc. Metaphorically, we're trying to make sure everyone on the ship is rowing towards the same direction & for the same reason.

For daily communication, we're all live on a discord video server during working hours so communication there is instant. We're supplementing discord with slack to enable asynchronous communication.

For roadmap & technical management we're already using Jira. Maybe Confluence would be good option?

So, if you're using Jira, Confluence is the obvious choice. However, I for one think it suffers from a big issue, i.e. discoverability.

Because there's no tree-like hierarchy, it's quite difficult surfacing information unless you know exactly what you're looking for. And while some people will know what they want, I find it beneficial to make everything as visible as possible, since more eyes means it's less likely for documentation to go stale.

At work, we've currently trialled a multi doc site using MKDocs, with different topics, published into GCS buckets, and sourced from a git repo. mdbook and gitbook offer similar strategies.

Discourse is similar to stackoverflow, and has the advantage of people being able to ask questions, but it's not the best medium for documentation.

I think something light like mdbook might be the right choice to start with, it wouldn't tie you into any particular solution, as your documentation would live in markdown, but would be consumed from a nicer, more polished UI.

This, of course, assumes you're all familiar and comfortable with markdown, but I think the best solution is to try different tools, so the more portable your actual docs are, the better.

Notion is also a very good candidate, and IMO, a better choice than Confluence, but similarly, discoverability isn't great

Valid considerations & so far I definitely agree Confluence struggles with discoverability. We've started using Confluence & hope to make sure we properly utilize "labels" to help mitigate the discoverability shortcomings. Another shortcoming we found for Confluence was the lack of Q&A options (we wanted support for something similar to an internal stack-overflow). So far we've mitigated that issue by leveraging a Q&A Confluence template from this video: https://youtu.be/IkRmyUCnRDo?t=144

Leveraging markdown to enable service agnostic documentation sounds really interesting...