We are looking for a tech writer for financial software to join our headquarters in Copenhagen, Denmark.
The first day of the ISTC conference TCUK12 offered workshops and great opportunities to meet tech comm’ers from all walks of life and many corners of the earth.
When I arrived late on Monday evening, I promptly headed for the bar and joined the advance party for a last round – which lasted so late that I’m not even sure in which timezone it was 2 am before I turned in…
Robert Hempsall: Information Design 101
Robert Hempsall offered a great and engaging hands-on Information Design 101 workshop about information design. The workshop focused on the five key areas of content and structure, language, layout, typography, and lines and spatial organization. Using a formal application to vote in English elections by mail, Robert led us through the process of designing the form to maximize clarity and usability.
Thanks to our versatile and engaged group of delegates, our work on the form was not only lively, but showed how different disciplines contribute to the solution of better information design, from tech comm (with its principles of minimalism and parallelism) via user interface design (with its emphasis on making completion of the form as easy and painless as possible) to graphic design.
In this sense, the workshop presented a good example of “design by committee” (which is usually a terrible idea): We discussed the most intuitive and user-friendly sequence of the form’s elements and how best to phrase the section headings, as questions or as imperatives. A seemingly innocuous “all of the above” check box also caused a debate: Should it precede the individual options, to make completing the form quick, easy and painless? Should it come last, so users hopefully first read and reflect on the options? Or should it be omitted altogether, so users have to think about each option and select all that apply.
Form design is maybe not among the core tasks for many tech writers. Yet I’ve found several challenges in it that are strikingly similar to getting a topic structure just right, whether it’s a consistent, indicative heading, good, clear instructions or logical structure.
Rowan Shaw: Quality Across Borders
Rowan Shaw‘s workshop Quality Across Borders: Practical Measures to Ensure Best-Value Documentation in Global Technology Businesses focused on creating documentation both with authors and for users who have English as a second language (ESL).
As in introduction, Rowan presented us with 10 sentences each of which had some element that can create a problem for ESL readers, ranging from “10/03/12″, which could mean 3 October or March 10, to metaphors and slang.
If you need to hire ESL authors, it can be helpful to ask applicants to sit for an exam which tests skills such as procedure writing, fluency of expression, structuring, detail, consistency – but also their motivation for applying, to spot those candidates who want a foot in the door, but might not be interested in tech comm in the long term. We discussed a sample test, whether it was applicable and appropriate in all cultures.
Rowan suggested that, given the practicalities of global ESL authors, you might have to settle for less than perfect profiles in candidates. Then it is important to know which skills are easier to teach someone on the job, for example, grammar, structuring, capitalization, punctuation and how to use a style guide. Other skills are harder to teach, such as an eye for detail, audience orientation, logical thinking, but also more intricate language skills, such as prepositions and correct modifiers.
Again, this workshop benefitted tremendously from the diverse talents in the room and the experiences delegates brought to the topic.
The right company
I keep harping on how much I enjoy and benefit from meeting other tech comm’ers. Just on the first day:
- I found that several other doc managers are also wary to hire subject matter experts, who are less committed to tech comm, because they might just want a foot in the door (see above).
- I had an immensely helpful conversation with someone who’s a visiting professor and who could give me tips and ideas that I can try as I consider teaching as a future path.
So day 1 was very fruitful already, and I’m looking forward to more sessions and conversations to come.
There are 3 reasons (at least) why you should hire a technical communicator for documentation, not a subject-matter expert (SME).
I work in the field of financial software. Applications for banks and other financial institutions are complex. The office swarms with people who have solid financial knowledge, both practical and theoretical.
Recently, I talked to a financial specialist who is writing documentation and his manager about the need for a second writer. Their idea was to hire a financial specialist who could make sense of the pricing formulas and the workflows surrounding the financial instruments.
I disagree. I think they should hire a professional technical communicator, especially since they already have a finance specialist in documentation. If they can find a writer with experience in finance, all the better. Here’s why:
1. Get the full package.
Only a technical communicator will be comfortable with and good at doing all the expected tasks. An SME is ready to explain the instruments and how to trade them. If you’re lucky, the person can also describe them well to users.
But that’s only part of it. The job also includes designing and structuring topics. Editing what other people have written. This takes some hefty experience to do efficiently and well. With an SME, you take the chance to run into a problem with reason number two.
2. Hire for years, not months.
Many SMEs don’t stick around, once documentation gets tough. They may not mind writing documentation, but they don’t think of themselves as technical communicators. So once you expect them to do the “full package”, interest often flags and sooner or later, they find something else to do.
3. Complements beat “more of the same”.
From a corporate perspective it makes sense to hire complementary skills instead of “more of the same”. If there are several financial specialists who can review or even supply domain knowledge they can support the technical communicator. If there is no tech comm person, financial specialists may just scratch their heads over topic types and structured writing – and in the worst case put “crap on a page“.
What’s your experience? Do you more reasons why technical communicators should write documentation and SMEs shouldn’t? Do you know counterexamples where SMEs are more helpful than tech comm’ers? Please leave a comment.
Here’s an example of how graduates of a tech comm program put their skills to use in a high tech company.
Specifically, National Instruments at Austin contributes two guest posts to the Texas Tech STC Student Chapter blog. Yes, these are recruiting posts, but they do ring true. I think they reflect well how a company can take tech comm seriously and benefit from the formal training and academic skills of graduates. It may be an exception among the employers of tech writers, but it’s an encouraging example. So I recommend these two posts:
Tech Writing…It’s Not Just For Tina Anymore
… asks Texas Tech alumni who now work as tech writers and their managers how they can apply what they’ve learned and what advice they have to students and prospective employees:
- Rayo emphasize task analysis before tool skills – which I’m glad to hear.
- Robin gives SME interviews a reality check that strikes a balance between what’s desirable and what’s possible.
- Heather explains how she determines which documentation formats get produced.
Technical Writing Skills
… has Nathan Stokes list and explain 5 skills which every tech writer can benefit from – especially in this less than obvious combination:
- Editing, including yourself: If you can edit yourself, you’ll be a better writer.
- Productivity, i.e., project management skills to keep yourself organized.
- Curiosity, which can drive you and help you to grow.
- Computer Knowledge
- Previously in these pages, I’ve covered a how a (non-tech comm) degree can help a tech writer.
Are these skills useful in the tech writer workplace? Can you learn them – or at least expect to learn them – in a tech comm program? If you have any thoughts or experience, please leave a comment.