Hi folks -

I upgraded my Adobe products and now my shared review workflow is irrevocably broken.

In my previous workflow, I did the following:

1. Save my FrameMaker book content as a PDF.
2. Open PDF in Acrobat.
3. Attach custom Adobe form (built in-house by my predecessor). The form just tells what the document is, the revision number, and provides a place for reviewers to "stamp" their approval.
4. Click All Tools > Send for Comments > Send For Shared Comments.
5. Reviewers receive an email notification and open the link to the shared review.
6. Reviewers make comments and add a Reviewed or Approval stamp to the form.

Through much back-and-forth with IT and Adobe, it looks like my previous method of shared reviews is no longer supported.

Using the latest Adobe Acrobat, I tried this new workflow:

1. Save my FrameMaker book content as a PDF.
2. Open PDF in Adobe Acrobat.
3. Attach custom Adobe form.
4. Click Share, type email addresses of reviewers, and click Invite.
5. Reviewers click the attachment in their email message to open the document in a web browser.
6. Reviewers add/post a comment.

The only thing caveat is that reviewers can no longer use a Reviewed or Approval stamp. I'm not married to having a stamp, but I do need a way for my reviewers to indicate Reviewed or Approved. Using e-signatures is not a direct substitution, and it looks like it would add a lot of unnecessary steps to my workflow.

Has anyone had a similar experience with Adobe Shared Reviews? If so, have you found any viable workarounds?

Please note: Adobe Acrobat is the preferred in-house tool; I just have to find a way for it to work without over-complicating the process for my reviewers.

Any feedback would be greatly appreciated. Also, I am more than willing to hop on Zoom to talk through options!

Thanks!

I am presently developing a bunch of extend scripts for FrameMaker. Mostly because it is fun but also because it helps me fix some the stuff that I find most annoying.
I have not met many people who have taken scripts into their workflow, though. Do you, or do you know anybody who does? And if... what problems do they solve?

Want to know if the Force is strong with your documentation? Of course you do.

In my talk, Delightful Documentation? Improving Documentation Quality with the Kano Model, you'll get a reader-validated framework, straight from two studies on what quality really means to the people reading your docs — no Jedi mind tricks required.

Register for #LavaCon using the referral code #LI26 for $400 off in-person tuition! https://lavacon.org

I've been thinking about something interesting: understanding a technical subject and explaining it clearly are two very different skills.

Someone can understand how an engine works, how a machine is designed, or how a new technology solves a problem, yet struggle to explain it to someone without the same background.

I think the real challenge is not simply simplifying the language. It's understanding which details matter, how the pieces connect, and what the reader needs to understand first.

This is especially important in engineering, product development, inventions, and technology businesses. A great idea can be difficult to appreciate when its purpose and value aren't communicated clearly.

I'm interested in the intersection of engineering, research, and technical communication, and I'd like to learn from people who work in these areas.

For the engineers, technical writers, founders, and researchers here: what's the hardest thing you've ever had to explain to someone who wasn't familiar with your field? And what helped you explain it better?

Hi everyone!
I know this might sound a little crazy, but I really want to work at Google someday, and I'm trying to figure out how to make that happen.
My goal is to join Google's end-user documentation team first and gradually build my skills in API documentation and developer documentation.
I'm hoping to get some genuine guidance from people who work at Google, have experience with their hiring process, or have successfully transitioned into developer documentation.

A little about me:

- 6 years of overall professional experience.

- 4 years of experience in semiconductor documentation, working on both hardware and software products.

- 2 years of experience as a prompt engineer.

I'm willing to put in the work, learn new skills, build a portfolio, and prepare seriously for interviews. However, I'm not entirely sure where to focus my efforts or how to get my foot in the door.

I'd really appreciate advice on a few things:

1. What skills and qualifications does Google look for when hiring Technical Writers?

2. How can I improve my chances of getting shortlisted? Should I focus on tailoring my resume, building a portfolio, networking, or getting referrals?

3. Given my background, should I target end-user documentation roles first, or could I apply directly for developer documentation roles?

4. What should I learn to become a strong candidate for API and developer documentation? REST APIs, OpenAPI, Git, Markdown, docs-as-code, or something else?

5. If you've interviewed for or worked in a Technical Writer role at Google, what should I expect from the interview process?

6. Are there any specific Google teams, job titles, or resources I should keep an eye on?

If someone from Google's technical writing team happens to see this, I'd genuinely appreciate any guidance you can offer. Even a few pointers on what to learn, what to showcase in my portfolio, or what hiring managers look for would mean a lot to me.
I'm not expecting anyone to hand me an opportunity. I just want to understand the path I need to take and work towards it in a focused way.
I know it's an ambitious goal, but I'd rather start working towards it than keep wondering if I could have made it happen.
Thanks for reading! ❤️

This is likely just me, but I went to Stripe to check out their Stablecoin stuff today, and was pretty shocked at how cluttered/busy the page is. There's just so much stuff here vying for my attention.

Obviously, the content I want is in the middle, but there's just so much blue everywhere that it took me a few seconds to realise what I actually needed to read.

I remember about 10 15 years ago Stripe docs were hailed as the best-in-class docs site. And I agreed! Is was super easy to find the exact info you were looking for. And I guess the info I need is there. It's just that there's a lot going on from a web-dev standpoint.

I dunno. Thoughts? Am I over analysing this, and that this is just what docs sites are like now?

I’m looking for a way to keep our specs as Markdown files in Git, but make them easy to read for people who don’t want to deal with Git itself.
Zensical caught my attention, and I’m curious if anyone here has actually used it for something like this.
A few things I’d love to hear about:
- How has it worked out for you? Did you have to build or tweak anything to make it work for your needs?
- How do you organize your specs? By business domain, system, project, or something else?
- How do you handle feedback from business users? Can they easily comment on a spec or suggest changes, or did you have to come up with your own solution?
- Do your business users have access to the Git repo, or do they just use the published site?
The idea is to keep Git as the source of truth while giving everyone else a simple way to browse the specs and provide feedback.
Would love to hear about your real-world experience, including any downsides or things you wish you’d done differently.

Screenshots go out of date, but video tutorials are worse. One UI change and the whole video is wrong, and re-recording with a voiceover takes hours.

DemoForge generates the video from a script. The clicks and narration live in a file, so after a UI change you run it again and get a fresh video with the same zooms and voiceover.

Free and open source (MIT): https://github.com/DixitRam/Demo-Forge

Would love to hear if this fits how docs teams work.

When you've applied to a company and you're looking over their website, do you ever point out any errors on their website typo or otherwise? Do you think it makes any difference to do this if you have an interview with them?

Hi everyone, on Tuesday I am interviewing for a technical writer role at a biotech company. I currently work as a scientist for a CDMO and I am really excited about this role and the direction it could take my career in!

I have already had introductory calls with some of the team and performed a writing task that they seemed to have liked, so this would be a final stage interview.

Does anyone have any advice for questions I should prepare for or general interview advice for this type of role?

Something we keep running into: AI makes drafting faster, but if you ask it to write the same instruction for several topics, the wording drifts a little each time. Individually each version is fine. Across a help center, readers end up with several versions of one instruction, and every product change means hunting down each copy.

Curious how others deal with this:
– Do you still rely on snippets/variables/conrefs, or do you fix wording in review?
– Has anyone tried having AI find duplicated text and convert it into reusable fragments?

Disclosure:

I work with ClickHelp, and we’re doing a webinar on exactly this on Oct 15, 18:00 CEST / 12:00 PM EDT.

I’m more interested in hearing how other teams approach it, though.

Hi everyone,

I’m looking for opportunities related to PTC Arbortext Editor development and Windchill CMS. I have experience working with technical documentation systems and automation, and I’m interested in connecting with people working in this area.

My areas of interest include:

• Windchill integration and data automation
• Arbortext Editor automation and customization
• XML document processing
• Structured content automation
• Technical document publishing

I’m open to freelance projects, contract work, and suitable job opportunities.

If anyone knows of relevant openings or projects, or can suggest where I should look, I would really appreciate your guidance.

Thanks!

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
• eview flow
• validation scripts
• ontribution 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.

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.

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.

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’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'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!

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.