The Technical Writer Roadmap for 2026: The $120K Career Nobody Talks About

Published on BirJob.com · March 2026 · by Ismat

The Day I Realized Documentation Might Be Worth More Than Code

When I built the first version of BirJob's scraper infrastructure, I was a one-person team writing Python, wrestling with Playwright, and managing 91 scrapers that pulled job listings from every corner of the Azerbaijani internet. Each scraper had its own quirks: different HTML structures, different authentication flows, different anti-bot measures, different API formats. Some sites used GraphQL. Some were SPAs that required browser automation. Some randomly changed their CSS class names every deploy.

I kept everything in my head. For months, it worked. Then one day I had to take a week off, and I came back to find that three scrapers had broken while I was gone. No one could fix them because no one — including my future self — could figure out how each one worked without reading every line of code. The scraper for boss.az used a GraphQL API with an undocumented query format. The one for tabib.gov.az relied on extracting data from a __NEXT_DATA__ JSON blob because their CSS class hashes changed with every deployment. The workly.az scraper had been converted from Playwright to static HTML parsing, but there was no record of why.

So I sat down and wrote documentation. Real documentation. How each scraper works, what the data schema looks like, what the common failure modes are, how to add a new source. It took a full week. And when I finished, I had an uncomfortable realization: that documentation week was probably the most valuable week of work I'd done in the entire project. The code was a black box; the docs turned it into a system anyone could understand and maintain.

That experience sent me down a rabbit hole. I started paying attention to the people who write documentation for a living — technical writers. And what I found was genuinely surprising. They earn $80,000 to $160,000 or more. They work remotely at higher rates than almost any other tech profession. The field is chronically understaffed because nobody grows up dreaming of being a technical writer. There's no bootcamp hype. No TikTok trend. No "Learn Tech Writing in 12 Weeks" YouTube course with a million views. It's one of the quietest, best-kept secrets in all of technology.

This roadmap is about how to break into technical writing, what the work actually looks like, and why it might be the smartest career move for people who are good at explaining things — a surprisingly rare and valuable skill. For our broader overview of the field, see our Technical Writing Career article. This roadmap goes deeper: week-by-week, tool-by-tool, all the way to your first job.

The Numbers First: A Well-Paid Career With Almost No Competition

Let me ground this in data, because the data is what makes technical writing uniquely attractive. Most tech careers have either good salaries or low competition. Technical writing has both.

• The U.S. Bureau of Labor Statistics reports the median annual wage for technical writers at $79,960 as of 2023, with the top 10% earning over $128,000. The BLS projects 7% growth from 2022 to 2032, faster than the average for all occupations. But the BLS figures include all industries — technical writers in software and tech earn significantly more than the overall median.
• Glassdoor puts the average technical writer salary in the U.S. at approximately $85,000, with senior technical writers at technology companies earning $110,000–$150,000. At Big Tech companies, the numbers go higher: Levels.fyi shows Google technical writers earning $150,000–$250,000+ in total compensation (base + equity + bonus). Google's tech writer role is notoriously competitive and essentially requires coding skills, but it demonstrates the ceiling.
• The Write the Docs annual salary survey — the most tech-writing-specific data source available — consistently shows median salaries of $90,000–$115,000 for U.S.-based tech writers, with senior staff writers and documentation managers earning $130,000–$160,000+. The survey also reveals a crucial detail for international workers: technical writers working remotely for U.S. companies from outside the U.S. report median salaries of $50,000–$80,000.
• A LinkedIn job search consistently shows thousands of open technical writing positions in the U.S. alone. The application-to-opening ratio is dramatically lower than for software engineering roles. While a mid-level developer position might get 200–500 applications, a technical writer position at the same company often gets 20–50.
• Remote work prevalence is exceptionally high. The Write the Docs survey found that approximately 80% of technical writers work remotely at least part-time, and a large majority work fully remote. Documentation is inherently async and text-based — it's one of the most remote-friendly jobs in existence.
• For emerging markets specifically: a technical writer in Azerbaijan, Turkey, Poland, or Colombia working remotely for a U.S. or European tech company can realistically earn $40,000–$90,000. In a market where local developer salaries might be $15,000–$30,000, tech writing for international companies represents a genuine economic step change.

Why is the competition so low? Three reasons. First, nobody grows up wanting to be a technical writer — there's no cultural narrative around it. Second, people who are good at writing tend to go into content marketing, journalism, or fiction — they don't know that a $120K technical writing career exists. Third, people who are good at technology tend to become engineers — they don't think of writing as a "real" career. Technical writing sits at the intersection of two skills (writing + technical understanding) that rarely overlap, and that scarcity creates the opportunity.

What Technical Writers Actually Do: The Five Flavors

"Technical writer" is a broad title that covers several distinct subspecialties. The differences matter enormously for your career path, your daily work, and your salary. Let me break them down.

1. API Documentation Writer

This is the highest-paid and most in-demand subspecialty. You write and maintain documentation for APIs — REST, GraphQL, gRPC, WebSocket. You create reference docs (endpoint descriptions, parameters, response schemas), tutorials ("How to authenticate and make your first API call"), and conceptual guides ("Understanding our pagination model"). Companies like Stripe, Twilio, and GitHub are famous for excellent API documentation, and they employ dedicated writers to maintain it.

Skills needed: Understanding of HTTP, JSON, authentication (OAuth, API keys, JWTs), basic coding ability (you need to write and test code samples), and familiarity with OpenAPI/Swagger specifications. This subspecialty pays a premium because it requires genuine technical depth — you're writing for developers, and developers will immediately notice if you don't understand what you're documenting.

2. Developer Documentation Writer

Broader than API docs. You write guides, tutorials, quickstarts, and reference material for developer-facing products — SDKs, frameworks, CLIs, infrastructure tools. You might work at a company like Vercel (documenting Next.js), HashiCorp (Terraform docs), or Elastic (Elasticsearch guides).

3. Product Documentation Writer

You document user-facing SaaS products — admin guides, feature descriptions, troubleshooting articles, knowledge base content. Think Salesforce, Zendesk, or HubSpot documentation. Less technical than API docs, but requires strong empathy for end users who are often non-technical.

4. Internal Documentation / Knowledge Management

You document internal systems, processes, and architecture for engineering teams. Runbooks, architecture decision records (ADRs), onboarding guides, incident response procedures. Companies with strong engineering cultures like Stripe, Notion, and GitLab invest heavily in this.

5. Developer Relations / Content Engineering

A hybrid role where technical writing meets advocacy. You write blog posts, tutorials, and educational content to help developers succeed with a platform. Companies like Vercel, Supabase, and Cloudflare hire heavily for this intersection. It often pays more than pure technical writing because it includes a marketing/growth component.

The Docs-as-Code Movement: Why Technical Writers Need Git

If there's one trend that has fundamentally transformed technical writing in the last five years, it's docs-as-code. This is the practice of treating documentation like software: writing it in plain text formats (Markdown, reStructuredText, AsciiDoc), storing it in version control (Git), reviewing it through pull requests, building it with static site generators, and deploying it through CI/CD pipelines.

This isn't optional anymore. If you want a technical writing job at a tech company in 2026, you need to be comfortable with:

• Git and GitHub: Cloning repos, creating branches, making commits, opening pull requests, resolving merge conflicts. You don't need to be a Git wizard, but you need to be fluent in the basic workflow
• Markdown: The lingua franca of technical writing. Headers, lists, links, code blocks, tables, images. Most developer documentation is written in Markdown or a superset of it (MDX)
• Static site generators: Docusaurus (React-based, used by Meta, Supabase, many others), Read the Docs (Sphinx-based, dominant in Python ecosystem), MkDocs (Python, clean and simple), GitBook (hosted platform, less technical setup). You should be able to set up a docs site from scratch in under an hour
• CI/CD for docs: GitHub Actions or similar to automatically build and deploy docs when changes are merged. Docs that require manual deployment are docs that go stale
• IDE/editor: VS Code is the standard. Know how to use Markdown preview, linting extensions, and Git integration

Why does this matter for your career? Because it's the filter that separates technical writers who can work at tech companies from those who can't. A traditional technical writer who's used to working in Word documents and SharePoint will struggle to land a role at a modern tech company. A technical writer who can open a pull request, write clean Markdown, and set up a Docusaurus site is immediately employable in the tech industry's highest-paying segment.

The Tools: What Technical Writers Use Every Day

A note on "traditional" tools: Some technical writing jobs — particularly in healthcare, manufacturing, and government — still use tools like MadCap Flare, Adobe FrameMaker, or Confluence. These are perfectly fine tools, and there are good jobs using them. But the highest-paying tech writing roles are overwhelmingly docs-as-code, and that's what this roadmap focuses on.

The Writing Skills: Clarity Over Creativity

This is where technical writing diverges sharply from every other form of writing. If you're a journalism major, a creative writer, or a content marketer, you'll need to unlearn some of your instincts. Technical writing rewards the opposite of what gets rewarded in most writing contexts.

• Clarity beats elegance. A beautiful sentence that's ambiguous is worse than a plain sentence that's precise. You're not trying to entertain; you're trying to transfer information with zero ambiguity
• Short sentences. If a sentence is longer than 25 words, it's probably too long. If it has more than one idea, split it
• Active voice. "Click the button" not "The button should be clicked." "The API returns a JSON object" not "A JSON object is returned by the API"
• Consistent terminology. Pick one term for each concept and use it everywhere. Don't call it a "function" in one paragraph and a "method" in the next unless they're genuinely different things
• Structured hierarchy. H2 for sections, H3 for subsections, H4 for sub-subsections. Numbered lists for sequential steps. Bulleted lists for non-sequential items. Tables for comparison data. Every structural choice should be intentional
• Task-oriented writing. Documentation should answer "How do I do X?" not "Here is a description of our system." Lead with the user's goal, not with your product's architecture
• Code examples that actually work. Every code sample should be tested, runnable, and complete enough to copy-paste. Broken code samples are the fastest way to lose developer trust

The best technical writers I've encountered share a specific cognitive trait: they can hold a complex system in their head and then systematically decompose it into digestible pieces for someone who knows nothing about it. This is structured thinking, and it's the core skill. Everything else — grammar, style, tool proficiency — is learnable. The ability to take complexity and make it simple is the talent.

Technical Depth: You Need to Understand the Product

Here's where many aspiring technical writers get tripped up. You don't need to be an engineer. But you need enough technical understanding to:

• Use the product yourself. If you're documenting an API, you need to make API calls. If you're documenting a CLI tool, you need to use the CLI. You can't document what you don't understand
• Read code at a basic level. You don't need to write production code, but you should be able to read a Python function, a JavaScript class, or a REST endpoint handler and understand what it does. This lets you work directly with the codebase, not just with what engineers tell you
• Ask good technical questions. When an engineer explains a feature, you need to know what follow-up questions to ask: "What happens if the user passes an invalid parameter?" "Does this require authentication?" "What are the rate limits?" Engineers respect technical writers who ask sharp questions
• Understand the developer ecosystem. Know what REST is. Know what JSON is. Know what a container is. Know the difference between SQL and NoSQL. You don't need deep expertise, but you need literacy

The skill ladder: A product documentation writer needs moderate technical depth. An API documentation writer needs high technical depth. A developer documentation writer needs near-engineer-level understanding of the product they're documenting. Choose your subspecialty based on your technical comfort level, and know that you can always grow into deeper technical roles over time.

The 12-Month Roadmap: Week by Week

This roadmap assumes you can write clear English (or another language — technical writing is increasingly multilingual) and have a basic interest in technology. You don't need a CS degree. You don't need prior writing credentials. You need a willingness to learn, a tolerance for detail, and the patience to spend a year building skills before landing your first role.

Phase 1: Writing Foundations and Technical Literacy (Months 1–3)

Goal: Build the core writing skills and technical foundation that every technical writer needs.

Best resources for Phase 1: Google Technical Writing Courses (free, excellent), Google Developer Documentation Style Guide, Microsoft Writing Style Guide, and Write the Docs Documentation Guide.

Phase 2: Docs-as-Code and Tooling (Months 4–6)

Goal: Master the docs-as-code toolchain and build your first complete documentation site.

Best resources for Phase 2: Docusaurus official docs (they're great — which makes sense), MkDocs Material getting started guide, Vale documentation, and OpenAPI Initiative learning resources.

Phase 3: Portfolio Building and Open Source (Months 7–9)

Goal: Build a portfolio of real documentation work that proves you can do the job.

Phase 4: Specialization and Job Readiness (Months 10–12)

Goal: Specialize, polish your portfolio, and land your first technical writing role.

Entry Points: How Real People Break In

The theoretical roadmap is nice, but let me tell you how people actually get their first technical writing jobs. There are several proven paths:

• Open source contributions: This is the most accessible entry point. Every major open source project needs better documentation. Find projects you use, fix their docs, submit PRs. After a few months of consistent contributions, you have both a track record and references who can vouch for your work. The Write the Docs community maintains lists of doc-friendly projects
• Google Season of Docs: Google Season of Docs is a program where technical writers work with open source organizations on documentation projects. It's competitive but doable, and it provides a Google-branded credential, a mentor, and a significant portfolio piece
• Internal transfer: If you already work at a tech company — in QA, support, engineering, or product — volunteer to write documentation. Many tech writers started by documenting their own team's work. This is the lowest-risk path because you already have domain knowledge and internal credibility
• Freelance/contract: Start with small freelance gigs. Document a startup's API. Write a getting-started guide for an indie developer's tool. Platforms like Upwork and Fiverr have technical writing categories, though the pay starts low. The real value is portfolio building and client testimonials
• Developer-to-writer transition: If you're a software developer who's good at explaining things, you're already 70% of the way there. Many companies actively prefer technical writers with engineering backgrounds, especially for API and developer documentation

Certifications: The Honest Assessment

Unlike fields like cybersecurity or cloud engineering, technical writing doesn't have a dominant certification ecosystem. There's no "AWS Certified Technical Writer" that opens doors. Here's what exists and whether it's worth your time:

The bottom line: In technical writing, your portfolio is your certification. A hiring manager reviewing technical writing candidates will look at your writing samples before they look at anything else on your resume. Three great documentation projects on GitHub are worth more than any certificate. Take the free Google course for foundational knowledge, apply to Season of Docs if you can, and spend the rest of your time building documentation that demonstrates your skills. For more thoughts on certifications across tech, see our Best Free Certifications 2026 guide.

Career Progression: Where Technical Writers Go

The DevRel transition is particularly interesting. Many Developer Relations professionals started as technical writers. Once you're skilled at explaining complex technical concepts to developers, the jump to DevRel — which adds public speaking, community management, and content strategy — is natural. DevRel often pays more than pure technical writing because it combines technical depth with marketing/growth skills. For more on the DevRel career path, see our Developer Relations Career article.

The stress factor: This is something nobody talks about but everyone should know. Technical writing is, by tech standards, a lower-stress career. You're not on-call. You're not fixing production outages at 3 AM. You're not responsible for keeping a service running. Your deadlines exist but are rarely the urgent, ship-or-die kind that engineering teams face. For people who want to work in tech without the burnout that plagues many engineering roles, technical writing offers an unusually sustainable pace.

The AI Elephant in the Room

I'd be dishonest if I didn't address this directly: can AI replace technical writers? It's the question I get every time I mention this career to someone. And the answer is more nuanced than either the optimists or the pessimists want to hear.

What AI does well in technical writing right now:

• Generating first drafts of reference documentation from code or API specs
• Reformatting and restructuring existing content
• Translating documentation between languages (with human review)
• Generating code samples in multiple programming languages
• Summarizing long technical documents
• Catching grammar and style issues (though Vale does this too)

What AI cannot do (and won't be able to do anytime soon):

• Verify accuracy. An AI can generate a beautiful explanation of how an API works. But is that explanation actually correct for this version of this product? Only a human who has tested it knows. And incorrect documentation is worse than no documentation — it erodes developer trust and generates support tickets
• Information architecture. Deciding how to organize a 500-page doc set so that new users can find what they need in under 30 seconds — that's a design problem that requires understanding human cognition, not just information. AI can't make those structural decisions well
• User empathy. Understanding what a developer is confused about, what they're trying to accomplish, what they need to see first — this requires the kind of audience awareness that comes from watching real users interact with your docs
• Cross-functional collaboration. Working with engineers who don't want to write docs, with product managers who can't explain features clearly, with designers who have context you need — this human coordination is a core part of the job
• Judgment about what to document and what to skip. Not everything needs to be documented. Deciding what's critical, what's nice-to-have, and what should be left to inline code comments requires judgment that AI lacks

My prediction: AI will make technical writers 2–3x more productive, not replace them. A technical writer using AI tools will produce higher-quality documentation faster than ever before. This means companies might need slightly fewer technical writers per product, but it also means that companies who previously couldn't justify hiring a dedicated writer will now be able to afford documentation — expanding the total market. The net effect: the same number of jobs or slightly fewer, but higher productivity expectations and higher quality standards. Technical writers who refuse to use AI tools will be at a disadvantage. Those who use them skillfully will thrive.

What I Actually Think

Time for some opinionated takes that you won't find in the "How to Become a Technical Writer" articles from content farms.

Technical writing is the most underrated career in all of technology. I genuinely mean this. It pays well, it's remote-friendly, it's lower-stress than engineering, it has low competition, and it's accessible to people from non-traditional backgrounds. The fact that it's underrated is actually a feature, not a bug — it means there are fewer people competing for jobs, which keeps salaries high relative to the effort required.

You don't need a degree in English, journalism, or communications. Some of the best technical writers I've come across have degrees in biology, music, history, and philosophy. What they share is the ability to learn complex things and explain them simply. If you have that trait, you can become a technical writer regardless of your educational background.

The "tech" in technical writing matters more than the "writing." This is counterintuitive but true. A mediocre writer who deeply understands API authentication patterns will be a better API documentation writer than an excellent writer who doesn't know what OAuth is. You can always improve your prose. You can't fake technical understanding. Prioritize learning the technology over perfecting your literary style.

Open source is the great equalizer. I run BirJob from Azerbaijan. If I wanted to build a portfolio as a technical writer, I wouldn't need to live in San Francisco or have a U.S. work permit. I could contribute to open source documentation for projects used by millions of developers, build a portfolio that any hiring manager in the world can see, and apply for remote positions. A merged PR to the FastAPI or Next.js documentation is an equally impressive credential whether you submitted it from Baku, Bangalore, or Brooklyn.

The docs-as-code skill gap is your biggest opportunity. There are thousands of technical writers who grew up in the Microsoft Word / Adobe FrameMaker world and haven't made the transition to docs-as-code. If you start fresh with Git, Markdown, and static site generators, you're immediately more competitive than many experienced writers who are struggling to adapt. Youth (in terms of toolchain familiarity) is an advantage here.

Remote work in technical writing is not going away. Documentation is inherently asynchronous. You write, someone reviews, you iterate. There's no "you must be in the office for the standup." Some of the best documentation teams in the world — GitLab, Automattic, Stripe — are fully or largely remote. The ~80% remote rate in technical writing is structural, not a pandemic artifact. For people in emerging markets, this is the golden path into the global tech economy. See our Remote Work from Azerbaijan article for more on this.

The Action Plan: Start This Week

Don't just bookmark this. Here are 7 things to do in the next 7 days:

1. Day 1: Read the Google Developer Documentation Style Guide. Not the whole thing — focus on the "General Principles" and "Language and Grammar" sections. Take notes on 5 rules that surprise you or contradict your writing habits.
2. Day 2: Go to stripe.com/docs. Spend 30 minutes exploring their documentation. Click through their API reference, quickstart guides, and tutorials. Pay attention to structure, not just content. How is the sidebar organized? How do they handle code samples? How do they use tables, callouts, and diagrams? Write down 3 things you'd steal for your own docs.
3. Day 3: If you don't have a GitHub account, create one. Create a repository called tech-writing-portfolio. Write a README.md file that introduces yourself, lists 3 documentation projects you plan to build, and explains why you're pursuing technical writing. Push it. You now have a portfolio page.
4. Day 4: Find a badly-documented open source project (they're everywhere). Pick one page — just one — and rewrite it. Submit it as a pull request. Even if it's not merged, you've practiced the workflow: fork, edit, commit, PR. And many projects will merge your improvement gratefully.
5. Day 5: Install VS Code if you haven't already. Install the "Markdown All in One" and "markdownlint" extensions. Write a 500-word Markdown document about any technical topic you know (could be how to set up a development environment, how to use a specific tool, how to debug a common error). Preview it in VS Code. Fix all lint warnings.
6. Day 6: Join the Write the Docs Slack workspace. Introduce yourself in the #introductions channel. Browse #career-advice and #job-posts-only. You're now connected to the largest community of technical writers in the world.
7. Day 7: Block 1 hour per day in your calendar for technical writing practice. Consistency is everything. Writing is a skill that improves with daily practice, not with weekend marathons. One hour a day for 12 months will transform your ability.

Sources

• U.S. Bureau of Labor Statistics — Technical Writers Occupational Outlook
• Glassdoor — Technical Writer Salaries 2026
• Levels.fyi — Technical Writer Total Compensation
• Write the Docs — Annual Salary Survey
• Google Developer Documentation Style Guide
• Microsoft Writing Style Guide
• Google Technical Writing Courses
• Google Season of Docs
• Write the Docs Community
• Docusaurus — Documentation Site Generator
• MkDocs — Documentation Site Generator
• MkDocs Material Theme
• Read the Docs — Documentation Hosting
• GitBook — Documentation Platform
• OpenAPI Specification (Swagger)
• Redoc — API Documentation Generator
• Vale — Prose Linter
• Mermaid — Markdown Diagrams
• Stripe Documentation (exemplary reference)
• GitHub Documentation (exemplary reference)
• Twilio Documentation (exemplary reference)
• freeCodeCamp — Free Technical Education
• STC — CPTC Certification
• OpenAPI Initiative — Learning Resources
• Instructor — Structured LLM Output (for AI-assisted writing)
• Technical Writer Roadmap — roadmap.sh

I'm Ismat, and I build BirJob — a platform that scrapes 9,000+ job listings daily from 77+ sources across Azerbaijan. If this roadmap helped, check out our other career guides: Technical Writing Career Overview, Developer Relations Career, Best Free Certifications 2026, Remote Work from Azerbaijan, and The AI Engineer Roadmap.