[tonygrue]

For me depends on what the knowledge is.

About Code: The only way I've found that works is comments in the code itself (or docs generated from code annotations).

Processes: Playbooks and Automation. Playbooks - DropboxPaper/Google docs that anyone can edit with things like "How to Build and Push XYZ Component", "What to do when the XYZ Server stops responding". Automation - When feasible turn the most used playbooks (or pieces of them) into scripts/tools. Make them the default way of doing things; and any time a break is discovered, fix the tool instead of working around it. Remove outdated/unused tools, so it doesn't feel like a wasteland.

Knowledge on how we do things: You don't want to write docs about 'how to do XYZ'. It will quickly be out-of-date and it'll be horribly micromanagey. But if you and your team collaborative define and document your team values or project/codebase/module principles, I've found you can onboard people quickly and reduce communication. They key here is referencing to the documents when you make a decision guided by them, to keep the docs fresh in peoples minds. And to regularly update the docs.