
Ask HN: How does your 10-25 person startup capture internal knowledge? - bbaumgar
Specifically, what processes, tools, and culture have you implemented to ensure systems-level documentation is in place. Are there are other areas that you document (eg. decision rationale, conversations, meeting notes)?
======
muzani
We found that the easiest way is with people. Build some redundancy into it,
so that someone knows even if someone else quits. People won't really read the
docs and docs can't audit code. We had gigabytes of docs; we needed humans to
point out the right one and latest ones.

For example we had a rather complicated cache system, which was fully
documented, multiple times, with full test coverage. But people still got it
wrong.

I think human support is a necessary feature and multiplier. It's sort of like
a game where someone needs to be the healer.

Also when you have all the tools, someone needs to be able to train them, and
someon needs to know the right tools for the right situation.

I recommend about 1 support person per 10 people. Usually technical managers
can also take on this role, but it's better to have someone specialize in it
and not be stuck managing.

------
usermac
We're a 24 person department; not a startup but we act in some ways as one. I
am the in-house tech person and I use a database to record each days work.
It's for myself but I know it will be valuable to the person who follows me so
it it very detailed. I have a daily backup of it and occasionally make it a
PDF just-in-case. I know this doesn't address your overall need. If I were to
do that I'd just make mine shared with the group and have them do entries as
well. It would be a time-line sort of documentation I guess but still super
valuable.

------
cattlefarmer
6 person team.

Based on what I previously learnt at Big Internet Company, I created a slack
channel to log all meeting decisions so that we could quickly refer back to
it. Only works for stuff up to about a month old but is good enough for sprint
retrospectives, planning and OKRs. (and then a few months later I realised we
were still using the free version... but anyway).

More rigid stuff like coding style guides, design patterns, API docs, design
specs were saved in a SaaS that's basically a Basecamp-clone.

Previously I would have tasks, bugs and feature requests, TODOs and FIXMEs,
etc. written up as a repo issue (GitHub/Bitbucket) till I realised no one
bothered reading them. So I moved them to the Basecamp-clone backlog instead
so at least the project manager might glance at them.

------
usermac
A Google Doc, shared would also do the trick. I was first thinking EtherPad
and I did that for years in-house but then I realized Google Doc is just that
only better as I didn't have to add plug-ins to get images. See my other
comment for what I do myself, professionally.

------
dabockster
My last role at a small business ran an internal MediaWiki containing all the
technical knowledge and documentation that we brought to the table. We were
able to write both small summaries and long step-by-step instruction guides.

------
dyeje
I love Nuclino personally. Just powerful enough, not as bloated as Wiki
solution.

