Communication channels for technical writers
Yesterday at work we heard that a team shuffle is happening. We have a new team, a couple of new team leaders and managers and a new focus. This affects just about every product and framework that I document. So next week I’ll be setting up new communication channels with the team leaders and managers involved. This made me think about how important our lines of communication are to us as technical writers. So this post is about the channels we use at work, and an invitation to you to let me know how you do it.
I think the top three factors that affect the quality of our documentation are:
- The quality of the communication between the technical writers and the development and product management teams.
- The quality of the technical writers.
- The quality of the product being documented.
Another factor is the documentation tool. But I think if you’ve got the above three things right, then you can produce good documentation with any of the tools available to technical writers today. Why have I included the quality of the product as a factor? It’s hard to create neat documentation for a messy product. Technical writers can give input into creating a better product. That’s another blog post!
For me, the absolute top factor is the quality of the communication. Without a good flow of information, you’re just the guy who sits in a corner and does documentation.
When I start working with a new team or start a new job, I’ve always found that one of the very first things I need to do is to set up the communication channels.
The goal is to keep me in the loop but not overload me with meetings and information I don’t need. Equally important, I want to let people know who I am and that I’m here, interested, enthusiastic and just basically kicking!
The actual communication methods available depend on the company you’re at and the development methodology used. At Atlassian, we follow an agile process using all these methods and more:
- Daily standups (short meetings, held standing up, where everyone says what they did yesterday and what they plan to do today)
- The wiki (Confluence, of course!)
- A feature, bug and task tracker (JIRA, equally duh)
- IM and Twitter (but this is ad hoc and not something I need to plan for)
- Email distribution lists (for informal communication within a team)
- Planning meetings (where we plan the tasks for the next week or so)
- Documentation-specific meetings (between the technical writer and the main contact person for each product)
So on Monday I’ll be setting up a quick meeting with the new team leaders and managers to suss out the names, times and places that matter. Maybe I’ll suggest we do it over a hot chocolate. Ah yes, the quality of the chocolate is that missing fourth factor 🙂
Posted on 25 April 2009, in atlassian, technical writing and tagged agile, communication channels, technical communication, technical documentation, technical writing. Bookmark the permalink. 8 Comments.