Balancing user advocacy and corporate responsibilities
Anne Gentle, in the post Writing Engaging Technical Documentation, says this:
I love it when I hear people say, “I no longer work for development. I work for the user.” They say it with disruption and evolution in their hearts and minds. They fully intend to serve the user the best they can.
Anne has a lot of experience with open-source projects, and I can see where this perspective might work in that area. But I feel that the “user advocate” position is problematic in commercial operations for a variety of reasons:
- Conflict of interest. Unlike an ombudsman or a guardian ad litem, technical communicators are not explicitly assigned to represent users. If you are on a corporation’s payroll, it’s impossible to be a pure user advocate. (I wrote about this in a post, Web 2.0 and Truth, back in June of 2008.)
- Isolation. Claiming the user advocacy role sequesters technical communicators from others within the organization. What about quality assurance? What about customer support? Are they not user advocates as well? Everyone, including developers, should have user advocacy as part of their role. When technical communicators claim this role, the implication is that others are not user advocates.
The biggest problem, however, is that what’s best for the user may not always be what’s best for the employer organization. Technical communicators need to balance those competing priorities.
And that led me to a chart:
I think that technical communication needs to balance user advocacy against corporate positioning. It also needs to balance tactical information (how to do something) against strategic information (why to do something). Here are some other types of communication:
- White papers. Usually conceptual information, with a distinct whiff of corporate positioning.
- Press releases. “Yay, us!”
- User-generated content. How do to something; highly specific; usually less conceptual.
- Customer support. Answers the customer’s question; may have some conceptual components.
- Third-party books. Very user-focused, in-depth on concepts. (You could convince me that some third-party books lie along the X-axis toward users instead of way up in the top right corner.)
- Bad tech comm. The writers didn’t or couldn’t take advantage of their inside access.