Should you hire a technical writer?

I spent nearly a decade in customer support before starting Pageloop, five years of it at Zapier, where I was a Support Lead, and then at Postman. Back then, I loved working with docs. They were a reflection of our support team, and they had to be amazing. So "should we hire a technical writer?" is a question I care about a lot.

A prospect asked me exactly that at the end of a call recently, as they were starting a POC with us. Thinking through my answer ended up changing a position I'd held about Pageloop and technical writers for a long time.

The prospect who was told to hire a technical writer

My first reaction was panic.

They had about 50 articles. Was a big part of their product still undocumented, and I'd somehow missed it? I should have known that.

Nothing was missing. Many of their articles just had outdated screenshots, and everything else was there. So I told them what I'd tell a friend. Personally, I wouldn't hire someone at this stage, and a full-time technical writer probably wouldn't be thrilled to maintain a knowledge base that small. If they wanted help, a fractional writer would make more sense. Then I asked where the idea had come from. One of our competitors had strongly advised it. I'm not naming them here.

It was a total head scratcher.

Their KB was small, it wasn't going to grow fast, and nothing was missing. A full-time hire at that scale only makes sense if you know the knowledge base is about to get much bigger, and that wasn't their situation.

Later it clicked. A friend of mine, a senior technical writer, had used that same competitor's product at her company. She'd told me it was so complex that she couldn't onboard anyone else onto it, and her team eventually churned and moved to another tool.

So, was the hire really for their docs? Or for someone who could actually use the product?

When to hire a technical writer

Hire a technical writer when your documentation needs someone to own it full-time and there's enough of it to keep that person busy. That depends on two things more than on team size:

1. How many docs you have. About 50 articles is a small knowledge base. Past roughly 100, the work changes.

2. Who will write them. One writer owning every page is a different job from PMs, Support and engineers all contributing.

A help center of about 50 articles, with nothing missing, rarely needs a full-time hire. A fractional or contract technical writer can handle the cleanup, and a full-time writer wouldn't be excited to maintain a KB that small. Past 100 docs, if one writer will own every page, hire a great one. If many people are going to contribute, the job looks different, and so do the tools you need.

What technical writers are actually for

No knowledge base software, however much Claude or ChatGPT sits behind it, can replace a technical writer.

Writers are the reason good docs exist.

The work they love is turning complex technical workflows into simple guides. A technical writer at one of our POC customers described what they'd do with a good first draft from a PM: use it as a guide to test the feature deeply, learn the happy paths, the UX issues and the workarounds, and then write docs their users can actually follow. What they don't love is the housekeeping, like hunting for outdated content, or finding every old screenshot after a UI change and replacing them one by one. Our mission at Pageloop, from the beginning, has been to take that painful, boring, repetitive work away so the writer's job gets more enriching.

Under 100 docs, a Claude skill is often enough

We have about 30 articles in our own help center, and our product is fairly simple right now. If I weren't building Pageloop, I'd run our docs on a Claude skill with two jobs:

• Track merged PRs from GitHub.

• Use Claude in Chrome to navigate the product and take new screenshots.

With that in place, a UI update wouldn't straight up eat 4 hours off my week.

So I'll be honest about where Pageloop fits. When teams with 50 to 100 docs come to us, we show them how to manage it with a simple Claude skill, because Pageloop would be overkill. We explain how to build the skill and the signs that it's no longer keeping up. There's a fuller walkthrough of that setup, and where it starts to strain, in can Claude or ChatGPT keep your product documentation up to date?

Beyond 100 docs, you need a system that keeps the whole team writing as if it were one person, and that gets better every time the writer touches it.

Two customers who changed my mind about technical writers

For a long time, when teams asked whether they should use Pageloop if they already had a technical writer, I said no. Two customers convinced me otherwise.

A compliance startup whose writer left

A popular compliance startup had a technical writer for over a year, and they have some of the best docs in the industry. The writer built a solid Claude harness, skills and all, to speed up their docs work. Then the writer quit, and Product couldn't pick it up. Nobody knew what to run, or when.

The harness was built by one person, for one person.

Claude can do a lot of what docs tools do. The cracks show almost immediately once a skill has to be used by more than one person. When someone leaves for another opportunity, you want to miss their personality and their smarts, and the whole system shouldn't leave with them.

Now Pageloop owns the harness, and their Product Managers review what it produces. When a feature ships, Pageloop decides whether it needs a new doc, an update to existing ones, or both.

When I asked whether they'd hire another technical writer, they didn't have an answer yet. It's mostly a yes, just a question of when. Whoever they bring in will inherit a working system on day one and get to high-leverage work much faster than they could otherwise.

A helpdesk company that opened its docs to PMs and Support

A well-known helpdesk company has a knowledge manager who has owned their docs for more than eight years. She decided it was time for Product and Support to contribute, and every time she invited contributors, the docs started to sound like they'd been written by different people. For her, that was a no-go.

Once PMs started contributing, she flagged three problems:

1. Product velocity was up, and for the first time users were reporting outdated docs, so the extra help was welcome.

2. She was spending more time editing PM drafts than it would take to write them from scratch.

3. There was no additional headcount coming for the foreseeable future.

During the pilot, Pageloop could only access their help docs while compliance and legal checks were still running, which was less information than the PMs had in their own Claude skills. A PM drafted an update with Pageloop, and she published it after exactly two edits. What would have taken an hour became a 5-minute review.

She set up Pageloop just before going on a month-long sabbatical. Since day one, PMs and Support Engineers have been reviewing and publishing doc updates nearly every day. Pageloop keeps those contributors sounding like one writer, and it learns from the edits people make and the updates they accept or ignore.

Their doc updates still sound like one person, not eight.

One writer or many contributors

I had it all wrong.

The deciding factor is a team's docs philosophy: one person writing, or many. If you choose multiple contributors, Pageloop fits, with or without a technical writer. If it's always going to be one person, my answer is still no. That team needs a great writer and, below 100 docs, maybe a Claude skill. The ways teams split that ownership, from a central writer team to everyone contributing, are laid out in who owns the help center.

Pageloop also exists for teams that don't have a writer at all. With or without a knowledge manager or a technical writer, they deserve docs their customers and Support agents can rely on, and great docs become a real advantage as the customer base grows.

Which brings me back to that prospect with about 50 articles and a handful of outdated screenshots.

So, if a tool's onboarding requires you to open a new role, is it really helping?


Image courtesy Unsplash and irmingham Museums Trust
Lake Scene, North Wales, 1811 By David Cox