Remote Shorts is live on Product Hunt today ๐Ÿš€๐ŸŽ‰

Welcome! We are helping each other build remote careers. Are you looking to build one?
  1. 10

Thanks, @hrishikesh :). I wanted to make a post today and wasn't sure what to write about. So the side-bar topic suggestions were useful.


We started working on creating a team wiki late last year (around December, I believe). We had doubled our team size (well, it was only from 4 to 9 ๐Ÿ˜…, but still) and I felt that onboarding had become quite tricky.ย 

You see, till then all the nuances of work were stored in each of our minds. So, even for the smallest of things people had to reach out to the concerned person. It would be a mess if that person was not working that day and was also not reachable by phone. And all this when we were still co-located.

So, we started by documenting every process in our startup. Initially, we broke it down by different functions and detailed each task in the startup. Next, we made a generic team document which contained other standard topics - leave policies, meetings, (and later remote work policies), etc.

I didn't want all this information to be in individual google docs. So, we used Slite which has a generous free plan. It has a slack-like structure but for notes - it basically organises information in the form of channels (or you can imagine folders).

Now, we start every new initiative by first documenting it in Slite. This helps in ensuring that any miscommunication is corrected immediately. I think this has become even more critical with us becoming a remote team.



1. Have you implemented a "Team Wiki" for your company ๐Ÿ“•?

2.ย If yes, what prompted you? If not, why don't you think it is necessary ๐Ÿค”?

3. Lastly, which tool are you using for it ๐Ÿ”ง?


  2. 5

    Good post . Nice to hear about slite. Personally, we haven't felt a need for a team wiki yet basically because were just 6 employees and we don't have policies :D.ย  We just trust people to do the right things. I guess when we grow big we have start thinking about this!

    1. 2

      Great, I also believe a full-fledged isn't needed for smaller teams. But where do you document SOPs or processes?

    2. 4

      We used to use a team GitHub repo + wiki for our onboarding docs and general information. But we've moved everything to Notion, which is much better organized and is now used for just about everything.

      1. 3

        That's interesting! Notion is a great tool to keep docs organized and accessible. What prompted you to choose Notion over others?

        1. 2

          The GitHub wiki is super basic compared to Notion - sharing/permissions, content formatting, content types, article linking, commenting, etc. We did have some internal docs in Google Docs as well, but the team preferred Notionโ€™s organization of โ€œpagesโ€ over Googleโ€™s pile of random folders and files.

        2. 2

          I can clearly see the advantage of moving to Notion but what use-cases particularly pushed the move in your case?

          1. 2

            We started doing some high-level project planning in Notion and realized we could move our internal wiki from GitHub and our other docs from Google Docs into one tool. So Notion has become our central hub for everything given its flexibility.

        3. 3

          I'm in the process of building more docs into Clickup, and making that whereย  our wiki(s) live. Anyone else gone this route? The wiki functionality (docs) in Clickup seems sufficient for the task, and doing that instead of adding another tool to the tech stack seemsย way better.ย 

          1. 1

            Personally, I haven't used Clickup (in general, not just for docs). But I have only heard really good things about it.

            I had a look at their docs (their product video) and it looks very neat - quite Notion like.

            So, I agree, it seems more than sufficient. The entire headache of having to switch tools is really really big. I am personally not happy even having one more tool open beyond Slack and my browser. So, even my to-dos are currently being noted in Slack itself (weirdly, messages to myself ๐Ÿ˜…).

          2. 2

            Great post Karthik!

            Keen to hear how @tristanpollock-597 @aaron-595 @tomasjasovsky-602 @ryanhitchler-605 @bradmiller-606 @shiva-607 implementing their Team Wiki :)

            1. 2

              Thanks hrishikesh. We started out putting all our docs in a git repo. Unfortunately that restricted it to people that were able to handle markdown and git, and also meant the docs went stale more quickly. We've since moved them all to confluence which I like because it has edit history, but is also accessible for non-tech functions.

              The rule we have is that the person being onboarded is resposible for maintaining the docs for the next person that's hired. That may mean updating things themselves as they discover them (we've got an internal glossary for example), or asking for bits to be updated in docs rather than communicating on a call.

              Our documentation still gets a bit stale, but it's certainly more alive than when we had them stuck in a git repo :)

            Remote Shorts - Stay updated with the best bite-sized remote work content | Product Hunt