Technical Writer

The Technical Writer owns the external documentation a user or developer relies on to succeed with a product - user guides, how-to and reference topics, API / developer documentation, release notes, and help-center content - and the docs-as-code workflow that keeps it accurate and fresh. This is an individual-contributor seat reporting to a docs / content lead or an engineering manager, with end-to-end ownership of the docs for the features and areas it covers and close partnership with engineering, product, and support. The deliverable is documentation a reader can act on: technically correct, written for the reader's task, structured so they can find it, and maintained so it does not rot. It is not the Content Designer, who owns the in-product text - microcopy, labels, empty states, error messages, and interface information architecture - that shapes the interaction itself (this seat documents the product the reader steps away to consult; the content designer writes the words inside the flow). It is not the Senior Technical Writer, who owns the docs information model, the docs-as-code tooling standard, and style governance across the whole doc set (this seat writes and maintains docs to that standard and escalates the architecture call rather than freelancing it). It is not a Developer Advocate / DevRel, who owns community, advocacy, and evangelism (this seat owns the reference and how-to a developer consults; DevRel meets them where they gather). And it is not Marketing content - the job is functional accuracy that helps a reader complete a task, not persuasion. Quality is visible in content freshness, documentation usage, and search success, so better judgment shows up as a reader who finished the task and never filed the ticket. What separates great from average is documentation the reader can actually use to get something done, and that stays true after the writer moves on: a how-to organized around the reader's task rather than the feature's menu, an API reference where every parameter and error is correct and every example runs, an information structure where the answer is findable in one search, and a freshness cadence that catches a doc the day its feature changed. A mediocre writer transcribes the spec, ships a wall of prose nobody can navigate, and lets it silently go stale; a great one gets the facts from the SME, writes for the task, structures for findability, and builds the review loop that keeps it honest.