What Technical Writers Actually Do
Writers' Table 1A
Welcome to The Way We Write Now — a 17-week technical writing series—two articles per week, every Monday and Thursday. Start anywhere. Work through in order if you want the full arc.
The job title is misleading. “Technical writer” makes it sound like the work is typing — taking someone else’s knowledge and dressing it up in sentences. That’s not what the job is. The job is finding out what users need to accomplish, figuring out what stands between them and that accomplishment, and removing the obstacle. The writing is the delivery mechanism, not the product. The product is the content.
This distinction matters because it affects every decision you make: what to document, how deep to go, what to leave out, and who gets a seat at the table when documentation is discussed.
The Typist Myth
The most persistent misunderstanding about technical writers is that their value is mechanical. SMEs generate knowledge; writers transcribe it. Engineers build the product; writers describe it. According to this model, the writer is downstream of everything, dependent on everyone, and replaceable the moment AI can generate coherent sentences.
This model is wrong, and not because technical writers are secretly better than it suggests. It’s wrong because it misidentifies what the job produces. Technical writers don’t produce prose. They produce usability. The output is a user who can accomplish a task — or, in a negative formulation, a user who does not open a support ticket, make a costly mistake, or abandon the product in frustration.
The prose is how that outcome gets delivered. It’s not the outcome itself.
I ran into this early in my own career, back when the deliverable was still a printed manual, and the tool was an IBM Selectric typewriter. Nobody handed me a finished document to type up. I sat with an engineer, watched him operate the machine, and wrote down what I saw him do — not what he told me he did, which turned out to be a different and less accurate thing. Forty years and several format changes later, that gap between what people say they do and what they actually do is still where the job lives.
What the Work Actually Involves
In a given week, a technical writer might:
Sit in a product planning meeting and ask the only question that represents the user: “What does a person need to know before they can do this?” Not “how does this work?” but “what does someone who has never seen this need in order to succeed?”
Review engineering specs for a new feature and identify the three places where a user will get stuck — before the feature ships, while there’s still time to fix the UX.
Write a procedure, test it against the actual product, and find that step four in the spec produces a different screen than the spec describes. File the discrepancy. The bug gets fixed.
Negotiate scope with a product manager who wants five new tutorials by the end of the sprint. Push back on three of them because two overlap with existing content and one describes a workflow nobody uses.
This is the job. Documentation strategy, user advocacy, cross-functional coordination, quality control — all of it packaged inside the job title “technical writer.”
Scope Management Is the Whole Game
New writers often think scope is a project management concern, something their manager handles. It’s not. Scope management is a daily writing skill.
Every time you receive a request — “can you document this?” — you’re being handed a scope problem. The person asking almost certainly hasn’t thought about whether this new piece overlaps with existing content, whether the audience for this document is the same as the audience for the adjacent document, or whether the gap they’re describing is a documentation gap or a product design gap.
Your job is to figure that out before you write a single word. That work — thinking before writing — is the most technically demanding part of the job, and it’s invisible in the output. Nobody reviewing your finished draft sees the time and effort you spent deciding it shouldn’t exist as a separate document at all, and should instead be three paragraphs folded into an existing page. That decision doesn’t show up anywhere except in the fact that your documentation set stays coherent instead of sprawling.
User Advocacy in Practice
The technical writer is usually the only person in the room whose primary constituency is the end user. Developers are responsible to the codebase. Product managers are responsible to the roadmap and the revenue. The writer is responsible to the person who opens the docs because something isn’t working.
That’s not a soft skill. It’s a structural feature of the role. Use it. When a decision in a planning meeting will make the product harder to document — which usually means harder to use — say so. When you can’t explain a feature clearly, that’s often a signal the feature itself isn’t clear. The documentation problem is downstream of a design problem.
You have standing to raise that. Raise it. And expect some resistance the first few times you do, because most teams haven’t had anyone in the room whose job is explicitly to represent the person who wasn’t invited to the meeting. That resistance fades once the pattern holds: the writer who flags confusing UX early is usually right, and being right consistently is what earns the seat at the table permanently rather than provisionally.
This isn’t everything about technical writing, or course. What’s been your experience? Is there anything you’d add?
Further Reading
Anne Gentle, Docs Like Code (3rd edition) —the clearest current statement of what technical writers actually control when they work like engineering teams do.
Mark Baker, Every Page Is Page One (XML Press, 2013) — probably the clearest explanation of why writers who think in “topics” rather than “manuals” produce more usable documentation.
Christopher Gales, The Product is Docs — Writing product docs within a development group.
Write the Docs guide — https://www.writethedocs.org/guide/
What You Can Do
Look at the last three tasks you were assigned (or, if you’re new, three tasks you imagine a technical writer might receive).
For each one, ask: Is this a documentation problem or a product problem wearing documentation clothes?
Write one sentence for each task — not a solution, just a diagnosis. What would you do with that diagnosis?
Thursday: Mastering Audience Analysis — why “general audience” is a myth that produces useless documents, and how to develop a user persona that actually changes how you write.