What Technical Writing Taught me About Endurance (and how you can also benefit)
Reading time: 5 minute(s)
Table of contents
Do you want to write more consistently?
Maybe you just want to write more?
Read on and discover 7 pillars that can help you succeed with both.
Many consider technical writing the “unromantic” writing genre.
Others consider it a boring vocation.
Sometimes I want to agree with them.
And many don’t know what a technical writer actually does.
That being said, I am grateful that technical writing equipped me to be a better indie author. And I hope that you will also benefit from what I learned, and share here.
Join me and I’ll share the 7 pillars that I learned after 40 years in this field…
Every single project that I worked on had a deadline. In most cases a tight, non-negotiable deadline.
If there was a technical writer who had writer’s block, they would have had a very short career path.
You are assigned a project (or part of a large project), and let’s say that it’s roughly a 100-page document. It must be ready to be shipped with the product in 3 weeks (arbitrary deadline). And yes, many times, the documentation was not part of the project planning (too many times, it was a nice-to-have, after-thought, but a customer requirement).
Now, you need to hit the ground running – no “blank page” freeze, no writer’s block syndrome – you have to start your research (that’s a topic for another time), and you have to start WRITING.
It’s this adherence to meet a deadline that helped me and every technical writer I worked with to be productive, and get our writing done.
With my personal writing (freelance and otherwise) I used this same strategy. Even if I was writing a personal blog post on Medium, I would set myself a deadline. Admittedly, I would not be as strict with my personal deadlines as was the case with technical writing.
Mentally, having that pending deadline, helped me to avoid the “blank page” and writer’s block was taboo. Yes, there were other tools that I used (more on them later) to improve our productivity, but a pending deadline was critical for us to write productively.
Try it: set yourself a real deadline, and then share it with someone you trust (or even g public with it). See if that makes a difference in your writing output.
Research (and Outline)
Writing a user guide or training manual, research was naturally critical. This is not fiction that we’re writing (even though research is needed in most fictional genres).
In technical writing, research is imperative because if the documentation is not complete and accurate, it will reflect badly on the company, in that the product cannot be used to its full potential.
You are no doubt familiar with those poor quality “user guides” that are completely vague, and contain bad English.
When a technical writer is working on a multi-million dollar project, there is no place for poor quality.
This aspect of technical writing helped me to be more meticulous with all my personal writing projects. Even though there wasn’t 100’s of thousands of dollars riding on my writing, it helped me pay attention to detail.
There was no writing of “quick short posts”.
With your writing, pay attention to detail, do your research, and don’t deliver an incomplete piece of writing. Don’t leave your with, “Oh, now what’s this writer actually saying in this blog post?” Or book, ebook – or whatever it is you’re writing.
Research thoroughly, and over-deliver with your writing. Your name depends on it.
There were very few (if any) projects that I worked on that didn’t have any planning. Albeit, sometimes it was basic planning. But, where there was zero planning it was usually a high-stress, late nights, project to work on.
Planning was essential because of the different elements that went into a technical writing project: research, availability of the product (physical or software), interviews with subject matter experts (SMEs), etc.
Imagine creating a multi-volume series of training manuals, and interviewing SME’s aver different time zones? It would be a nightmare without any project planning.
Even though my personal writing is not nearly as complex as some of the technical writing projects I worked on, I nevertheless adopted a planning system for my writing.
Let’s say you’re a blogger, your basic planning can comprise:
- Write outline [1 day]
- Source (or create) graphic images [1 day]
- Write draft (including research) [3 days]
- Edit draft (add source material as required) [1 day]
- Write final post [2 days]
- Publish post [2 hours]
- Promote [5 days]
Even a basic plan like this can help your writing project run a lot smoother than with zero plan.
For a book, the plan will naturally be more detailed.
It’s a fact that multitasking does not work. By following even a basic plan, your productivity can be improved several fold. Try it.
Technical writing projects were usually a multi-discipline exercise: writing, graphics, editing, testing, photography, etc.
With the project planning, the technical writers could see the whole picture. This way we knew what needed to be done, and when it needed to be done.
In my personal writing (books), this helped me in that I could identify what disciplines (tasks) were needed and which would take longer than others.
Using Brian Tracy’s “eat that frog”, it often helped if I made a start on the more difficult (or time consuming) task first. Or depending on what I’m writing, I will work on the harder parts early in the morning, and the easier parts later in the day, or at night.
Focus on the Reader (Humility)
In technical writing, the writer is 100% invisible. Every guide or manual is created totally for the benefit of the reader.
There is no place for ego in technical writing.
This kept me humble and focused with my personal writing. Even though with writing blog posts or books, the writer’s personality (or voice) can come through, it’s always a good idea to always focus on the needs of your reader. What will she get from reading your blog or book? Remember the adage of, “What’s in it for me?”
Pressure to meet a deadline, late nights, following up with developers, etc. Without perseverance and determination, it would not have been possible to finish a technical writing project.
As mentioned earlier, almost every technical writing project I worked on ran on very tight deadlines. And it was the nature of the beast to have things come out of left field (delays with software, SME’s not available to interview, etc.) In order to meet the deadline, we had to persevere and often push through late into the night.
Without perseverance, writing will be a nightmare. With discipline and planning, it becomes easier (not necessarily easy) to develop perseverance.
It is also valuable to know the reason you are writing. If your reason is trivial you will find it hard to write. But when your reason is based on a deep-rooted emotion, you will in all in all likelihood find your writing flows like a faucet gushing water.
Sense of Humor
I just had to add this one.
Although this has not directly helped me as an indie author, it really helped in my technical writing career, and has been useful with my freelance writing.
“Can you just write this quickly?”
“Give me your estimation of how long this will take to write.”
“Why isn’t that finished yet?”
Just some of the common things I’ve heard and been asked over the years.
Having a sense of humor with my personal writing has actually helped sometimes. Being able to laugh at yourself, and circumstances can help reduce stress.
This is more applicable in freelance writing, where you may hear similar comments from clients. Business 101 is if you have a difficult, or unreasonable client, fire them.
Life is too short to add unnecessary stress to our lives.
I hope these tips will help you with your writing.
Let me know in the comments below if any of these help you with your writing.