Whenever I visit LinkedIn, I’m always shocked to see the number of short-term contract technical writing positions. The majority of them must be technical editor positions, because six months is no amount of time to ramp up on complex subject matter, gain a thorough understanding of the audience, and produce impactful content. In my experience, six months tends to be when new writers start to hit their stride, when they finally know enough about the organization and the product to make meaningful headway in a sea of ambiguity.
When I first joined AWS, I had years of experience working with data analysis software. I already knew the documentation tools inside and out and pushed my first changes to the public website within a couple days. Even still, looking back at my commit history, my work was surface-level for months: bug fixes, content deduplication, clarification, reorganization, troubleshooting steps, tips. I had to wrap my head around the existing content and get to know the team. Then I had to learn, de-learn, and relearn the product itself. The comprehensive security overhaul, detailed feature explanations, and plug-and-play code samples came later. For example, my first Java code sample worked, but I rewrote it twice over the course of a year as the product ecosystem changed. New libraries meant that I could simplify the most complicated portions of the code. If I’d been on a contract, that inferior initial version would have been the only version.
I struggle to think of situations in which short-term contract technical writers make any sense at all for a company. Technical editors, sure—sometimes you need to make a bunch of content look professional. But the entire point of a writer is to produce original content. You can’t (or at least shouldn’t) write without expertise, and acquiring expertise takes time, to say nothing of the craft of putting metaphorical pen to paper.
Equally flawed is the idea that contract writers can create the initial version of the documentation, and then the rest of the company can maintain it over time. When something is everyone’s job, it’s actually no one’s job. Like code, documentation needs regular refactoring to stay coherent and useful. It’s never done. If the documentation has no owner, smart, well-meaning people will litter it with needless warnings and duplicate content in four locations because “a customer missed it.” They might add to the documentation, but they’ll never consider it holistically. Over time, it will devolve into a disorganized mess.
My advice to companies is to look more deeply at the needs of your customers and hire people who can deliver on those needs for years to come. Your contract position should almost certainly be a staff position.