In last month’s issue of the CIDM e-newsletter, JoAnn Hackos wrote about what makes an effective information-development manager. The following are responses to that article:
Donn Le Vie
Technical Publications Project Manager
Personal Client Architecture Components Group
Technical Communications Council Manager
I’d like to clarify my position for CIDM readers:\
Technical publications organizations or managers need not be less “obtrusive” or be apologetic for their need to collaborate with engineering or development. My position is that engineering/development organizations actually control the perceived obtrusiveness of technical publications organizations, so the solution lies with overcoming preconceived misperceptions. You do that with three central strategies:
- Have in place a proven high-quality, repeatable information-development process
- Educate those you collaborate with about your information-development process
- Understand the language of your collaborators
Have in Place a Proven Process
You have to be able to back up the talk with the walk. Fine-tune your process so that it works every time to yield high-quality information products.
Educate Those You Collaborate with about Your Information-Development Process
To get visibility into technical organizations with whom you collaborate, you have to teach others—even evangelize—about how your process works. Show them the successes from previous projects. Show them on an X-Y plot how the relative level of effort (RLOE, Y-axis) for everyone increases during the development phase of a project when they first engage the information-development team during that phase (the X-axis shows the various phases of your organization’s product life cycle). Then show them an X-Y plot of the much lower overall RLOE over the project life cycle when they engage the information-development organization during the earlier stages, such as the exploration or planning stages. This comparison works great when your information-development project-management life cycle parallels that of the product life cycle.
Understand the Language of Your Collaborators
Information-development professionals—especially managers—need to be very good at shaping the environment by influencing or persuading others. We also need the skills to work conscientiously with existing circumstances to ensure quality and accuracy. It also helps that we excel at cooperating with others within existing circumstances to carry out tasks or strategies. These characteristics—influence (I), conscientiousness (C), and steadiness (S)—comprise three of the four Dimensions of Behavior characterized by the Personal Profile System®. The fourth behavioral dimension is that of dominance (D), which is characterized by an emphasis on shaping the environment by overcoming opposition to accomplish results. People exhibiting this behavior (engineers and programmers are notoriously high D types) tend to make quick decisions and solve problems without consulting others (they prefer to jump to the solution space without defining objectives or much planning), are highly task-focused to get immediate results, and have little patience or interest with any projects, programs, or initiatives that distract them from their task-oriented, problem-solving environment.
For balance, high D-type people need others who are skilled at weighing the pros and cons; who can calculate risks; structure a predictable environment or process; research facts; who can deliberate before deciding; and who recognize the needs and input of others. If you know how others process information and approach their particular professional specialty, you can be more effective in getting your message across.
JoAnn and I point out that there’s no need to be apologetic or unobtrusive. Don’t wait for an invitation from engineering or development; inject yourself into the process as a stakeholder. Your job is to ensure your organization produces top quality, value-added information products. The proper balance of assertiveness, diplomacy, education, and moxie will go far in changing the misperceptions engineering or development has about “obtrusive” information-development processes.
Donn Le Vie
Supervisor, Documentation, Thermo CRS
I think that information developers should not only not apologize for what they do but also actively evangelize throughout the organization for the business benefits of their expertise. Here at Thermo CRS, the documentation team not only produces all the hardware and software product documentation, it also produces and maintains the content of the Web site, edits and sometimes writes marketing and corporate communications, produces training materials, writes the work instructions for the production staff, and provides training to all staff on business communications. It wasn’t always this way: I was originally hired to create a documentation team that only produced traditional documentation. But by persistent lobbying, volunteering, demonstrations, developing business cases, and some shameless bragging and flattery, I was able to convince the company that the documentation team could add a ton of value to communications performed by other functions in the organization.
I guess what I want to say to information developers is “think big, and deliver.”