Engineering docs cost $50,000/year. Nobody talks about it.

There's a line item in your engineering budget that nobody accounts for: the time your engineers spend writing and maintaining documentation. It doesn't appear in any project plan, it's never estimated in sprint planning, and it's rarely discussed in retrospectives. But it's real, it's expensive, and for most teams it's one of the largest untracked costs in the department.

A senior engineer in the US earning $180,000-$220,000 per year costs roughly $85-$105 per hour when you include benefits and overhead. A senior engineer in the UK earning £80,000-£120,000 costs roughly £50-£75 per hour on the same basis.

If that engineer spends five hours per week on documentation, writing wiki pages, updating architecture docs, documenting API changes, explaining decisions in long-form text rather than code, the annual cost is somewhere between $22,000 and $27,000 in the US. Across a team of ten engineers each spending three to five hours per week on docs, the total is $130,000-$270,000 per year in engineering time spent on writing rather than building.

These numbers are conservative. They don't include the time spent in Slack explaining things that should be in the docs, the time spent in meetings reconstructing context that was never documented, or the time spent answering the same onboarding questions every time a new engineer joins.

Where the time actually goes

The five hours per week isn't one block of focused documentation writing. It's scattered across the week in small chunks, each carrying its own context-switching cost.

Post-PR documentation. After shipping a meaningful change, the engineer updates the wiki, the API docs, the architecture diagram, and any relevant READMEs. This might take thirty minutes to an hour per significant PR, but the context switch from code to prose is draining in a way that the time alone doesn't capture.

Answering questions that should be in the docs. A junior engineer asks why the payments service is structured the way it is. A product manager asks how the data pipeline works. A new hire asks where to find the deployment guide. Each question takes ten to twenty minutes, and the answers are given verbally or in Slack threads where they'll be lost within days.

Maintaining existing docs. A refactor makes three wiki pages inaccurate. An API change invalidates the integration guide. A dependency update breaks the setup instructions. Someone has to find and fix these, and the work is tedious enough that it often doesn't happen until someone follows the outdated instructions and wastes an afternoon.

Onboarding documentation. Every new hire prompts a burst of documentation activity as the team realises that the things they've been carrying in their heads need to be written down for someone who doesn't have the context. This is reactive documentation at its most expensive: created under time pressure, often incomplete, and rarely maintained after the new hire no longer needs it.

The opportunity cost

The cost of documentation isn't just the salary hours. It's what those hours could have been used for instead.

Five hours per week of senior engineering time is five hours of architectural thinking, code review, mentoring, debugging, or feature work. Over a year, for a single engineer, that's roughly 250 hours, or about six full working weeks, redirected from the work they were hired to do.

The engineers who feel the opportunity cost most acutely are typically the most senior ones, because they're the ones with the most context to document and the most valuable alternative uses of their time. The documentation burden falls heaviest on the people the organisation can least afford to distract.

The alternative

The cost calculation above assumes that documentation requires human engineering time, which has been true for as long as software engineering has existed. Self-writing documentation changes this assumption.

When documentation is generated and maintained automatically from the engineering activity that's already happening, the sources that currently hold your knowledge in transient form (GitHub PRs and commits, Slack conversations, meeting recordings, design documents), the human writing cost drops to near zero.

Engineers still review the generated docs, correct inaccuracies, and add context that the automated system missed. But the baseline work of converting institutional activity into structured, searchable documentation is handled by the system rather than by the people whose time costs $85-$105 per hour.

For a team of ten engineers each spending five hours per week on docs, eliminating even 80% of that manual effort saves $100,000-$215,000 per year in recovered engineering time. That's the equivalent of hiring an additional engineer, funded entirely by not wasting the time of the engineers you already have.

Frequently asked questions

Is five hours per week realistic? Surveys of engineering teams consistently put documentation time at four to eight hours per week for senior engineers, with the number rising during onboarding periods and after major refactors. Five hours is a moderate estimate, and many teams would find their actual number is higher once they track it.

What about teams that just don't write docs? They pay the cost differently: through longer onboarding times, more interruptions to senior engineers, more errors from misunderstood architecture, and more knowledge loss when people leave. The cost of not writing docs is often higher than the cost of writing them, it's just less visible because it's distributed across dozens of small inefficiencies rather than appearing as a single line item.

How do you calculate the cost for your own team? Count the number of engineers, estimate their average hours per week on documentation-related activities (writing, maintaining, answering questions that should be in docs), multiply by their loaded hourly cost. Most teams find the number surprisingly large once they actually calculate it.

Related reading: Why engineering docs matter, Why engineers hate writing docs, How much is bad documentation costing you?. Related pages: Self-writing docs, For engineering teams.