Technical Writer
Creates accurate, navigable documentation that helps users or developers understand, integrate, operate, and troubleshoot Web3 products.
New to this area? Learn the foundations before building proof.
Also listed as
Documentation Engineer · Developer Documentation Writer · API Technical Writer
What this role actually does
In practice, the role moves between planned work and live issues. A normal day may require the practitioner to draft or revise pages, test instructions, review code or product changes, and resolve accuracy questions.
The role is accountable for documentation architecture, technical accuracy, and task-based guides. It normally hands off decisions about product marketing claims and support ownership.
Where the role sits
Technical Writer usually sits inside Product, Operations, Customer Experience, or a founder-led operating team. Common reporting lines include Head of Product, COO, Product Operations Lead, Customer Experience Lead, or a functional founder. Most strategic roles are core-team positions; support and execution roles also appear as contractors, agencies, or fractional operations support. The role usually collaborates with Developer Relations, Product Operations, Backend Engineer, Web3 Educator / Curriculum Builder.
Core responsibilities
- Interview engineers, product owners, support, and users to understand real tasks and failure modes
- Plan documentation architecture across concepts, tutorials, references, troubleshooting, and release notes
- Write and test procedures, code examples, diagrams, and cross-links
- Maintain versioning and remove stale or contradictory instructions
- Build documentation review workflows tied to product changes
- Measure search gaps, failed tasks, support deflection, and reader feedback without assuming page views equal comprehension
Daily, weekly, and reactive work
A typical day
Draft or revise pages, test instructions, review code or product changes, and resolve accuracy questions.
Weekly or monthly
Run documentation audits, review search and support signals, update the backlog, and coordinate releases.
When conditions change
Publish urgent notices or fixes when an API, contract address, network requirement, or security instruction changes.
Deliverables
How success is judged
- Task completion
- Lower confusion
- Fewer repeated support questions
- Accurate versioning
- Usable search and navigation
- Fast correction of stale content
Read signals in context. Read task completion together with lower confusion. Neither signal is meaningful without the relevant launch, incident, market, workload, or attribution context.
Tools in practice
- Docs-as-code or CMS
- Draft, review, and maintain documentation map and concept guide, with owners, source links, and change history.
- GitHub
- Read code and issues, test examples, review documentation changes, and keep docs aligned with released software.
- Markdown or MDX
- Draft, review, and maintain documentation map and concept guide, with owners, source links, and change history.
- OpenAPI tooling
- Validate endpoint definitions, request and response examples, authentication requirements, and generated reference coverage.
- diagram tools
- Map system components, data flow, trust boundaries, and failure paths so reviewers can challenge the model before implementation or publication.
- analytics and search logs
- Measure the role-specific signals behind documentation map and concept guide and document attribution, time window, and known gaps.
Skills and prerequisite knowledge
Hard skills
- Technical writing
- Information architecture
- Code-reading or API literacy
- Testing instructions
- Version control
Working skills
- Structured communication
- Prioritization
- Reliability
- Cross-functional coordination
- Comfort with ambiguity
Prerequisite knowledge
Know the product architecture, target reader, prerequisites, common failure modes, and how changes move from engineering into documentation.
Expectations by level
Entry level
At entry level, a candidate should be able to complete a scoped assignment with review. That includes the ability to interview engineers, product owners, support, and users to understand real tasks and failure modes, to plan documentation architecture across concepts, tutorials, references, troubleshooting, and release notes, and to produce reviewable artifacts such as a documentation map and a concept guide.
Mid level
At mid level, the practitioner normally owns documentation architecture, technical accuracy, and task-based guides without constant supervision. They can coordinate adjacent teams and improve the workflow behind a documentation map and a concept guide, including when the role must publish urgent notices or fixes when an API, contract address, network requirement, or security instruction changes.
Senior
At senior level, the work shifts toward standards, decision rights, and review quality. A senior Technical Writer defines how documentation architecture, technical accuracy, and task-based guides are handled, reviews high-risk cases, and builds systems that do not depend on one person.
Proof of work and portfolio
Reviewers should be able to inspect a documentation map and a concept guide, trace the inputs or decisions behind the work, and understand what the candidate personally owned.
Strong proof
- A tested quickstart
- A documentation information architecture
- A before-and-after rewrite
- A troubleshooting guide based on real failure states
Weak evidence
- Polished prose that has never been executed
- API reference copied from code with no task guidance
- Documentation with no version or ownership
Common mistakes and misconceptions
- Taking responsibility for product marketing claims and support ownership without the mandate or approval to do so
Common misconception
Technical Writer may overlap with Developer Relations, but the hiring evidence is different. This role is judged on documentation architecture, technical accuracy, and task-based guides, not on ownership of product marketing claims and support ownership.
Scope boundaries
Usually owns
- Documentation architecture
- Technical accuracy
- Task-based guides
- Reference clarity
- Documentation maintenance
- Reader testing
Usually does not own
- Product marketing claims
- Support ownership
- Developer advocacy by default
- Engineering roadmap decisions
- Legal policy
Interview focus
Expect questions about technical writing, information architecture, and code-reading or API literacy, plus a scenario where the role must publish urgent notices or fixes when an API, contract address, network requirement, or security instruction changes. Interviewers are looking for evidence that the candidate knows where documentation architecture and technical accuracy stop and product marketing claims and support ownership begin.
How do you verify that a quickstart actually works for a new user?
How would you structure documentation for concepts, tasks, references, and troubleshooting?
What do you do when engineers disagree about the correct behavior?
Compensation and role risks
Direct technical-writing evidence exists in some Web3 companies, but adjacent software and documentation roles remain common references. Numeric ranges require current role-specific listings; broader occupational medians are context only.
No reliable role-specific range
KRAFT did not find a reliable role-specific range that meets the evidence standard. Compensation may still exist through salary, contract fees, retainers, grants, commissions, token or equity packages, creator revenue, or business economics. These models are described separately rather than compressed into an invented number.
Wider Web3 market, for scale
Typical advertised averages $65,000 – $200,000 / year
Individual postings run from about $40,000 to $350,000.
Across the role categories this index tracks, advertised averages sit between roughly $65,000 and $200,000 per year, with individual postings from about $40,000 to $350,000. This is whole-market scale from advertised roles - not a figure for this specific role, and not verified paid compensation.
Role risks
- Stale documentation
- Late involvement in product changes
- Unclear source of truth
- Being asked to explain broken product behavior away
- Maintenance debt
Compensation can change materially by geography, seniority, employment model, company stage, market cycle, and the mix of cash, bonus, commission, equity, token, vesting, royalties, or fees. A published range is useful only when those dimensions match the role being considered.
How to read compensation evidence
- Direct
- Evidence from the same or a materially equivalent role.
- Adjacent
- Evidence from a neighbouring occupation, used only for context.
- Broad market
- Category-level Web3 or labour-market evidence.
- Unverified
- Estimates without enough source or methodology detail.
Confidence reflects the quality and comparability of the evidence, not the value or legitimacy of the role.
Career path and role fit
Common progression
May fit people who
People who enjoy precise explanation, testing every instruction, and building systems that remain useful after launch.
May not fit people who
People who only enjoy promotional writing or who dislike maintenance and repeated technical review.
Practical next steps
How this guide is built. Role content is drawn from current first-party hiring material and reputable industry evidence, with compensation labelled by confidence and evidence tier rather than a single number.
Turn this role into evidence.
Choose a proof-of-work project, package the result, and practice the questions this role is likely to ask.