We ran the cost-of-drift calculator past five product teams this month. The smallest number it returned was £612k a year. The biggest was over $2M. Both teams reacted the same way: "that can't be right."
Then we showed them the maths. None of them argued with it after that.
Documentation drift — the gap between what your wiki says your product does and what it actually does in production — is the most expensive line item nobody puts in a budget. Engineers translating product to code. PMs maintaining specs that go stale within a sprint. New hires spending three months figuring out what the wiki got wrong. Every one of those costs is real. None of them shows up in your finance system.
Here's how we model it.
Two streams of cost, not one
There are two distinct streams that compound, and most teams only think about one of them.
Engineering interpretation. When the spec is wrong (or missing), engineers don't refuse to work — they re-derive how things work. Tracing through the product, pinging a teammate, sitting in a meeting. Stripe's 2018 research pinned the cost at 42% of engineering time on maintenance vs new features. Atlassian's 2024 work found 97% of developers lose significant time to these inefficiencies, citing insufficient documentation as a top cause.
We model it as up to 20% of engineering time — the exact rate depends on how AI-heavy your team is. A small, steady team running low AI adoption sits closer to 5%. A high-throughput team where most code starts as AI generation tops out at the 20% ceiling. Pick the bucket that fits your team and the calculator does the rest.
PM doc maintenance. Someone has to write the spec. Then re-write it after every release. Then re-re-write it three months later when the original author leaves and a new PM joins. We see 4 to 12 hours a week per PM doing this. The exact number, again, scales with AI adoption: 4 hours when the team ships at a calm cadence, 12 hours when AI-driven velocity has the PM constantly chasing behaviour changes. GitLab's 2024 research backs the upper end: 7 hours per week lost to inefficient processes, including poor knowledge sharing.
For a team with 4 PMs running medium AI adoption, that's roughly $128k a year of senior-PM time spent on wiki janitorial. The high-AI bucket pushes it past $190k.
Both costs are real. Both are invisible in your P&L. And both compound the moment your team adopts AI coding tools that ship more PRs per week than humans can document.
Three inputs you actually know
We built a calculator that asks for three things: engineering team size, region, and AI coding tool adoption.
Three inputs because most other "developer productivity calculators" ask 15 questions, half of which require you to guess, and the result feels invented. Three inputs you actually know. Engineering team size you can find on LinkedIn. Region sets the salary defaults — we use fully-loaded annual costs ($180k US, £110k UK, €95k EU). AI adoption sets where in the 0–20% range your team sits — higher adoption = more PRs per week = more drift volume = closer to the upper bound.
PM count is derived from a 1:8 ratio because most non-technical buyers don't think in PM ratios. The methodology section shows that derivation openly so you can see exactly what we did.
The calculator also shows you the with-Specsight counterfactual: how much of that cost goes away when your spec comes from the product itself instead of from human effort. Engineers stop interpreting because the spec is accurate. PMs stop maintaining because there is nothing to maintain — Specsight is the documentation. We model the recovery rates as 70% on engineering interpretation and 90% on PM doc maintenance, which are the midpoints of typical customer outcomes (60-80% and 80-95% respectively).
Why the number is uncomfortable on purpose
We didn't aim for "useful estimate". We aimed for "honest worst case" using numbers everyone in the industry already accepts.
The bounds — up to 20% engineering interpretation time, 4–12h/week PM maintenance, 70%/90% recovery — come from Specsight's research with product teams, layered with published stats from DORA, Atlassian, GitLab, and Stripe. We anchor low/medium/high to the actual bounds of those ranges rather than picking a single midpoint and multiplying it, because "up to 20%" means 20% is the ceiling, not a number we should silently exceed.
If you run the calculator and the number is too high to share with your CFO, the methodology section spells out which assumptions you'd need to challenge to drag it down. Most teams' response, after they read the methodology, is "actually, that's probably an underestimate."
What to do with your doc drift number
Three things.
- Stop treating doc drift as a soft cost. Once you have a dollar figure, it's a budget conversation, not a culture conversation. Your engineering leader gets a line item to point at when defending the time spent. Your CFO gets a savings opportunity.
- Decouple human-authored from machine-extracted. PMs and engineers should write the why and the judgement calls. The what — what does this feature actually do — should come from the codebase. That's a process change, not a tooling change. The tooling change is whatever lets you do it.
- Try Specsight on your own repo. The fastest way to validate the savings number is to analyse your real codebase. Specsight gives you a complete spec in about two minutes. You can start here, or browse a live demo first if you want to see the output before connecting a repository.
Either way: the number was real before you saw it. Now you have it on paper.
