Growing a Big Team in a Useless Field

Do you feel underrepresented in your company? This method will get you heard.

Let me tell you a little something about technical writers. Being a technical writer is a sophisticated job. Accomplished technical writers ought to have a wide variety of skills. They need to excel in linguistics, communication, terminology, usability, didactics, law, standards, technology, and many more.

In short, there is a reason universities offer technical communication courses that take just as long as a course in computer science or engineering. However, if you don’t talk to a fellow technical writer, you are often considered a failed engineer. Sometimes, the person doesn’t know what a technical writer is altogether.

Imagine you start as a technical writer in a software company. The staff predominantly comprises software developers. The majority of the managers also used to be developers. On the first day, you realize a few things:

• There are a couple of hundred developers but only a few technical writers.
• The technical writers don’t write the technical documentation. Instead, the developers do.
• The quality of the technical documentation is unprofessional, but nobody seems to care since it‘s just documentation.

Only one way to fix this: we need a paradigm shift! In this story, I will show you how you can promote your field in your company, even if it is does not have the highest priority.

I gathered this knowledge working for several different companies. I explain the procedure based on my own experience in technical writing. However, I believe you can apply it to any underrepresented group of people in a company.

With this approach, I grew my team from two technical writers to seven in four years. Two of these years were during a crisis.

How you can improve your situation

1. Analyze the problem

A paradigm shift in an underrepresented field does not happen overnight. First, investigate the issues at hand. The best way to do this is to interview your stakeholders.

I started by interviewing the people who create the documentation, i.e., developers. Afterward, I interviewed the readers, i.e., colleagues in the project business.

What I heard in these interviews matched what I expected.

The readers did not appreciate the documentation. They were unable to find helpful information. Even when the readers found something, it wasn’t user-friendly. The content had a poor overall information structure, or the language was difficult to understand.

Many developers neither had the time to write proper documentation nor the skills or the motivation for it. Even the most committed developers with solid language skills lacked the skill set of a professional technical writer, which made the process very inefficient and the output unprofessional.

To make this clear, I am not blaming the developers. Some are putting admirable effort into creating helpful user documentation. However, it is only natural that they do not excel in a foreign field. I wouldn’t do too well myself developing software, despite having a basic understanding of programming languages.

So there you have it: unmotivated and untrained writers equal poor documentation. I found the core issue.

2. Define your vision

After understanding the problem, defining the vision for the future technical documentation was a straightforward task, or so I thought. As an ambitious technical writer, I wanted to work on exceptional documentation.

So the first draft of the vision focused on improving the quality of the documentation. It sounded something like this:

Instead of developers, trained technical writers provide complete, understandable, and findable documentation content. This documentation will improve the overall user experience of our product.

When you think of your vision, you should write it down in a statement that is to the point and answers the following questions:

• What do you want to achieve?
• How do you want to achieve it?
• What is the current situation?

Once you have your vision statement down, discuss it with your team to get their feedback. Transparency is the key to defining a vision. After all, you want to include all stakeholders who will be affected by it to increase acceptance.

3. Test your vision

I was bursting with confidence. With my great little vision at my disposal, I asked several different colleagues from development for their opinion. Shockingly, they didn’t share my enthusiasm! Doubt started to fill my endorphin-soaked brain. Maybe the vision was not so great after all.

I tried to understand what was wrong with it. To me, it contained everything essential, was crisp, and relatable. I added more points to the statement, e.g., legal safety and other documentation qualities. But all of these changes felt forced and didn’t make for a game-changer.

And then it struck me: the target group! I am not dealing with fellow technical writers here. I am talking to developers. Later, I will discuss it with managers who once were developers. If the developers aren’t interested in these quality-based facts, why should the managers be? The following hypothetical dialogue unraveled in my mind:

“We need better content quality!”

“Meh, it’s just documentation. Don’t make such a fuss.”

“This will improve the legal safety of our products!”

“No lawsuits so far, so why would that change now?”

My vision was no good for the people I needed to convince. I had to understand what they needed, how we could improve THEIR situation, not OURS.

With your vision, try to get a hold of surrogates. They should be similar to the people you will have to convince in the end. If the managers you need to convince had been developers, ask fellow developers to provide feedback. Do a dry run with them.

4. Sell your vision

I remembered how the developers told me that they often didn’t have the time to write the documentation. They already struggled to have their code ready in time. Writing the documentation took away precious coding time. That was the hook I needed. I kept the original vision for my team, but I created another one that should sell the idea to the management.

Instead of developers, a team of trained technical writers creates the documentation. This approach enables the developers to have more time to develop the products.

When I shared this idea with developers, several people started to chase me around. They kept asking when I will finally realize the vision. They couldn’t wait to stop writing the documentation.

You can see that you will benefit from your dry run with the surrogates. Use their feedback to draft a vision that focuses on the needs and interests of the target group, i.e., the managers who will decide over your vision’s success.

5. Realize your vision

After defining the vision and completing a successful dry run with the developers, I needed to take the next step — convince the people who can approve additional positions.

This step is the most difficult one and will drain you the most. I am not going to lie: your supervisor, project manager, or whoever else you need to convince might not board your hype train. To sell the vision, prepare your presentations meticulously. Emphasize the benefits. At the same time, you will need a lot of stamina to deal with rejections.

Of course, every single manager is different. I would love to hand you a specific recipe that would magically work with every single manager. However, we are not living in a fairy tale or sitcom. Still, I will give you some advice that helped me stick with my vision until I finally made it.

1. Prepare a little proof of concept with a prototype project to show that it works. Document its advantages, e.g., cost savings, improvement of usability, etc. It is vital to have reliable numbers since managers tend to challenge you on those.
2. Don’t take rejections as a “no” for infinity. First of all, you shouldn’t get too discouraged by a no. Challenge it. Ask why the manager doesn’t want to follow your vision. Try to understand the take of the other person. Often, there are very plausible explanations for a rejection, e.g., the current economic situation of the company or the priority lies with another field right now. If you can’t convince the manager just yet, take it easy by knowing that the other person now knows about your vision. Try again under more suitable conditions and refine your presentation. For instance, you could provide a return on investment calculation.
3. Show the idea to different stakeholders and promote the idea top-down and bottom-up. There isn’t only one way to reach your goal. Promote your idea at different levels, create a lobby for your vision. The more allies, the better for you. If there is an internal communication channel, try to reach out to your colleagues through it. But do not undermine your supervisors. Be open and transparent about your intentions.
4. Try to create a personal relationship with the manager. Managers are people just like you. You wouldn’t want a manager to treat you as a mere resource, so you shouldn’t treat the manager as a strictly analytical being that only considers naked numbers. Do a little small talk, ask about their well-being, show a little interest. People with whom you share a more personal relationship tend to be more open to your ideas. You’ll be surprised how often these analytical beings turn out to be humans, after all.

Your turn!

Technical writers, software testers, requirements engineers, and other people who feel underrepresented in their companies: Thank you for reading my story thus far. I appreciate it.

Now, all you need to do is start working on your vision. Prove to the managers that your field is not as useless as one might think: I know it, you know it, now make sure the people who need to know will learn it, too. If you don’t take care of it, nobody will.

Once you rose to the top and became a well-known manager for your now appreciated field, please don’t forget from where you came. For tips on being a great manager, see my earlier story, in which I explain why and how great managers listen to their staff, even when they’re silent.