Internal documentation is the work everyone agrees matters and nobody prioritizes. Part of the reason is that it felt unmeasurable, so it always lost to shipping features. The research changed that. Once you price the hours people burn hunting for information, good docs stop being a nice-to-have and start looking like one of the cheapest returns you can buy.
Key Takeaways
- Knowledge workers spend around 19% of the workweek (about 1.8 hours a day) just searching for and gathering information (McKinsey).
- Each one-point gain in a developer-experience index correlates to about 13 minutes saved per developer per week (getDX).
- For a 100-person team, a modest improvement is thousands of reclaimed hours, an easy positive ROI.
- Docs compound hardest for distributed teams and onboarding, where you can't just ask the person next to you.
The Cost of Not Writing It Down
The hidden cost of thin docs is search time, and it's enormous. McKinsey found knowledge workers spend roughly 19% of their week, about 1.8 hours a day, searching for and gathering information (McKinsey). For engineers it's at least that high, because so much of the job is finding the one config, the undocumented setup step, or the person who knows why the weird thing is weird. That's close to a full day a week, per person, hunting instead of building.
Good docs attack that directly. getDX's research tied documentation quality to their Developer Experience Index and found each one-point improvement correlates to about 13 minutes saved per developer per week, roughly 10 hours a year per developer. It's the same time-reclamation story as technical debt, where Stripe found developers lose about 17 hours a week to friction. Docs are one of the cheapest levers on all of it.
A Concrete Version
Do the math on a 30-person team. If each engineer loses even one hour a week to a search a good doc would have prevented, that's 30 hours a week, roughly 1,500 hours a year, close to a full engineer's worth of output evaporating into "where is that thing?" Spend two weeks writing the setup guide, the architecture overview, and the runbooks, and you claw a big chunk of that back permanently, and it keeps paying with every new hire.
Why It Compounds for Distributed Teams
Documentation matters most exactly where informal knowledge-sharing breaks down. In a co-located team, a missing doc is a quick desk question. On a distributed team it's a blocked engineer waiting hours for a reply, or worse, guessing wrong. Written knowledge is the substitute for the hallway, which is why async-first teams treat docs as core infrastructure, not overhead.
| Missing doc costs... | Co-located | Distributed |
|---|---|---|
| Time to unblock | A quick question | Hours of waiting |
| Onboarding speed | Slower | Much slower |
| Knowledge risk | Contained | Concentrated in a few heads |
The Honest Counterpoint
Docs have a real failure mode, and it isn't "too much documentation." It's stale documentation, which is worse than none, because a confidently wrong doc sends people down the wrong path with full trust. So the goal isn't to document everything. It's to document the high-traffic, slow-changing stuff (setup, architecture, runbooks) and keep it current, while letting fast-changing details live closer to the code. Write the docs that get read a hundred times, not the ones written once that rot.
Docs and Onboarding
The clearest place docs pay back is onboarding. A new engineer's slow first commit is usually a documentation gap, not a weak hire, as we covered in engineering onboarding metrics. Fix the docs once and every future hire ramps faster. For distributed and nearshore teams, that's the difference between a two-week ramp and a two-month one. See available engineers.
Frequently Asked Questions
Does documentation actually improve productivity?
Yes, measurably. McKinsey found workers lose about 19% of the week to searching for information, and getDX tied each one-point developer-experience gain to roughly 13 minutes saved per developer per week. Docs cut directly into both.
Is documentation more important for remote teams?
Much more. Written knowledge replaces the hallway conversation. On a distributed team, a missing doc blocks an engineer for hours instead of seconds.
What documentation has the highest ROI?
The high-traffic, slow-changing stuff: setup, architecture overviews, and runbooks. They speed up every new hire and get read constantly. Keep them current, because a stale doc is worse than none.
The Bottom Line
Documentation is no longer an unmeasurable nice-to-have. McKinsey prices the search problem at nearly a day a week per person, and the DevEx data shows how much good docs claw back. Treat internal docs as infrastructure with a real return, and keep the high-traffic ones current.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
