Is Technical Writing Stressful?

The thing that gets me is the gap between when a feature is "done" and when it's actually done for documentation purposes. Engineering has a definition of done that's mostly about functionality. Does it work? Does it pass the tests? If yes, it's done, it ships. For me, a feature isn't done until I've tested it end to end in the staging environment, understood every edge case, written the reference docs and the how-to guide, and had at least one engineer confirm that I haven't described anything incorrectly. That process takes time. Time that the release schedule does not account for.

Last quarter we shipped 14 features. I had adequate documentation time for maybe nine of them. The other five got docs that were, let's say, 70% of what they should be. Not wrong, but incomplete. And those five features have generated a disproportionate share of our support questions since they shipped, which isn't a coincidence. The stress isn't the deadline moment. It's the weeks afterward knowing that I shipped something I wasn't satisfied with and I'm watching the evidence that I was right to be unsatisfied.

My manager Petra, she's good about shielding the team from unrealistic requests when she can. But she's one person and she's not in every product meeting. By the time a release date gets locked, I usually find out through the project tracker, not through a conversation. And then I'm calculating backward from the date to figure out what's achievable. Four features due in eight days. That math doesn't close.

Legacy documentation. I have 6,000 pages of legacy documentation. Six thousand. Some of it was written in 2014 by a TW who left in 2016. Some of it was written by product managers who are no longer at the company. Some of it, I don't know who wrote it or when. It's just there, in the docs portal, and users are reading it and calling our support line because it's wrong.

The product I support is a corporate treasury management system. Our main users are corporate finance teams at mid-size companies, 500 to 5,000 employees. These are accountants and treasury analysts. They are not going to assume the documentation is outdated. They are going to follow the instructions, and when the instructions are wrong, they are going to assume they did something wrong. And then they're going to call support. And support is going to escalate to me. Last month I got seven escalations from support that traced back to documentation that was at least three major releases out of date.

I have a spreadsheet tracking the legacy debt. Color-coded. Red is actively harmful, yellow is outdated but not causing support tickets yet, green is current. Right now I have 847 pages in red. My director Quinton says to address the red pages before anything else, which I agree with in principle. In practice, that means every new feature I document pushes more legacy work out. The backlog has been growing since I arrived. I am one person and the red column is bigger now than when I started. That's the stress I take home. Not the deadlines. The sense that the hole I'm trying to dig out of is getting deeper.

The stress is always information access. That's my bottleneck for everything. I need to understand what a feature does before I can write about it, and understanding it requires access: to the engineers, to the staging environment, to someone who can walk me through the edge cases. Those are all scarce resources at a startup where everyone is already overloaded.

Our backend lead is a person named Rashid. He is excellent and he is always busy and he responds to my Slack messages in what I would describe as geological time. That's not a complaint about him personally. He has four engineers reporting to him, he's in customer calls sometimes, he's pulling context from six different systems to debug things. He doesn't have a lot of spare bandwidth. But I can't write accurate documentation for his features without him. And the release date doesn't move because Rashid was busy. So I end up sending the same message three times, at escalating levels of specificity, until I either get an answer or make my best educated guess from the code comments and staging environment behavior and hope I got it right.

I came from paralegal work. In that world, if you needed information from someone, you sent a request letter and there was a legal obligation to respond. Not here. Here you need a relationship and the grace of timing. I've gotten better at it. I know that Rashid is most responsive between 10 and 11 in the morning before the afternoon call stack builds up. I know that if I send him a specific question with a yes/no component, he'll answer faster than if I send an open-ended one. I've learned the communication patterns for every engineer on the team. That's not writing. That's organizational fieldwork. But it's the job.

The thing that stresses me at this point in my career is not volume or deadlines. It's accuracy at scale. I write developer documentation: API references, CLI guides, SDK tutorials. Our docs have about 4.2 million page views a month across all properties. When I write an API reference and I describe a parameter incorrectly, 4.2 million people might encounter that error. Not immediately. But over time, some percentage of them will hit the wrong behavior and have to figure out why.

Before I was a TW, I was a software developer for ten years. I know what it's like to be the person reading the documentation at 11 PM trying to figure out why an API call is returning a 422. If the documentation is wrong and it takes me two hours to figure that out, that's two hours of my time and considerable frustration. Multiply that by however many developers hit the same wall before someone files a feedback ticket, or before I catch it in a review cycle. The stress comes from caring about that and knowing I can't eliminate it entirely.

My review process is thorough. I have a colleague named Beatriz who was also a developer before she moved into TW. We review each other's API references before publication. She catches things I miss. I catch things she misses. It's added maybe 40% to the time it takes to ship documentation, and it's worth every minute. The thing that stresses me is the documentation that went out before we had this process. Some of it is still live. Some of it is wrong in subtle ways. I find it periodically and I feel the weight of it.

The regulatory version of this job has a specific stress that software TW doesn't have, which is: the documentation is a regulatory submission artifact. If my instructions for a cardiac monitoring device are wrong, and a clinician follows them incorrectly, and a patient is harmed, that is a documented failure mode that will end up in an FDA investigation. I'm not being dramatic. That is the actual liability structure of this work.

I was a regulatory affairs coordinator before I moved into TW. I came into this role understanding the regulatory framework. What surprised me was how much the writing itself feels different when you know what's at stake if it's wrong. I read every procedure I write at least three times. I test every instruction in the sequence I described, with the actual device, in conditions as close to real clinical use as I can simulate. I have a colleague, Bart, who does engineering review. I have a clinical specialist named Yolanda who does clinical review. Three sets of eyes before anything goes to regulatory. And I still find myself lying awake sometimes thinking about the one thing all three of us might have missed.

People ask me if I like the work. Yes, I like the work. The work is precise and consequential and when it's done well, it's genuinely important. The stress isn't incidental to why I do it. The weight is part of it. It's the difference between writing something that matters and writing something that could matter if someone remembers to read it.

My stress is different now than it was when I was a writer. As a manager, the stress is about defending the time. Every release cycle, I'm in some version of a negotiation about what documentation is achievable in the time available. Product managers want comprehensive docs. Engineering wants them fast. Sales wants them before the feature ships. My team wants realistic timelines so they can do good work. Those interests do not naturally align and I'm the one standing at the intersection.

I have four writers. Lucinda owns the core platform docs, which are the most complex. Reggie handles the data pipeline integrations. Priya covers the API reference. And Tobias, who joined six months ago from a background in science journalism, is still learning the product. Four writers, eighteen active feature tracks, release cycles every three weeks. The math requires prioritization that someone always disagrees with. When I decide that the data pipeline docs get the most TW time this cycle because a major customer is doing a migration, Lucinda's backlog grows, and she knows it, and I know it, and I have to live with that decision.

The stress I didn't expect when I became a manager was the distance from the work. I don't write as much now. I review, I plan, I advocate, I run the process. The craft that drew me to this in the first place, sitting with a complex system and figuring out how to explain it clearly, I don't do that as often. I miss it. The advocacy work matters and somebody has to do it. But I sometimes look at Lucinda's drafts and I'm aware that I'm envying her. She's the one who got to actually figure out how to explain the new query optimizer. I approved the timeline for her to do it.