Technical writer – how does their working day look like?

Technical writer? So what do you do, actually?

There’s really a lot of different names for this job position. We are often called technical editors, documentation engineers, UX writers, content designers/managers/editors/writers, communication specialists. However, each time I tell someone that I work as a technical writer, immediately the question arises, “But, seriously, what do you do?” And my answer to this apparently innocent question results in… questioning looks and the avalanche of the next questions. “What does it mean? What is it? Is it you who write these unclear manuals added to software installation packages?”

If you have already read previous posts on our blog, you know who a technical writer is and what they do. We wrote about this role in articles such as Technical Writer – the master of words in IT and Technical writer – get to know their superpowers! What are the responsibilities related to such a position, and what skills are needed – I want to tell you how it looks from my perspective and to help you familiarize yourself with the everyday challenges in this job.

Not only formal education

The choice of this career path means continuous learning. However, our job requires much more than involvement in formal education. All the time, we cooperate with experts from various fields and often from various industries. As a result, we have to expand our knowledge, sometimes on our own. But also – through participation in courses or webinars.

As a technical writer, you need strong organizational skills to smoothly manage the information you must gather. In many cases, acquiring knowledge is not difficult, but defining which information is relevant for an audience can be challenging. Many experienced technical writers publish a few new textbooks every year. They must assimilate new information, understand them, organize, prioritize, and – what’s most important – finally pass on the teaching in an accessible form.

But before a particular document is created, meaning a result of our job, along the way, a lot of things have to happen. Our everyday life is verifying materials, reviewing the existing documentation in terms of language, translating, and other project tasks in line with the established standards of conciseness, style, and terminology. Sometimes, we also play the role of a business analyst and even a tester! Creating documentation takes about 40-45% of the time spent in the project – of which two-thirds is devoted to planning (for example, understanding user stories, cooperating with developers, testers, product managers, or analysts) and documentation delivery. The cooperation with BAs is for us a valuable source of knowledge – we do not only get from the information on the project; we also support them in their current tasks.

Working in this position requires taking pleasure from organizing countless documents’ pages. Editorial skills are essential (such as structuring, edition, writing, proofreading) and familiarity with methodologies as well as consequent following a determined style guide. Our ultimate goal is to deliver what a customer needs, but without leaving any trace of our own voice – and this means cutting off from our own ego.

Technical writer meets a guru

One technical writer, who has been in the profession for over seven years, once told me an interesting story. It concerns the role of technical writers in IT and how much they can bring to the project, incidentally. Every technical writer has experienced this awkward moment when they need to describe a really complex system function. Exactly then, our internal perfectionist won’t let go. So we start playing with an app, exploring it; we spend hours understanding how most users would use a particular functionality, which is the key to describing it better. Hours pass, and we are still not happy with our research, although it’s really extensive. Finally, we decided that the time had come – the time to ask a guru for help. Guru, that is, obviously, a developer. The idea of such a meeting makes us really nervous because we are afraid of being laughed at. And when we eventually ask developer’s a question and expect some brief feedback, instead of an answer, we hear, “I did not even know that this function might work like that. We didn’t do this on purpose. Actually, it’s the old code, and we were afraid of removing it, so… Good job!”

As you can see, a technical writer’s job is not only about writing. After implementing a new product and providing a new code, a tester performs testing activities on a particular feature; a technical writer also does that, disguised as an end-user. Why? Because they mirror the first customer. Testing supports documents created from the end user’s point of view. And usually, in such moments, situations described in the above-mentioned history happen.

Technical writing – what did a poet have in mind?

Technical writing is far different from the literary writing style. The language we use differs from the standards we are taught at school or during our studies. Let’s take a look at Edgar Allan Poe’s poem.

“To Helen”

Helen, thy beauty is to me

Like those Nicéan barks of yore,

That gently, o’er a perfumed sea,

The weary, way-worn wanderer bore

To his own native shore.

As a technical writer, I would say about these lines, “The subject finds Helen beautiful.” And that is the essence of our work – transforming complex and challenging materials into clear and concise documentation that is understandable for the target audience.

Technical writers are the art people, although I’m aware that at first glance calling a technical writer an artist may seem inaccurate. However, whenever we deal with linguistic mastery – whatever it is a poem or manual – we have to deal with art. Additionally, it dispels the myth that technical writing is boring and uncreative.

By writing this text, I wanted to show you the technical writer’s job from this other less-known but more creative side. I cared about convincing you that the technical writer’s involvement in the project is profitable. Developing a user guide for the end product written by a developer may result in unnecessary descriptions or exaggerated benefits. Though maintaining a high level of detail is crucial, professional technical documentation should be concise, objective, and frame the facts clearly. High-level prepared documents and user guides prove the professionalism of an organization.