Category Archives: Technical communication

Our “Life in Docs”: building and sustaining a community

Logo for the Life in Docs survey

Image source: David Ryan

David Ryan, cofounder of a company called Corilla, has garnered responses from 333 technical communicators for a “Life in Docs 2018” survey. The respondents answered questions about how we do our work and what we like and dislike about it.

Ryan posted the results in two articles on Medium: first the data, then his interpretations of the data (or insights, to use his term).

I’d include a link to Corilla’s website, but at this writing the site is down.

Overall, the results don’t surprise. We technical writers are happy at our work, we use a variety of tools and processes, and we want to collaborate more effectively.

Today I want to zero in on a section in Ryan’s “insights” post, titled Communities of practice are the cultural engine room.

The survey didn’t have questions about associations or affiliations, so I don’t know how Ryan arrived at this “insight.” Perhaps he tripped over his own bias toward looser-knit, informal communities and against established societies.

That said, it’s a point worth discussing. Continue reading

Advertisements

When you have something shocking to say

The news reports buckled my knees. According to a Pennsylvania grand jury, hundreds of Roman Catholic priests across the state sexually abused more than 1,000 children over a 70-year period.

handwritten letter about a case of child abuse

Image source: Josh Bernoff

The details are shocking and sickening. It’s hard to imagine the scope of the damage done.

Imagine having to write about that story. How do you do it? How do you keep from veering into lurid sensationalism on the one hand and cold, dispassionate, recitation on the other?

The anonymous person who wrote the grand jury’s report handled it brilliantly.

In his excellent analysis, Josh Bernoff calls the report “an amazing document, a model for clarity of description in an emotionally charged environment.”

Josh mixes excerpts from the report with his comments. Here, I’ve boldfaced some of Josh’s comments and added mine in response.

I hope you’ll add your comments as well. Continue reading

Stand up and be counted: the technical communication census

It’s not just another survey. If you’re engaged in technical communication — as practitioner, teacher, or student — I encourage you to take part.

census taker in front of house

Take part in the census. And don’t worry: no salesman will call.

A team at Concordia University in Montreal, led by Dr. Saul Carliner, is conducting research called the census of technical communicators. It’s in survey format, but unlike most surveys targeted to technical communicators, this one isn’t about tools or technology. Instead, the research is about you: your background, your job satisfaction, your aspirations, and how you stay current in the profession.

I’m delighted that Concordia is conducting this census. Most data-driven research about our profession centers on the tools we use and the technologies we support. Some of it is geared to providing tools vendors with data so they can better market their products.

There’s nothing wrong with any of that. But it’s refreshing to see research that’s about us: who we are, and how we perceive our work. Having completed the census questionnaire, I can tell you that it was well designed to yield a complete and accurate portrait of the people in our profession.

I look forward to seeing the results of the census, which will be published later this year in STC’s Intercom magazine. More in-depth analysis of the data might also be submitted to academic journals.

Although STC is helping to publicize it, the research project was developed and is being conducted by the team at Concordia. I’ve known Dr. Carliner, the project lead, for more than 25 years. I very much admire his energy, his dedication, and his insight.

One last thing: No one asked me to promote the census. I’m encouraging you to participate because I have high regard for the research team and because I think the research will greatly enhance our understanding of our profession and its people..

When you’re the only star (part 2)

(part 2 of 2)

You’re a star performer. The other members of your team aren’t. What do you do? Last time we looked at a few things that don’t work — whether you’re the best basketball player in the world, a popular and accomplished baseball player, or an all-star technical writer on a team that isn’t getting the job done.

Now here are some things that do work.

What does work: Have faith in the team

Remember: while you might think you’re the only star on the team, the team members probably don’t share your view.

Here’s something else to remember: no one on your team is trying to fail. Nor are they incompetents, unable to do the job.

Somebody hired them, thinking they had the necessary skills. Surely, then, you won’t need to look very hard to see the qualities that can turn your teammates into capable performers, even if they’re struggling with the current project.

Yellow Brick road from the Wizard of Oz

Your vision can guide your teammates to taking their first steps along the yellow brick road to the goal

So try a dose of humility. Continue reading

When you’re the only star

(Part 1 of 2)

You’re a star performer. The other members of your team aren’t. What do you do?

In the business world, almost everything is a team sport. As a technical writer, for example, you might be an all-star. But you succeed only when the other members of the team — writers, editors, artists, publishers, SMEs, managers — do their jobs effectively.

So what do you do when they’re not effective? Here are a few things that don’t work.

What doesn’t work: Carry the whole load

LeBron James shouting at teammate J.R. Smith

What were you THINKING??

You’ve probably seen this photo of LeBron James, by all accounts the best basketball player in the world. He’s confronting teammate J.R. Smith after Smith’s mental blunder in the first game in this year’s NBA Finals.

James’s Cleveland Cavaliers went on to lose that series — but not because he didn’t give it his all.

He spent more time on the court (by a wide margin) than his next busiest teammate. He attempted more shots. He accounted for nearly half of his team’s assists.

In sports we often admire the guy who “carries the team on his shoulders.” But when a team needs to be carried, when it relies too much on one person’s contributions, that’s not a good thing. Continue reading

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:

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

crowd of people

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.

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?