I have been a technical writer during my time at a large IT services company. Most of the time I’d sit with developers, quality assurance professionals, and DevOps experts. Their conversations would always revolve around development, sprints, testing, load testing, etc. I was a technical writer who was tasked with writing the product description of a software product, the conditions under which it worked (including exceptions, etc.).

Our audience was IT managers in client organizations. They would often be reading our documents and make decisions based on what we mentioned in there (although not entirely, there were business needs that need fulfilling as well). However, being a technical writer meant that I had to understand what my team was trying to say, and ensuring that we communicate it effectively in product brochures, flyers, sales presentations (as appendix materials), response for proposals, etc.

The thing here is that most of our team members were excellent developers and quite good at their jobs, but they lacked English skills (because they had studied in their native Indian languages). So, trying to understand what they were saying and writing that in a manner that experts in that topic would understand, was always a challenge.

What is your work life like?

It’d mostly be sitting in meetings with teams, understanding and making sense of what they were talking about, and making reams of notes of it. Then, I’d come back to my desk, and write them in a structured format so that we don’t lose out on the essence of it. This would then find a place either in a product brochure or in a sales deck that our sales personnel used to carry to client meetings. Sometimes, I would have taken 20 pages of notes which would ultimately result in just 2 sentences in the final document. (But the learning was worth it).

In IT service companies, sales personnel are experts at what they sell, they’d often know the intricacies of the solution because they would have been software developers themselves not too long ago. So, when I’d be finished with the first draft of the document, I’d take it to the developers to verify if it was factually correct. Then, I’d request sales personnel to review it before we sent it to clients. This helped weed out obvious errors in the document before our clients saw it.

Sometimes, life would get easy as I would be required to capture the circumstances under which we helped a client, the solution, and the benefits. This was pretty straightforward because we were distilling it down to bare facts and numbers.

Pros

• It isn’t as complex as it sounds – We get to learn a ton of technical stuff and even seemingly complex things can be really simple. For example, calculating the cloud cost of delivering a streaming service can be done via Amazon’s calculator, but you ought to know what is the bitrate, how is it calculated, etc.
• Wide knowledge – I gained a lot of knowledge in the time that I spent there. The knowledge was diverse across industries and use cases that we catered for. Each use case was different from the rest so that there was a lot of learning in every project that I worked on.
• People care for you – Being a technical writer, my teams cared about my presence because they knew that we can avoid a lot of rework at a later stage. They knew that I was responsible for putting complex words into meaningful sentences that others can understand, so they were patient with me, despite the tons of work they had.

Cons

• Frustration – This happens very often in these roles. It happens when nobody is knowledgeable enough to give you the right response/feedback about the service that we were offering and what the client ought to know. This was because they relied on superiors in their teams for this input, and would wait for days to get responses. (This is true in all large B2B companies). And, when they did not have the answers, I was left in the lurch because I was answerable for the completion of the technical document. So, I had to play this game very carefully without losing the confidence of both parties in me.

Proofreader – Mark Hemming

Libra Translation

My name is Mark Hemming, and I work at Libra Translation in the UK. Proofreading and editing is a large part of my work, whether proofreading translat … Read More

Date Concierge – Hannah Deau

Select Date Society

My days are extremely busy! I’m constantly juggling things, so I have to stay organized. As a Date Concierge for Select Date Society, I am responsible … Read More

Speech-Language Pathologist – Lauren Hermann

I am a speech-language pathologist (SLP). The field of speech-language pathology is extremely broad. SLPs can work with patients across the lifespan- … Read More

OB/GYN – Dr. Nichole Butler

Weiss Memorial Hospital - Women's Health Center

What does a typical day at work look like for you? My last group I was in had an on-call schedule that was very structured so that only those who were … Read More