Here's a belief I've earned the hard way: internal knowledge doesn't fail because people write it badly. It fails because nothing announces when it stops being true. The risk is never in what people wrote down. It's in what they quietly stopped keeping current.
Datadog has every ingredient for this problem at scale right now, and this post is how I'd run the program built to stay ahead of it.
At their DASH conference in June 2026, Datadog shipped over 170 new products and features in two days. They also employ roughly 1,200 people whose entire job is talking to customers about the product: sales engineers, account managers, support engineers. The moment that keynote ended, every one of those people became responsible for answering questions about things that didn't exist the week before.
They don't answer from memory. They answer from an internal library of help articles, setup guides, and talking points. Whatever a customer hears is only as good as the document the employee just pulled up.
And documents rot silently. Each one is accurate the day it's written, then the product changes underneath it and nobody comes back. It's never marked wrong anywhere. The first person to find out is a customer.
At Datadog's size, that quiet rot compounds fast. The math:
- 1,200 customer-facing people
- 5 questions a week each about the new capabilities
- = 6,000 answers a week riding on that library
- Now assume the library is outdated just 1 time in 20
- = 300 customers a week hearing something that isn't true
That's with a forgiving assumption for docs covering 170 brand-new features.
And nobody logs any of it. A customer doesn't file a complaint when a support engineer walks back what a sales engineer promised. They just trust the next answer a little less.
So the real question isn't how to write more documentation. It's this: how do you make staleness visible before a customer finds it?
I'd seen this exact failure before, just wearing a different costume. At Accenture I ran the risk tracker for a program spanning 18 teams and roughly 770 people, the shared log where every team reports what might go wrong. It was reliable for about six weeks. Then updates thinned out, and here was the trap: a team that had stopped reporting looked identical to a team with nothing to report. Silence and health look the same in a tracker. The fix wasn't asking people to report more. I built a small tool that flagged any entry nobody had touched in too long, so stale items surfaced on their own instead of hiding in the list.
A document library needs the same instrument, so I built a simple mock to make the idea concrete: a freshness tracker. Twenty-four invented articles, each with a named owner and a last-reviewed date, and one number at the top: the percent of the library checked in the last 90 days. Nothing in it is real Datadog data. It exists to make the argument visible: the moment a document's age sits on screen next to a name, staleness stops being invisible.
Now suppose Datadog hired me as the program manager who owns this. My mandate in one sentence: when any of those 1,200 people answers a customer, the information behind the answer is current, and we can prove it.
Scope. Documentation isn't the only way knowledge moves through an org like this. People learn from experts, Slack threads, enablement sessions, AI search, and hallway answers, and no freshness tracker touches any of that. I chose documentation because it's the one channel where ownership and measurement can be made explicit. A program needs a place where accountability can actually attach, and this is it.
Here's the first 90 days, ordered so each phase earns the next.
Days 1-30
Sample what 1,200 people are actually telling customers
Docs show what was written, not what's being said
Days 31-60
Give every article an owner and a review date
Instrument content age, not content count
Days 61-90
Extend only to content someone proved they'd maintain
Coverage is easy to fake, freshness isn't
Days 1-30: measure the problem before touching it. Pick the three new capabilities driving the most customer questions and sit with the people answering them. Don't audit the documents; documents only show what was written. Read real support threads and call notes, and count how many different answers exist to the same question. More than two, and you've found real inconsistency, with a baseline number to beat. Without that baseline, nothing later can prove it worked.
Days 31-60: attach one name and one date to every document. For those three capabilities, every article gets a single accountable owner, a person, not a team, and a date it must be re-checked by, agreed with the team leads who'll live with it. The hard part here isn't assigning owners. It's making ownership lightweight enough that people are still doing it six months later, which is why the review is one date and one name, not a committee. Then track the age of the library the way the mock above does. Four hundred articles where nobody knows what's still true isn't an asset. It's a liability with good search.
Days 61-90: scale only what the pilot proved. Roll the owner-and-date model out to the rest of the new material, but only for the kinds of documents the first 60 days showed people actually maintain. Whatever nobody kept current gets archived, not expanded. Scaling a system before a small version has survived contact with real people is how programs die politely.
Why this order: each phase de-risks the next. The baseline in phase one lets phase two prove improvement instead of asserting it. The pilot in phase two tells phase three what's worth scaling. Run it backwards and you've spent the quarter before learning whether anyone maintains anything.
By day 90, success is checkable, not a feeling:
- Every pilot document has one named owner and a review date
- Over 90 percent of the pilot library is reviewed on schedule
- Fewer distinct answers to the same customer question than the month-one baseline
Underneath the sequencing is a measurement philosophy. Most companies track this work with numbers that describe the past: documents written, trainings completed, complaints received. Document age is different. It predicts the failure before the customer meets it, because a 120-day-old document about a fast-moving feature is a wrong answer waiting for someone to ask the question. I'd rather manage the number that warns me than the number that files the report. Thirty articles somebody owns beat four hundred nobody does.
Which brings it back to where this started. Internal knowledge doesn't fail because people write it badly. It fails because nobody owns proving it's still true.
If you run this kind of function at a large company and think I've got that backwards, I'd genuinely like to hear why.
The freshness tracker from this post is live here. Mock data, 24 articles, six owners, one number.