One of the initial goals I shared with the team at Chronicle of Philanthropy was to build a “culture of documentation” at the organization. Shortly after, I started rolling out Slab as the knowledge hub — and it’s still going strong. Here’s what actually worked about turning it into a habit, not just a tool.
Why “culture,” not just “documentation”
When people routinely reach for documentation a decision, cite it in a disagreement, or write the page while the process happens instead of after — that’s a culture shift.
These practices are necessary for any documentation effort to succeed. Without instilling them an organization’s culture, documentation tools become graveyards.
Here’s why that shift is worth pushing for:
- It changes how decisions get made and defended. When “where’s that written down?” is a normal question to ask in a meeting, disagreements get resolved against a shared record instead of whoever argues loudest or remembers most confidently.
- It reduces single-person dependency risk. As more people rely on and contribute to the documentation, they become more familiar with it — and the tools and processes it describes. They become more familiar with the tools they use, rather than asking the tech team to do everything.
- It builds institutional memory that outlasts any one person’s tenure. New hires years later can learn from decisions and incidents they never witnessed, because writing it down was the default, not the exception.
- It compounds instead of decaying. Recurring problems get solved once and referenced forever, rather than relearned every time they resurface. Moreover, it empowers knowledgable staff to point others to documentation, rather than describing “how to” steps over and over.
- AI raises the stakes. An AI assistant is only as useful as the institutional knowledge it can draw on — it can’t sit in on the meeting where a decision got made, or ask a veteran employee why something’s built the way it is. A real documentation culture is what turns an org’s knowledge into something an AI (or a new hire) can actually reference, rather than knowledge trapped in a handful of people’s heads.
At the Chronicle, I rolled out Slab for our knowledge base. Their features emphasized my team-first approach to documenting; plus, the tool is free for nonprofits.
Laying the groundwork and rolling it out
Documentation isn’t just “how to” procedures — it’s any and all record-keeping. That’s the primary definition to instill in your team: if there’s something worth knowing, we need to keep a record and we need to do so transparently. (Of course, executive-level information is often privileged and proper to keep walled-off on those circumstances.)
For this reason we often used the terms “intranet” or “knowledge base (KB)” to describe our tool.
Documentation isn’t just “how to” procedures — it’s any and all record-keeping.
Here are some steps to get moving:
Document the meta-layer first. Don’t just turn the tool on — publish the instructions for how to think about it. Before asking anyone to contribute, write the “why,” the “how to use the tool,” and the “how to write well” docs. Many of your users have never written documentation, nor read it. Share the basics and refer back to it: what we might document, how to get started, and best practices for writing it well.
Set light governance, not heavy process. The only real rules we enforced were: no new top-level topics and no public topics. Individual teams got their own folders to structure themselves. That’s enough guidance to prevent chaos without enough process to kill momentum.
Keep gaps visible instead of hidden. We seeded stub pages like “Our Founding and History” with the skeleton and flagged what was missing, rather than waiting until the picture was complete.
A documentation backlog. We kept an Asana project tracking the documentation still to complete and assigned the tasks to staff across the organization. It got them started with ideas for what to include.
Let templates and status tags carry the governance load. Labels like [Template], [WIP], and [RETIRED] lived right in the document title. Anyone browsing instantly knew what was authoritative, draft, or dead — no separate tracker or spreadsheet needed.
Adding the important stuff. If your tool is the primary source of truth for many things, staff will use it and think of it more often. Here are some other things to include:
- Staff handbook and policies
- Holidays and vacation calendars
- HR processes for PTO, leave, reimbursements
- Copies of All-Staff messaging and announcement
- Recordings of All-Staff meetings
- Team bios
Instilling the Culture
The difference shows up in who initiates it. When contribution is understood as something everyone owes the team, not as a task handed to “the documentation person,” then you know you’re in a good place.
Stakeholders in every team. Ensure you have a primary person on each team who is excited and ready to add content. This person will be your proxy in team meetings.
Cross-team collaboration. Use this for management buy-in; because every team struggles with silos and collaboration. Leaders should encourage their teams to “add it to the KB” any share that information with peers instead of just sending an email that will be hard to find later.
Have a script ready. “Is that in the KB?” and “That’s been documented here,” for example. Help your advocated know good ways to reference the tool in their conversations. Instead of recapping a how-to every time they are asked, document it and share the link.
There’s a lot that can be done to “gamify” documentation. You can automate posting to a Slack channel anytime something new is published; you could keep a leaderboard; you could shout-out new posters.
But the other side of the coin is to train people against being passive-aggressive when referencing the tool. When a peer is asking for help, but you direct them to a URL, it’s really easy to come off that way (“Let me Google that for you…”)
Lessons to abide by
Keep the bar low: write short. Across our knowledge base, the median document length was around 285 words. Few items need to be a manual; instead, add many single-answer posts and link them together. This low bar is likely why we scaled our KB to hundreds of documents instead of stalling at a handful of long ones nobody finished.
Title help docs as the question someone would actually ask. “I want to change my Microsoft password. What do I do?” finds people faster than a formal header like “Password Reset Procedure” — it matches how people search, not how they’d file.
Build in decay prevention. Set up a system — a re-verification date, a recurring review, whatever your tool supports — so documentation gets revisited on a schedule instead of relying on someone remembering to update it. Documentation is only valuable if it’s accurate and reflects current practices.
