The Name of Your Department Does Matter
Although some feel the name of your tech writing department doesn't matter a whole lot (for example, TexasWriter says "Find out what people now call it. Ask what they mean by it. If it's accurate, use it. You aren't marketing, don't make it up"), actually your department's name does have an impact on the role you're expected to play.
For example, our current department's name is "User Education." Because of this, every time a user has a how-to question about the application, they send the user to me to be educated. It would not be so, I believe, if our department name were different.
Lately I've been having conversations with a QA guy as I carpool to work. We've been talking about roles. Because I am a "technical writer," he wonders why I feel I should comment on software prototypes, or interact with users. "You're a W-R-I-T-E-R," he says. "You shouldn't be interfacing with the customer. That would be overlapping other people's jobs. You should be writing help material. That's what writers do."
People make decisions all the time based on connotations of job titles and department names. For example:
- A user needs help with the application. Who should he call? "User Education" or "Information Design"?
- You're setting up a meeting to evaluate prototypes. Who should be included? "User Information Development" or "Technical Publications"?
- You need to develop some e-learning materials for training. Who should you call? "Learning Support" or "Strategic Communications and Media"?
In each case, I bet you leaned toward the first option. Your department's name does affect how others perceive the role of your department. I guarantee you will be asked to provide more user training and support with a name like "User Assistance" than "Communication Strategy and Design."
Given the importance of choosing a department name, here are some options. Many of these were sent to me by tech writers over Twitter. Others I pulled from the archives of the Techwr-l listserv.
- Information Design
- Information Development
- Learning Support
- Technical Publications
- Technical Publications Office
- Technical Communications
- Training and Publications
- Design and Development
- User Information Development
- Technical Information Development
- Technical Documentation
- Documentation
- IT Documentation
- The Knowledge Group
- Knowledge Transfer
- Strategic Communications & Media Group
- Customer Focused Communications
- Global Content and Training Products
- Customer Communications
- User Success Group
- Corporate Publishing
- User Knowledge Center
- User Assistance
- User Help Department
- Help Design
- Documentation Analysis
- Information Architect and Strategist
- Communication Strategies
- Customer Focused Communication Design
- Communication Strategies and Design
- User Assistance Strategies and Design
- Information Strategies and Design
And a few silly names:
- Fellowship Renowned for Excellent Documentation (FRED)
- Masters of All Spatial Order, Chronological Hierarchies and Interesting Sorts of Trivial Stuff
- The tellers of how stuff works and what is
- Department of User Intelligence (DUI)
None of the department names jumps out at me as "the one." In the end, I'm convinced that a slightly vague name is better than a limiting name. I'd rather be "Information Development" than "IT Documentation." In the former, you might contribute to prototype design; in the latter, you would more likely just describe the design.
I would rather be "Information Strategies" than "User Knowledge Center." In the former, I might make high-level analytical decisions about branding, user awareness, and task efficiency. In the latter, someone would assign me to assemble a knowledge base.
I would rather people said, "Communication Strategies and Analysis -- what the heck is that? Rather than "Learning Support? Oh, good, I have a group of new users that needs a Webex."
Have you ever had a department name that you worked against you? What department name do you prefer?
Additional Reading
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.