Recently, the STC Management SIG has been engaged in a thread about the “visibility” in the organization of information-development processes. The question focuses on how obtrusive these processes should be in the organization. One view, expressed by Donn LeVie, argues that other managers, especially engineering managers, may find our processes to be annoying. They don’t want to be told that publications needs to write information plans and content specifications or needs three weeks to make publications print-ready.
My concern with the focus of the discussion is this. Why should information-development managers go along with the assumption by others that our work is second class? Do we need to hide our processes or make them unobtrusive because they might annoy others in the organization?
I contend, and have always done so, that the development of information to support effective use of a product is essential to its success, whatever form that information may take. The information may be text and explanations directly in the interface as a form of performance support. It may be help text tied closely to activities being performed by the user. It may be supplementary reference texts, FAQs, knowledge bases, training information, and more. Without information (text and graphics) of some sort, we would have command-based interfaces in which expert users would have already memorized the commands. Not many products start at that point these days, if they ever did so.
On the other hand, I know of at least one instance in which an engineering manager called the publications director to get a senior writer fired because that writer had created a detailed content specification for a project and asked members of the engineering team to review it. The engineering manager argued that producing such a specification was a complete waste of time, and he never wanted to see or pay for another one. The publications director told him that they would continue to plan, they just wouldn’t ask him to review the documents anymore. A partial capitulation, but it stopped the screaming.
We all know of examples of writers who have to resort to bribes to get engineers and programmers to give them information or review documents. They keep up a steady supply of candy, cookies, or fruitcake (oops, probably not fruitcake) to get “professional” colleagues to act professionally.
Why do some people in organizations regard it as their right to treat others badly? Do they also abuse janitors, delivery people, and secretaries? What is the publications manager supposed to do in response? Why are your team members treated badly?
You won’t succeed, I would argue, by becoming unobtrusive. We have to have well-developed, thorough processes in place, setting a good example in terms of project management. We need to collect and report measurements that show the relationship between good planning and a reduction in development time and errors. We need to act professionally at all times and avoid whining about a lack of respect. We need to be effective managers who strongly support the activities of our team members and teach them how to act appropriately in difficult situations.
In short, we always need to stand up for what we do. I know many, many excellent managers who take this stance. They are assertive about the responsibilities and needs of their team members but not unpleasantly aggressive in pursuing their own agendas. They also spend a lot of time and effort educating team members in professional behavior.