5 reasons technical writers should be pursuing side projects

Photo by Glenn Carstens-Peters on Unsplash

I had a job interview a while back where the company took issue that I pursue side writing projects. It got me thinking since it had been a while since I heard an objection to that facet of my professional career. It has been a part of my professional life for a long time and something I make sure to keep a wide separation from my day gig. So in the past, I’ve stayed away from projects that potentially put me in conflicts of interest or where the side project was working for a competitor of my employer at the time.

There is no better reason than seeking side projects than to have an alternative income stream to build up the war chest. There are also some more professional reasons for a technical writer to pursue freelance writing projects on the side including:

1. Keeps professional skills sharp

The definition and role of a technical writer in some organizations can go very stagnant. If a technical writer is pursuing their writing projects on the side, then their skills can remain sharp even as budgets and politics at their day job may shift them to a non-writing role. One of the worst things that can happen to a technical writer now in today’s tight economy is to let their skills go. It’s just too competitive out there.

2. Demonstrates passion for the craft of writing

Writers should be writing. Writers should be enjoying writing. Writers pursuing writing projects outside of their regular 9–5 shows passion for the work.

3. Offers a chance to learn new technology

My side freelance writing projects got me to think and write about technologies that I did not see during my day job. My entire experience writing about social media and mobile applications comes from side projects. I wouldn’t have the grounding in these subjects if it weren’t for the projects I pursue on the side.

4. Reinforces project and time management skills

To work on a part-time freelance project management the right way you have to treat it like any other project. The part-time nature and off-hours schedule make project and time management skills even more critical to the success of such projects.

5. Reinforces client management skills

It’s one thing to manage a client you see face to face every day but another to manage a client you work for part-time and virtually. Side freelance projects can help technical writers reinforce their client management and communications skills. There is the misperception in some circles that there has to be a lot of face-to-face interaction with clients but I hear to say that is not true because I’ve worked on some client projects where the client was located elsewhere, and I was working off hours. Success on the project meant I had to manage client expectations and communications to the degree that my part-time schedule was never an issue.

As long as an employee is avoiding conflicts of interest, not using company equipment, and delivering on their day job, then employers should see side projects as differentiators versus an issue. While some IT professionals pursue open source and volunteer projects (both worthy of merit), paid side projects should not be seen as a threat but another tool of professional development.

Do you pursue freelance projects on the side?

My name is Will Kelly. I’m a technical writer and content strategist living and working in the Washington, DC area. My current focus is thought leadership and technical marketing content. I got my start writing user guides, administrator documentation, online help, and later moved into SDLC documentation. My articles about enterprise mobility, BYOD, and other technology topics have been published by IBM Mobile Business Insights, Samsung Business Insights, TechBeacon, CNET TechRepublic, and others. Follow me on Twitter: @willkelly.

Things they don’t teach in technical writer school

Photo by Feliphe Schiarolli on Unsplash

I got my start as a technical writer before any formal technical writing degree programs got their start. While college gave me a solid foundation, much of what I know today, I learned by actually doing the work. Regardless of what professors say, there is no substitute for actually being out there and doing the job.

While it’s rare for me to work with junior technical writers anymore, I have had a lot of opportunities to collaborate with non-writers on documents. This got me thinking as to what I learned on the job versus what I learned in school. Understanding organizational dynamics and people skills were something I had to learn once I was out of college.

Here are some things they don’t teach (but should) in technical writer school:

Programmers are lazy (but in a good way)

If I had my way, I would work with programmers all the time because some of my absolute career highlights have been working directly with software development teams. They are lazy. But in a right way mind you. The way many of them reuse code and use shortcuts should be a model for the rest of us mainly technical writers.

Following on the “programmers are lazy” model, technical writers can also learn about program elements by studying similar items in the same program. While this is a simple concept to some people, I have come across some who never considered this angle. Understanding how programmers work including how they design and implement program features can help a technical writer immensely by shortening their learning curve on new projects and help them contribute more throughout the development process.

Microsoft Office doesn’t always work as advertised

As a technical writer, you may have to spend more time just getting Microsoft Office applications to work as advertised especially if you stumble onto a hokey implementation. This means that a fraction of Microsoft Office troubleshooting skills can help a technical writer shine especially if the help desk is more focused on closing Remedy tickets than actually resolving user problems.

Technical writers need a grasp of the concepts they write about

While a technical writer doesn’t need to be a technical expert, they do need to be able to learn new software and technical concepts to write their documents. If technical writers are dependent on drafts from SMEs to do their work, then they are not a writer. Organizations setting this as the status quo for their technical documentation need to reassess the role of technical writers in their development efforts.

Questions should be targeted not broad

Leading off with only broad questions is a waste of time. Question asking can be an art when you consider a technical writer may stumble into some project element that hasn’t been fully thought out by the rest of the team. Asking the right questions can help drive the documentation especially if the technical writer has a grasp of the technology underlying the project.

Artificial barriers to information are just an invitation

If an artificial barrier is put up between a technical writer and information, it should serve as an invitation for the technical writer to work around it. This means a technical writer needs some people skills, charm, and a talent for seeing the angles to work when faced with such a situation.

Meeting Minutes are for suckers

My views on meeting minutes in the workplace are well documented. Technical writers should never volunteer to take meeting minutes or see it as some “key to the inner sanctum.” Once programmers see a technical writer taking meeting minutes, then they automatically equate them with being a secretary. Not that there is anything wrong with being a secretary but a technical writer needs to sit at the same table as the programmers and not let themselves get minimized into what is traditionally a very nontechnical support role.

While I welcome formal technical writing programs to the fold, I’ve never really been very trusting of academia but hope these programs keep their feet in reality and don’t fill their students’ heads with nonsense that has no direct application in the real world of today.

What else do schools need to teach to prospective technical writers?

Hi! My name is Will Kelly. I’m a technical writer and analyst based in the Washington, DC area. I’ve worked with clients like NetApp, Dell, and Neustar to develop technical, training, and thought leadership content. My articles have been published by IBM Mobile Business Insights, TechBeacon, CNET TechRepublic, Toolbox.com, ZDNet.com, and others. Follow me on Twitter:@willkelly.