Two BLS figures define this field, and they point in opposite directions.
Well paid and not growing. That combination is the whole strategic picture, and it produces a specific and slightly counterintuitive conclusion about where the work is.
Set that against net growth of 500 jobs over a decade. Almost every one of those 4,500 annual openings is replacement demand, meaning people leaving the occupation rather than new positions being created. Writers retire, move into product management, move into developer relations, or leave for adjacent roles.
That distinction matters because a flat occupation with high replacement demand behaves very differently from a shrinking one. There are 4,500 chances a year to enter a field paying a $91,670 median. What there is not is an expanding pool of employers competing for writers, which is what would push those salaries up.
The practical reading: employment in this field is available but static, and the leverage is not in getting hired. It is in selling documentation as a service to the large number of organisations that need it and have no technical writer at all, which is a market BLS does not measure because it counts employees rather than engagements.
That gap between what the statistics count and where the work is deserves emphasis, because it recurs across several guides on this site and it is consistently misread. An occupational projection measures payroll positions at organisations large enough to have them. It is silent on the software company with forty people, an API, and documentation written by whichever engineer had time. There is no employee to count there, so the demand is invisible to the statistics while being entirely visible to anyone who tries to integrate with the product. A flat projection is therefore evidence about hiring, not about need, and treating it as a verdict on the field is the most common mistake people make when reading these numbers.
The apparent contradiction resolves once you look at what generative tools did to the work.
Drafting prose from a specification got dramatically cheaper. So did tidying inconsistent terminology, generating boilerplate reference sections, and producing a first pass at a how-to guide. These were real parts of the job and they are now fast.
What did not get cheaper is everything that requires knowing whether the documentation is true.
A model can write a fluent explanation of an API endpoint from its signature. It cannot run the endpoint, discover that the documented parameter was renamed two releases ago, notice that the error response is undocumented, or determine that the recommended approach breaks under pagination. That verification work is the actual product, and it requires access to the system, the engineers, and the willingness to test what you are describing.
So the pay stays high because the remaining work is skilled, and the headcount stays flat because each writer covers more ground than they used to. That is the same pattern as the graphic design guide on this site, with one important difference: designers' median sits at $61,300 while technical writers are at $91,670, because the verification work here is harder to fake and the cost of getting it wrong is more visible.
Five categories, and they are not equally paid.
There is a sixth category worth naming separately because it is growing and barely staffed: documentation for machine readers. As more software is integrated by AI agents rather than by developers reading pages, the qualities that make documentation useful shift. Structured, complete, unambiguous reference material with machine-readable specifications and consistent naming matters more; discursive tutorials matter less. Companies are beginning to notice that their documentation is now consumed by systems that cannot ask a clarifying question or infer intent from context. Writing for that reader is a specialism nobody has a decade of experience in, which makes it unusually open to someone entering now, and it is the one part of this field where being early is genuinely possible.
The pattern across all five: value tracks the cost of the documentation being wrong. Where wrong means a support ticket, rates are moderate. Where wrong means a failed integration, a compliance finding or a safety incident, rates are high.
Anyone can write clearly. The rate difference comes from something narrower.
Since employment is flat and engagement demand is not measured, this is where the opportunity sits.
The buyer to target is a software company with an API, engineers who dislike writing, and no technical writer. That description fits an enormous number of companies, and the ones actively losing customers to bad onboarding documentation are motivated buyers.
The obstacle for everyone entering is the same: clients want to see documentation you have written, and you cannot show work you have not been hired to do. This field has an unusually clean answer to that.
Document an open source project. Thousands of genuinely useful projects have poor documentation, the maintainers know it, and contributions are welcome. You can pick a project, set it up as a new user, document what was missing, and submit it. The result is public, attributable, reviewed by real maintainers, and demonstrably used. No client work has those properties.
Write the quickstart that was missing. Rather than improving prose, find a project where getting started is genuinely hard and write the guide that fixes it. That is the single most valuable artefact in developer documentation and the easiest to demonstrate value with, because a reader can follow it and see whether it works.
Document a public API you did not build. Pick a service with mediocre reference documentation, integrate with it, and publish a better integration guide. This proves the two things clients care about: that you can read an unfamiliar system, and that you verify rather than transcribe.
Show the defects you found. A portfolio piece saying "the existing quickstart failed at step three because a prerequisite was undocumented, here is the corrected version" is more persuasive than any polished sample. It demonstrates the verification work, which is what separates you from generated output.
Contribute to documentation in the toolchain. Doing this through pull requests in a real repository also proves you can work docs-as-code, which is the other thing the better-paying clients screen for.
The reason this works better here than in most fields is that documentation quality is objectively checkable. A prospective client can follow your guide and see whether it gets them working. Very few portfolio pieces in any discipline can be verified that directly.
What to Charge
There is no published freelance rate card for technical writing, so anchor on the employment figure and adjust for what freelancing actually costs.
The BLS median of $91,670 implies roughly $44 an hour of salary value. A freelance rate must additionally cover the absence of benefits and paid leave, unbillable time spent selling and on admin, gaps between engagements, self-employment tax, and the employer overhead that no longer exists. The usual multiple applied to convert a salary to a defensible freelance rate lands well above that figure, and specialists in API documentation and regulated sectors sit higher again.
Better still, avoid the hourly conversation entirely.
Price the audit as a fixed fee. It is bounded, it is the natural first engagement, and its value is the defect list rather than the hours spent finding it.
Price documents as deliverables. A quickstart, a migration guide, a set of reference pages. State what is included, how many review rounds, and the turnaround.
Price the retainer per release cycle. This is the arrangement most aligned with how documentation actually decays, and it is easier to renew than a project is to repeat.
Two things that justify a higher number, and both are worth saying explicitly in a proposal. You verify rather than transcribe, which means running the software and reporting defects the client did not know about. And you work in their repository through their review process, which means no engineer has to reformat anything you produce.
Rookie Mistakes
Writing from the specification without running anything. The fastest way to produce documentation that is fluent and wrong. If you have not executed the thing you are describing, you are transcribing rather than documenting.
Organising around the system instead of the task. Documentation structured to mirror the codebase is comfortable to write and hard to use. Start from what the reader is trying to accomplish.
Charging hourly. Your speed improves rapidly with tooling and experience, and hourly billing converts that improvement into a pay cut.
Competing on writing quality alone. Fluent prose is now cheap. The sale is accuracy, verification and structure, and positioning on writing craft alone puts you in competition with something that has no marginal cost.
Avoiding the toolchain. Refusing to work in a repository, in Markdown, through pull requests, excludes you from the best-paid segment of this field.
Accepting an engineer's explanation without testing it. Engineers describe how the system is supposed to work. What it does is sometimes different, and finding that gap is part of what you are being paid for.
Neglecting the maintenance conversation. Documentation written once and never updated becomes actively harmful, because readers trust it. Raising this at the start leads naturally to the retainer.
Documenting everything equally. New writers try to cover the whole surface at uniform depth, which spreads effort across pages nobody reads and leaves the critical path thin. Most readers follow a small number of paths, and the quickstart and the top few integration flows deserve more care than the rest of the reference combined. Asking a client which three tasks matter most, and building outward from those, produces a visibly better result for the same budget.
Accepting a rewrite brief without auditing first. A client asking for a rewrite has usually diagnosed the symptom rather than the cause, and the cause is frequently structure rather than prose. Quoting a rewrite before establishing that is how a project ends with better-written documentation that is still hard to use.
Finding Clients
The buyer profile is unusually easy to describe, which makes prospecting more targeted here than in most freelance work.
A software company with an API, engineers who dislike writing, and no technical writer. That is the whole specification, and it fits an enormous number of companies. The ones worth approaching first are those whose documentation is visibly failing.
Diagnose before you contact. Try to integrate with their API as a new developer would, using only their documentation. Note where it fails. That failure list is your opening message, and it is far more compelling than any pitch, because it is evidence rather than assertion.
Approach developer relations and engineering leadership, not marketing. Documentation quality is felt as support load and failed integrations, and the people who feel it are the ones who can authorise fixing it. Marketing owns the website and rarely owns the docs.
Time it to a launch. A company shipping a new API, a major version or an SDK has an acute, dated documentation need and frequently no capacity. Launch announcements are a prospecting list.
Watch for the support-load signal. Public issue trackers, community forums and support channels full of questions the documentation should have answered are a company paying for bad docs in engineering time. Quantifying that is a strong argument.
Subcontract through agencies and developer relations consultancies. They win work they cannot staff. Lower rate because they hold the client, and no sales function to run while you build a portfolio.
Ask the maintainers you contributed to. If you built a portfolio by documenting open source projects, the maintainers of those projects work somewhere, and some of those employers need exactly this.
The single strongest opening remains the audit offer framed as evidence: here are six specific places your quickstart fails, here is what it would cost to fix them. That converts far better than describing your writing experience.
Gotchas Worth Knowing
Access is the bottleneck and it is often slow. You need the environment, the credentials, the repository and the engineers' time. A project that looks like three weeks of writing becomes eight because access took a month. Make access a contractual dependency with a stated start condition.
Subject matter experts will disappear mid-project. The engineer you depend on gets pulled onto an incident. Build this into your timeline and your terms rather than absorbing it.
Documentation debt is usually worse than the client believes. An audit frequently finds that the existing documentation describes a version of the product that no longer exists. Scope the audit before committing to a rewrite price.
Review cycles expand without a cap. Engineering review is necessary and it is also where projects lose their margin. Two rounds, defined, with a stated rate for additional ones.
You may need to sign broad confidentiality terms. You are being given access to unreleased functionality and internal systems. That is normal, and it constrains what you can show in a portfolio, so agree publishable case study terms early.
Regulated documentation carries real liability. In medical devices, aviation and similar sectors, documentation is part of the compliance record. Understand what you are signing before working in those fields, and price accordingly.
The product may change under you mid-project. Software ships continuously, and a team can rename a parameter or restructure a flow while you are documenting it. This is normal rather than a client acting badly. Agree what happens when it occurs: whether changes during the engagement are absorbed, billed, or deferred to the next cycle. Silence on this point means absorbed, and on a fast-moving product that can consume the whole margin.
Your best work is invisible and hard to attribute. When documentation is good, integrations succeed and nobody notices why. Support tickets that never get filed do not appear in any report. This makes renewal conversations harder than the value justifies, so capture the evidence while you can: the defects you found, the failed steps you fixed, the support threads that stopped. Without that record the client remembers the invoice and not the problem.
How Documentation Became a Profession
The shape of this job, and why it is paid what it is, comes from a specific history worth knowing.
Technical writing began as a manufacturing function. Complex machinery needed manuals, and the people who wrote them sat close to engineering because the information existed nowhere else. The defining constraint was that the writer had to understand the machine, and that constraint has never gone away.
Software inherited the practice and changed the economics. Manuals became help files, then web pages, then continuously updated sites. The important shift was in the update cycle: a printed manual described a product that had shipped, while software documentation describes a product that changes weekly. Documentation stopped being an artefact and became a process.
Then developer-facing software changed it again, and this is the change that produced the pay. When your customer is a developer integrating your API, documentation is not support material. It is the product surface. A prospect evaluating your service reads your docs before they talk to your sales team, and if the quickstart fails they leave. That made documentation quality a direct revenue input at a category of company with money, which is why API documentation pays what it does.
Two structural facts follow from that history, and both explain the current situation.
Documentation quality is checkable in a way most writing is not. A reader either gets working or does not. That objectivity is unusual, and it is why portfolio building works so well here and why generated documentation gets found out.
And the writer's value has always been proximity to the system rather than command of prose. The manual writer needed to understand the machine; the API writer needs to run the endpoint. Every wave of tooling that made the prose easier left that requirement untouched, which is why the field survived desktop publishing, content management systems, structured authoring and now generation.
Working With Engineers
Most of the difficulty in this job is not writing. It is extracting accurate information from people who are busy, who find explaining tedious, and who often do not remember which parts are undocumented because they have known them for years.
Arrive with specific questions, never with a blank page. "Tell me how authentication works" produces a twenty-minute ramble. "I got a 401 calling this endpoint with a token that works elsewhere, is there a scope requirement that is not in the reference?" produces a two-minute answer and the engineer's respect.
Do the reading first. Read the code, the tests and the pull requests before asking. Tests in particular are documentation written by someone who had to be precise, and they answer a surprising share of questions without troubling anyone.
Ask about failure, not just success. Engineers naturally describe the intended path. Documentation defects concentrate in what happens when something goes wrong, so ask specifically: what does this return on a bad input, what happens on a retry, what breaks under pagination.
Never make them review three drafts. Ask for one technical review of something close to final. Writers who send successive drafts for comment train engineering teams to deprioritise them.
Surface disagreements rather than resolving them. When two engineers describe the same behaviour differently, that is a finding, not something for you to arbitrate. Documenting it and putting it in front of them is genuine value, and it is frequently the moment a team realises the documentation project is worth having.
Give them credit. An engineer whose explanation improved the docs, publicly thanked, becomes a willing source for the next question. This is the cheapest investment available in a job that runs entirely on other people's attention.
Report defects as findings, not complaints. You will discover things that are broken rather than merely undocumented: an endpoint returning the wrong status code, a parameter that does nothing. Raising these as bugs you found while documenting, in the team's own tracker, in their format, makes you an asset. Raising them as evidence the documentation was impossible to write makes you an irritation, and the difference is entirely in the framing.
Who This Suits
Direct, because the entry barrier is unusual: it is technical comfort rather than writing ability.
It suits people who write clearly and are not intimidated by code. You do not need to be an engineer. You need to read a function signature, run a code sample and notice when reality and documentation disagree. Someone who can do both halves is rarer than someone who can do either.
It suits developers who dislike building but like explaining. This is a genuinely common profile and the field pays it well, because the verification work that makes documentation valuable is trivial for someone with engineering background.
It suits people who enjoy imposing order on a mess. Most of the highest-impact work is structural: realising the documentation is organised around the system when it should be organised around the reader's task.
It suits people who can be pleasantly persistent with busy specialists. Much of the job is getting twenty minutes from someone who would rather be coding, repeatedly, without becoming an irritation.
It does not suit anyone who wants to write creatively. Good documentation is invisible, plain and unmemorable. Prose that draws attention to itself is a defect here.
It does not suit anyone who needs quick income. Access alone frequently takes weeks, and the first engagement typically starts with an audit before any substantial fee.
It does not suit anyone unwilling to work in a repository. That single preference excludes you from the best-paid segment.
Behind the Scenes: An API Documentation Project
The realistic version begins with a client who thinks they need writing and actually needs testing.
A software company has an API, a set of reference pages generated from code annotations, and a complaint from their sales team that prospects cannot get integrated. They want someone to "clean up the docs".
The first week is not writing. It is getting access, which takes longer than anyone estimated, then setting up the environment as a new developer would, from the documentation as it exists.
That exercise is the audit. You fail at step three because a prerequisite is undocumented. You fail again at step six because a parameter was renamed. The error you get is not in the documentation at all. By the end you have a list of defects that nobody inside the company could have produced, because everyone inside already knows the undocumented parts.
Then the structural finding, which is usually the same: the documentation is organised by endpoint, and the reader wants to accomplish a task that touches four endpoints in a specific order. No amount of improving individual pages fixes that.
Then the interviews, twenty minutes each with engineers who are helpful and busy, to resolve the questions the code could not answer: which approach is recommended, what the rate limits actually are, what happens on retry.
Then the writing, which is the fastest part and the part the client thought they were buying.
Then review, where an engineer disagrees with a recommendation you documented, and it turns out two engineers disagree with each other, and the documentation cannot be finished until they resolve it. Surfacing that disagreement is genuine value and it does not feel like it at the time.
Then delivery, and the observation that this will be out of date in two releases, which is the retainer conversation.
Refusing to use generative tools in this field is a losing position: clients can see the productivity gain and will not pay for slowness. Using them badly is worse, because it produces exactly the confident, unverified output that damaged documentation's reputation. There is a workable division.
Use them for first drafts of descriptive content. Reference sections, parameter tables, boilerplate structure. This is the work that got cheap, and pretending otherwise wastes your time and the client's money.
Use them to find gaps rather than to fill them. Asking a model what questions a reader would have about a page, or what is missing from a quickstart, produces a useful checklist. You then answer the checklist by testing, which is the part it cannot do.
Never let them assert behaviour. Any statement about what the software actually does, what a parameter accepts, what an error means or what the recommended approach is must be verified against the running system. A model will produce a plausible answer for an endpoint that does not exist, and plausible-and-wrong is the worst possible documentation defect because readers trust it.
Disclose it and make it a selling point. Telling a client you use these tools for drafting and verify everything against their system positions you correctly: faster than a writer who refuses, and safer than output nobody checked. That is the honest description of the value you add, and it is the same division of labour every other guide on this site keeps arriving at.
Keep the verification record. Noting what you tested, in what environment, on what date, turns your accuracy from a claim into an artefact. It also makes the maintenance conversation concrete, because a verification dated three releases ago is visibly stale.
The reason this matters commercially rather than just ethically: the market is currently full of cheap generated documentation, and clients are learning what it costs them. Being demonstrably the other thing is the strongest available position, and it requires only that you actually do the testing.
Where This Goes Next
Four arguments about trajectory rather than forecasts. The common thread is which parts of the work resist automation and which do not.
Headcount stays flat and engagements grow. The 1 percent projection measures employees. It does not measure the software companies with an API and no writer, and that is where demand is going, because the work is project-shaped and the need is intermittent.
Verification becomes a named service. As more documentation is generated rather than written, confirming that it matches the system becomes distinct work. It requires the same skills, it is easier to scope, and it is growing precisely because generation got cheap.
Docs-as-code becomes non-negotiable. The gap between writers who work in the repository and those who do not will keep widening, because the first group can be part of the release process and the second cannot.
Regulated documentation holds its value best. Where a documentation defect is a compliance or safety issue, nobody is going to accept generated output without human sign-off. That segment is slow, exacting and durable.
The replacement demand stays and the entry route narrows. Those 4,500 annual openings are people leaving rather than positions being created, and they will keep occurring. What changes is the shape of the vacancy: fewer roles for a writer who produces prose from specifications, more for one who verifies, structures and works in the toolchain. That is a harder job to enter with no technical exposure, which is why the portfolio route through open source contribution matters more each year.
Structure outlives prose. Information architecture, task orientation and knowing what a reader needs are the parts of this job with no automated substitute. A writer whose value is fluent sentences is competing with something free; a writer whose value is knowing what to document, in what order, having verified it, is not.