Which of these would you hire to join your Technical Writing Dept? Someone with great writing skills but little technical knowledge or, for example, a Computer Science graduate with deep technical knowledge but average writing skills? We’ve been talking about this on LinkedIn and here are some thoughts.
Why Writing Skills Are More Important
- Technical writing is about writing. Words are the foundation upon which the rest is built.
- If you don’t have the writing skills, then regardless of how well you know the application, you can’t explain how it works.
- Your ability to drill down and describe complex functions may be beyond your grasp.
- To resolve this involves arranging sessions & workshops with developers, IT architects etc, all of which cost time/money.
- If writing skills were not necessary, programmers could write the user guides! Ever see a well-written user guide from a 22 year old Java developer? There are exceptions but…
- Technical writing is about communication. Technical writers are trained to interview people and extract the relevant information. Of course, listening skills are not exclusive to technical writers but many (that I know) feel they grasp the importance of this more than others.
- Writing skills give you the tools to communicate – and to help/teach others to communicate.
FYI – One of the trends I see in Tech Comms, is the changing role of the Technical Writer / Technical Communicator into an educator, facilitator, and becoming the central point of contact for technical information distribution (i.e. technical information coordination).
The counter argument is as follows.
Why Technical Skills Are More Important
- Technical knowledge is the starting point. You need to know how the system works, otherwise all the writing skills in the world may be of little use. If you don’t know what it actually does, what can you begin to write?
- Most ‘non-technical’ technical writers (e.g. graduates with English degrees) waste/take up developers’ time asking questions about how the application works, instead of actually generating content. While there is some leeway here with new technologies, developers have their own deadlines and can’t be expected stop coding to explain the innards to the application.
- Those with technical skills can hit the ground running – it’s the responsibility of the Technical Editor to refine the text.
- Those with technical skills know which questions to ask. As they understand the application/industry/codebase they can ask the hard questions that ‘non technical’ writers would not see in the first place.
Which would you hire?
If you were running a technical writing dept, which type of person would you hire?
A technical writer with strong technical skills, but prone to the occasional typo, or someone with perfect grammar, sound writing skills, but low on technical knowledge?
PS – you can connect with me on LinkedIn here – http://www.linkedin.com/in/ivanwalsh
In my experience, 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. (I may be biased, as I don't have any formal technical training beyond a “Physics-with-Chemistry” O-level some umpty-seven years ago!)
Of course there are exceptions to this, and I have met people who were both brilliant engineers and brilliant writers, but they are rare.
Good technical writers know that they need to research their topic well, and avoid the danger of being a “bother” to busy experts. On the other hand, a technical writer without a technical background is often more capable of understanding the product user's point-of-view than the engineer or software developer. This can be more valuable than understanding the minutiae of product design, as effective technical writing is all about giving your audience the information they need.
Hi David,
<effective technical writing is all about giving your audience the information they need.
That sums it up.
One of the issues we’ve encountered, for example, with developers in their lack of interest in the readership.
Sometimes this manifests itself in a certain type of arrogance, e.g. “let them find out what the API does…” rather than helping the reader to understand how it works. Many people resent having to write documents and this is reflected in the material.
I've found the if someone has an interest in sharing how the technology works, then they will go the extra mile and make sure the user really understand how it works.
They want to ‘look after the reader’ and make sure they have all the information they need.
It’s the writer’s attitude, really.
The tech writer with less technical knowledge is probably more like the reader than the engineer-as-writer is, which means the tech writer can place him/herself in the reader's shoes a lot easier. I can't begin to count all the times I've seen SMEs make assumptions about the user's knowledge. Even if an engineer is good with words, there's still the possibility that they won't be able to put themselves in the user's place.
Hi Bill,
<I can't begin to count all the times I've seen SMEs make assumptions about the user's knowledge.
The problem from SMEs is that they’re experts and see the world through their lens. Most I worked with resented having to write documents; they had better things to do and actually they have a point.
I try to do as much ‘prep’ work as possible. Later when I interview them (or send emails) I focus on the gaps where only they can offer some insight rather than making them wade through a list.
Of course, you can always play to people’s vanity – sometimes that’s the simplest and quickest way to get things done.
Things they don’t teach you at Harvard etc…
I am a non-technical – technical author with a degree in history and a minor in information design. Developers when writing a document prefer to explain the technical in, and outs. The end user is another world. Getting the tech bods to spend time with you is the hardest part of the job. Why? Because many do not want to explain how it works from the front. To them it is a simple process.
The question is how do you get around this problem?
In my case, I learn how to use the application and if I have a problem, I send my queries to SMEs, testers (generally the best people to ask in my experience), developers, and their boss. Therefore, if they don't respond I can always refer back to the boss.
Last year I had an interview with a Telco. They asked me to complete a task using their on line instructional content, which in their opinion were very well written and informative. The previous evening I had looked at that very content. The instructions were vague using terminology many people would not understand. When I pointed out that their instructions were “terminology dependent” and not geared towards end users (someone like me) my words were a slap in the face. Oddly enough, it took that company 10 months to find a suitable technically minded TA.
Hi Michael,
<In my case, I learn how to use the application and if I have a problem, I send my queries to SMEs, testers (generally the best people to ask in my experience), developers, and their boss.
One of the mistakes I made starting out was not knowing how to extract information and interview SMEs. These guys/girls have bigger fish to fry and their own deadlines.
Like you said, learning how the app works makes a real difference. You can ask more informed question and – small trick! – ask why they designed features, screens etc in such a way, i.e. to get a dialogue going. Then it’s easier to ask questions, i.e. look for attention.
I try to get them onside. It’s a bit like dealing with small children sometimes; sometimes it’s flattery, bribes, treats… whatever works.
<Last year I had an interview with a Telco. They asked me to complete a task. When I pointed out that their instructions were “terminology dependent” and not geared towards end users (someone like me) my words were a slap in the face.
I've been there.
At an interview with a chip designer in Sacramento many years back they showed me their docs.
‘Well, what do you think?’
I highlighted every fault I could find.
I thought that’s what they wanted.
In retrospect, I should have been more diplomatic and thrown in some compliments.
And going back to the 10 month job hunt. The role of HR is often to extend the recruitment process until they find the ‘ideal’ person. It’s often just a poor excuse to keep themselves busy.
If it takes them 10 months to find a technical writer…
Interesting argument! Unfortunately, each side often holds up poor examples of the other side to bolster its argument: Writers point to developers who can't spell; developers point to writers who are attached to their laps. That's beside the point since I'd expect all professionals to be able to spell and to know not to steal their colleagues' time.
I think the real issue is this: Which essential skill takes longer to master? Knowing how to structure and present information to users? Or knowing how to use a product or application?
In my limited experience, 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 definicies 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 essential skill takes longer to master? Knowing how to structure and present information to users? Or knowing how to use a product or application?
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.
And… I think there is more money if you have deep technical knowledge rather than strong writing skills.
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. Better writers than me weren’t even considered.
Something to think about, isn’t it?
Thanks for dropping by,
Ivan
I totally agree with your statement that a non-technical, Technical Writer spends more time questioning how the application or technology works. On the other hand, technically skilled guys can ask the right question and need less information.
However, the dissimilarity here comes up with the writing skills; I believe Developers or Engineers can do documentation by themselves. How good it would be is a different case.
So the so-called ‘Technical Writers’ should have good writing skills by default and a willingness to learn – an extra effort to quickly adapt to the technology and the project should help. This goes to the Technical Writers with less technical skills – learn technology and solutions that you need to work on, you are not in a training center, learn yourself.
The best solution is to hire a person with good writing skills and basic technical skills. The whole purpose of documentation should be to communicate the right information to the right audience in a very clear and precise manner. I strongly believe this could be possible only if one has good writing skills.
Nice! I guess all of you make a great point here. At the end of the day, doesn't it boils down to how well you know the audience you're writing for. No, frankly, if you aren't skilled to write for a particular audience, maybe you shouldn't take up the job in the first place. Making your resentment obvious is better than making a motley assortment of things! To further illustrate my point, how reasonable would it be to expect a non-technical person to write a documentation set for let's assume a new compilation tool that includes compilers, linkers, assemblers, simulators, emulators, and so on? I guess the issue is a tad deeper than what we're debating right now. Don't you think stakeholders should make their expectations clear to the hiring department(s) before they get someone aboard?
Don't you think stakeholders should make their expectations clear to the hiring department(s) before they get someone aboard?
Good question.
I've always found it odd that HR is so involved in the hiring process, eg sitting in on interivews and then stating 'well, I'm not very technical but I’m here to listen. I've always found it better when depts – all depts – do they own hiring.
They know what they’re after and can smell dodgy CVs a mile away. You don’t need HR for that.
Pingback: Gina Blednyh Interview: How Social Media Will Make You A Better Technical Writer | I Heart Technical Writing