Hiring a Technical Author starts with understanding what you need the person to achieve. That might be reducing repeated support questions, documenting an API, clearing a backlog, or taking responsibility for documentation across several products.
The next step is finding someone who can investigate the subject, organise the information, and explain it clearly. A list of authoring tools on a CV will only tell you part of that story.
This guide explains how to define the role, choose between permanent and contract support, assess candidates, and give your new Technical Author the conditions they need to succeed.
Cherryleaf provides specialist Technical Author and Technical Writer recruitment. The advice here also helps employers running their own recruitment process.
How to hire a Technical Author
A typical recruitment process follows these steps:
- Define the documentation problem and the results you need.
- Decide whether you need a permanent employee, contractor, or managed documentation project.
- Separate essential skills from experience that someone can acquire.
- Set a realistic budget and describe the working arrangements.
- Review relevant writing samples and the decisions behind them.
- (Optional) Use a short, representative assessment.
- Ask structured interview questions and compare candidates against agreed criteria.
- Prepare access, reviewers, and priorities before the person starts.
Writing ability matters throughout. However, Technical Authors usually spend only 50% of their time writing. The rest of the time is spent on tasks such as information gathering, planning, information design, reviewing, and measuring. This means you also need to consider their technical understanding, time management skills, and the ability to get reliable information from other people.
What does a Technical Author do?
A Technical Author turns specialist knowledge into information that a defined audience can use.
The work involves finding out how something works, identifying what users need to know, checking the facts, and creating a structure that makes answers easy to find. It also involves keeping that information accurate as products and processes change.
Depending on the role, the outputs could include:
- User guides and online help.
- Installation, configuration, and administration instructions.
- API documentation, tutorials, and code examples.
- Maintenance procedures and engineering documentation.
- Internal procedures and knowledge-base articles.
- Release notes and troubleshooting guidance.
Technical Author and Technical Writer are commonly used as alternative job titles. Other titles include Information Developer and Documentation Specialist.
The responsibilities can differ between vacancies; positions with the same title can involve very different audiences, technical subjects, and levels of ownership.
Why recruiting a Technical Author is different
Technical communication is a small profession in the UK. We estimate there are approximately 4,500 Technical Authors and Technical Writers, although the variety of job titles makes an exact count difficult.
The pool for a particular vacancy becomes much smaller when you account for the number of them looking for a new job, their subject knowledge, location, salary, and availability.
There is no established UK degree route into the profession
There are currently no dedicated undergraduate or postgraduate degree programmes in technical communication offered by UK universities. Specialist training courses are available, such as those offered by Cherryleaf, and universities outside the UK offer relevant qualifications.
Employers therefore cannot rely on a regular intake of technical communication graduates. Candidates arrive through different educational and professional routes.
Technical communication is often a second career
A common route starts with someone taking on documentation as part of another job.
They might work in engineering, software development, support, testing, or training. They become the person who writes the instructions, explains a process, or improves the team’s guidance. They discover they enjoy the work and decide to become a full-time Technical Author.
Their first Technical Author position can follow several years in another profession.
In our experience, this gives people entering technical communication a broader age profile than employers might expect from entry-level IT recruitment. Someone starting their technical writing career can already have substantial experience of products, customers, and working with specialists.
Assess relevant experience across the whole career
When reviewing applications, look beyond the number of years someone has held the Technical Author title.
Ask what documentation they produced in previous roles, who used it, how they checked it, and what they learned from feedback. A support specialist who has written and maintained useful troubleshooting guidance already has relevant experience to discuss.
Career changers still need to demonstrate writing ability and learn the methods of the profession.
Recognise these different routes and examine the evidence each candidate brings.
Start with the problem the person needs to solve
Your job description should help candidates understand the audience, workload, priorities, and state of the existing material.
For example:
Our implementation team spends several hours each week explaining configuration steps to new customers. We need a Technical Author to create and maintain administrator guidance, starting with the tasks that generate the most questions.
That gives you a basis for discussing the work and assessing candidates.
Before advertising, establish:
- Who needs the information and what they are trying to do.
- What documentation exists, where it lives, and whether it is reliable.
- Which problems need attention first.
- Who holds the source knowledge.
- Who will check technical accuracy.
- Who will manage the person and resolve competing priorities.
- What improvement you expect to see.
Our article on why UK software companies hire technical writing specialists explains how documentation needs emerge around sales, customer onboarding, support, and product change.
Define success without counting pages
Some organisations fall into the trap of measuring quantity, forgetting to also measure quality. Creating lots of content isn’t useful if the documentation doesn’t help the readers.
Better starting points include whether a customer can complete a configuration task, whether installation instructions have been tested, or whether documentation is ready when a feature launches.
When establishing KPIs, choose measures the person can influence. If you want fewer support requests, give them access to support data and the people who understand those requests. Establish a baseline before expecting an improvement.
Choose between a permanent hire, contractor, and managed project
The right arrangement depends on the duration of the need and who will direct the work.
| Your situation | An approach to consider | What you need to provide |
| Products change continually and need someone to own their documentation | Permanent Technical Author | A continuing remit, management support, and access to product teams |
| A launch, backlog, migration, or period of absence creates a temporary need | Contract Technical Author | Clear priorities, available reviewers, and someone to manage the assignment |
| You need an agreed documentation outcome and want a supplier to organise delivery | Managed documentation project | Access to subject experts and someone authorised to agree scope and approve work |
A contractor can bring specialist experience and temporary capacity. You still need to make decisions, provide access, and review their work.
A permanent employee gives you continuing ownership and knowledge that develops over time.
A managed project suits an organisation that needs help planning and delivering the documentation as well as writing it.
Cherryleaf offers a managed project service, plus a recruitment service for placing contractors and permanent staff.
Be clear about which responsibility you are buying.
Decide what level of experience you need
Your first documentation hire will have to make decisions about scope, structure, priorities, and working methods. Allow for that when setting the seniority of the role.
An experienced Technical Author can establish an approach, identify missing information, and negotiate a workable review process.
A junior Technical Author needs someone who can review their writing, explain documentation decisions, and help them develop. Subject experts can check facts, but they are not automatically equipped to coach technical communication.
Hiring someone at the beginning of their career can work well when you have that support. Giving a junior employee sole responsibility for fixing a neglected documentation function is a different proposition.
Look for writing, delivery, technical understanding, and collaboration
Our free webinar on hiring a Technical Author recommends examining writing ability, time management, domain knowledge, and tools knowledge.
For your vacancy, turn those broad areas into observable evidence.
Writing and information design
Can the candidate explain an unfamiliar subject clearly? Do they organise information around the reader’s task? Can they distinguish a prerequisite from a step, and an explanation from a reference entry?
Look for evidence that they understand what the reader already knows and where additional explanation is needed.
Delivery and time management
Ask how they plan documentation work, handle delayed reviews, and decide what must be ready for a release. A strong answer explains dependencies and trade-offs.
Technical and domain understanding
The person needs enough understanding to ask useful questions and recognise when an explanation is incomplete or wrong.
The depth depends on the work. API documentation can require someone who can make requests, inspect responses, and test examples. Engineering or scientific documentation can require particular subject knowledge.
Review the level your role actually needs.
Tools and publishing workflows
Experience with your tools helps, particularly when the person must become productive quickly.
However, distinguish familiarity with one product from understanding the underlying method. Someone with experience of topic-based authoring, content reuse, and conditional publishing has relevant knowledge even if they have used a different application.
The same principle applies to version control and documentation platforms. Ask what they did with the tools.
Collaboration and investigation
Technical Authors need to obtain information from busy people, reconcile conflicting answers, and ask questions that expose missing steps.
Assess those behaviours directly. Interview confidence alone is a poor substitute for evidence of effective working relationships.
Add software and AI skills where the work needs them
Our October 2026 review of UK software vacancies found recurring requirements for Git, Markdown, APIs, code literacy, and documentation within product delivery. The review covered software roles only; the situation will differ in other sectors.
For a software role, useful evidence could include a documentation contribution made through a pull request, a tested API tutorial, or an explanation of how content was kept in step with releases.
For work involving AI-assisted documentation, ask how the candidate checks generated material. Can they identify unsupported claims, verify examples, and trace statements back to reliable sources?
If the role includes preparing content for an AI assistant, assess their approach to content ownership, structure, versioning, and maintenance.
Set a realistic salary or contract budget
Benchmark the work, seniority, and working arrangements together. Check comparable roles for subject knowledge, responsibility, location, and office attendance. You can contact Cherryleaf for information on the current market salary range.
Cherryleaf also publishes a monthly survey of UK Technical Author and Technical Writer recruitment activity. Be aware that a stronger or softer market does not establish how many candidates have the specific experience your role needs.
Write a job description that candidates can assess
Explain the work before listing the requirements.
Candidates need to understand what they will own, who they will work with, and what support will be available.
Publish the salary range and working arrangements so both sides can judge whether a conversation is worthwhile. We’ve found there is a considerable drop-off in enquiries when there is no salary range advertised.
Here is an example brief to adapt:
We are recruiting a Technical Author to create and maintain our customer-facing software documentation.
XYZ develops software for measuring widgets.
Your first priority will be to improve installation and administrator guidance for our main product. You will work with engineering, product management, and support to identify missing information, test procedures, and publish updates alongside releases.
We need evidence of clear technical writing, the ability to investigate unfamiliar software, and experience managing reviews and deadlines.
Our documentation uses Markdown and Git. Experience with this workflow is useful; we will also consider candidates who can demonstrate relevant publishing and version-control experience.
The role reports to our Head of Product. Product specialists will be available for technical reviews.
Add your actual salary, location, attendance requirements, employment terms, and selection process.
Divide requirements into essential and desirable. Each essential requirement should have a reason connected to the work.
Find candidates beyond an exact job title match
Search across relevant titles and examine what people have produced.
A candidate called an Information Developer might have exactly the experience you need. Someone called a Content Designer might specialise in a different kind of work.
Use recruitment channels that reach the relevant technical communication community. That could include direct advertising, professional networks, referrals, and a specialist recruitment agency, such as Cherryleaf.
A useful shortlist should explain why each person fits your brief.
Assess portfolios for usefulness
It can be difficult to accurately assess a portfolio, especially if you don’t have experience of technical communication. You’re unlikely to be able to test whether information is accurate or complete, as you probably don’t have access to the product it is describing. And an attractive sample can draw attention away from weak instructions.
Start with the reader’s task and work through the content.
Use a consistent set of questions:
| Criterion | What to examine |
| Accuracy | Can the instructions be verified against the product or source material? |
| Clarity | Can the intended reader understand the explanation? |
| Completeness | Are the necessary prerequisites, steps, and outcomes included? |
| Examples | Do examples help explain unfamiliar concepts or decisions? |
| Organisation | Does the sequence make sense for the task? |
| Findability | Can someone locate a particular answer? |
| Style | Is the language appropriate, direct, and consistent? |
| Task focus | Does the content help the reader achieve something? |
| Visual presentation | Do layout, diagrams, and screenshots support understanding? |
Ask candidates to explain their contribution. Was the structure theirs? Did they write the content, edit it, create the illustrations, or manage publication? Who else contributed?
Then discuss the decisions:
- Who was the intended reader?
- How did you identify what they needed?
- What did you leave out, and why?
- How did you check the content?
- What changed after review?
- What would you improve now?
These questions reveal the reasoning that is not obvious from just looking at the finished page.
Allow alternatives to confidential samples
Some candidates cannot share previous work because of confidentiality restrictions.
Offer alternatives such as an anonymised sample, a public contribution, a personal documentation project, or a short exercise using material you supply.
Respecting a previous employer’s confidentiality should not count against someone.
Use a short, representative writing assessment
A good assessment resembles the work and gives candidates enough information to complete it.
One option is to provide a short help article and ask for three improvements, with reasons. This reveals whether the candidate notices missing prerequisites, unclear sequencing, or assumptions about the reader.
Another is to provide a small fictional product brief and ask for instructions for one defined task.
For an API role, provide a working test environment and ask the candidate to document and verify a first successful request.
Set a reasonable expected effort, such as 45–60 minutes, and allow a submission window that accommodates existing work commitments. Keep the task small enough to respect that limit.
Tell candidates:
- Who the reader is and what they need to achieve.
- What source material they can rely on.
- What output you expect.
- How you will assess it.
- Whether AI tools are permitted and what use must be disclosed.
- How they can request adjustments to the assessment.
If you need substantial work, agree payment and usage terms in advance.
If AI tools are allowed, ask candidates to explain what they used and how they checked the result. Discuss their decisions afterwards.
Ask interview questions that reveal working methods
Use the same core questions for each candidate, with follow-up questions based on their examples.
| Question | Evidence to listen for |
| Tell us about a time the source information was incomplete. | Investigation, useful questions, and clear handling of uncertainty |
| How did you deal with conflicting answers from subject experts? | Verification and a way to reach an agreed answer |
| What did you do when a reviewer missed a deadline? | Planning, escalation, and an understanding of release priorities |
| How have you checked whether instructions work? | Product access, testing, and attention to prerequisites |
| Describe a documentation decision you changed after feedback. | Reasoning and willingness to revise |
| How did you decide what to document first? | User needs, business risk, and workable priorities |
| How would you start improving our documentation? | Sensible questions before committing to a solution |
Give candidates time to assess you, too.
Expect questions about product access, reviewer availability, reporting lines, documentation ownership, and the state of the backlog. Their questions can show that they understand what delivery depends on.
Compare candidates against an agreed scorecard
Agree the criteria before reviewing applications. Otherwise, the most recent interview or most polished presentation can dominate the decision.
The following is an example for a general software documentation role. Adjust it to your vacancy.
| Area | Example weighting |
| Writing and information design | 30% |
| Technical understanding and verification | 25% |
| Investigation and collaboration | 20% |
| Planning and delivery | 15% |
| Tools and publishing workflow | 10% |
Score each area from one to five and record the evidence behind the score.
You should still consider your essential requirements. If the person must test API examples, strong presentation skills cannot compensate for an inability to do that work.
Have assessors record their judgements before discussing candidates together. Where evidence is missing, identify the gap rather than filling it with an assumption.
Avoid common hiring mistakes
Several decisions can make an otherwise sensible recruitment process fail.
- Requiring every tool in your current system, which can exclude people with transferable experience.
- Treating a technical degree as proof that someone can explain a product clearly.
- Expecting the person to be an experienced programmer, QA tester, copywriter, and Technical Author, all in one. That’s called a unicorn, and they don’t exist.
- Expecting a junior employee to establish and run the whole documentation function.
- Assessing appearance without checking whether the content helps its reader.
- Giving candidates a large unpaid task.
- Hiring for a deadline without making reviewers available.
- Leaving salary, office attendance, or responsibilities unclear until the final interview.
Each creates avoidable uncertainty. Resolve it in the brief or assessment process.
Prepare for the person’s first 90 days
The appointment gives you capacity. Your organisation still needs to provide access, decisions, and technical review.
Before the start date, arrange access to the product, existing documentation, publishing tools, and relevant support information. Identify the people who can explain the subject and approve technical content.
For a permanent hire, a starting plan could be:
| Period | Useful focus |
| First 30 days | Understand users and products, review existing content, and agree priorities |
| Days 31–60 | Deliver an initial set of priority content and test the review process |
| Days 61–90 | Extend delivery, resolve ownership gaps, and agree an ongoing maintenance plan |
Adapt the plan to the assignment. A short contract needs a tighter schedule and an explicit handover.
Make documentation part of the product or operational workflow. Someone needs to tell the Technical Author when a feature changes, a procedure fails, or a recurring customer question appears.
Frequently asked questions
Is a Technical Author the same as a Technical Writer?
The titles are commonly used interchangeably. Assess the audience, subject, outputs, and responsibilities rather than assuming the title defines the work.
Does a Technical Author need to be a developer?
The necessary technical depth depends on the role. Developer documentation can require code literacy and the ability to test examples. Other roles need different subject expertise. Assess the tasks the person will perform.
Should we hire someone who knows our industry?
Make industry knowledge essential when it is necessary to work accurately within your timescale. Otherwise, examine whether the candidate has learned comparable subjects and how much support you can provide. There is an advantage to being a beginner, as they will have empathy with the new users of your product.
Can we hire someone without previous Technical Author experience?
Yes, if they demonstrate writing ability and learning potential, and you can provide suitable supervision. Assess relevant work from other roles, training, or personal projects.
How long does recruitment take?
The timescale depends on candidate availability, notice periods, budget, location, and how specialised the requirements are. Agree assessment dates and decision-makers before starting the search.
Can an agency send me the CVs of three candidates before they advertise the role?
Sometimes an agency already knows people who could be suitable. However, knowing someone’s background is different from knowing they are available, interested in your vacancy, and willing to have their CV submitted.
Before putting forward candidates, a specialist agency needs a clear brief. That includes the responsibilities, salary or day rate, working arrangements, and intended start date. It then needs to contact potential candidates and check whether the opportunity suits them.
An existing database can help start the search. However, it does not provide a ready-made shortlist for every vacancy.
At Cherryleaf, we review CVs and speak to suitable candidates before sending you their details. Advertising and approaching people through our network help us establish who fits your requirements and wants to be considered.
If you are still deciding whether to recruit, ask the agency for an assessment of the brief, likely candidate availability, and budget. That will be more useful than three CVs from people whose interest has not been checked.
Can AI replace the need for a Technical Author?
AI can assist with drafting and editing. Someone still needs to identify missing information, verify claims, test instructions, and take responsibility for what is published. Include those responsibilities when defining the role.
How Cherryleaf can help you hire
Cherryleaf is a UK technical communication specialist founded in 2002. We recruit permanent and contract Technical Authors, Technical Writers, and related documentation specialists.
Our recruitment service includes help defining the requirement, reviewing CVs, speaking to suitable candidates, and providing a focused shortlist. CVs receive human review by people who understand technical communication.
We also provide documentation, consulting, and training services. That gives us practical experience of the work you are recruiting someone to do.
We focus on permanent vacancies offering above-average salaries. We can also discuss contract support or a managed documentation project.
Contact Cherryleaf about your vacancy. Send your job description, or tell us what needs documenting, the audience, budget, working arrangements, and intended start date.
Free recorded webinar
A step-by-step guide to recruiting the right technical communicator for your team
In this free, on-demand webinar, Cherryleaf’s recruitment specialists walk you through every stage of the hiring process, so you can hire with confidence the first time.