I started to comment on Patty Blount’s post, Kevlar Vests for Tech Writers?, but as sometimes happens, I was waxing verbose and decided to respond in my own post.

Patty asks, “Why are we, as tech writers, so maligned? How can we get development teams to appreciate us more?” I’m going address the “maligned” part more than the “appreciate” part; I think they are two separate discussions. (I may pursue the second issue later.) I’m sure there are many answers to the question as to why project team members may avoid tech writers or develop a negative opinion of us. Much of it probably has to do with how we interact with them.

A few suggestions here, all regarding good people skills.

Respect Others’ Time

First, since much of technical writers do is gather information from other people, be respectful of their time. Don’t ask for a minute unless you literally want 60 seconds of their time or less. If I have what I think is a brief question requiring a brief answer, I ask, “Hey Dan, do you have a few minutes to answer a question, or should I come back later?” They’ll usually be honest about whether they need to finish something first or if they can give me their full attention right then.

Be a Little More Than a Coworker

Second, try to interact with others more than just asking them for information. If you’re early to a meeting, strike up a conversation with a developer about his family or the vacation he just had. That way, you’re seen as a real person and not as just a hound that’s always after something. But remember to be genuine and not seen as exercising that social technique you just read about on someone’s blog.

Relax

Do you think tech writers are viewed as uptight? Do we complain too much?

Do you like talking to uptight, complaining people?

We can take ourselves too seriously sometimes. Of course documentation and user assistance are important, but they’re not the most important thing. Products aren’t created so that there’s something for technical writers to document.

When a developer forgets to tell you about a last-minute change to the UI, take a deep breath. He probably didn’t do it to get on your nerves. Can you imagine a developer saying to himself, “That tech writer bugs me so much, I’ll show him. I’m going to change the order of links in this menu so I screw up all his screenshots. He’ll have to bust his hump to get his changes in by the deadline tonight. *snicker*”

If you can picture this, it’s probably because you have an imagination. But it’s pretty ridiculous. Project teams don’t set out to make the tech writer’s life harder (at least not in my experience, and if you have truly found that developers do this, I’d start looking for another place to work). If you act like they’re doing this, their opinion of you won’t improve. So relax a little and look for ways around the problems you encounter. Don’t play the victim. People usually don’t like the one who always blames others for the pickle she’s in.

Wrap-up

A lot of getting team members to like us isn’t any different than getting anyone else to like us. Just like dogs and cats can coexist peacefully, developers or designers don’t have a natural enmity for technical communicators. You don’t need a T-shirt that says, “Don’t hate me because I’m a technical writer.”

By respecting others’ time, taking a personal interest in them, just plain not taking yourself too seriously, and exercising other good people skills, you’ll probably be more liked on your project team. And you can leave that kevlar vest at home—as well as that “Don’t hate me” shirt.

In my project portfolio, our release manager—the one who instituted release scrums—wants to standardize on release notes across applications. Many of the projects are in a maintenance period, so releases are planned for each project every month or two on something of a rotating basis. These releases will include small enhancements and bug fixes.

One of the challenges of standardizing on release notes is coming up with a release notes process that can efficiently turn out these documents within about a week.

› Continue reading…

Still somewhat surprised that Vanessa, the project manager, had labeled him a major player in solving the customer’s problems, Henry projected his improved diagram onto the screen. Everyone looked at Vanessa.

“Henry, will you explain the diagram, and then we can go through each situation and find out whether the right things are happening.”

Henry hadn’t expected to guide the discussion, but he talked through the diagram. Then he began going through each relationship and explaining the effects of the relationship on the reports that the users were generating using the software.

As they went, the customer identified where things were happening correctly and where something needed to change. Vanessa kept track of action items, and since they uncovered a couple of inaccuracies, Henry took note of where he needed to make changes. Vanessa then asked Henry to create a version of the diagram that represented what should be happening in the software as if it already was. The development team could take that version and begin creating and assigning tasks.

When the meeting was over, Henry couldn’t help but experience some relief. The spotlight had been moved elsewhere. His original documentation on the software had contained a couple of errors, and he would fix them, of course. It was possible that the number of questions and problems coming back to the customer stemmed from those errors. But this possible communication problem had exposed a programming problem. And Henry, being the professional communicator on the team, had taken the task of communicating to the customer how the software currently worked, and doing it clearly enough that the customer could make informed decisions. So communication had been the first step to solving the programming problem.

› Continue reading…

This week I read a post by Ivan Walsh of I Heart Tech Docs entitled “Who Makes The Most Money—Technical Writers with Strong Language or Deep Technical Skills?” For some reason, his site won’t let me comment, but since it turned out that my reply was somewhat lengthy, it’s better to respond here in my own space instead of imposing on his.

At first, Ivan seemed to be saying that technical skills are more important than writing skills. But I read the post again, and I think he’s saying that technical skills are worth more in the marketplace because they’re harder to develop.

My take is that the reason a developer who does some tech writing gets paid more than the full-time tech writer is because the first guy is still a developer. Developers get paid more than technical communicators most of the time (or all the time, most likely). I think a programmer with some interest or a bit of practice in technical writing getting a job ahead of experienced technical writers may be a signal that management (or HR) doesn’t know what they’re supposed to be looking for in a technical writer.

› Continue reading…

Once again, Henry met with the project leadership; only this time, he was the star of the show. In the last meeting, he had taken the assignment to diagram the relationships that were currently possible to set between two types of objects in the software, as well as the downstream effects of those settings. He had to represent four criteria in a two-dimensional diagram but had a hard time thinking in four dimensions at first.

After some thought and experimenting, he accounted for all four types of variables by combining two of the criteria into one axis, putting the third across the other axis, and explaining the effects at the intersection of row and column. It didn’t look amazing, but it would do the job.

A little timid, Henry projected his laptop screen onto the conference room wall. He glanced around and saw a couple of confused looks.

› Continue reading…

Henry opened up a PDF on his laptop and went to page 27. The meeting continued around him as he scanned the text of the procedure he’d written 18 months before so he could verify some of the information that had been distributed.

“One way to look at this is that we want to prevent our customer from getting these phone calls all the time—or at all,” said Vanessa, the project manager. “What’s the first step?”

George, the business analyst, lifted a hand. “Well, since he keeps getting asked why people are or aren’t seeing this or that in the reports, I think it’s a data problem. We need to start there.”

“Or it’s a training problem,” said Melanie, the lead of the quality assurance team. She looked at Henry. “If there’s a data problem, maybe the users don’t understand how to set the data up correctly.”

› Continue reading…

Scrums are part of the particular flavor of Agile methodology project teams use in the portfolio I work in. The managers recently borrowed the scrum concept for release preparation because the projects in this portfolio are interrelated and often have to be released together. This means that a lot of coordination is needed so that there are no surprises for anyone.

In these scrums, we have 15 minutes or so for a representative from each project team to report on the progress of showstopper bugs, testing, problems that have emerged, and so on. They usually happen during the week or two before a release (as opposed to all the time). Then, if the release date needs to be adjusted, or if a feature isn’t quite complete, management decides what to do. They still have a final go/no-go meeting, but the release scrums keep everything out on the table.

Because technical writers enjoy surprises as little as anyone else, I get invited to these scrums. This lets me know how much time I have to put release notes together and whether there are any last-minute changes I need to make to them or to any other documentation. Since some of my deliverables are deployed with the application builds, I need to know whether to remove the updates from the build before it’s released.

These release scrums have turned out to be an advantage for our portfolio. They especially help me to stay informed. If you use some variation of Agile, I recommend release scrums. Technical writers often need every resource available to know what’s happening with the release schedule.