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)?
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.<p>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.<p>I think human support is a necessary feature and multiplier. It's sort of like a game where someone needs to be the healer.<p>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.<p>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.
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.
6 person team.<p>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).<p>More rigid stuff like coding style guides, design patterns, API docs, design specs were saved in a SaaS that's basically a Basecamp-clone.<p>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.
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.
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.