My career path is supposed to be impossible. I’m doing engineering work and technical writing for an aerospace company without an engineering degree or much strength in math or science. That’s not supposed to happen, but here I am. How does this happen?

The longer technical communicators stay with an organization or field, the more they become “subject matter experts,” if only through repeated contact and growing familiarity with the subject. That’s part of it. Another question one might ask, though, is what do I mean by engineering? Often the image one conjures up is someone sitting in front of a computer, developing CAD (computer-aided design) models, performing stress calculations, or doing hands-on work “bending metal.” Those are or can be aspects of engineering, but they are not the only ones. For instance, I wouldn’t trust me to develop a CAD model or handle machinery. I used to cut myself on a regular basis just working with box cutters as a stock clerk. I’ve flooded bathrooms and blacked out rooms. No, I am not the one you want touching the machinery. Fortunately, there are other aspects to engineering. One type of engineering in particular is a good fit for liberal arts majors–at least as a way to broaden one’s career choices–and that’s systems engineering.

Systems engineering, as I’m learning on the job, is all about understanding how complex machinery or software or processes fit together. And when you look at engineering through this perspective, it makes perfect sense for someone from the liberal arts to get into it. For starters, technical writers often get tasked to write content about multiple aspects of an engineering business, if only because a lot of engineers hate writing. So one week you might end up working on the production end of things, the next you might end up in software design, the next you could be supporting a program manager with a technical paper. Writing is often one of those underrated transferable skills that causes one to bounce around a company (or industry) a bit, learning useful content as one goes.

Tech writers–especially proposal writers–often have to tell stories to get their products sold. That means explaining how things fit together, what their meaning is, and communicating the meaning to uninvolved audiences. All of those skills can lead the writer unexpectedly into the role of an engineer or, barring that, a “subject matter expert,” a title I actually held prior to my role at Zero Point Frontiers.

Here’s another ugly little secret about systems engineers: a lot of their work involves simply making sure that Group A is sharing information with Groups B, C, and others. “Hey, they just changed the power in the space station from 28 volts to 120 volts. You might want to make sure all the avionics are compatible with that.” Or there’s the one that someone missed: “You guys are measuring descent speed in meters per second, right?” Incorrect assumptions can be corrected very easily just by asking what some might call an obvious or “stupid” question. If someone asks the stupid question and it saves $125 million, it’s not a stupid question.

There are other things engineers do that do not require mathematical skills but simple language, such as describing organizational, production, testing, operations, or risk management processes. And–here’s an advantage, English majors–the more clearly a process is described, the more likely it is someone else can repeat and use it later.

I won’t kid you: there are things in the engineering business might forever elude me and for which I must trust my properly schooled technical peers to understand, do, or explain for me. But my balderdash is getting better, which is to say: I actually speak Engineerish pretty well and don’t have to stop someone a dozen time to explain something while they explain it. Now it’s more like half a dozen. Or less. The trick is to maintain my ability to communicate clearly–not to “go native” and write like an engineer too much. I have products and services to market, after all. I am learning enough to consider supplementing my sporadic education with some sort of formal training in the systems engineering discipline, but my math could still use a little work. And my knowledge of tools. And many, many other things. But if you work as a technical communicator in a small-business engineering firm, the odds are good that eventually you will find yourself writing content that usually would be written by an engineer. It’s not a bad thing, just a sign that you’re learning to speak the language.