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:

https://twitter.com/Mantia/status/1013559718759956481

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.

https://twitter.com/larry_kunz/status/1014256240489390081

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?

 

 

 

 

 

 

 

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?

Finding your own community and security

Last week I described a bygone day of two-way loyalty between companies and their employees. While I doubt that day will ever return, I proposed a few ways in which managers can give their people a healthy, realistic sense of community and security.

Maybe you’re not a manager or a leader. You’re a rank-and-file worker, and you’re not in a position to try out any of those things I talked about.

Today we’ll look at it from your point of view. What can you, as a worker, do to increase your sense of community and security when there seems to be too little of both?

Here are a few ideas. Leave a comment and tell me what you think.

Do new things

Happy ending to the video: the switches are installed in a rack.

Last month I made my first live-action video (as opposed to screen shots). The video shows how to install network switches in a rack. It won’t win an Academy Award, but it’s taught me a lot about writing scripts, planning video and photo shoots, recording audio, and editing the whole package. I know those new skills will serve me well on other projects.

Try doing new things whenever you can. You’ll increase your value to your employer, and you’ll add new skills to your repertoire.

The idea is not to make yourself indispensable (as if you could). The idea is to make yourself flexible so that you’re ready to take on new roles or, if need be, to land a new job.

Don’t be a wallflower

I know. You’re introverted. So am I. You won’t see me in the middle of the action at the next company party. But I’ll be there, and I won’t be hiding behind the potted fern either. I hope you’ll be there too, because you can’t feel like you belong to a community if you don’t act like you belong to the community.

Wallflowers are pretty. But they don’t reflect — or inspire — loyalty.

When I mentioned loyalty, remember that I described it as two-way loyalty. You want to know that your company’s loyal to you, while you’re being loyal to your company.

Loyalty to the company doesn’t just mean following the rules, showing up on time, and always speaking well of Good Old Spacely Sprockets. It also means — it especially means — being loyal to the people who make up the company, the people who work alongside you, the people who might want to feel like they’re part of a community too.

So say hello to them. Chat with them at the water cooler. And for heaven’s sake, don’t pass up the company party.

Know yourself — and trust yourself

Maybe, even though things look the same, your workplace has changed. Your car’s in the same parking space. Your cubicle walls are the same shade of — what color is that? But you know things are different. There was such a great vibe when you hired on, but today — for whatever reason — all the joy is gone.

Maybe the management team changed. Maybe a merger or an acquisition upended the culture. Maybe the company’s slipping in the marketplace and everybody’s stressed out about it.

It’s normal to feel uneasy, even helpless, in the face of changes like these. Yet it’s vital to keep your balance. How? Make sure your center of gravity is secure. Take stock of yourself. Remember what’s really important to you. Decide what you are, and are not, willing to do.

I once joined a company I admired for the high quality of its work and for its generosity of spirit. Over time, through a series of setbacks and managerial changes, I saw those good attributes fade away.

Eventually I saw that I was part of a company that cut corners and tried to squeeze as much money as it could from customers and employees.

How long would it be before I was called on to do something that went against my values? Before I was asked to betray a client’s trust by passing off poor-quality work? I had to decide what mattered to me: which lines I could cross and which ones I couldn’t, even if it meant losing my job.

Fortunately, I never had to make such a drastic choice. But by drawing those lines, by determining that I wouldn’t cross them, I empowered myself. I gained a bit of control over my situation — and with it, a sense of security. I knew that, even if things around me went sideways, I could stand firm and hold onto my integrity.

I also kept my resume up to date and constantly checked job postings, which gave me an additional sense of control — hence, again, a sense of security. I kept in close touch with my professional network, so that they became my community. Eventually it paid off: I found a new job in a much better situation.

This work — this taking stock and drawing boundary lines — is something you have to do for yourself. You can’t delegate it. You can’t get it from reading a book or a blog post. It’s uniquely yours. Don’t neglect it, even if right now you’re happy with your situation.

Things change. Make sure you’re ready.

Back to school part 2: enhancing my technical communication skills

Joe Welinske’s talk, Key Trends in Software User Assistance, has inspired me to learn new skills, or burnish my existing skills, so that i can continue to succeed as a technical communicator.

In my last article I described 3 of those skills: search-engine optimization (SEO), video production, and storytelling.

Here are the rest.

User communities

Our readers no longer live in isolation For help and guidance they look not to the official company-produced materials (like manuals and context-sensitive help) but to each other.

Smart companies, like the one I work for, host user forums and post knowledge bases on their websites. Customers can ask questions and get answers from each other and from experts on the company’s technical staff.

In many cases, online communities exist independently as well — on sites that aren’t affiliated with a product’s manufacturer. Those sites might have a lower signal-to-noise ratio, but they’re still popular. In some cases they’re preferred because, many believe, you’re more likely to find the unvarnished truth there.

I would be arrogant and a blockhead if I, as a technical communicator, chose to ignore these sources and insisted that my readers rely only on the official documentation.

I need to learn where my readers are seeking information about my products, and then I need to come alongside them — for example, by answering a question on a user forum and providing a link to the appropriate section of the documentation.

I also need to learn how people are interacting with my company on social media and be ready to step in when someone is looking for something I can provide. And when I step in, it should go without saying that the phrase RTFM is strictly verboten.

Designing and writing for the small screen

Joe noted that the most popular documentation format is still PDF, with web- and browser-based content cutting into its lead. However, the adoption of tablet- and smartphone-based formats like eBook remains flat. I think it’s because most technical documentation simply doesn’t lend itself to being read on a small screen.

It isn’t that people don’t want to read our content on a smartphone. It’s that we haven’t made it feasible. Yet.

We’re starting to see tools that can break up large technical documents into topics and push them to a tablet or smartphone in such a way that they can be updated automatically and the reader can make bookmarks and other notations.

So the technology is coming. Now we need the skills to create content for the small screen. Break large oceans of text into something more succinct. Find a better way to present content that exists today in large tables or complicated graphics.

How will we do that? I think we’ll have to pick and choose: figure out what content lends itself to a small-screen presentation and concentrate on that. Then provide download links to everything else. We’ll also need to evolve a skill we should already have developed: telling our story as succinctly as possible.

There’ll surely be demand for small-screen content. We have to figure out how to meet the demand.

UI strings and embedded assistance

The most direct way a technical communicator can show people how to use a product is to design the product’s user interface — or at least write the text strings in the UI. In the software world, more and more of us are getting to do just that.

When an input field is labeled in a way that makes sense for the audience, with a well-written help tutorial, the software becomes much easier to use and much less in need of detailed instructions.

Joe noted that in this area, technical communicators might have to fight to earn our place at the table. After all, there are already software developers and UI designers who consider this to be their jobs.

But some technical communicators have already gotten the chance to create UI strings and embedded assistance, and they’re making the most of it. As we — the technical communication community — develop a track record of success, with specific examples of how our work improved a product and made money for the company, we’ll get even more opportunities.

When those opportunities come, we need to be ready to seize them.

 

User communities. Designing and writing for the small screen. UI strings and embedded assistance. Have you been honing your skills in these areas? What other skills are you looking to update? What tips can you share with others?

Back to school: enhancing my technical communication skills

Here where I live it’s back-to-school time: a reminder that no matter how long I’ve worked in technical communication, there are always new things to learn.

The skills I’ve already mastered, while still valuable, won’t be enough for me to succeed in a world of new technologies and new ways of consuming information.

What will I be looking to learn this year? The following list is inspired by Joe Welinske’s talk, Key Trends in Software User Assistance, which
he gave last week to the STC Carolina chapter.

Search-engine optimization (SEO)

Joe’s succinct advice, to everyone in the room, was “Learn this.”

No matter what kind of technical content you create, it’s going online. Even the lowly (but still popular) PDF. And your readers will find it using a search engine.

So you need to understand how the right words and phrases, both in text and metadata, make your content bubble to the top of the search results. The best advice: don’t try to game the search engines. Make sure your content is relevant, and use terminology appropriately.

Technology for the gray at heart

My hair has long since gone from graying to gray. So I was happy to read Andy Patrizio’s article in CIO magazine debunking the myth that older workers struggle more with technology than their millennial counterparts.

I’m an old hand but I know how to use the technology.

Citing research by cloud storage provider Dropbox and a marketing firm called Ipsos Mori, Patrizio finds that older people are just as likely to use a variety of technologies in their work — and are less likely to be stressed out using them.

For Patrizio, the findings reflect people’s level of frustration with their workplace technologies. And younger workers actually feel more frustrated because, being accustomed to really good technology in their personal lives, the have higher expectations when they come to the workplace.

Maybe that’s true. Another reason, I think, is that older workers tend to take a pragmatic view of technology. For us, technology is a means to an end. We evaluate it simply on how well it helps us get our work done. Not on how elegantly designed and shiny it is.

I applaud Patrizio’s assertion that older workers are just as effective using technology at work as their younger counterparts.

But I’m taken aback by the last thing he says. Quoting Rick Devine of TalentSky, a job-search website, Patrizio writes:

…the burden of keeping people’s technology skills up to date falls on the employer. “Employers need to see where your deficiencies are so they can provide for you. It is the moral obligation of every employer to see the deficiencies of their workforce, so if these older professionals are falling away in skills, shame on their employer for not providing them with the work experience to be employable,” [Devine] says. “And that’s a failing of the system and we all need to come together to right that wrong.”

Is it really up to my employer to make sure my skills stay current? Sorry: I might’ve believed that in 1986 — and then only because I worked for IBM, where the “you have a job for life” culture was still in place. But I’ve known for decades that no one but me cares about keeping my skills current. I’ve counseled countless colleagues and students to take charge of their own skills development. It’s why I encourage people to attend conferences, to get training, and to read up on what’s happening in the profession.

If the onus is on employers to keep their people’s skills up to date, many employers will use that as just one more reason to push out older workers and replace them with younger ones fresh out of college or grad school.

I appreciate it when my employer gives me work that hones my skills. I appreciate it when they train me in new technologies that I’ll need on the job. But I, and I think they, understand that I’m ultimately responsible for maintaining a skill level that makes me valuable to them and to potential future employers.

What do you think? Have you found older workers to be just as skilled as younger workers in using technology at work? Do you agree with Patrizio that employers are responsible for keeping their people’s skills up to date? Why or why not?