One of the challenges that technical communicators in the category of documentation face is keeping up with changes made to the product as it is developed. In some environments, specs or requirements are set out at the beginning, but in others—particularly in some software development companies—the customer, project management, or developers may alter the original set of requirements because of unforeseen circumstances, such as technical limitations or time constraints.

This challenge may be aggravated when the technical writer remains unapprised of such changes. Personally, I have signed in to a software application and seen user interface tweaks that affect the documentation in no small measure: images, procedures, descriptions; you get the picture. But I have found a few ways to get into the developers’ consciousness so that I’m not taken by surprise.

I: Technical Writers Should Be Seen

In the last two or three years that I have worked in my current job, the improvement I have seen in communication from the development team stems mainly from the fact that they see me every day. My workstation is among theirs, and I attend scrums, which are daily, fifteen-minute meetings in which each member of the team reports progress and brings up roadblocks. I get a turn just like everyone else.

What if you work offsite? If possible, visit the office regularly for meetings or when you have a number of team members to talk to. If your team holds video or other conferences over the Internet, attend them. When the rest of the team sees you and knows what you do, they start thinking about how what they do may affect you. In one project I work on, the project manager gives me a few minutes in a meeting held every other week to report my overall progress. I don’t need as much time as the QA lead or the development lead, but that’s face time that is valuable for the exposure I get.

II: …And Heard

The squeaky wheel may be noisy, but it gets what it wants. That is not to say that we should pester developers, or they may subconsciously start to resent us and withhold information. I mentioned the scrum, where I get a chance to voice concerns and to coordinate with developers, and that makes everyone aware of what I am doing and the needs I have as a member of the team. I attend one project’s scrum by phone because most of the team is located offsite.

Developers should know when what they do affect you. If one team member makes a change that results in extra work for you, hold a conversation with him that is simply getting confirmation that the change was intentional or that it is complete. Do not give the impression that the developer is imposing on you; remember, development projects are not created so there will be something to document. You want the developer on your side, so be polite.

III: Look up the Ladder

Get support from those whose voices everyone takes seriously. Chances are, you were hired because someone thought documentation is important. You may find yourself in an environment where you have to prove your importance, and many times that is a battle fought for a matter of inches rather than miles. But some good work makes itself important. In any case, talk to the customer or stakeholder if any is available and get her expectations for documentation. If you meet or exceed those expectations, you may very well receive commendation from the customer along with the development team, and the mentality I have encountered is that if it’s important to the customer, it takes on importance to everyone.

Talk to the project manager, as well, if you are concerned that you have no voice. You may need to ascertain the manager’s opinion about the importance of documentation. More than likely, either he or the customer wanted a technical writer. If it was just the customer, you may want to draw on that to win the manager over to your side so that you get that face time you need.

I count myself lucky that in one project, the manager considers the documentation important because he saw the work I did in a previous project in which he was a developer and heard the customer talk about the documentation in meetings. That kind of “luck” takes time and effort, but it’s possible, even in an organization where, as little as three years ago, there were no technical writers except the occasional intern. It took about two years to affect the culture in this way, and it’s not perfect, but now project teams in my part of the department are coming to expect a technical writer’s presence. A degree here and a degree there can significantly change the course of the largest ship.