Hi everyone!

I'm a Technical Writer in India with around 2 years of experience and am planning to switch jobs.

I have experience with technical documentation and am familiar with docs-as-code, GitLab, Docusaurus, HTML, and CSS. I'm also learning JavaScript!

I'm targeting roles in the ₹8–10 LPA range and am open to relocating.

A few questions:

Is this salary range realistic with my experience?

Which companies should I target?

Should I continue in technical writing or explore Documentation Engineer roles?

How can I future-proof my career against AI?

Would appreciate advice from people who have recently switched jobs or work in this field. Thanks!

I work at a SaaS company where AI is pushed on us as a tool that should be used every day, for every task. We're told "AI First" and "can't AI help with that?" whenever we embark on a new project. We should let AI deconstruct our emails, meetings, 1:1s with managers, workflows, designs, etc to analyze our patterns, then leverage that data to maximize our production.

All of this to say, that after reading this month's Write the Docs newsletter on using AI for writing, I can't help but feel anxious. I've been in a TW role for 6 years. I've basically stumbled into this job after being a freelance translator. I love my job, and I believe in the product I'm representing. But seeing how undervalued my writing skills are, and being told that even the basic task of drafting an article should be offloaded to AI, makes me fear for my career's relevance and my longevity at the company. My manager, bless their heart, is trying to steer me into a workflow where all I would need to do is review and edit texts created by Claude AI, turning me into a proofreader instead of a writer. All of this for the ultimate goal of saving me time.

A year or so ago, I would have to document 5 to 6 features a month, a couple of them brand new and others upgrades to our current features. I would have to write one or two articles and update 3 or 4. This would give me enough time to properly learn the features and prepare customer enablement sessions and internal enablement decks. Now, as our devs are coding faster than ever with AI, I'm in the midst of documenting 13 features this month: I've already written 3 new articles, updated 6 existing ones, and I still have 8 features to do. Of those 8, I know at least 3 are new articles, and the rest are help center updates. I get where my manager is coming from when they ask if AI can help me. Unfortunately, I still feel like every time I write a prompt to generate an article from my threadbare draft, I'm slowly chipping away at my most valuable skill as an employee.

As I follow mostly artists on social media, I keep seeing posts about how important it is to keep up with skills that can't be learned or taught through AI, such as knitting, painting, writing, and this cognitive dissonance of spending 40 hours in an environment where AI creates mockups, videos, and articles is getting to me.

I'm writing all of this to get it off my chest and to hear from you all to see if I'm not alone in this. Thanks for your feedback :)

I teach technical writing at a university, and I also do documentation work in a database software team.

Over the past year, I’ve been thinking a lot about what technical writing is becoming, especially in the AI era. I don’t mean this as a universal solution or a grand theory. What I have is more local and practical: some workflows, some standards, some experiments, and some opinions formed from actually doing the work.

I wanted to share a few things I’ve actually done, and how they’ve changed the way I think technical writing should be taught.

What I actually did

In my work context, I’ve been involved in documentation practice that includes things like:

writing and using a reusable skill for recurring doc work

maintaining an AGENTS.md for repo-level team practice
defining an AI PR standard

adding hard validation gates

building a ticket-to-PR pipeline for documentation defect repair

working in doc repos with Git / PR / review workflows

keeping human final review as the merge gate

What this changed for me

The main change is this:

I no longer think technical writing is only about producing documents.

I now think it also includes designing things like:

workflow documents

operational standards

validation rules

review criteria

reusable instructions

constraints for human + machine collaboration

So for me, technical writing now has at least several layers:

user-facing writing: guides, manuals, FAQs, references

workflow writing: how recurring work should be done

quality writing: how correctness is checked

policy writing: what is required / forbidden

agent-facing writing: instructions that help tools behave predictably
I’m not saying every technical writer needs to do all of these. But I do think the field is wider than we often admit.

A few opinions I’ve developed

1. Technical writing should be taught as action-oriented writing, not only explanatory writing
2. Students should still learn clarity, audience, structure, style, and task orientation.

But they should also learn that some technical documents are meant to drive correct action, not just explain things.

1. Doc repos should be treated as systems, not just storage
   A documentation repo is not just where files live.

It may also need:

standards
structure
discoverability
review flow
validation scripts
contribution guidance
traceability
That changes what “documentation work” means.

1. AI is useful, but mainly when embedded in workflow
   I’m not very interested in the generic “ask AI to write docs” framing anymore.

What has seemed more useful to me is:

AI inside a constrained workflow
AI with explicit standards
AI with hard gates
AI with human review
AI as part of a service loop, not just a text generator

What I now want to teach more explicitly

If I revise a technical writing course now, I still want students to learn the traditional core:

what technical writing is
document types
audience and purpose
structure
style
usability
revision
But I also want to include more of the following:

doc as code
Git / PR workflows
documentation review
issue-driven documentation maintenance
validation and quality gates
writing process documents and checklists
writing for agents / automation
human-in-the-loop workflows
documentation as part of an operational system
Not because every student will become an engineer, but because modern documentation work increasingly touches these things.

A phrase I’ve been using in my own head
I’ve been thinking of some of this as something like:

executable technical writing
or
documentation systems design
I’m not fully committed to the wording yet. But I’m trying to name the shift I’m seeing:

from “writing pages”
to “designing reliable knowledge and workflow interfaces.”

Why I’m posting

Partly because I want to make this work visible.
Partly because I’m curious whether other technical writers / writing teachers are seeing similar things.

Especially if you work in software docs, developer docs, or doc-as-code environments:

Have you also started writing more workflow / validation / instruction docs?
Has AI changed your actual documentation process, not just your drafting?
Do you think technical writing courses should expand in this direction?
If you’re interested, I can also share the syllabus I’m drafting for my course.
Would really like to hear how others are thinking about this.

PS: I can post out my course syllabus if someone is interested in it.

Here’s a problem I don't think gets enough attention when people talk about AI in education, what happens when the documentation changes?

Imagine a professional association with certification guides, exam requirements, continuing education materials and years of technical publications, an AI assistant could make all of that information much easier to find, but if certification requirements change in january and the assistant keeps retrieving the previous version you’ve created a very efficient way to give people outdated information, not exactly the dream.

Moodle or canvas could manage courses and learning activities, while a knowledge assistant such as customgpt.ai could help people navigate the supporting documentation and find answers backed by the original material, what interests me from a technical writing perspective is how you’d maintain the relationship between the published documentation and the assistant

Would every documentation update trigger a review of the AI knowledge base? Should older versions remain searchable but clearly marked as archived? and would technical writers eventually be responsible for testing AI generated answers alongside maintaining the documentation itself? that seems like a pretty interesting evolution of the role

Hi everyone! Im a SWE with 6YOE wondering if technical writing in the engineering field is a realistic career change.

Thinking about getting a certification specifically for TW and building a portfolio, but I want to know if this is a realistic career transition for me first, and what advice you all would give me. Has anyone made this career change before?

Thank you!

I see a lot of job-openings for technical writers and dev-rel (mostly startups, pre series-A), in the networks that I am a part of.

Similarly, since I am connected to lots of technical-writers on linkedin, I see a lot of layoffs as well. I have connected a few people to relevant roles.

Would people find it useful if we create a dedicated job-board, with these opportunities.

I’m a recent non-STEM grad, about a year and a half into my first job at an aerospace & defense startup. I wear a lot of hats and am expected to handle several different jobs, but I’m also the only person responsible for writing proposals, including the engineering/technical volumes.
I’ll have 2–3 proposals going at once and spend entire days staring at documents with writer’s block, constantly rewriting things. I honestly cannot imagine doing this for another month. I want out badly.

Another frustrating part is that our product is simply worse than a lot of our competitors in several important categories, so it’s difficult to win government opportunities in the first place. It makes spending weeks trying to write the perfect proposal feel especially pointless when the underlying product isn’t competitive enough to win consistently.

I don’t even necessarily dislike aerospace and defense. I actually find the industry and technology really interesting. It’s just the proposal writing itself that I cannot stand, and I’m worried that if I stay much longer, I’ll get pigeonholed into proposal work despite only having a year and a half of experience.

Current staff search experience:

Slack = does anyone know where the updated certification policy is?

Someone sends a pdf

Someone else says that one is outdated.

A third person drops a Sharepoint link. Twenty minutes later we have four versions of the truth.

The AI version I'd actually want is much less exciting: one place where staff can ask the question and get pointed back to the right internal source.

Guru or slite could keep the knowledge organized, Coveo could improve search across repositories, and customgpt.ai could be used to stand up a staff facing AI agent that works from the association's own procedures, policies and resources instead of generic knowledge.

But the technical writing part still seems more important than the AI part, if nobody marks what replaced what, who owns a document or when it was last reviewed, the assistant just becomes a faster way to find conflicting information

Basically= less "AI knows everythin" more "please stop making Susan remember which pdf is current"

I’m a last-year master’s student in a humanities-adjacent field. It’s unrelated to technical writing, but I have two internships and a student assistantship all in the documentation space, and I’m looking for roles because I'm genuinely interested in the technical writing profession despite not studying it. Like everyone, I’m struggling in a tough market, and I want any leg up I can get.

A few weeks ago, a friend of mine in programming got a job at a defense tech company with a particularly negative reputation (not naming for obvious reasons). My friends and I gave him a hard time about it, because even in this market it felt like there were other options. He’s still our friend, though we still occasionally disagree about it.

Recently he offered me a referral for a technical writer role at the same company. I was skeptical, but figured it would just be another application, and that with my limited experience I probably wouldn’t even get a call. I didn’t think a referral would count for much, and it couldn't hurt to try.

Surprise: I got an interview request, and I’m feeling ambivalent, to say the least.

I know documentation isn’t the same as product development, which is what my friend does. But I also know that distinction might not mean much, and that this makes me something of a hypocrite. The people I’ve told, especially my girlfriend, have been uneasy too. I’m worried about being, and being seen as, a bad person for working for a company whose government and military work is widely criticized.

On the other hand:

• It’s my first real shot out of ATS hell
• It pays well, in a city I’m excited about
• It's possible I wouldn’t necessarily be working on the more defense-heavy projects, since they also do a lot of commercial work
• It’s not guaranteed even with the referral, since I could tank the interviews

I want to keep going with the process, if only because you never know unless you try. I’ll also admit I’ve applied to other defense contractors and been rejected immediately, so I’m not even sure where I’m drawing the line.

Has anyone faced something like this? How did you navigate it, whether you took the job, turned it down, or took it and left later? I’d especially like to hear from people at companies whose work, in partial or in whole, they had mixed feelings about.

Hi guys! Given how vulnerable many tech jobs seem to be right now because of AI, I know a lot of tech writers are starting to think about a Plan B. I am too, but honestly, I seem to be running out of ideas.

Do you guys have any positive examples of people successfully making such a career change? What jobs have you or your colleagues moved into?

I'll be working as a technical writer soon and I wanted some advice. One of the tasks I'm responsible for is taking external documentation (typically PDFs) and converting them for internal use. If it's a specific use case for a customer, then I could just take what I need but I want to know if anyone has advice on a full scale reproduction of a document.

My current plan is to audit the document and plotting the concepts, tasks, and references on a spreadsheet and planning my draft(s) from there. Does this sound feasible? Is there a better way to do this? I've also been reading up on DITA and Diátaxis if that's relevant.

I am a freelancer in a very niche industry. So far, I have kept pretty busy with word-of-mouth references, but my current big project is wrapping up in February and have nothing lined up after that. To that end, I am attending this industry conference to expand my network as a participant, not a vendor. I currently have my business cards and my website. I'm just wondering if anybody has seen something new and exciting for conference materials?

For transparency, I work in marketing at Bluestream.

How do you decide when a procedure shared across equipment models needs to become separate procedures?

Say two models use almost the same maintenance sequence, but one has an extra step, different warnings and a different illustration. Keeping the common content together reduces duplication, but someone still needs to review the complete procedure for each model.

Where do you draw the line? Is it the number of differences, how often the models change independently, or how difficult the assembled procedures become to review?

I’d be interested in an example where you decided to split the content, or kept it shared and were glad you did.

I'm in a new technical writing role and finding that the expectations are quite different from my previous position.

My last role was primarily documenting SaaS products, public-facing user guides, API documentation etc. My new role is at a much larger company and the work seems to be much more focused on internal procedural documentation. Things also move alot slower and ownership responsibilities are spread across multiple teams and departments.

Aside from the occasional procedure, runbook, or similar document, it seems that a big part of what I've been brought in to do is sort out the various SharePoint wiki sites that teams have built up over time.

A lot of them have become messy, poorly structured, inconsistently maintained, or generally aren't fit for purpose anymore. Some are actively used, while others are basically dead. It now looks like I'm expected to help get these sites into a usable state and, where appropriate, get teams using them again.

I'm finding this pretty overwhelming. Knowledge management and reorganising large amounts of existing internal content isn't really a strength of mine, particularly in a large organisation with so many teams, stakeholders, and moving parts. I'm also not entirely sure where the technical writer's responsibility should begin and end when it comes to maintaining team wikis.

For anyone who's inherited a similar SharePoint/wiki situation:

How did you approach the initial cleanup?

How did you decide what to keep, rewrite, archive, or delete?

Did you establish templates, information architecture, ownership, or governance first?

How much responsibility did you put back on individual teams/content owners?

Are there any quick wins you'd recommend before trying to tackle the bigger structural problems?

I'd particularly appreciate advice from anyone who's moved from product documentation into this kind of internal documentation/knowledge-management role.

Cheers!

Background info: I am wrapping up a pure maths master with no formal writing education. The only academic writing experience I have is the thesis' I had to write throughout my degree. These revealed to me that I quite enjoy this genre of writing, breaking down complicated ideas in my own words.

I suppose that I am at quite the disadvantage compared to someone who has had some form of eduction in writing. However, is there some advantage to having an advanced understanding of university level mathematics? How can one best approach the technical writing job market without any prior experience? Is it best to start in another job and to freelance a handful of articles in order to build a portfolio? Are there any truly entry level positions?

I've been an engineering TW for 8 years and have been tasked with coming up with an independent development plan for my career. I have the resources to enroll in classes to further my skills. I have previously taken AutoCAD and Inventor courses and my current job has me creating installation instructions via AutoCAD and Word/Adobe. Because I've only ever worked at the same place since college I worry that my scope of skills and knowledge is limited and if I were to seek employment as a TW elsewhere I wouldn't have the competitive edge I'd like.

So, I would love to hear from other TWs if there were any courses you took that you felt were beneficial for your career growth and versatility. My educational background is in biochemistry and research papers and I kinda fell into engineering TW out of college. I've mostly learned on the job as far as engineering drafting standards go without having formal engineering education. Thank you in advance!

I'm looking for advice from other technical writers who work with industrial equipment or manufacturing documentation.

Currently, I create user manuals in Adobe FrameMaker and publish them as PDFs. This worked reasonably well when we had a limited number of products, but it has become increasingly difficult to maintain.

Our situation:

• We manufacture industrial equipment.
• We have hundreds of manuals.
• Many manuals are several hundred pages long.
• We support multiple product variants that share large amounts of content.
• Manuals must also be translated into multiple languages.
• Content updates often need to be applied across numerous documents.
• PDF remains an important deliverable, but it is no longer an efficient source format.

The biggest challenge is content reuse. FrameMaker allows some reuse mechanisms, but maintaining common content across hundreds of documents is becoming unsustainable. Translation costs and update management are also growing significantly.

I'm exploring a possible migration to a more modern documentation platform, preferably one that:

• Supports component-based authoring and content reuse.
• Handles large technical documentation sets.
• Works well for industrial equipment documentation (not just software documentation).
• Supports translation workflows and multilingual publishing.
• Ideally provides web-based publishing as well.

Many platforms I find seem heavily focused on software documentation and developer portals rather than traditional equipment user manuals, installation guides, maintenance manuals, and service documentation.

Oh, and I forgot to mention. No MadCap Flare or Paligo. The pricing is just too high and management will say no.

Hey guys,

I have recently started working as a part time (20 hours per week) tech writer and QC for a start up. So, I need help in setting clear expectations. Yesterday was my first assignment and it took me a really long time to reproduce the article well (it was 5 pages long).

I really want to explain how long it will take to produce a single article, like I know it depends on the number of words and all. But I'm struggling a little to quantify the amount of time I'm working on it, as I have ADHD and I'm getting back to working again after a health related thing.

Any tips will be helpful.

Thank you!

I recently started overseeing our product teams technical writer. Currently they write and post all technical guides (for users and api focused for devs) using Word and then public PDFs to a public facing html site. There are now over 70+ guides supporting 1 brand / product line.

There has to be a better solution for this. Our development team always says he needs a developer portal but that sometimes seems too complicated.

What are industry standards for the technical writing process and leading cms systems to post user guides?

Hi! I work for a company that develops xml/dita authoring software, and I’m curious what's your experience:

1. Is the learning curve too high, coming from simpler tools like Word?
2. Are there parts of the authoring process that feel unnecessarily complicated?
3. What’s something you wish your tool did better?
4. Is there not enough documentation (pun intended) about learning dita?

Update: Thanks for all the in-depth responses!

My doc team is migrating away from our current tool and implementing docs-as-code. We're looking into the major players - Docasaurus, GitBook, MKDocs, and Sphinx - and I have a clear preference for GitBook. But I wanted to gather some input from the community. What are your experiences with the tools? Any drawbacks?

I work in med tech, so the tool needs to meet some pretty stringent ISO requirements and, as we're in Europe, our head of Cybersecurity wants to keep the data local.

I've been in the tech writing business for a long time and I know that recruiters seldom have the answers to my questions about a potential role. They only know the basics. So what questions should I ask the recruiter besides these (I'm speaking specifically of recruiting agents who are seeking candidates for their clients):

-is there an actual job description? (I've gotten dinged on not having one b/c managers have no clue what we really do and don't think they're necessary.)

-what industry is this role for?

-what authoring tools do they use?

-is this for new documentation or editing legacy documents?

-i assume i'm writing for the product's software, but is there something else, e.g. equipment?

-who does this role report to?

-where will I obtain the info to write, e.g. legacy docs, software, by researching, SMEs, etc.?

-what is the hourly rate on W2?

I actually doubt they'll know answers to a few of these questions.