In the face of fundamental changes, skills seem to follow attitude. That’s my second conclusion from Sarah O’Keefe’s webinar about “Managing in an XML environment”. Read on for my summary of her argument and my comments. (Or see my previous post “Top strategies to embrace cost metrics” for more insights.)
Technical writers need a different skill set when moving to structured writing, topic-based authoring or an XML environment, Sarah explained. The general types of skills are the same as when writing “old style” books, such as user manuals: You still need writing skills, people skills, tool knowledge and domain knowledge. But the skills shift focus and application.
Shifting skills
Basically, Sarah argued, you need less tool knowledge and more of the other three skills – and better:
- Writing skills focus on writing topics and their reuse. Writing topics requires more structure and better compliance to templates than book-like documentation which suffers free-form writing more easily. And topic reuse involves a lot of collaboration.
- People skills enable increased collaboration. Colleagues may reuse, tweak and add to your topics. In fact, there’s no such thing as “your” topics, once they are subsumed into a larger collection of topics to which several colleagues contribute.
- Tool knowledge decreases due to the separation of writing and publishing. Yes, you need to learn new tools, Sarah allowed, but that’s an initial effort. Much of the tool effort is split off into implementation and production of the documentation.
- Domain knowledge steps in to sustain documentation quality. You can no longer hide behind the tools and improve specific parts of the documentation by layout or presentation.
Among all these changes, Sarah said, the biggest challenge is actually to come to constructive collaboration among writers. In a structured environment, the emphasis is on the process of writing and maintaining topics, not on the deliverable end product, such as a manual. Writers share responsibility for topics – which is very different from “owning a book”.
That’s why Sarah urged us not to “succumb to BOSSY, the Book Ownership System SYndrome” and to remember that “CROC is your friend” which stands for “Creating Reusable Objects and Collaborating” (somehow “CROAC” seemed a less appropriate acronym, I guess…).
Shifting attitudes
I agree with Sarah’s premise that topic-based writing requires different skills, with her analyses and her final recommendations. Yet I think the difference she describes is one of attitude rather than of skills:
- Writing skills are different, not harder. I think it’s just as difficult to write a good, “old style” user manual as writing good topics. Writing topics seems to require more skills, because it’s new and different. I don’t think it’s actually harder, once we writers come to terms with its newness – and our resistance against it, however good reasons we may have.
- People skills are overdue. I guess we tech writers feel the same pressure as many other professions: To collaborate, to heed stakeholders, to reach out to other teams and to connect to customers. If we notice the pressure more, it may be because we’ve worked in relative isolation. Mastering any change is much easier with a bunch of like-minded people than when you feel alone, stuck in the trenches.
- Tool knowledge is overrated. Banking on tool knowledge isn’t the best career choice since your job hinges on a tool – and a specific version… When your tasks change, there’s the chance that your tool isn’t the best (anymore) for what you need to do. Tech writers should be really good at wrangling content (props to Scott Abel), not tools. If you distinguish methods and tools, I think you’ll find that it’s much faster to learn a new tool than to learn a new method, such as topic-based authoring.
- Domain knowledge is second to content proficiency. While one can never have too much domain knowledge for a job, our key skill is to structure and relate that knowledge. I firmly believe that you should “always hire the better writer“, for two reasons:
- It helps your corporation to build up complementary skills: Your corporation probably has lots of domain specialists already – but how many really good writers does it have?
- In my experience it takes a year or two to become a decent domain specialist – but it takes longer than that to become a decent writer. (Though your mileage may vary…)
That’s why I come to a different conclusion. How successful we tech writers are when changing to a environment or processes depends less on our skills, but more on our attitude to them. There are at least two different ways we tech writers can regard our deliverables, our writing skills and our tool knowledge:
- If they are our assets and define what we do, any change in environment and processes will threaten us.
- If they are the results of previous learning, we can embrace change with the confidence that we can rise to the challenge again.
For example, when I feel I own a manual, any review, any editing has serious crisis potential already. I know what it’s like, I’ve been there… But once I feel shared reponsibility for the documentation at large, it takes on a more constructive, larger dimension, where we’re all in it together. Well, most of us, anyway… 🙂
Your turn
What determines how you face change: Your skills or your attitude? Can training and skills ensure buy-in for a new environment or processes? Or is it more important to have a self-confident, competent attitude?
Filed under: change management, managing, structured writing, tools, topic-based authoring, writing | Tagged: Sarah O’Keefe | 6 Comments »
Kai's Tech Writing Blog 