Below is a transcript of our podcast episode 34, called “How to assess a technical communicator when you’re recruiting”:
Welcome to the latest episode in the Cherryleaf podcast. My name is Ellis Pratt.
And today I’d like to talk about an event that’s coming up called “Build your docs career”, which is a one-day conference created by or sponsored by Pronovix and in partnership with the Government Digital Service, which is the UK arm that produces the Gov.UK website.
I’m going to be speaking at that event.
There’s only going to be 50 places available at the conference.
So I thought what I’d do is share what I’m going to talk about, in this podcast.
And also do a dry run, check that what I’m going to be saying makes sense.
So let’s talk about the conference.
I’ll give you the blurb from the website about what the topics are:
“Writing technical documentation is so much more than just writing. There is a wide variety of tools skills and experience required for different roles. And these requirements vary not just by job, but also change over time. As documentarians we often have to take responsibility for our own development and learning. At this day long conference organised in collaboration with the Government Digital Service, we will hear from those who have gained new skills and discuss how to manage and develop your career in documentation.”
My presentation is how to assess a good technical communicator from a bad one when you’re recruiting.
Without further ado, let’s listen to my rehearsal.
We’re going to look at how to assess a good technical communicator from a bad one when you’re recruiting.
And we’re going to look through a number of different things:
- the issues and challenges around recruiting a technical communicator
- the type of skills that they need for the role
- how you could measure their writing ability or assess the portfolio that they provide
- considerations of how you assess whether they would work with others in your team
- understanding their thinking process again related to the portfolio they might provide
Hello.
Let me introduce myself.
My name is Ellis Pratt.
I’m a director at Cherryleaf.
And Cherryleaf is a technical writing services company based in the UK.
Now in addition to writing documentation for clients, sometimes we’re asked to act like a specialist recruitment service as well and place permanent and contract technical communicators.
And technical communicators is the general term to describe people that might have a job title like Technical Author, or Technical Writer, or UX Writer, UI Writer, Instructional Designer, Information Developer… titles like that.
Let’s begin by looking at some of the challenges.
And issues around recruiting a person who’s doing that type of role, a technical communicator.
And one of the main challenges is that it doesn’t really fit with the standard model for recruiting IT staff.
In fact, there’s fewer than 5,000 technical communicators in the UK.
And in terms of IT jobs probably one or two in every 1,000 IT jobs advertised are for a technical communicator.
So many of the mainstream IT recruitment companies, the people that work there, doing their work, may not have ever filled a position like this before.
So they may struggle in having the understanding of what makes a good author, a bad author, and also in having the contacts and the people to approach.
And it gets also more difficult because there isn’t a common career path as to how people start as technical communicators in this country.
There isn’t an undergraduate course in technical communication, and there isn’t a currently a postgraduate course either.
And often it tends to be a second career; people start off doing one thing part of their role might be doing some instructional content, and they discover that there is this job where you can do that full-time.
You can do that exclusively as your activity, as your job role.
And equally, there’s no certification barrier.
There’s not a requirement to have a particular certification in order to be able to do the job.
And also it’s not always limited to whether you know one particular tool or not either, because a lot of the work requires having skills that you might describe the soft skills, which are harder to measure.
So the standard recruitment process that you often see where people, organizations and recruitment companies will automate part of the process can end up with it filtering out good candidates by mistake.
So you can have a process often where there’ll be words in a job description.
And then what people will do is use software to search for those words in candidates CVs.
Do they have skill X? Yes or no Do they know particular tool Y? Yes or no.
And filter based on that.
This can be problematic because often if somebody has skills in one tool it’s often very easy within the world of technical communication for them to pick up the skills in using another tool.
And that’s why specialist recruitment companies such as Cherryleaf are around, because they offer the ability to tap into their network, their network of contacts within the community of technical communicators.
It’s also because they tend to carry out the tasks of selection manually, by reading CVS, and inferring skills from the information on the CV that aren’t necessarily explicitly written down.
Now this isn’t the cheapest form of recruitment, because it’s not automated to the extent that you have with mainstream IT positions.
However, what it does lead to is you getting good candidates able to do the job.
And you are able to fill these roles arguably more quickly than having to wait for mainstream agencies who aren’t so familiar, don’t necessarily have the experience or the network to find these people quickly.
So I’ve said that the role is different, let’s look at that let’s look at why it’s different.
Let’s look at the type of skills that you need in the role of a technical communicator.
There are competency frameworks that have been developed,.
And if you look at them there aren’t quite a lot of competencies that they list for the role.
However, for the process of selecting a candidate, they may not be so useful.
They could be handy in terms of developing the job description, but in terms of selecting the right person, I’m not sure they necessarily help you go much further.
Instead, we recommend that you focus on these core skills.
We’ve done number of surveys over the years from people within the technical writing community, asking them about the important issues when they hire somebody.
And consistently these are the four skills that they look for, and they tend to be in this order:
They tend to be first and foremost writing skills.
Can somebody write well?
Secondly time management skills.
Can they deliver on time? Nobody wants a project to be held back because the documentation hasn’t been written to the deadline that’s been set, or nobody wants to issue a product and the documentation not to be ready, nad for that to come along at a later date.
So Number one, writing skills; Number two, time management skills.
Third and fourth sometimes swap around.
They can change around, but in this order.
The third is domain knowledge.
Do people have a familiarity with the subject that’s being discussed? Now often it doesn’t need to be a great deal of knowledge.
Often with software there’s a beginning and an end.
The process, or flow.
And it’s quite easy for a technical communicator to move from one product to the next.
But in some sectors, domain knowledge is important – in areas like API documentation it can be important to understand some of the issues around that.
Issues around medical equipment, mass spectroscopy and the like, having a basic understanding of the chemistry that’s going on, or within the City, and understanding of a trade and certain financial instruments are – that type of domain knowledge can be important.
And fourth is tools knowledge.
Does somebody know a particular authoring tool or a particular authoring standard?
Now often, if somebody knows one particular tool, then it wouldn’t take them too long to get familiar with another tool.
Because they both are essentially similar in the approaches they take of topic-based writing.
So knowing a specific tool might not necessarily be a deal-breaker in somebody joining your company and getting up to speed very quickly.
We’re seeing a fifth one emerge as well, which is UX skills.
Where content is becoming embedded more into the user interface.
And sometimes having skills and experience in user experience, user design, can be important.
But these are really the key skills to look for in your candidates.
It is possible to learn those skills.
One of the things that Cherryleaf offers is training courses in technical writing, technical communication.
And it’s also possible to train people in domain knowledge, get them up to speed with the terminology and the issues relating to your particular marketplace.
In fact it’s probably easier, or experience tends to show it’s easier, to take somebody who’s really good at writing and build up their technical domain, knowledge skills and technical skills, than the other way around.
Sometimes, it can be harder for technical people and developers to learn how to write clearly.
So if writing ability is so important, how can you measure somebody’s writing skills?
And it can be difficult if somebody gives you a sample of their work the portfolio.
And you’re looking at it for just a couple of minutes then your eyes are naturally attracted to what you might call the shiny stuff ,the visual impact, the visual images that are there.
And it may be harder to assess actually the quality of the writing, the information design, the flow of the information, the way in which has been written.
What we recommend is you use the same criteria that you would use if somebody was doing work within a team and you were giving it a quality check before it got published.
And one of the most common standards or criteria that people use within the technical publications or technical communication community or industry is to use a document quality criteria that was developed at IBM.
So the IBM quality criteria looks at a number of different factors:
Accuracy. Are there any mistakes in the steps that have been described?
Clarity. Can people understand it completely? Is there the right amount of detail. is there not too much and not too little?
Concreteness ,by which they mean, is there appropriate use of examples to try and explain things ? Terms that might not be familiar to somebody.
And organization. Is it arranged in an order that makes sense for users?
The other four factors, are:
Retrievability or findability. Can somebody find the information they’re looking for quickly in the document?
Style, which is about the tone and the appropriateness of the words they used. And this can relate to plain English or clear English.
And something called task orientation. Is it focused on people do, what they want to achieve, and getting on with their job?
And visual effectiveness. How attractive is it ? How well laid out? Issues around white space, colour, typography, icons, and those type of factors.
So there are nine elements within the IBM quality criteria.
Before you can assess some items. You can judge the CV by the criteria of:
Clarity. is it clear and easy to understand?
You can look at it from an information design perspective. Is it organized in a good way?
The style of the language. Have they used clear simple English?
And visual effectiveness. Have they used any graphical images? What font have they used? Have they used white space?
So you can use a CV to assess four of the key criteria.
So you can see if they’ve treated their CV as a user centred design problem.
Now another thing that people often bring along to interviews are writing samples, samples from where they were working before.
Now there are limitations often with technical communicators as to what they can provide, because often what they’re doing is confidential. They’ve signed NDA’s. Sometimes they struggle with that.
So it might be a sanitized work sample they give you, or something outside of the work they were doing. But if they do give you a writing sample, you can again use those measures that are provided in the quality criteria by IBM to assess that writing sample/
Now you can cover a lot of things because it’s a sample. You can judge it by clarity. Again you can judge it by concreteness. Have they used examples? Organization. How well it’s organized, how easy it is to find specific information. Retrievability that is. Style for words they’ve used. Task orientation. And visual effectiveness.
The ones that you may not be able to assess from a writing samples accuracy if you don’t have access to the product that they are talking about – you can’t judge whether what they’ve written is accurate or not.
So that’s one issue.
And completeness. Again, because you don’t have access to the product that they’re describing. You can’t tell whether it’s complete it gives you all the information that you need.
So this leads in many situations to companies asking candidates to do a writing test.
And through a writing test, it is possible to look at whether somebody can describe something accurately and completely. You can also assess clarity, organization, findability, style, and task orientation.
Because it’s a slightly artificial environment, they may not have time to do a representative job as they would in their place of work.
So sometimes it’s harder to assess how good they are at the visual effectiveness and image design aspects of things. Because often these are the things that can take quite a bit of time to put together.
When it comes to writing tests and all other types of tests you ask a candidate, if you ask them to do a timed writing test on the day, that can be unrepresentative. That can put undue pressure on somebody. It’s probably better to ask them to do a piece of work and give them a deadline of maybe five days or three days to do the work.
That means that it’s more representative of the type of time pressures they would have within the work.
It is unlikely that they’d be doing a piece of work with somebody sitting over their shoulder, expecting it to be done within a very short space of time.
Having said that, it is representative to ask somebody to do a proofreading or editing test within a timed environment.
Because often you might be asked to look at somebody else’s work and spot any mistakes at a very short moment in time short amount of notice.
And editing and proofreading tests are worth considering. It’s a way of checking if somebody is good at checking the accuracy of the wording that somebody has used; checking where they can spot when things are unclear or not.
And it can also, if you’re asking to edit and reorganize the information, check on their capability of organizing information focusing on tasks and making information easy to find.
So editing and proofreading tests are worth considering.
What we see from some clients is a different type of test.
And this one’s very good.
And that is to provide a link to a page of their existing help content and ask the candidates to suggest three improvements that could be made to that particular page.
And by doing this, it can help you understand how they think about the process of improving content.
The technical communicator role is one where you’re involved with interacting and engaging with other people.
So how a person the candidate might work with other people is important to assess it the role requires you to get on and do your work
But it also involves getting information from other subject matter experts and getting feedback from others on the word that you’ve done.
So in the interview process, what it’s also worth looking at is seeing how that person gets on with you. Do you develop a rapport with that person? Because they’re going to need that in their daily job. They’re going to need to be able to get on with people.
We’ve mentioned this already. And it’s also an important thing when looking at your recruitment process is – it’s good to understand how people created a piece of content to understand their thinking process.
And as a technical communicator, they need to be thinkers. They need to be curious by nature. They need to understand users, understand the audience. They need to be able to take information and condense it. Simplify it, synthesize it so that it’s easy for the users to understand.
And this means they often need to think about how they’ve done something could it be done in a better way to reflect on what they’re doing.
So asking people how did they identify the needs of the customer, and what content did they produce can help you assess their skills and capabilities.
And often asking them the reasons why they did things in certain ways.
Often documentation can be a compromised due to lack of time or resources.
So let’s summarize what we’ve covered.
What we’d recommend is that you focus on looking for people with good writing skills.
And good time management skills.
And also think about and ask yourself, could they work with others in your team? Because they’re going to need to interact with others to get information.
And don’t necessarily get too hung up over experience of particular tools. Because those can be learned quite quickly. They may have skills that can map across quite easily.
And also consider using a specialist recruitment agency like Cherryleaf. It may save you a lot of time and end up with you getting some very good candidates.
Would it help you if you had an interview pack for interviewing and selecting technical communicators?
By which I mean, a pack that gave you the writing tests and marking guidance, or perhaps even a way of having independent assessment of the answers that candidates provides? Things like a proofreading or editing test, or job description, or job competency framework, or advice on the questions to ask candidates. Would that help you in the process of selecting the right candidates? That’s something that we’re thinking of putting together for companies outside of those that use us as a recruitment agency.
If that is something that you’re interested in, and you’d like to be kept up to date with that then email us info@cherryleaf.com and let us know.
So finally thanks for listening.
Leave a Reply