Roles we recruit
Seven practices, 27 functions. Start at the practice when you cannot yet name the title; go straight to the function when you can.
Browse all 229 roles Brief us on a seatFlat 15% of first-year base · shortlist in 10 working days
A technical writer turns how your product works into documentation customers can follow: help centers, API references and guides that cut support tickets. Clean samples are easy to show, so we screen for docs that reduced a ticket count, how they get answers from engineers, and how they keep pages current after a release.
Documentation earns its place when customers stop asking the same questions. Each stage below has a signal that predicts it, and we test for that signal before you meet anyone.
The ramp, and the test behind each milestone
Weeks 1 and 2
The product hands-on, the existing docs, the most common support ticket topics and the questions sales hears. Builds a list of what is missing, wrong or out of date, ranked by how many customers it affects.
On track looks like a ranked gap list agreed with support and product, and the first corrections live.
How we test for it before you meet them
A short exercise in our screen: a feature description and an engineer's rough notes, turned into a help article. We score accuracy, order and what they leave out.
Weeks 3 to 6
Articles and guides for the five topics that generate the most tickets, written with the engineer who knows the answer and tested by following them step by step.
On track looks like published pages for the most common ticket topics, with a way to see whether those tickets fall.
How we test for it before you meet them
We ask for docs they wrote and what happened to ticket volume afterwards. A former support lead confirms it.
Weeks 7 to 10
A short style guide, templates for each page type, and a review routine with engineers, so new pages are consistent and a release does not leave old ones behind.
On track looks like docs updated in the same cycle as a release, using templates the team follows.
How we test for it before you meet them
We ask how they kept docs current at their last job: where the source lived, who reviewed and how they heard about changes.
Weeks 11 to 13
An API reference, quickstart or setup guide tested with someone who has never seen the product, with the first call or first task working from the page alone.
On track looks like a new customer or integrator completing a first task from the docs without help.
How we test for it before you meet them
A reference call with an engineer or support lead about a doc set this writer owned and how they handled a release that changed everything.
After day 90
Strong writers start tracking what customers search for and fail to find, retire pages that no one uses, and report on tickets deflected and time to first success.
On track looks like a monthly view of search terms with no results and ticket topics, driving the next quarter's work.
How we test for it before you meet them
We ask what they would measure first in your help center. A specific answer tied to tickets predicts a writer who runs a program, not a backlog.
Five responsibilities. If the seat is mainly blog articles and ebooks, it is a content writer; if it is mainly code and developer tooling, it is a developer advocate.
Task-based articles that let customers set up and use the product without contacting support.
References, quickstarts and examples that a developer can follow to a first working call.
What changed, who is affected and what to do, written the day a release ships.
Getting accurate answers from busy people, and reviewing pages with them before publishing.
A workflow, templates and ownership so pages are updated when the product changes.
Three neighboring seats absorb work people assume belongs here. Drawing the line wrong is how a documentation hire ends up writing marketing articles or building developer tools.
That seat ownsArticles, guides, case studies and ebooks written to build trust with buyers.
Hire it instead whenyou need a steady flow of educational content for prospects, not product documentation.
That seat ownsThe editorial standard and calendar across writers, editors and freelancers.
Hire it instead whenthe problem is consistency and quality across many writers, not a missing writer.
That seat ownsThe tools, workflows and measurement behind how content is planned and published.
Hire it instead whenthe content exists but the process, tooling and reporting around it are broken.
The title stays the same; the reader does not. Pick the one that matches who uses your docs.
Writes help articles, guides and release notes for the people who use the product every day.
Writes references, quickstarts and tutorials for developers, often in a docs-as-code workflow.
The first dedicated writer, taking over docs that engineers and support wrote in spare time.
The questions we ask in our own screen. Use them in yours; the warning signs are as useful as the answers.
Every candidate we put forward is scored on these five, and the scores travel with the shortlist, gaps included. Four out of five with a named weakness beats a clean sweep you cannot verify.
| What we score | Weak evidence | Strong evidence |
|---|---|---|
| Docs that reduced tickets | Reports page views and article counts. | Names pages and the ticket topics that fell, with the measure. |
| Accuracy under uncertainty | Writes from rough notes and assumes the rest. | Finds the gaps in our exercise, asks the right questions and flags what is unverified. |
| A workflow that keeps docs current | Updates pages when asked. | A release process with owners, templates and review, confirmed by an engineer. |
| Clear, task-based writing | Describes screens instead of tasks. | Short, ordered steps a stranger can complete, tested with a new reader. |
| Fit with your product | Consumer app documentation for a technical B2B product, or the reverse. | Has documented a product like yours, for readers like yours. |
Public US benchmarks, read October 2026. The two sources agree closely for an experienced technical writer. Seniority and developer-docs skills lift the number: Built In’s senior technical writer median base is $95,000, and the BLS band is wider because it covers every industry.
Each bar runs from the 25th to the 75th percentile, the middle half of reported pay.
Base salaryWages including commission (BLS)Median base salaryAverage total pay, base plus variable
Technical Writer
Salary.com base, Built In total
$68,126 to $84,483 base$87,276 average total
Senior Technical Writer
Built In, self-reported, the next seat
$95,000 median base$118,812 average total
Content Writer
Salary.com base benchmark, neighboring seat
$67,129 to $82,227 base
Technical writers
BLS, all industries
$70,880 to $115,510
Technical Writer bar and Content Writer: Salary.com base salary, 25th to 75th percentile, United States, as of October 1, 2026. Technical Writer ring and the Senior Technical Writer dot and ring: Built In median base salary and average total compensation (base plus additional cash, self-reported), reviewed October 13 and 14, 2026. Technical writers: U.S. Bureau of Labor Statistics, Occupational Employment and Wage Statistics, May 2025, annual wage at the 25th and 75th percentiles (SOC 27-3042), all industries. Public aggregates, not ZaphyrRecruit placement data.
A technical writer explains how a product works so customers can use it without help. They write help articles, guides, API references, quickstarts and release notes, get accurate answers from engineers and keep pages current as the product changes. A good one also tracks what customers search for and which docs reduce support tickets.
Salary.com puts a technical writer at $68,126 to $84,483 base, with a median of $76,242 (October 2026). Built In’s self-reported figures show a $70,000 median base and $87,276 average total pay, rising to a $95,000 median base for a senior technical writer. The BLS band for all industries runs from $70,880 to $115,510. Developer-docs skills and seniority move the number.
A technical writer documents the product for people using it: tasks, references and fixes, measured on whether customers succeed without help. A content writer writes articles, guides and case studies that build trust with buyers. The skills overlap, but the first needs product depth and patience with engineers, the second a feel for the buyer and the brand.
A contractor suits a one-off project, such as documenting a launch or migrating a help center. An in-house technical writer pays off once the product ships regularly: they learn the product, build the workflow and keep docs current after each release. We recruit the in-house seat, and will say on the first call if a contractor fits better.
When engineers or support spend real hours each week writing or answering the same questions, when new customers stall during setup, or when partners cannot integrate without calling. Before that, a few good pages written by a product manager may do. The signal is ticket volume on topics a document could answer.
Give them a short feature description and an engineer’s rough notes and ask for a help article and the questions they would put to the engineer. An hour is enough. It shows accuracy, structure and judgment about what is missing, which polished samples hide. Avoid long unpaid projects: strong candidates decline them.
Ten working days from a signed brief to a shortlist of three to five calibrated writers, each with our exercise scored and their docs checked with a former support or engineering lead. Interview speed decides the rest: good technical writers rarely run one process at a time, so a decision within a week of the first interview keeps them.
Tell us who reads your docs, what the product is and where the questions come from. We come back within one business day with how we would run the search and what the seat pays.
We build shortlists from people doing this work now, often before a seat is advertised. Set up a job alert for content roles, or send your CV and links to docs you wrote and we will come to you when a seat opens.
The technical writer is one of twelve seats in this function. If the gap sits elsewhere, start there.