How to Become a Technical Writer From a IT Support Background
Moving from IT Support into Technical Writing is one of the more natural lateral moves in tech, because you've already spent your career translating cryptic error messages and system behavior into language a frustrated, non-technical person can understand. The main gap isn't technical aptitude — it's proving you can write in a structured, edited, style-guide-driven way for an audience you'll never talk to in real time, rather than the improvised, verbal, one-off explanations you give on a ticket or call.
Skills that transfer
Every ticket resolution you've written is essentially a micro-draft of a troubleshooting guide; you already practice diagnosing a problem and writing the fix in a way a non-expert can follow, which is the core loop of task-based technical writing.
You've heard, verbatim, the exact phrases and misconceptions users have about software and hardware, which gives you a real feel for where documentation fails — most technical writers have to guess at this from user research, you already have hundreds of hours of it.
Diagnosing an issue across an OS, an app, and a network stack is the same skill as tracing a feature across an API, a UI, and a config file to document it accurately end-to-end.
Familiarity with tools like Zendesk, ServiceNow, or Confluence KBs transfers directly to the CMS and doc-platform habits (versioning, tagging, searchability) technical writing teams expect.
You've already learned to adjust explanations for different skill levels on calls; this is the instinct behind writing for a defined audience persona rather than assuming universal technical fluency.
The gap to close
In support you can ask clarifying questions and adjust in real time; in documentation the reader gets one shot at your words with no back-and-forth, so ambiguity that you'd normally patch verbally has to be eliminated in the draft itself.
Take five of your own past ticket resolutions and rewrite each as a standalone how-to article with no assumed follow-up question — have someone unfamiliar with the issue try to follow it exactly as written.
Technical writing teams are judged on consistency across hundreds of documents — voice, terminology, and formatting rules that don't matter in a one-off ticket response become critical at scale.
Read the Google Developer Documentation Style Guide fully and rewrite a few of your KB articles to conform to it exactly, noting every rule you had to look up.
Most technical writer job postings now expect comfort with Markdown, a static site generator (like Docusaurus or MkDocs), and basic Git workflows for submitting doc changes — not a word processor.
Fork a small open-source project's docs repo, write or fix a page in Markdown, and submit a pull request; this single exercise touches Git, Markdown, and review workflow at once.
A large share of technical writer roles, especially at software companies, are API/SDK documentation, which is a different skillset from end-user help articles and requires reading code or API specs directly.
Pick a public REST API with thin docs, write a sample endpoint reference (request, response, error codes, one worked example), and post it as a portfolio piece even if unsolicited.
As a writer you'll often document a feature before it's finished, based on specs, engineer interviews, and beta builds, rather than a fully working system a user is stuck on — a much more ambiguous starting point than a ticket.
Practice by picking an internal tool or script at your current job that has no documentation and writing a full guide for it from scratch, interviewing whoever built it as your only source.
First steps
- Convert 5-8 of your strongest past ticket resolutions or internal runbooks into polished, standalone how-to articles for a public portfolio (use a free site like GitHub Pages or a simple Notion page)
- Read the Google Developer Documentation Style Guide end to end and apply it to your portfolio pieces so you can speak fluently about style-guide conventions in interviews
- Learn Markdown and basic Git (add, commit, push, pull request) well enough to contribute a documentation fix to one open-source project
- Write one piece of API reference documentation for a public API you don't work with professionally, to show you can document developer-facing material, not just end-user help
- Ask your current employer if you can shadow or assist the documentation/knowledge-base team, even informally, to get a writing sample reviewed by an actual technical editor
- Rewrite your resume to lead with writing artifacts (links to your portfolio pieces) rather than support metrics like ticket volume or resolution time
Common questions
No — most hiring managers care far more about a portfolio of clear writing samples and evidence you understand the subject matter than about your degree; your IT support background actually gives you subject-matter credibility many English-degree holders lack.
It depends on how you frame it: if you present ticket counts and resolution speed, it reads as unrelated support metrics, but if you present the actual troubleshooting writing you produced as documentation samples, it reads as directly relevant experience.
Given a typical IT support background, end-user-facing documentation (help centers, KB articles, user guides) is the more natural first landing spot since it mirrors what you already write; API documentation is reachable but usually requires you to build coding-adjacent comfort first, so treat it as a second move rather than the opening one.
Get a personalized version of this plan, built from your actual background, with progress you can track.
Get your personalized plan