Career Change to Technical Writer at 40

Why did you leave teaching?

The writing was staying. The students were leaving. I don't mean they dropped out. I mean that in year 14, I was teaching the same rhetorical frameworks I'd always taught, the same essay structures, the same argument analysis skills. And the students were great. Some of them were exceptional. But at some point I noticed that the part I looked forward to was not the classroom day. It was the planning. Designing the unit, sequencing the information, figuring out how to explain a concept I'd explained 40 times before in a way that worked for a person who'd never encountered it. I was doing instructional design for its own sake. The classroom was just where I delivered it.

Technical writing showed up because my brother-in-law Ned, he works in software sales and he mentioned that his company had been looking for a technical writer for six months and couldn't find one. I asked what the job was. He described it as "writing documentation so people can use software." I asked if anyone was hiring people without a software background. He looked it up on his phone and said "it seems like some companies care more about writing than technical background." I spent the next three weeks reading everything I could find about the field. I found the Write the Docs community. I read job descriptions. I identified that my writing skill was real and my technical knowledge was essentially zero and figured out that the zero was fixable if I put in the time.

How did you get your first job with no portfolio?

I spent about four months building one. I found five open source projects on GitHub that had poor or missing documentation. I picked one that I could actually learn well enough to document: a tool for managing e-commerce product catalog data. Python-based. I had never written a line of code. I spent three weeks learning what the tool did by reading the README, the GitHub issues, and installing it and trying to use it from a complete beginner's starting point. That beginner perspective was useful, it turned out. I wrote from genuine confusion. The existing documentation assumed knowledge I didn't have, so my guide for new users was actually better than what they had because I'd been the new user.

I wrote three portfolio pieces in total. That open source guide. A fake API reference for a fictional SaaS product, following a real API reference I found and studying its structure. And a set of release notes for a software update I invented, formatted correctly, with appropriate change categories. None of it was for a real company. All of it showed that I understood the formats and could produce something a technical person would trust. I applied to about 30 jobs. Got three interviews. Got one offer. The hiring manager at this company told me afterward that my open source guide was the thing that made her believe I could do the work. She said most candidates have samples from their current job. Mine showed I'd gone out and learned something new specifically for the application. That mattered more than the samples themselves.

What did 14 years of teaching transfer directly?

The sequencing. That's the big one. Teaching requires you to think about the order in which information is introduced and why. You cannot introduce subordinate clauses before you've introduced clauses. You cannot teach argument analysis before you've taught the structure of an argument. I had 14 years of practice figuring out the right order for a learner who doesn't know what I know, and that skill transfers directly into documentation writing. Every onboarding guide I write is a lesson plan. Step 1 has to be achievable without having done any other step. Step 2 has to build on step 1. If step 6 assumes something I didn't establish in steps 1 through 5, I've made the same mistake I would have made putting complex syntax before simple syntax in an AP unit. I see this mistake in other writers' docs all the time. It's invisible if you've never had to sequence instruction for a learner.

The other thing teaching gave me is patience for the confused reader. When a student doesn't understand something I've explained, my first instinct is not "the student isn't paying attention." My first instinct is "there's a gap in my explanation." That instinct is exactly right for documentation. When a user files a support ticket saying they couldn't follow the setup guide, that's not a failing user. That's a gap in my setup guide. Teaching built in that assumption so deeply that I don't even have to think about it. Some TW colleagues I've talked to, they got defensive about documentation failures, as if the user should have read more carefully. That never occurred to me. If they couldn't follow it, I didn't write it clearly enough.

What did you have to unlearn?

That more is better. In AP English, a student who wrote 800 words when the prompt asked for 500 was demonstrating depth. In documentation, 800 words when 300 would do is failing the reader. Users are not reading docs for pleasure. They're reading docs to accomplish a specific task. The moment the guide says something they already know, or something that isn't necessary to complete the task, they disengage. They start skimming. They miss the one step that's actually critical.

My first drafts at this job were too long. My manager Renata kept marking sections with "do the users actually need this?" And the honest answer was no. I was including context because I was used to building context before making a point. An essay writer builds toward the argument. A documentation writer states the instruction and gets out of the way. That required real rewiring. I got there, but it took about eight months before I stopped automatically explaining why something worked before I explained how to do it. The why is for background reading. The how-to guide is for someone at 10 AM who needs to do the thing and move on.

What was the financial reality?

I was at $72,000 in year 14 of teaching. My first TW job paid $67,000. That was a $5,000 pay cut to start over at the bottom of a new field at 41. I had tenure in teaching. I had no tenure in this job. I had a pension building at Omaha Public Schools that I stopped contributing to when I left. The pension would have been meaningfully larger if I'd stayed. My husband Garrett runs a small HVAC business. We have two kids. The math required some adjustment. We took a family trip less that first year. We delayed a bathroom remodel. These are not tragedies. They're real tradeoffs.

After two years in TW, I'm at $78,000. Better than my teaching salary. Not dramatically better, but I have a clear path to $95,000 if I add API documentation to my skill set and move into a more technical role, which I'm working on. The financial trajectory is better in TW than it would have been in teaching if I stayed. Nebraska teacher pay is essentially flat above a certain experience level. The ceiling is lower and closer. In TW, especially in software, the ceiling is higher and farther. Whether I'll reach it is not guaranteed. But it's there. That matters when you're deciding whether to start over.

What do you wish someone had told you before the switch?

That the technical learning curve is faster than you think. I spent a lot of time pre-switch being anxious about the technical side. Do I need to learn to code? Do I need a computer science degree? Do I need to understand databases and APIs before I apply? The answer to all of those is some version of "less than you think, and you can learn on the job faster than you're expecting." The ability to learn a new system quickly is the core skill. If you have that, you can pick up the technical details as you encounter them. I was honest in my interviews that I had no software background and I was actively learning. That honesty got me a job at a company willing to invest in my ramp time. You don't have to come in knowing everything. You have to come in being the kind of person who learns fast and asks good questions.

Why did you leave engineering?

A few things converged. The main one was that I'd been writing most of the technical documentation for our team since about 2014. Not officially. Informally. Our department had two systems engineers who were responsible for procedure documentation, and they were both fine engineers and neither of them wrote well. Their procedures worked in the sense that you could follow them. They weren't clear. Someone doing a procedure for the first time might miss an implied step or fail to recognize a critical verification point because the way it was written, it looked the same as a routine step.

I started rewriting them. Not because anyone asked me to. Because I was the test lead on procedures that relied on them and I was tired of briefing the technicians on the three things the doc didn't say clearly enough. My manager Conrad noticed and asked if I wanted to formally take over procedure documentation as a 20% project. I did. I was better at it than I was at the structural stress analysis I'd been doing for most of my career, which is saying something because I was good at that too. But I was good at the stress analysis because I'd gotten good at it. The documentation felt natural in a way the engineering never quite did. After about two years of doing the 20% project, I went looking for TW roles.

You went from aerospace to medical devices. That's a specific choice.

Regulated industries. My 16 years in aerospace were spent working under FAA requirements and MIL-SPEC documentation standards. The documentation at that level is formal, structured, version-controlled, and consequential. When I looked at TW roles, I was not attracted to startup jobs where the documentation process was whatever someone had time to invent. I wanted a place where the documentation had rigor behind it. Medical device documentation under FDA regulations is that place.

My colleague Svetlana came from marketing communications at a consumer products company. She's excellent at the user-facing documentation: patient guides, quick-start materials. She thinks about accessibility and plain language in ways I respect. For the regulatory submission documents, the 510(k) device descriptions, the instructions for use that are part of the cleared device, she defers to me because I understand the evidentiary structure. A regulatory submission document isn't just a document. It's a claim with supporting evidence that must meet a specific standard of completeness and accuracy. That's what a structural analysis report is. Same logic, different domain. The FDA reviewer is doing the same thing my stress analysis reviewers did. They're deciding whether the documentation proves what it claims. I know how to write to be reviewed by that kind of reader.

What transferred from engineering that you didn't expect to matter?

The tolerance for precision without payoff. Engineering involves a lot of work that doesn't produce anything visible. You calculate the stress on a bracket and the bracket works fine and nobody knows you calculated it. The work is invisible because the work succeeding means nothing happens. Documentation is the same. Good documentation means users do things correctly and nothing bad occurs. No one files a support ticket. No one calls. Nobody sees the documentation working because when it works, it's invisible. Engineers are used to this. A lot of writers who come from communications backgrounds struggle with it. They want the documentation to be read and appreciated. I just want nothing to go wrong. After 16 years of hoping that my structural calculations meant a satellite component would survive launch, I'm comfortable with success being a non-event.

The risk mindset also transferred. When I read a procedure, I automatically look for the step that, if performed wrong, has irreversible consequences. I find it immediately. In aerospace those are often called "irreversible actions." Install the fastener before you've verified the component is correctly positioned: you've got a problem. In medical device documentation, the analogous steps are things like: applying the monitoring electrodes in the wrong position before confirming lead placement. Documenting them clearly, with explicit warnings, is the minimum. Engineering trained me to see them at a glance. I was surprised that not every TW has that instinct. It turns out it's not universal. It's learned from working in fields where getting it wrong has consequences you can measure.

What did you have to unlearn?

Completeness as a virtue. In engineering documentation, you include everything. Full specifications. All the boundary conditions. Every assumption. The reader is another engineer. They want the data. They can handle density. User-facing documentation is the opposite. A patient using a home cardiac monitor is not reading to get all the information. They're reading to do one specific thing correctly. Everything in the document that isn't about that one thing is friction. I had to train myself to cut. Not to summarize, but to cut. If the information isn't needed to perform the task safely, it is not in the document. That sentence describes a skill I built over four years that I didn't have on day one. On day one, I was writing user guides that read like technical specs. My manager at the time, a person named Celeste, marked them up with the note "who is reading this and what do they need to know right now?" She asked that question on every paragraph. I now ask it myself before I write each one.

The other thing I had to unlearn was assuming the reader's technical literacy. Sixteen years of writing for engineers built in a baseline assumption: this person knows what I mean by the technical terms. Medical device user documentation is sometimes for clinicians, sometimes for patients, and sometimes for home caregivers. The patient audience might have no technical background at all. "Electrode impedance" is a phrase I would not use in an engineering specification without definition. In a patient guide, I don't use it at all. I say "make sure the sensor is making good contact with your skin." Same concept. Different translation. Teaching myself to find that translation every time took longer than I expected. It's not that I didn't know how. I'd just never had to do it for sixteen years.

What was the financial reality of the switch?

I was at $118,000 in my final year of aerospace engineering. Senior engineer, fifteen years of experience, strong performance record. My first TW role at a different medical device company paid $78,000. That's a $40,000 pay cut. I knew going in it would be a cut. I did not quite anticipate $40,000. The initial offers were in the $68,000 to $75,000 range. I leveraged my engineering background and the regulatory documentation experience to negotiate to $78,000, and I took it.

I'm at $97,000 now, four years in. Senior TW title. My engineering background is visible in my work in a way that's recognized, especially on the regulatory side. The ceiling from here at this company is around $115,000 for a principal writer, which is still below what I was making as an engineer. If I stay in regulated industries and specialize further, I think I can get to $120,000 to $125,000 within five years. That's a ten-year path from $118,000 to $125,000. Not a financial upgrade. My wife Dorinda did the math and asked why I did it. I said because I was better at the writing than the engineering, I was more interested in it, and I didn't want to spend the next twenty years doing work I was competent at rather than work I cared about. She said "OK, but you could have told me that before I bought a new car in 2021." She's not wrong. I should have had the career conversation before the car conversation.

What do you wish someone had told you before the switch?

That your prior expertise is worth more than entry-level. I undersold myself in the job search. I applied for mid-level TW roles and took a mid-level TW salary. With my engineering background and my domain knowledge, I was worth more from day one. Not what I'd been earning as a senior engineer. But closer to it. I should have applied for senior roles with a pitch that went: "I have no TW title history, but I have 16 years of producing the kind of documentation you're trying to hire for, in an industry that required it to be correct." I found that pitch only after I'd already accepted the job. The company I now work for, if I'd applied there first with that pitch instead of a junior TW frame, I might have started at $85,000 to $90,000. The gap closed over four years. It would have been faster if I'd come in correctly positioned from the start. Know what you're actually worth before you let someone else price you.