Savinder has been managing documentation teams long enough to know exactly what's broken about the old model. At Perforce — 52 products across 24 brands — the Knowledge Team is responsible for producing content that ships with every release. That information gets picked up by support engineers, customer success, TAMs, and even pre-sales for proof-of-concept support. That's a lot of downstream pressure on a team writing documentation the same way companies have written it for decades.
"We've always written product documentation in a manual style," he says. "Here are all the wonderful features this product has, and here are five different implementation options for any given feature." The problem is that nobody reads that way anymore. Users want short, task-based instructions — e.g. the five steps to implement this feature — and not five pages of a manual to get to the point.
A few years ago, Savinder started addressing that shift change. His team shifted to task-based authoring: tighter, more structured, and supplemented with video for anything complex. That solved one side of the problem. Then he looked at how the writers themselves actually work and found the same inefficiency waiting for him there.
That's what brought him to Doc Holiday.
We started off with a remit to generate content quicker, but we found we could actually do a lot more than we expected.
Savinder Chauhan · PerforceThe initial goal was speed. The actual outcome was bigger.
The initial goal was speed: generate content faster, use fewer tools, work natively in the environments engineering already lives in. Savinder was surprised with how quickly the scope expanded.
"We started off with a remit to generate content quicker, but we found we could actually do a lot more than we expected." The example he kept coming back to was action plans: role-specific, actionable updates that go out to different teams when a release ships. Support needed to know how the new feature worked under the covers. Pre-sales needed talking points. Customer success needed a high-level brief.
"These are things that we do manually, or other people at Perforce do manually. Why couldn't that be automated as well?"
New use cases kept surfacing the further they got into implementation. The documentation team, it turned out, sat at the center of a content supply chain that fed almost every other function in the company. When a release ships, the ripple extended further than most organizations ever stop to map.
The question is no longer how to document faster.
Savinder is still in implementation; the moment where he steps back and says, "Okay, this is working", hasn't arrived yet. But he's confident it's close, and his read on AI tooling in general shapes his expectations: a lot of front-loaded work, followed by fast returns once the system is running.
What has already changed is how he thinks about the problem. The question is no longer just how to document faster. It's what else the documentation team could be generating, and for whom.
My team produces content that stems from what engineering builds. Marketing needs stuff for the website. Press releases. Training content. Why do we need separate writers for all of that?
Savinder Chauhan · PerforceFor someone who has spent years thinking carefully about how people actually consume information, the answer to that question is becoming pretty clear.
