Photo by Shane Rounce on Unsplash

The longer I spend in the IT industry as a technical writer, the more I come to see my job is more about people than ever before. By that, I mean that the technology part is easy. The people part can be complex, so I try to lead with empathy in my role.

I work as an individual contributor, so I work across different teams and personalities to get my job done. Here are examples of how empathy can help you as a technical writer.

Knowing the motivations of senior technical staff

As a technical writer, I believe you have to understand the motivations of senior technical staff and management. It’s more than if the person supports your writing efforts. It’s about where the project fits into the person’s professional world. Is it in their area of technology interest? Are they all talk but deliver nothing? Do they only go to project meetings to appear busy? Is the project tied to the staff member’s personal or professional goals? Other questions abound depending on the corporate culture, project, team, and employees should come to mind.

The lesson is to know your audience just as if you’re writing technical content.

Learning the ebbs and flows of people’s schedules

I once wrote that the best advice I’ve gotten about technical writing comes from programmers and it remains true to this day. I like to work as an individual contributor in a technology organization. It’s been years since I worked on a writing team.

Working the ebbs and flows of other people’s schedules is about knowing the best time and place to get information from people. You also need to use their preferred medium in which to get information from people. For example, I like to write and review documents myself. It’s my preference. However, it’s a rarity in my experience to work with people who work that way. I’ve had to bend and mold my working style to accommodate whiteboard ideation sessions.

I’ve also learned to adjust to people’s schedule when needed to get information. Whether it means coming in early, online chat sessions at odd hours, and most anything in between I’ve had to do it in the past.

Starting with a blank page

Ever since I got my start as a technical writer way back when I never understood why some technical writers who wrote nothing themselves. I’ve found that if you can start a document at a blank page and write as much as you can on your own it’s a whole heck of a lot easier to get information and reviews out of subject matter experts and management.

Dealing with people who blow deadlines

During my time as a technical writer, I’ve worked in environments where deadlines were optional. People just blew past them. There was almost never any accountability either.

Dealing with people who consistently blow deadlines can be complex and tiresome at least for me. Here are some methods I’ve used in the past to deal with people who blow deadlines:

  • Minimize my dependency on them as much as possible for the project (not always workable)
  • Bring people the answer and let them tweak it.
  • Build in a buffer for their procrastination.
  • Acknowledge that blowing deadlines is just part of the culture.

Discovering people who are in over their heads

One of the loneliest times in my professional life as a technical writer is when I find somebody who doesn’t know what they are talking about and tries to talk their way around the topic without answering my questions. You’re wasting your time feeling sorry for these people. They think they have you fooled because you’re just a technical writer. My tactic in dealing with them is just trying to work around them. Nod your agreement with them then quickly and diplomatically move on.

The flip side of that person is somebody who openly admits they don’t know the answer to my question. Sometimes it just takes a little time in a room with a whiteboard for them to figure out their answer to the question.

Final thoughts

At its heart, technical writing is a people game. The more energy you put to working with people the better you will collaborate with your team. Empathy will also improve how you interview subject matter experts.

My name is Will Kelly. I’m a technical writer and content strategist based in the Washington, DC area. I’ve written for corporations and technology publications about such topics as cloud computing, DevOps, and enterprise mobility. Follow me on Twitter: @willkelly

%d bloggers like this: