When I joined ComplianceQuest, the documentation workflow was primitive. Technical writers created Microsoft Word documents, zipped them, and sent them to each other through email or Teams chat. That was the review process. That was the version control. That was the system.Files got overwritten. Versions got confused. Someone would review an outdated draft because the latest one was sitting in someone else's inbox. There was no single source of truth, no audit trail, and no way to know whether the file you were looking at was current.For a company that made compliance software, the irony was not lost on me.
Moving Everything Online
I migrated the documentation workflow to online collaboration tools. Every document lived in a shared environment where multiple people could review it simultaneously. No more zipping. No more emailing attachments. No more "which version is this?"The data was stored online with no risk of local file corruption. Everyone could see the current state of any document at any time. Review comments were inline, traceable, and persistent. Not buried in an email thread.This sounds obvious in retrospect. But changing how people work is harder than changing what tools they use. The shift required showing writers that the new process was genuinely faster, not just theoretically better. Once a few people adopted it and stopped losing track of versions, the rest followed.
Version Control
I enabled version control across all documentation. Every change was tracked. Every previous state was recoverable. Writers could see exactly what changed, when, and by whom.For compliance documentation (Installation Qualification and Operational Qualification materials for Salesforce CRM products), this wasn't a convenience. It was a requirement. Auditors need to see document history. Version control turned what had been an informal process into something that could actually survive scrutiny.
Automating the Tedious Parts
One of the most time-consuming tasks was version numbering. Every time a new version shipped, technical writers had to manually open each document file and update the version string. With dozens of files per release, this was hours of mindless work that added no value.This was before LLMs existed. There was no tool to ask for help. So I wrote scripts to batch-rename and update version numbers across all files automatically.The scripts weren't sophisticated. They didn't need to be. They replaced a manual process that was slow, error-prone, and universally hated. After I built them, other technical writers adopted them. The hours that had been spent on version updates were redirected to actual writing.
What I Took From This
ComplianceQuest was where I learned that the biggest productivity gains don't come from better writing. They come from fixing the process around the writing.The documentation itself was important. IQ/OQ materials for Salesforce products need to be precise and compliant. But the leverage wasn't in writing better sentences. It was in eliminating the friction that made everything slower: manual version tracking, file corruption, review cycles lost in email threads, and repetitive tasks that could be automated.
Most of the improvements I made were not in my job description. I saw inefficiency, and I fixed it. That instinct (to look at the system around the work, not just the work itself) has shaped every role I've had since.
