Documentation & UX 2026
Technical Writer Resume (Harvard Format)
Turn dense engineering reality into docs people actually finish — and prove your resume can too.
How do I write a Technical Writer Resume (Harvard Format) resume in the Harvard format?
Technical writers are hired to reduce support tickets, shorten time-to-first-call, and make complex products usable — not to write pretty prose. A strong Harvard-format resume proves you ship documentation as code (Markdown, Git, CI), own information architecture and API references, and tie every doc to a measurable outcome like deflection rate or onboarding time. This guide shows you how to quantify writing work that usually hides in Confluence.
What recruiters look for
- Docs-as-code fluency: Markdown/AsciiDoc/reStructuredText authored in Git with PRs, plus static-site generators (Docusaurus, MkDocs, Hugo, Antora) and CI builds (Vale linting, broken-link checks)
- API and developer docs: OpenAPI/Swagger reference generation, Postman collections, code samples in 2+ languages, and tools like Redocly, Stoplight, or ReadMe
- Structured authoring and single-sourcing: DITA, topic-based authoring, and CCMS/help-authoring tools (Paligo, MadCap Flare, Oxygen XML, Adobe FrameMaker)
- Measurable impact: documentation deflection rate, support-ticket reduction, time-to-first-successful-call (API), search-success rate, and doc satisfaction (thumbs-up / CSAT) scores
- Style and quality systems: ownership of a style guide (Google/Microsoft Writing Style Guide or a custom one), Vale rule sets, and readability targets (Flesch-Kincaid grade level)
- Cross-functional credibility: working from engineering tickets, reading code/PRs, running SME interviews, and shipping docs inside the product release cycle
Required sections, in this order
Header & Skills Band
- Use a clean one-line header: name, email, LinkedIn, and a portfolio/published-docs URL — for a writer, a missing portfolio link is a red flag
- Group a tight skills band by category recruiters scan for: Authoring (Markdown, DITA, AsciiDoc), Tooling (Docusaurus, MadCap Flare, Git, Vale), API (OpenAPI, Postman, Redocly), and Domains (SaaS, fintech, devtools)
- Name the style guides you've worked under (Microsoft Writing Style Guide, Google developer docs style, custom) — it signals you know house rules exist
- Skip generic adjectives like 'detail-oriented' and 'excellent communicator'; for a writer, the resume itself is the proof, so spend the line on a tool or domain instead
Experience Bullets (Harvard XYZ)
- Lead every bullet with the outcome a doc manager cares about: ticket deflection, onboarding time, search success — then name the doc set and tool you used to get there
- Quantify the writing: number of articles/endpoints documented, words or pages migrated, % reduction in support contacts, or % lift in doc CSAT
- Show ownership of process, not just output: 'established the docs-as-code pipeline', 'authored the team style guide', 'ran the doc review SLA' — these signal seniority
- Include collaboration mechanics — SME interviews, reading PRs, working from Jira tickets — so reviewers see you operate inside engineering, not beside it
Portfolio, Education & Certifications
- Add a one-line portfolio entry with concrete artifacts: 'Published API reference (live), onboarding guide, and migration runbook' with the URL — recruiters click this first
- List relevant certifications precisely: Google Technical Writing, Write the Docs participation, API documentation (Postman/ Idratherbewriting course), or a CPTC (Certified Professional Technical Communicator) credential
- Education stays one or two lines: degree, institution, year — relevant coursework (technical communication, CS, UX) only if it strengthens a thin work history
- If you came from a non-writing background (engineering, support, QA), name it as an asset: domain depth that lets you document without hand-holding
Sample in Harvard format
Strong vs weak bullets
Wrote and maintained documentation for the company's software products.
Cut support-ticket volume 31% across 6 product areas by rewriting 140+ help-center articles in docs-as-code (Markdown + Docusaurus), instrumenting each with thumbs-up feedback to prioritize the worst 20 pages.
Leads with deflection %, names scope (140+ articles, 6 areas), the toolchain, and the feedback loop that drove prioritization.
Improved the API documentation and made it easier for developers to use.
Reduced time-to-first-successful-API-call from 47 to 12 minutes by generating an OpenAPI 3.1 reference in Redocly, adding runnable code samples in Python and JavaScript, and shipping a 5-minute quickstart validated with 8 developer usability tests.
Uses a real developer-experience metric, names the spec version and tooling, and shows the usability testing behind the claim.
Helped set up a new documentation system and style guide.
Stood up the docs-as-code pipeline (Git, MkDocs, Vale CI linting) and authored a 40-rule style guide adopted by 14 engineers, cutting doc-review cycle time 60% and broken links to zero in CI.
Shows process ownership, the linting/CI discipline, adoption scale, and two concrete before/after gains.
Migrated old documentation to a new platform.
Migrated 1,200 legacy pages from Confluence to a single-sourced DITA architecture in Paligo, reusing 38% of content as shared topics and cutting localization cost for 6 languages by ~$45K annually.
Quantifies volume, names the structured-authoring approach, reuse %, and ties single-sourcing to real localization savings.
Mistakes specific to this role
- No portfolio or published-docs link — for a writer this is disqualifying; recruiters want to read your actual work, not your description of it
- Listing tools as a wall of logos without showing what you built with them; 'MadCap Flare' means nothing without the deliverable and outcome attached
- Vague verbs ('assisted with', 'helped maintain') that hide whether you owned the doc set or just edited typos
- Zero metrics — no deflection rate, no onboarding time, no doc CSAT — which makes writing look like unmeasurable busywork
- Typos, inconsistent capitalization, or mixed tense on a writer's resume; the document is the work sample and small errors read as career-ending
Your résumé starts here. Pay later.
Start composingFrequently asked
- How do I quantify technical writing when I don't control the analytics?
- Use proxies you can defend: number of articles or API endpoints documented, pages migrated, reduction in repeat support questions (ask the support lead for ticket tags), doc-review cycle time, or thumbs-up/down feedback on pages. Even 'documented all 84 endpoints for the v2 API launch' is concrete. If you genuinely have no numbers, quantify scope and adoption (e.g., 'style guide adopted by 14 engineers').
- Do I need to know how to code to be a technical writer?
- For developer/API documentation, yes — at least enough to read code, run a curl request, edit a code sample, and work in Git with pull requests. Put the languages you can read (Python, JavaScript, SQL) in your skills band. For end-user or hardware docs, deep coding isn't required, but Git and Markdown fluency is increasingly table stakes.
- Should I include a portfolio link or attach writing samples?
- Include a live portfolio URL in your header — it's the single highest-leverage line on a writer's resume. Link to real published docs (API reference, quickstart, runbook). If your best work is behind a login or NDA, build a small public sample set: redacted excerpts or a personal docs site for an open-source tool.
- Is docs-as-code worth learning if I come from Word/FrameMaker?
- Yes — most modern software roles now expect Markdown or AsciiDoc authored in Git with CI checks (Vale, link checkers) and a static-site generator (Docusaurus, MkDocs). You don't need to be a developer, but showing one docs-as-code project on your resume sharply widens the roles you'll qualify for. Structured-authoring/DITA skills (Flare, Oxygen, Paligo) remain valued in enterprise and regulated industries.