Too many technical writers live in style guides, single sourcing, FrameMaker, processes, and methodologies. They can sometimes escape from the business of software development. This monk like college advanced composition teacher existence can separate the technical writer from the realities of today’s dysfunctional workplace. When facing down ambiguity, technical writers have two choices:
Wallow in the dysfunction and complain how the organization
doesn’t understand technical documentation and that they can’t do anything right. At least they get out of taking meeting minutes because the organization isn’t so formal. They get to spend plenty of time on Instagram. But that last until project gets on the critical. Demands come down for documentation deliverables. Then a mad scramble begins to complete the documents under tight timelines.
Chart their own course for your documentation projects by building strong cases for decisions and take documentation off your management’s worry list leaving the manager to fight real fires. It’s always better to be controlling your documentation efforts.
Ambiguity should be seen as an opportunity to take the reins over technical documentation and help your client or manager cross out one worry from their list. Technical writers can rise and fall from the opportunities that happen in ambiguous environments.
Technical writers need to take ownership of their projects in such environments.
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.
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