The Technical Writer's Role in a Team
Next Tuesday, Nightjar ships SMS alerts on its Team plan. The engineers have finished the code. But the alerts guide, the API reference, the plan comparison, the release notes and the support team's saved replies all still describe a world without SMS. Nobody owns noticing that, unless the company has a technical writer.
The rule
You stand between the people who build and the people who use.
Knowledge about a product starts with the people who make it and has to reach the people who use it. The technical writer is the route it travels. In practice that means working with almost every team:
- Engineers and product managers know what is changing and why. The writer reads their plans, asks questions, tries early builds and gets their review on accuracy.
- Support sees where users get stuck every day. The writer turns repeated questions into pages, and support links those pages in replies.
- Designers shape the interface. Button labels, error messages and onboarding text are often written together.
- Marketing publishes tutorials and launch posts. The writer keeps their technical details correct.
What the writer owns is the documentation as a whole: which pages exist and how they connect, whether they are accurate and current, the style guide and word list, and the process that gets a change reviewed and published. At a small company like Nightjar one writer covers all of it; at a large one, a docs team splits it by product area.
Timing is part of the role. Documentation is part of the feature, so a feature is not really finished until its docs are. That means the writer joins while a feature is being designed and built, not after users start complaining.
The shortcut
Follow the change. For any product change, ask: who does it affect, and which page or piece of text will each of them read?
Start from the change
SMS alerts arrive on the Team plan next Tuesday.
The trap is waiting until after launch. The first users then meet an empty or outdated guide, and support answers the same question dozens of times.
Drills
Answer fast — trust the rule.
Nightjar renames its "Integrations" menu to "Connections". What is the writer's job?
When should a writer ideally start on the docs for a new feature?
Which team is usually the writer's best source for where readers get stuck?
At a five-person start-up, the only writer is asked to cover the docs, the interface text and the technical parts of a launch post. How typical is that?
Remember
- You stand between the people who build and the people who use.
- Shortcut: follow the change: who is affected, and what will each of them read?
- Trap: starting the docs after launch instead of while the feature is built.