40 years in the making

The IBM Kingston lab

40 years ago — on May 29, 1979 — I walked into the IBM programming lab in Kingston, New York, for my first day of work as a technical writer.

I’ve seen a lot in those 40 years. Some things about the profession have changed a lot; some haven’t changed at all.

Audience

The audience has always been the focal point for everything we do. 40 years ago, we paid lip service to that fact. Today we understood that we’re here to serve our readers, but we often struggle with how to do that. Soon it’ll be non-negotiable: If we don’t satisfy our readers, they’ll go elsewhere to get information, and they might even choose our competitors’ products over ours.

Tools

Since 1979, tech writing tools have evolved from literally nothing to the jangle of options we have today. (And the interval, from the first tool to the first job posting requiring that tool, was about 5 minutes.)

But eventually the basic principles behind text editors and graphics programs became well enough established that a writer could move easily from tool to tool.

Architecting value

A month ago, I got a new job title: Information Architect. I maintain my company’s content infrastructure, training and supporting a writing team that has, through mergers and acquisitions, tripled in size over the last 18 months. I also look to the future, defining strategic goals and figuring out how to achieve them.

In describing my new beat, I told the writing team that I have two priorities:

• Help the team do their jobs as effectively as possible — by listening to them, by training them in both tools and concepts, and by fixing problems
• Position our documentation products to provide value to the company and its customers

What does that look like in real life? Well, the first priority is pretty much what you’d expect. If I’m listening to the team, I know where they need training and guidance. And I try to be responsive when someone has a problem. (I also rely on a couple of colleagues who can also step in and troubleshoot when needed.)

The second priority, for me, is the crux of my job. But, paradoxically, it’s a lot harder to envision.

Into our reader’s world

You’ve parachuted onto a random stretch of road. You could be anywhere in the world. How quickly can you figure out where you are?

That’s the idea behind GeoGuessr, a web game that’s occupied some — ahem, too much — of my time lately. You might find yourself on a muddy road outside an Eastern European village, a lonely highway in West Texas, or a scenic drive on the Isle of Skye. (For that one, I guessed New Zealand — exactly halfway around the world. Zero points!)

Technical writers are used to this. We parachute into our reader’s world, and we do whatever we can to orient ourselves. We try to understand their work environment, their background, and anything else that helps us communicate with them.

A rocky coastline. A car driving on the right. Are you on Vancouver Island? Almost: you’re on the Olympic Peninsula, and that’s Vancouver Island in the distance. (Screen shot from GeoGuessr)

In GeoGuessr, you use whatever clues you can find. The game is based on Google Street view, so you can move back and forth, explore intersecting roads, and zoom in on your surroundings.

You’re looking for clues in topography, road signs (Do you recognize the language? Place names?), vegetation (Tropical? Subarctic?) — anything that would suggest or disqualify a particular location.

As technical writers, we look for clues to orient ourselves to the reader’s world.

Do we understand ourselves?

People don’t understand us. From the first time I met a technical writer, I’ve heard them — I’ve heard us — say that.

Our bosses don’t understand us. Subject-matter experts don’t understand us. Our audiences don’t understand us.

So, at long last, we have a chance to change that. A few days ago on Twitter, an app designer named Louie Mantia put this out to the world:

What‘s something that seems obvious within your profession, but the general public seems to misunderstand?

— Louie (@Mantia) July 1, 2018

As Louie’s tweet kept popping up in my timeline — with answers from journalists, lexicographers, and historians — I pondered how a technical writer might answer.

It was harder than I expected.

First take

First I thought of answering Louie’s question like this: Our top priority is writing directly to the people who use the instructions.

Then, in my imaginary dialog, I heard a resounding yawn from the general public: Of course you write for the people who use the instructions. For us. Who else would you write for?

Writing for the audience. While we technical writers trumpet it as a big deal, to our audience it’s so blindingly obvious that it goes without saying.

Second take

So I tried a different approach. Technical writers think in terms of how to use a product, not how the product works.

General public: We know that! It’s common sense, right? I don’t need to know how an internal-combustion engine works. I just want to change the oil.

Third take

Might the people understand us better than we think?

My third try: We work hard to tailor our information to our audience — in terms of both content and media.

GP: Hmm. The tailoring part, again, should go without saying. Maybe we don’t understand why you have to work so hard.

After all, when we get it right, it looks effortless. And when we get it wrong, it looks like we haven’t tried at all.

I began to realize that the skills we technical writers prize the most and discuss the most among ourselves, like audience analysis and media expertise, are things that — in the minds of our customers — ought to be second nature.

When we say that people don’t understand us, it’s not because they don’t grasp our skill set. It’s because they don’t realize how much energy we devote to honing those skills and to reminding each other how important they are.

Why do we need to remind each other of things that are so fundamental? Is it because our perspective is skewed from spending too much time with our work colleagues (especially Development) and not enough time with our customers?

Maybe it’s not that people understand us. Maybe we don’t understand ourselves.

Epilog

I finally did answer Louie’s question about what seems obvious to us but is misunderstood by the general public.

In the corporate hierarchy, technical writers see themselves as advocates for the people who use the product. #techcomm https://t.co/UK6rdysFdf

— Larry Kunz (@larry_kunz) July 3, 2018

What do you think of my answer? How would you have answered?

Do you think our customers would be surprised to learn how much time we spend talking about things that, to them, ought to be second nature?

 

 

 

 

 

 

 

You might’ve heard…

I’m taking a few days off. But please check out my guest post on Amruta Ranade’s blog, in which I describe a few things you might’ve heard about technical writing.

Thanks, Amruta, for giving me the opportunity to contribute to your blog!

Launching your technical communication career

Last time I wrote about the places you can go, or the different trajectories your career can take, when you work in technical communication.

But how do you get that first job? What qualifications do you need, and what are employers looking for?

Prompted by interview questions from a Tech Comm graduate student, and based on my experience working in the field and interviewing candidates, here are some thoughts.

We listened to different music in 1979, and breaking into the field was different too.

I got my first technical writing job a long time ago — in 1979. One thing I know for sure is that your breaking-in story won’t be the same as mine. Things were a lot different then, and I’m not just thinking about the music we listened to. Companies, having realized that technical people didn’t necessarily make good technical writers, went looking for young writers who weren’t necessarily versed in the technology but who could learn it.

Armed with a double-major in English and philosophy, and having a tiny bit of experience with computers, I landed that first job with IBM.

You won’t have the same experience. Your résumé will need to look a little shinier than mine did.

What are the educational requirements for working in Technical Communication?

Follow-up question: Are certain degrees or backgrounds more sought after by employers?