5 tips for hiring technical writers

Photo by J. Kelly Brito on Unsplash

I’ve written about hiring technical writers two or three times in the past with some interesting results. In fact, my initial article garnered me some not very nice emails from technical writers. It’s a timeless topic, so I wanted to go back and see if any of my initial advice and thoughts have changed in light of today’s economy.

There are still a lot of contrasting viewpoints on the role and skills of the technical writer. The contrasting views can even be confusing to technical writers. This unnecessary confusion also leads to the fallout that affects the salary and career mobility of technical writers. But as a hiring manager, it gives you more room to craft a technical writer position that can be of most significant benefit to your organization.

Here are my tips for hiring a technical writer:

  1. Throw out preconceived notions about the role. Writing your job description for the position may seem like common sense but it means digging down and looking at where your technical documentation needs to go, the challenges getting there, and then when you get there how to maintain the documentation and ready it for the next step.
  2. Ask for what you want in a technical writer (and be prepared to it back it up). It’s one thing to write the technical writer job description that fits your organization’s needs and doesn’t create an additional drag coefficient on your development team and the project as a whole. Even in today’s economy be prepared to pay the freight to get a high-end technical writer. This might mean securing more budget and even cutting out third-party recruiters with their 40–65% markup on contractor’s hourly wages.
  3. Align the technical writer to your business. Academia and graduate degrees have polluted the waters of technical writing and other professions like instructional design. Graduate degrees are no substitute for real-life experience. Look for technical writers that have worked in your industry or a similar one.
  4. Decide on Contractor? Contract to Hire? FTE? My recent look at my local market shows that the majority of technical writer positions are now 3–6 month contracts. If you have budgets and project timelines to contend with then starting out with a contract technical writer might be the way to go for your organization. Look for an experienced technical writer who has a history of coming into new projects, learning the product, and documenting it in your industry or a similar one. Contract to hire is the way to go depending on your budget and is an opportunity to have a shakedown cruise with a technical writer especially if you’ve been burned by technical writers in the past and rethinking the future of technical writers in your organization.
  5. Look for evidence of technical curiosity. A good technical writer needs to be curious about technology. It’s not they need to be a programmer or engineer, but it’s the technical curiosity that drives them staying up to date with technology. There is an industry myth about “ignorance is an asset” that some lazy technical writers still try to push on people especially hiring managers new to bringing on technical writers. It’s not about “ignorance,” instead it’s curiosity that drives a technical writer to learn new technologies and figure stuff out. Technological ignorance in a technical writer will only cost you on the back end with an annoyed development team and lengthier document review and editing cycles.

Rolling your own technical writer job description and ignoring the confused nature of the technical writer role today is the only way to go.

How do you hire 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, Network World, Toolbox.com, ZDNet.com, and others. Follow me on Twitter:@willkelly.

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.