Hiring a tech writer in Copenhagen

We are looking for a tech writer for financial software to join our headquarters in Copenhagen, Denmark.

SimCorp is a leading provider of investment management software and service solutions. For details, see the job ad or ask me via twitter @techwriterkai or via LinkedIn.

TCUK12, day 1: Workshops & company

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.

Advertisement

From SME to tech writer in 7 steps

My colleague Mattias Sander writes today’s guest post about his journey from an SME to a tech writer – which is a noteworthy answer to my post two weeks ago why not to hire an SME for documentation. I thank Mattias for the permission to reprint the post from his own nascent blog The Techwriting Engineer.

---

I work as a professional technical writer even though I am really a subject matter expert. This provides a lot of challenges and opportunities.  Before my current job I couldn’t care less about the uses of en and emdashes, something that has now taken up at least an hour of my life. More importantly I did not have a clue of how to produce quality technical information. What I have is the problem solving skills and natural curiosity of an engineer – willing to analyse and solve any and every problem I run into. I also live by the philosophy that the best way to learn is by doing. The quickest way to learn a new skill is to find someone who already masters that skill and mimic as best you can – naturally taking into consideration that your problems might not be the same as the expert’s – and filtering accordingly.

The first thing I did when starting this job was to find a book on technical writing with good reviews – Developing Quality Technical Information – and then starting to produce my very first user manual. The result left much to ask for – but still had the focus on task orientation – with clarity and concreteness being the most important properties. Choosing this book as my techwriter’s bible was a good choice as it’s easy to use, easy to understand and it’s easy to find what you are looking for in terms of specific topics.

The challenge I now face is how to get a grip on using topic based authoring and structuring content so that it’s easy for my users to find what they are looking for – hopefully making their life a bit easier – because that’s really what user documentation is all about – helping users perform their daily tasks, isn’t it?

The title of this post seems to promise a seven step procedure, so here goes…

To produce quality user documentation – follow these steps:

1. Buy Developing Quality Technical Information and read it from start to finish.
2. Find out who you are writing for and put yourself in their shoes.
3. Research what information would really help them do their jobs (or install their microwave oven).
4. Write down the questions your users need to have answered, write down what task they need to perform and what reference information topics they need to have at hand.
5. Produce the user documentation – using the book as your bible. Make use of the checklists in the appendix for checking the quality of your documentation.
6. Ask SMEs and fellow techwriters to review and edit your documentation – based on different levels of edit.
7. Kick back and enjoy the feeling of having helped Mr Smith install his new microwave oven in time to surprise his wife with a real microwave gourmet dinner.

Top 3 reasons not to hire an SME for documentation

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“.

Your turn

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.

Recommended read: Degree helps tech writers

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.
• Enthusiasm
• 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.

Your turn

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.