Broadening the definition of technical communicator at ASTC (NSW) 2014

I’m attending the annual conference of the Australian Society for Technical Communication (NSW), ASTC (NSW) 2014. These are my session notes from the conference. All credit goes to the presenter, and any mistakes are mine. I’m sharing these notes on my blog, as they may be useful to other technical communicators. Also, I’d like to let others know of the skills and knowledge so generously shared by the presenter.

Kylie Weaver‘s presentation was “Broadening the definition of the technical communicator”. Humans are very good at categorising things. This is very useful, both in life and in the workplace.

Rigid categories can be limiting. Kylie believes strongly that there’s a hybrid role in the workplace: tech writers and business analysts merged together. Technical writers often work through the entire project cycle, from the beginning of development to the end where the product is shipped.

Kylie has observed that poor documentation can slow a project down and reduce its quality. Poor communication leads to misunderstandings. We need more technical writers.

Being involved throughout  software development lifecycle

Documentation is needed throughout the software development lifecycle. The roles involved include technical writer, instructional designer, change manager, business analyst, and project management. Kylie has worked in environments where these roles blur together. Technical writers tend to span all these roles during the course of a project.

Kylie walked through the documents produced at various stages of the SDLC: requirements analysis, specifications, design documents, test cases, requirements for usability testing, user documentation, training material, corporate communications, handover for production readiness, and more. The role of technical writer is traditionally confined to just the user docs and perhaps the training material. We can in fact contribute at all stages. It’s very exciting to get involved right from the start, and we have the skills to do that.

The hybrid role that can span the project is “business analyst/technical writer”. If you are are interested in solving the business problems and talking to the end users, this role is for you.

The importance of (all types of) documentation

Finding out what people want, and documenting that clearly, is essential at the start of the product. Specifications help developers and testers write code quickly and effectively. Kylie walked through the other documentation types, showing how each is essential to the successful conclusion of a project. Technical writers all know about audience analysis. So many business analysts and project managers don’t.

Comparing the roles of technical writer and business analyst

Technical writers translate geek speak into normal speak. And business analysts do it the other way round! We’re all good at creating technical documentation. We all focus on helping people do their job. And we care about the end user. We have good negotiation skills.

We’re all the hub of all knowledge, acting as the liaison point between the big-picture people (PMs) and the details people (developers). Kylie says that this is a particularly difficult aspect of the role. And we find pragmatic solutions.

So, what are the differences? Tech writers focus on the documentation solution, while BAs focus on the technical/software solution. TWs may focus on a specific procedure, whereas BAs often have a broad focus on business process. And both groups focus on different documentation standards and conventions, as defined for their roles.

BAs facilitate workshops, so this is something a TW may need to learn. They also manage the expectations of users’ and subject matter experts’.

How to move towards this hybrid role, if you want to

Look for opportunities and offer to help. Remember how you became a technical writer – you probably merged into it in much the same way. Remember that you have extremely valuable skills. It’s a joy to read a document written by a technical communicator.

Step back and look at the big picture.

Look back at the roles you’ve already filled. You’ve probably done part of the BA role already. Kylie gave some examples of hybrid-role projects she had worked on. One was an IT architecture project, connecting front end and back end systems. Kylie came into the project when it had been going a while, and was asked to define the scope of the end-user training that would be required. She found that none of the design or solution had been decided or documented yet. So she let the team know that they needed to define the business processes, and helped do that. She and the team created templates and a SharePoint site, pinned something down, and brought success out of the ashes. If they’d had a BA at the start, the project would never have been at that state by the time Kylie was called in.

Is this role for you?

An awesome, fun-filled section of the talk was Kylie’s overview of her motivation for “stepping between worlds”. She told us what she enjoys, and how it fits into the hybrid role of BA/tech writer. Basically, it’s just “tremendously exciting” and it all comes down to this: “if you enjoy getting your breakfast routine down to the most efficient sequence of tasks, then this role is for you.” 🙂

Conclusion

This was an inspiring, humorous, and buoying talk. Thank you Kylie for a unique, personal, authoritative session. Kylie’s favourite project was documenting how to refuel aircraft at Mascot airport!