Failing as a Technical Writer

I am writing about past failings to show that I’m not super-human or perfect all the time. I have made mistakes and reflect on them mistakes to learn from them an improve.

In this article, I share how I failed at being a technical writer, which at the time I thought would be easy enough for me to do as I was “over-qualified” to do the job.

Through my story, I hope you understand the importance of knowing why influences performance more than knowing how to do it or having stellar past results.

This article will take you less than six minutes to read.

source and more information

Introduction

I once took a job as a technical writer at a growing company because I had inside information they had a hard time filling that role and I was looking for a job.

I never formally trained as a technical writer, I just happen to do it in my last job, writing the team’s work as a document and standardizing it at an international level.

When I was applying for the technical writer job, I thought, how hard could it be?

• I trained technically as an engineer.
• I worked as a programmer.
• I standardized technical documents at an international level.

I figured it out the work then and had great success. This time, I can apply the same principles and it would work out, right?

New Job Honeymoon Phase

At the start of the job, things were fine. My assignments were small and those were easy wins. I was the second person on the documentation team and it was all good. I was getting into the role, which was different than my previous role as a programmer that had a small side of writing. The job now was full-time writing.

I was thinking: technical writing isn’t as hard as it looks. My play-book works.

I just kept doing the same thing as I did from the start. As challenges kept getting a bit bigger, I kept applying the same technique from the beginning: just write the usual way I did.

Why fix something if it ain’t broke?!

Cracks Start Appearing

Eventually, I started getting feedback on my work that it wasn’t up-to par. The feedback was on style, tone, and wording. Pull requests comments seemed elusive to fix. Things were confusing. I kept asking:

“How can I improve?”

My boss gave me some books to read and I read them.

Even after reading them, things didn’t make sense. How does style and tone work in this context? They seems subjective and I couldn’t nail it. Wording seemed easy and I applied some tricks to help out.

I still kept asking how to improve? What was I missing? Do I need to read more books? How do I get better? How do I achieve the desired level?? Can you just tell me what you want??

The Divorce

Eventually, my boss’ boss took me aside and let go from the role. It was bitter as I had dreamed of plans based on that job and all those dreams disappeared in that moment.

Even though I had feedback, I thought I was doing fine. Things seemed smooth the whole time until the end, where I got a little bit of negative feedback.

At the time, it felt getting fired after a little bit of negative feedback with no time to improve seems drastic, isn’t it?!

Key Learnings

There has been time since I was a technical writer. I’ve had different experiences and learnings since then.

Two significant books that contribute to my learnings:

• Start with Why by Simon Sinek: where understanding he most important question to answer is “why” to do something above how to or what to do.

• Extreme Ownership by Jocko Willink and Leif Babin: where a leader needs to “believe” in the mission or they will not be able to overcome any unexpected hurdles.

These two resources have enlightened me on my failure of this experience.

Seeing things with the Why Lens

At the start of the job, it seemed logical that I would fit in the role. I had the technical background and did the job before, the how to do the work. I have results to prove I did the work, the what.

I was missing the why that linked my results to the company’s mission.

• Why did I have to do technical writing before?
• Why was I in that role at that company?
• Why was I in that role at the current company?
• Why didn’t I ever focus on being a technical writer elsewhere?

Not having why aligned caused problems as the initial honeymoon phase of the new job ended and the cracks started to show.

I didn’t know how to improve as I didn’t have a solid understanding why I was being a technical writer.

That’s why I couldn’t improve. When I received feedback on poor performance, I only asked how and what questions to improve.

When I look back and think why did I take that job, I understood: I didn’t take the job to be a technical writer. It was to solve a key problem in my life: not having a job.

Importance of Why

When one believes they are doing the right thing, they know why they are there, when a setback appears, they just overcome it. Every part of their being aligns with the vision and use every resource to overcome the setback.

This is the importance of why, above knowing how and what.

After understanding the importance of understanding why, I realized how I failed at being a technical writer.

• I had the basic skills - I didn’t have the drive to hone them on my own without explicit guidance. I required too much oversight in getting better.
• Even though I got technical international standards published, the goal of technical writing is documentation and has a different audience.
• The main result of the previous job where I was standardizing international standards was not technical documents.

I couldn’t see what a good technical writer would be as I didn’t in that job to be a better technical writer, only to have a job.

The best technical writer around me was my boss there and at best, I would just emulate him. In a fast-growing organization, I would expect everyone to be able to stand on their own, independently.

Missing these two important factors: why I want to be a technical writer and what a good technical writer does, put me in a situation where I caused organization drain, which is horrible in a fast growing organization.

Conclusion

At the time my failure as a technical writer, I was in shock and had no idea what happened.

When I have a solid why based reason, it sets up a frame of mind that is stronger than any how or what based reasons as it:

• motivates you to solve any unforeseen problems, which there always will be.
• pushes yourself to improve to do things better.
• others will feel your enthusiasm and support you.

I am glad I was a technical writer, it’s taught me more than I expected.