What to Look for When Hiring a Technical Writer
At some point, every growing technology company faces the same realization: the documentation isn’t keeping up. Engineers are writing release notes between deploys. The getting-started guide hasn’t been touched since the UI overhaul. Support is fielding questions that good documentation would have answered before they were asked.
The natural response is to hire a technical writer. The less natural part—the part that trips up even experienced engineering managers and founders—is knowing what to look for when you do.
Technical writing sits at an uncomfortable intersection of disciplines. It requires genuine writing craft, real technical understanding, and enough organizational awareness to navigate the gap between engineering and the customer. Finding someone who brings all three skills to the project is harder than it looks. The consequences of getting it wrong include poor documentation, inflated support costs, lower developer adoption, and a lack of customer trust, often without anyone identifying the documentation as the root cause.
Here are some important things to watch for:
Red Flags
“Technical writer” doesn’t mean what you think it means
The job title “technical writer” covers a wide range of actual capabilities. Some technical writers are exceptional writers who have learned enough about technology to navigate a product. Others are former engineers who can explain complex systems accurately but struggle to make those explanations readable. Very few are both.
What you want—and what is genuinely rare—is someone who understands technology at a deep level, not just someone who is comfortable around it. There’s a meaningful difference between a writer who can follow an engineer’s explanation and one who can read your codebase, call your API independently, and identify gaps in your documentation before your users do. When evaluating candidates, probe for depth, not just familiarity.
Dialect inconsistency
Documentation written for a specific regional audience should be edited by someone whose native dialect matches that audience. Spelling conventions, idiomatic phrasing, and subtle word choices vary enough between US, UK, and Australian English that using writers from outside the target region can make your documentation feel off, even if your customers can’t articulate why. This doesn’t reflect on the writer’s skills; it understands and accepts the importance of matching editorial oversight to the target audience.
The “anyone can write” assumption
They can’t. This misguided assumption is often the root cause of underwhelming documentation and overwhelming expense. Writing that is merely grammatically correct is not the same as writing that is clear, well-structured, and useful. The gap between competent prose and genuinely good technical writing is significant, and it shows up most painfully in the documentation your users struggle with most.
To compound the problem, hiring managers evaluating writing samples often can’t identify the difference themselves. If nobody in the room has strong writing instincts and solid technical skills, the evaluation defaults to surface-level criteria, such as length, formatting, and the absence of obvious errors, rather than the qualities that actually matter.
Passive voice as a clarity killer
One of the most reliable signals of weak technical writing is an over-reliance on passive sentence structures. Passive voice isn’t always wrong, but in technical documentation, it frequently obscures exactly the information users need most: who is doing what, and where.
I encountered a vivid example of this while working on a VR project that included both desktop and headset components, serving both customers and developers simultaneously. In that context, subject clarity wasn’t a stylistic preference; it was a functional requirement. Every action needed a person or role attached to it, because the same interface element behaved differently depending on who was interacting with it and the platform they were using.
A writer on that project produced this line: “A message will be displayed when the button is clicked.” Read it twice, and you’ll see the problems:
- Who is clicking the button, the developer or the customer?
- What button are they clicking?
- Where is the button displayed, on the desktop or the headset?
- Where is the message displayed, on the headset, the desktop application, or in the browser?
While the sentence is grammatically intact, it communicates almost nothing.
The same problem appears in less obviously complex contexts. Consider: “A reminder will be sent for each calendar item.” Sent by whom? Sent where? Compare that to: “The system will send a reminder to your mailbox for each calendar item.” Same information, twice as useful, because it answers the questions a reader will immediately have.
When reviewing writing samples, look for this pattern. It reveals whether a writer thinks about the reader’s experience or just about the information being conveyed.
Using the wrong tools for the job
A surprising number of documentation problems aren’t writing problems; they’re tooling problems. Companies that build documentation workflows around tools like MadCap Flare, Paligo, or Doxygen often discover a hidden cost: subject-matter experts either don’t know about or don’t have access to these tools for collaboration. For example, engineers, whose reviews are essential for technical accuracy, are pulled out of their normal workflow to interact with unfamiliar systems. The result is reviews that are delayed, cursory, or skipped entirely.
Documentation that lives in the same ecosystem as the code—a practice called Docs-as-Code—allows engineers to easily review it through pull requests and deploy it alongside the product via the same pipeline. This strategy keeps engineers in their day-to-day workflow and results in documentation that engineers actively engage with. When the review process feels like their normal day, they’re far more likely to participate meaningfully.
When hiring technical writers, ask candidates not just what tools they know, but why they would choose one over another for your specific situation. The answer will tell you a great deal.
Green Flags
Technical depth in the hiring process
The best way to evaluate a technical writer’s depth is to ask them to demonstrate it. Not through whiteboard exercises or take-home projects. Those processes are as counterproductive for writers as they are for engineers. Instead, explain your situation to them and assess the depth of their technical skills through conversation.
Ask candidates to explain a core technology your company uses. Ask them how they would approach documenting your API, what questions they would need answered before they started, and what they would do if the engineering team was too busy to answer them. A writer with genuine technical depth will ask good questions, surface non-obvious considerations, and demonstrate that they understand the problem before they start solving it.
Tool selection that matches the actual need
Strong technical writers don’t have a favorite tool. Instead, they have a process for selecting the right one. The answer to “what documentation tool should we use?” is always “it depends,” and a good writer should be able to explain what it depends on.
For example, if you’re documenting a REST API with multiple versions and storing that information in a single repository, Docusaurus is a strong choice because it supports versioning natively. Astro doesn’t. If you need to pull documentation from multiple repositories and combine them into a unified site, Antora handles that elegantly, where Docusaurus falls short. Similarly, Markdown is perfectly adequate for straightforward documents, but if your documentation requires tables, callouts, annotations, and complex formatting, AsciiDoc’s richer feature set will save you significant pain.
A writer who can walk you through that kind of reasoning, unprompted, understands documentation as a system, not just a writing task.
Collaboration strategies that respect subject matter experts
Documentation depends on subject-matter experts, and the best technical writers know that those experts have their own workflows and that documentation reviews need to fit into, not compete with, those workflows.
For engineering teams, that usually means pull requests and code reviews. By conforming to these processes, you allow your subject-matter experts to use familiar tools and processes, resulting in minimal friction. For subject matter experts who aren’t engineers, like physicians, attorneys, or researchers, a shared Google Doc is often dramatically more effective than asking them to navigate a Git repository.
A writer who asks about your subject-matter experts before proposing a collaboration strategy understands that documentation is a team effort, not a solo deliverable.
Speed and deployment discipline
Documentation should ship with the code it describes. Every day that passes between a product change and the documentation that reflects it is a day your users are working with incomplete or inaccurate information.
The best technical writing engagements have a clear, fast cycle: review → revise → approve → deploy. Look for writers who treat that cycle as a professional standard rather than an ideal. Ask them how they’ve handled tight deployment timelines in the past, and listen for whether they frame documentation as part of the release or as something that follows it.
A clear strategy for keeping documentation current
Outdated documentation is a silent tax on your support team, your users, and your reputation. The military discount situation I described in an earlier post—where a UI change generated months of avoidable support tickets—is a direct consequence of documentation that had no ongoing maintenance strategy.
Ask candidates how they approach documentation audits. How do they identify sections that have drifted out of date? How do they stay informed about product changes? How do they prioritize updates when everything seems urgent? A writer without good answers to these questions will produce documentation that is accurate on the day it ships and increasingly wrong every day after.
Making the right call
Hiring a technical writer is not like hiring for most roles. The output is specialized, the evaluation criteria are unfamiliar to most hiring managers, and the cost of a poor hire is often invisible until it has been accumulating for months.
The red flags in this post are patterns I’ve seen repeatedly in companies that hired on price, in organizations that assumed any competent writer could handle technical content, and in teams that never connected their support volume to their documentation quality. The green flags are the things that distinguish writers who will make your documentation genuinely better from writers who will simply produce more of it.
The difference matters more than most companies realize until it’s too late. If you’re evaluating technical writers and want an outside perspective on what good looks like, I’m happy to help.
Inkwright, Inc. provides technical writing and ghostwriting services for technology companies. Get in touch.