October 27, 2006

Not an Engineer

I was re-reading the post about April's interview in the Statesman, and the last sentence stuck out at me:
...the fact that she is not a programmer or engineer serves her well as a tech writer.

This phrase is very true. I said the very same thing to a class of students at UTSA last fall, and I find myself thinking it at the career fairs I've been to recently. Many job applicants hear "technical writer," or sees what NI does, and think "I'm not a programmer" or "I'm not an engineer." To these students, I say, good.

We need more non-engineers and non-programmers looking at our products: testing them, writing about them, and polishing them via documentation or other means. We need creative people with non-technical backgrounds to push back on the developers and say "This isn't designed well" or "If I can't understand it, how will a customer?" After all, just because we're a tech company, that doesn't mean all our customers are technology oriented. Engineers and programmers are trained a certain way, which doesn't always include ease of use or user-friendliness. That's (part of) our job. So in these cases, being a non-techie is very beneficial.

So we don't need, or sometimes even want, you to be tech-savvy when applying for the open technical writer positions we have (hint, hint). When we're interviewing or looking at resumes, what we are looking for is that you are interested in technology or are curious or passionate about it. We don't need you to come in and start writing C++ immediately - that's for the programmers.

We do, however, expect you to come in and start writing English immediately :-)


  1. I've heard this line of reasoning many times, and to a certain extent I agree; but I've also seen technical writers with no technical background fail to grasp the model behind the software or technology they're trying to communicate. We're in the business of knowledge transfer and most of us are transferring technical information to a less technical audience. While it's essential to be able to approach the material from the perspective of our audience, we also need to be able to grasp material that our audience couldn't comprehend (not always because they don't have the time or inclination; sometimes because they don't have the technical expertise). In these cases a technical background is essential because no one's going to put the information into simpler terms for us -- that's what we were hired to do.

  2. Both are sides have a point. For new technical writers or writers wanting to break in to technical writing, I think what eventually tips the scales is whether you have enough interest in the subject matter to want to understand what's going on. I suppose I'm making the (big?) assumption that if you as a writer are excited about the technology or subject matter of which you currently know very little about, your genuine interest in the subject will go a long way to helping you understand the underlying model and communicate that information effectively.

    That said, should text books on brain surgery be written by brain surgeons or writers that think CSI is a really cool show?

    Sure, some businesses will need to hire writers with specific, technical backgrounds. On the other hand, other businesses will also benefit from writers who can take the point of view of a newbie, ask the right questions, and find those simpler terms. I think a lot of software businesses can fall into the latter category, especially if the tech writers are allowed to get involved with user interface and usability testing.

    Unfortunately, not all companies can afford a writing staff to fit all the needs. A lone tech writer would have to wear many hats, so having that technical background in place already might be essential for getting that kind of work and being successful at it.

  3. Jeff,

    I agree with you. It's a fine line to walk, for sure. On one hand we don't want a super-engineer who will not understand what the audience says. And on the other, we don't want someone who can't understand what it means to program in LabVIEW.

    However we have found there is not necessarily a connection between having technology experience (prior to interviewing here) and being a good technical writer. Many of our writers were relative technical neophytes when they interviewed. During the interview, they impressed the hiring managers by demonstrating interest in, appreciation of, and dedication to technical concepts.

    They were hired on the basis of these (and other) traits, and so far it's going well.

    For these people, and actually everyone here, we *give* them a technical background. We expect technical writers to be able to learn on the job about the products they document. Two year ago, I didn't know a bit about model-based control design, but now I can (and have) put together a fairly comprehensive overview of the subject.

    The trick, though, is identifying those who can and will learn NI's technology from those who cannot and/or will not. In these situations, a technical background helps us immensely in evaluating candidates. It's just not an absolute requirement.