September 1, 2026
Hi Everyone,
About 10% of a company's internal documents get 90% of the reads. That's what David Nunez found after running documentation at Uber and Stripe.
Most of what teams write down goes unread, while the questions people ask every week stay unanswered.
Today we're breaking down the four documents worth writing, and how to skip the rest.
1. A getting-started guide for new hires
Without one, a senior person teaches every new hire the same things, one by one.
You don't have to write it all by yourself. Ask each new hire to note down what they learned in their first few months.
After three or four hires, you have a solid guide, and it improves with every person who joins.
2. Runbooks for the tasks only one person knows
A runbook lists the exact steps for a recurring task, like restoring a server or running month-end invoicing, so the work doesn't depend on one person being available.
At Uber, internal search data showed engineers struggled most with an obscure server tool where a wrong change could take the service down. Once Nunez's team documented it properly, complaints dropped, and the tool showed up far less often in outage reviews.
Start by writing one runbook for the problem your team hits most often.
3. A record of big decisions
Keep one page per major decision. Write what you decided, why, and what you rejected. The format works for pricing, org design, and vendor choices alike.
Months later, when someone asks why you chose this vendor or this price, the answer is written down instead of reconstructed from memory.
βWe built a one-page template for exactly this. Fill in the outcome row and file it.
4. One page on how you work
GitLab, fully remote since 2011, runs on a public handbook of more than 2,000 pages. It got that way through one rule anyone can copy.
When a question comes in (say, someone asks in Slack how client discounts get approved), you don't type the answer into the chat. You write it into the shared document first, then reply with the link. The next person who asks gets the same link. You've answered the question once, for everyone.
Start small. Pick the tool you already have β Notion, Google Drive, a wiki β and make it the one place answers go. A handful of well-categorized pages is enough, as long as everyone knows that's where to look.
What to skip, and how to keep the rest trusted
Skip detailed procedures for routine, low-stakes work. They rarely get read and go out of date fast.
People also stop trusting internal docs when they arenβt maintained, so give every document a named owner, and delete outdated ones instead of leaving them up.
Try this today
Pull up the questions your team asked most in Slack this month.
If Claude or ChatGPT is connected to your Slack, this takes five minutes. Paste this in:
"Search [#general, #support, #ops] for questions people asked in the last 30 days. Group similar questions into topics and rank the topics by how often they come up. For the top five, show me the topic, roughly how many times it was asked, and two example questions in the askers' own words. Then tell me which topic you'd document first, and why."
Then write one document for the biggest topic this week. We made you a one-page template to start from.
Go deeper
π First Round Review: Investing in Internal Documentation: A Brick-by-Brick Guide for Startups β read this before you write anything; the sections on picking your top five topics and deleting old docs are worth the click alone.
π DORA: Accelerate State of DevOps Report 2021 β open this if you want the numbers behind documentation as a performance multiplier; Google's team found it improves nearly everything else.
π GitLab: The importance of a handbook-first approach β see how a fully remote company answers every question once, and borrow the "write it down first, then share the link" rule.
π Spotify Engineering: When Should I Write an Architecture Decision Record β use this to set up decision records, including a simple test for which decisions deserve one.
Coming up tomorrow
Tomorrow we'll show you how HubSpot handed over the CEO job without missing a step, and how to build that kind of succession readiness on your own team.
Thanks for reading!