Posted on 7 Comments

Who Makes More Money? Technical Writers with Language or IT Skills?


Kai raised an interesting point about which skill (writing or technical) takes longer to master.

Knowing how to structure and present information to users? Or knowing how to use a product or application? That got me thinking. If you want to make money as a technical writer, which area should you focus on?

Sharpen your writing skills or deepen your technical knowledge, for example, learning how to document an API?

Which Technical Writers Makes The Most Money

I think there is more money if you have deep technical knowledge rather than strong writing skills.

Kai’s point is, “…it’s always been easier and faster to learn a product/app. So knowing about structuring and presenting information has been the more valuable skill in a writer – and the rarer one, too, that’s much harder to learn from colleagues!

So I agree with David: “… it’s easier for a good non-technical writer with an interest in technology to become a good technical writer, than it is for a good engineer to become one.”

… and with Ivan, that writers can make up deficiencies with interest: “… if someone has an interest in sharing how the technology works, then they will go the extra mile…”

I think the real issue is this:  Which skill takes longer to master?

I have to admit, that’s a very good way of looking at it. I hadn’t actually thought of it in those terms.

  • My take is that it’s easier to develop language/writing skills… or at least to develop them to a level where you can perform your duties as a technical writer.
  • With technology it’s more complex as (at least for me) I’m always learning. Even in areas where I have considerable knowledge, I still find that I’m learning and finding better ways of doing things.
  • When I started out my writing skills were rather ‘unsophisticated’ and that’s being kind. But, I knew how to program (Cobol, C, Fortran) and landed some nice contracts as a results. Writers with much better qualifications weren’t even considered.

I think there is more money if you have deep technical knowledge rather than strong writing skills.

What do you think?

Posted on

Mistakes to Avoid when Evaluating Technical Content

How do you evaluate the quality of your documents in a way that’s impartial, accurate, and easy to implement?

Recently we looked at how to create scoring frameworks (usually in Excel) to evaluate and score technical documents.


From one angle, the scoring is the easy part. What’s more difficult is getting people onside.

Encouraging them to use the framework, score correctly, and most important not see it as a tool which will be used to show up their weaknesses.

That’s the usual reaction.

Mistakes to Avoid when Evaluating Technical Content

If I score low, will my position be threatened or my performance reviews be affected?Content

This is a valid question as ultimately writers will be assessed partly on how they score. However, it should only be one factor in their overall assessment. With that in mind, let’s look at how to implement a scoring system that gets accepted, improves quality, and can be scaled.

  • Give fair warning. No one likes to be caught unawares. So, let the writers know in advance that this is on the agenda and you and the team will be working on it in the coming weeks or months. This allows people to see what’s coming and prepare questions in advance.
  • State your intentions. Once the project starts, explain why you’re doing this. Is it because you’ve been told to (not my idea but…) or because you feel the team will learn and benefit from it. Explain why. Give examples.
  • Define the scope. Is everything going to be assessed? Probably not. Identify the scope of the project, ie what content will be evaluated first, for example, user guides, release notes, online or help, and use this as a baseline.
  • Start small. The first phase is really to get the wheels in motion and find where it can be improve. Don’t expect too much from the numbers. It’s also the phase where you try to get the scoring system embedded into day to day operations, so later it’s just another task to be completed.
  • Describe how it works. Walk the team through the process. Show them how scores are awarded, how (and why) weights are applied, and how this will be tracked over time. Why? It reduces fear of the unknowns and neutralizes some of the gossip and Chinese whispers.
  • Don’t work in isolation. Instead of developing this by yourself – and then trying to launch it by yourself – get others involved early. Look for writers who are keen to better themselves, want to learn more, and are interested in expanded their skillsets. These will usually have the drive, energy, and attitude to help you get the system up and running.
  • Dealing with naysayers. Expect resistance. There will always be team members who’ll try to undermine your position, find flaws in your plan (answer: so, how would you suggest we improve it?) and encourage others to do likewise. While this is to be expected, at least to some degree, you may need to talk to team members whose attitude is influencing the team negatively.
  • Explain consequences. Be honest. Scores reflect your performance at work. However, they should only reflect part of your overall performance. For that reason, clarify how this will affect writers, for example, as bonuses are often determined by performance reviews, and what may occur if writers are consistently getting low scores.


Your team is more likely to accept and use the new scoring system if they’re involved from the get go. Let them know why you feel this will help their careers and if they have suggestions on ways to judge the quality of the content.

Delegate tasks so everyone is involved to some degree, for example, creating templates in Excel, adding best practices to the wiki, and updating style guides if necessary.

Posted on 2 Comments

Do Technical Writing projects need a Documentation Plan?

Gordon McLean asks: do you plan to review your plan?

This is in relation to the Documentation Plan (aka Information Development Plan) that most technical writers prepare in advance of starting a major project. Granted, on smaller projects you can get away with this if you know the product, have the resources and the deliverables are nailed down.

But, his point is that the plan itself should be reviewed/updated during the project lifecycle. Or, at least, that’s how I read it. Continue reading Do Technical Writing projects need a Documentation Plan?