Importance of Technical Writing in business: A real story of a Tech Writer leading a business initiative
Hi there! I’m Daria, and I’m now a Technical Communicator at SoftServe. I’m here to tell you a story about how Technical Writing can help a business communicate with customers in a way that strengthens their loyalty and trust, bringing tangible value to the whole company.
So, what’s the purpose of Technical Writing in business? When a business can timely and clearly communicate what its customers should expect, how to prepare for it, and what to do next, this business is well up and running like a professional marathoner. Everything that builds up and adds to the marathoner’s health is a value. In our story, it’s a business value that a Technical Writer brings in and that builds up and adds to the health of your business.
If you’re a Tech Writer, like me, I hope this story will buck you up:
- Your confidence in the importance of your job will grow stronger.
- You’ll be inspired to engage in business initiatives at your organization.
- You’ll have a concrete argument for taking a leading role in your company’s communications with people.
If you’re from a non-writing profession but wish to know how a Technical Writer can benefit your team and business, I hope you’ll find a lot of interesting things here:
- Technical Communication is a multifaceted and sophisticated craft that takes more than just accurate writing.
- A Tech Writer is a professional who connects the dots of multiple pieces of knowledge from different areas of expertise across your company.
- All communication projects at your org should include a Technical Writer as one of the actively managing, if not leading, stakeholders.
Where the story starts
My quiet workday was coming to an end. I was sipping my five-o’clock tea, closing my work tasks, and thinking about dinner. And suddenly, I got a Slack message.
Someone tagged me in a channel where Support Engineers and Managers were hanging out. I realized I’d never met and talked to those folks before. “Okay, that’s probably a request for a quick fix in our docs,” I thought. It wasn’t. It turned out to be a request to prevent a customer’s potential failure during the upgrade procedure, mitigate the risk of receiving hot support incidents, and provide the customer with additional knowledge right before they decide to download the latest release.
So, what’s the challenge
Our Senior Support Engineer discovered a potential problem that a customer could bump into if they tried to upgrade to the latest release with an unsupported product license. The product simply wouldn’t start up. Definitely, that’s not an expected system behavior or a satisfactory user experience.
So, the Support Engineer asked me to come up with a note for the product download page that would describe the issue and recommend changing the license type.
How long would it take a Tech Writer to compose a two-sentence info note? I’ll tell you. It took me — and a dozen other stakeholders — four weeks.
Why?
Believe me, when I prepared a report about this task and counted the number of days, I was as stunned as you might be now. But let me explain. And please bear with the details of the entire technical writing process that I’m going to guide you through. This is just how it works on my project. If, on yours, you can make decisions in a faster and smoother way — well, lucky you.
The request must be communicated to and agreed with the Development Team.
The request came from a Support Engineer who was testing the upgrade procedure. As a Tech Writer, I was contacted directly, without any preliminary discussion with the Product Owner or the Technical Lead. Well, I am responsible for “texts,” am I not?
I certainly could provide a solution. But I couldn’t bring it to life without agreement with and approval from my team. I had to discuss that with the Product Owner and Developers, who were ten hours ahead of me, sleeping peacefully when the issue arose. The following morning, however, I was fortunate to get a positive response from them.
The request must be reported to the top management, hence the business initiative.
Of course, I don’t normally share each and every request from the Support Team with Program Managers and the Head of Development. But that case was different.
Much prior to this whole story, we launched a vast communication campaign to inform our customers about the end of support for a particular license type. We provided alternative business solutions and guidance on how to get on them. We posted tons of announcements in the company blogs, product documentation, and even customer forums. During all that time, our top management was actively engaged in everything: from the development to the content.
Yet, all of a sudden, after the first release with that change was sent out into the wild, there came a concern from a Support Engineer that all those efforts might not be enough without a two-sentence banner on the product download page.
The top management had to be aware of that concern and give us (me) the green light to work on additional communication. Luckily, they were either in my time zone or a few hours behind me, so I got their blessing that very day.
The request must be shared with the other product Writers and their product teams.
The thing is that the same significant and impactful change was planned for a number of our other products. Each of these products had its own Development Team and Technical Writer. That meant we had to be aligned and consistent in what we’d decide to communicate to our customers.
My task was to notify the other Writers about the request in a way that wouldn’t overwhelm them with the prospect of having even more work to do. At the same time, I really needed them to prioritize the work on the banner for their products because the release dates were close, and the request was rather urgent.
To ease their burden, I decided to create a template that they could use to describe the specifics of the upgrade procedure in their products.
To my great relief, the Writers’ team reacted quickly and positively, reassuring me of their support. ❤️
The text must be written and sent for review.
What should the info banner tell our customers about? That the new release doesn’t support a particular license type? That the product won’t start if they still decide to upgrade with the unsupported license? Any tips on what the customer needs to do?
In the evening, when I got the request from the Support Engineer, I came up with three variants of the banner text. I played with the level of detail in each of them: from a dry and straightforward sentence about the unsupported license type to a few paragraphs in an apologizing tone.
After I finished, I sent the page with the texts to stakeholders from Support Engineering, Development, Program Management, Technical Writing, and even Marketing. I expected to get the first review the following day so that the stakeholders from all the time zones could take a proper look.
The text must be reviewed. More than once.
I couldn’t believe my eyes when I opened my page the following morning. More than ten people had reviewed the texts and left almost twenty comments.
I immediately started looking through their feedback, and I realized that no one preferred variant of the text. Some subject matter experts insisted that we needed to provide more details of the issue and a guideline on how to solve or prevent it. Others voted for brevity and references to existing official sources of information.
I called out for all my courage and rolled up my sleeves to write one more, the fourth variant of the banner that would consider most of the feedback I had received. The new variant turned out to be longer than the previous ones, but it wasn’t too revealing and included a recommendation for preventing the potential upgrade issue.
As you’ve already guessed, I sent the new variant for another round of review. Although a few comments were appearing on the page during the whole following week, there was a nice common thing about them. All the reviewers preferred the latest longer variant.
Even the advocates of brevity eventually put up with the text length because our Support Engineers raised a rational argument: the more details the banner contains, the fewer questions we’ll get from customers.
Because different stakeholders finally agreed on the banner’s content, I just needed to polish its shape. With a few other Tech Writers, we spent some time improving the word choice, voice, and tone.
Finally, the text was ready and approved by our Support, Development, Marketing, and all the top managers involved, including the Head of Development.
The ticket to publish the banner must be created.
It might happen that even though you’re responsible for content, you don’t have access to the environment where it needs to be published. So, you need to contact the team who has access there and give them instructions on what to publish, when, and why.
My interaction with the publishing team was happening through several related Jira tickets. Because that team obviously had other priorities and wasn’t expecting any off-schedule publication, I had to be very clear about my request to them and about the reason for the urgency. Luckily, we knew the exact date when the banner had to become public, and there was quite enough time for the publishing team to triage my request and add it to the queue.
All that remained was to wait.
Whoo-hoo, it’s done! But what’s next?
Finally, the big day came! I was looking through my emails in the morning and saw a notification from the publishing team that our announcement had already been made public. I quickly checked if everything was alright with the layout and text, and it looked like nothing was going to bode ill.
I shared the update with the Development and Support Teams, the other Tech Writers, and the management. Everyone seemed satisfied and relieved. Phew!
Now, when the situation was saved and our customers were aware of how to resolve a potential issue during the upgrade, there was a question: what should we do next?”
Together with the Developers, Support Engineers, and Program Managers, we decided to observe and react asap if we would get any feedback from the customers. As a Technical Communicator, I was also engaged in the observation and the work on responses that we’d need to provide to customers reaching out to us.
So far, we haven’t received any support requests about that issue with the upgrade described in the banner. So, we’re keeping our fingers crossed and continuing to improve our software products.
Some fun stats
When I was preparing the report about my work, I thought it could be fun to check out how many resources we needed to prepare a two-paragraph banner.
Here are some statistics that I collected:
- 1 month of work
- 4 versions of the banner text
- 10–20 reviewers in total at different time
- 28 resolved comments on a draft page
- 3 continents from where the experts were involved
- 5 types of expertise (Tech Writing, Support, Development, Marketing, and Program Management)
- 200+ of Slack messages
Have you counted how many of these things you need for technical and business writing? Share in the comments.
Final thoughts: Importance of Technical Writing in business communication
It’s not a person or position that brings business value to your company. It’s what that person on that position, with all their knowledge and experience, can do to make your product better, your customers happier, and your company wealthier.
A Technical Writer can contribute to all these areas. A Technical Writer will not only write a piece of text but also connect the right people, build the strategy, maintain the process, and create a positive and productive vibe of fruitful collaboration between different experts driven by a common business goal.
Here’s to Technical Communicators! Cheers! 🍷
