Becoming a freelance Technical Author

In this episode of the Cherryleaf Podcast, we take a look at becoming a freelance Technical Author. We’ll cover:

  • Why do companies hire freelancers?
  • The benefits
  • The downsides
  • Working from home
  • Working abroad
  • The legal and tax considerations
  • Finding work
  • What to do in the quiet periods

Links:

Sponsored :

Ask your questions to the podcast team

To record your questions and comments to the podcast team, use the green button:

What does the future hold for technical communication?

This autumn, Communicator will be celebrating 50 years. We’ve been asked to write an article for a special supplement for the Autumn issue on what the future holds for technical communication. We’ll be looking at what technical communication will be like in ten or twenty years into the future.

We’d like feedback on the draft article, to test our predictions and consider other ones that we might have missed out. If you’d like get involved, send us a message, and we’ll send you a link to the draft document.

The risks with Technical Author certification

As part of the attempt to make technical writing similar to other professions, there have been a number of moves by different technical communication societies to introduce certification. This can be a good thing, but there are some dangers with it as well.

Certification usually involves some training and a test. Students can be accredited or certified as having reached a certain standard. This might lead, at some point in the future, to organisations only hiring certified Technical Authors, in the same way they might only hire certified accountants.

So what are the dangers?

One danger with testing is that you tend to test what’s easy to measure, rather than test the talents someone needs to have. For example, multiple choice questions are easy to mark, but they tend to only test someone’s knowledge. They can test if someone knows “which X does Y”, but they are less good at checking if someone is able to explain “how X”. This can lead to an over-emphasis on teaching topics like the legal requirements for documentation, rather than testing whether someone can actually write clearly and simply.

A second danger is assuming there is only one right way to write a user guide. Technical communication is still a relatively recent area of study. We should still be open to ideas, to challenge accepted practice, if user testing shows that method or belief to be wrong. We don’t want to be the like the Paris Salon, which refused to show impressionist works by Manet, Monet, Renoir, Degas and Whistler, because they didn’t meet their definition of good art.

Le déjeuner sur l'herbe

Although it’s more labour-intensive, we should ask students to make something, and then measure that against a set of user acceptance criteria: can they find the information they need?; do they understand it?; is it accurate?; is it complete?; is it cohesive? etc.

Transcript from What’s the deal about structured content? Part 2/2

Below is a transcript of second half of our podcast episode What’s the deal about structured content? :

So what’s come about is lots of different standards for the ways in which we can do structured writing. And you know the same about standards and toothbrushes? Everyone wants to use their own. No-one wants to use anybody else’s. And that is often the case with standards and structured writing standards.

So a couple I’ll talk about.

Continue reading “Transcript from What’s the deal about structured content? Part 2/2”

Your questions about Technical Authors and Technical Writers answered

On a future episode of the Cherryleaf Podcast, we’ll be answering the top 20 most popular questions on Technical Authors and Technical Writers.

You can submit your question via our contact form or record your question by voicemail, using the button below.

Potential questions include:

  • What is a Technical Author?
  • How do I become a Technical Author?
  • How much does a Technical Author earn?
  • What makes a Technical Author?
  • Which is the best term? Technical Writer, Technical Author or Technical Communicator?
  • Are there opportunities for Technical Authors to get a job abroad?
  • What is the career path for Technical Authors?
  • Is technical writing a good career?
  • What do Technical Writers do?
  • Can a Technical Author work from home?
  • How to become a Technical Author without experience.
  • What does a Technical Author need to know?
  • Can a Technical Author become a Business Analyst or Product Manager?
  • How to interview a Technical Author.
  • Why hire a Technical Author?
  • What performance goals should you set for a Technical Author?
  • Can I become a Technical Author with an English degree?
  • What training is available in technical writing?

We’re looking for two contract Technical Authors/Documentarians, SW London, 3/6 months

Plus someone interested in a permanent position, too.

See:  #4187 Contract Technical Author, South West London, 3/6 months

You must have:

  • A proven track record in technical writing
  • Experience of creating content for an IT Operations/technical audience
  • Experience of using Linux (e.g. using the CLI; being able to execute and test shell commands that install and configure applications)
  • An understanding of JavaScript, or a similar scripting language
  • Experience of documenting enterprise products (both on-premise and SaaS)
  • The ability to work autonomously, with little supervision
  • The ability follow an established writing style guide

Upcoming presentations in 2018

Cherryleaf’s Ellis Pratt will be speaking at two upcoming events:

London Content Strategy Meetup, 7pm 22 February 2018

What’s the deal about structured content?

Content can often seem like jelly – messy and hard to manage. In this presentation, we’ll look at whether you can reduce this messiness through structured writing. In this overview of the topic, we’ll explore what is structured writing, what it promises to give its adopters, the different standards, and the challenges that come with using structured writing.

Venue: SYZYGY London, 84 Theobald’s Road, London WC1X 8RW

London Content Strategy Meetup

MadWorld Europe 2018 conference, 11-13 September

Documentation as Self-service Support

In this session, Ellis Pratt will look at the different approaches to self-service support, and the role of the technical communicator within that environment. He’ll explore questions such as where end-user documentation fits in in self-service support, and the realities of expecting users to write content. And finally, Ellis will discuss whether software-as-a-service changes the type of support and organization needs to provide.

Authoring in an Agile World

Agile development has been growing rapidly in the software industry and other industries. While the agile development model may make sense from a product development perspective, the methodology doesn’t explain the best way to create Help content for users. In this presentation, we’ll look at how authoring teams have responded to this challenge and developed agile approaches to technical writing.

Venue: Boscolo Prague Hotel, Prague, Czechia / Czech Republic.

MadWorld Europe 2018

Don’t say “simply”

At this month’s WriteTheDocs London meetup, Jim Fisher of Pusher presented a talk called “Don’t say Simply“.  He talked about words, such as “simply”, that can seem innocuous when written in user documentation, but which show a lack of sympathy when read.

He showed how popular “simply” is with developer documentation writers, by showing the number of hits for that word in GitHub: 93 million! If you restrict the search to Markdown files (the file type on GitHub used mostly for documentation) , it’s 3,325,386 hits.

“Easy” and “easily” are also problematic, and overused: There are 4,127,104 Markdown pages on GitHub for “easy”, and 2,797,143 Markdown pages for “easily”.

The problem with “simply” and “easy” is that the related task or concept is unlikely to be always simple or easy when the reader needs to read the documentation.

These words are typically “banned” in the main technical writing style guides, but they could be appropriate in training or marketing material. In general, it’s best Technical Authors avoid them.

Here is a link to Jim’s slides: Don’t say “simply” (Write The Docs London, 2018-01-23).