Month: March 2026

Why I Didn’t Pursue ISO 27001 or ITIL Certification as a Technical Author (And Why That Matters)

Do technical authors need ISO 27001 or ITIL certification? This article challenges the assumption, explaining why real-world experience often delivers more value than foundation-level qualifications—and when certification actually makes a difference.

Tweet
Pin
Share
0 Shares

Introduction

Over the years, interviewers have asked me the same question. One topic that often comes up is the debate between technical author vs certification, which frequently leads to interesting discussions about their respective merits.

“You’ve worked with ISO 27001, ITIL, GDPR, PCI… why didn’t you complete the certifications?”

On the surface, it looks like a gap. Technical Authors v Compliance.

It reflects a deliberate decision about where the role of a technical author begins—and where it should not drift.

The Assumption Behind Certification

Many organisations assume that working alongside standards such as:

      • ISO/IEC 27001
      • ITIL
      • GDPR
      • PCI DSS

naturally leads to certification.

Foundation becomes Practitioner.
Practitioner becomes Expert.

This progression makes sense for:

      • Information Security Managers
      • Service Delivery Leads
      • Compliance Officers

But it does not automatically apply to technical authors.

The Role of the Technical Author in Compliance

A technical author does not own the framework.

The role is to:

      • Translate requirements into structured documentation
      • Align content with controls and governance models
      • Ensure documentation supports audit evidence
      • Create a single, coherent source of truth

In simple terms:

The framework defines what must exist.
The technical author ensures it is documented, usable, and defensible.

What Experience Delivers That Certification Does Not

After working across multiple compliance-driven projects, patterns become clear:

      • Policies that do not reflect actual operations
      • Processes that lack sequence or ownership
      • Controls that exist conceptually but not in documentation
      • Repositories with no lifecycle, governance, or consistency

These are not theoretical problems.

They are the reasons organisations fail audits.

Understanding how to fix them comes from:

      • exposure to failed documentation environments
      • Rebuilding
        The compliant Technical Author
        The complaint technical author

        structures under pressure

      • aligning documentation to real-world operations

This is applied capability, not classroom knowledge.

The Certification Trade-Off

Certifications do provide value.

They:

      • Improve credibility with recruiters and procurement
      • Help pass automated CV filtering
      • Provide standardised terminology

However, they also introduce a shift in perception.

If I had progressed to practitioner level, there is a strong likelihood:

I would no longer be seen as a technical author.

Instead, I would be positioned as:

      • a compliance specialist
      • a governance lead
      • a service manager

That is a different role, with different expectations.

The Reality in Delivery Environments

There is an uncomfortable but consistent observation across projects:

Some certified professionals struggle to produce:

      • clear policies
      • usable processes
      • audit-ready documentation

Experienced technical authors often:

      • stabilise failing documentation environments
      • restructure repositories
      • enable organisations to pass audits

without holding formal certifications.

Knowing Enough to Deliver

There is a phrase that often needs clarification:

“I know enough.”

This does not imply limited understanding.

It means:

      • understanding the intent behind standards
      • knowing how to translate that intent into documentation
      • ensuring that documentation stands up to audit scrutiny

It also means recognising boundaries.

A technical author’s strength lies in application, not ownership.

When Certification Does Make Sense

There are situations where certification adds clear value:

      • Building a consultancy offering
      • Productising compliance services
      • Working in procurement-heavy environments
      • Increasing commercial positioning for senior roles

In these cases, certification supports:

      • trust
      • marketability
      • pricing leverage

Cost vs Return

Foundation certifications typically cost:

      • £500 to £1,500 per course

Covering multiple frameworks can exceed:

      • £3,000 to £4,500

For knowledge that often overlaps with existing experience.

The return is therefore not always proportional—particularly for experienced practitioners.

The Positioning That Matters

The distinction is important:

A certified professional understands the framework.
A technical author ensures the organisation can prove it is working.

These are complementary roles—but not the same role.

Conclusion

When asked why I did not pursue certifications, the answer remains consistent:

My value does not come from owning the framework.
It comes from making it work—through structured, controlled, audit-ready documentation.

In environments where documentation determines the success or failure of an audit, that distinction matters.

Write Less. Say More. The Technical Author’s Discipline.

Why fewer words are better and make reading technical reports easier and clearer.

Tweet
Pin
Share
0 Shares

As technical authors, we strive to remove friction and use fewer words, making instructions clear and concise.

We do:

      • Cut duplication.
      • remove padding.
      • Replace vagueness with precision;
      • Replacing lengthy explanations with fewer words is often our crucial task.

Much of what we read—reports, emails, procedures, specifications—still contains unnecessary words. Using fewer words consistently improves clarity.

Wordiness is not sophistication.
It is inefficiency. Fewer words deliver ideas faster and more effectively.

In regulated environments, long-winded language introduces ambiguity. In engineering environments, it slows down decisions. In operational settings, it creates risks. Eliminating excess leads to fewer words, helping to prevent misunderstandings.

Clarity is not about “dumbing down.”
It is about control. Using fewer words achieves better control over the message.

Below are examples of overworked sentences, followed by sharper alternatives that use fewer words.

Three words instead of one

Overworded: Sharper:
Due to the fact that the system was not operational at this point in time, we were unable to proceed with the implementation process. Because the system was down, we could not proceed.

 
Remove empty phrases
It should be noted that the team is currently in the process of reviewing the documentation. The team is reviewing the documentation.

 
Replace Word Clusters with a Single Word
At this moment in time Now
In the event that If
For the purpose of To
Make a decision Decide
Cut Passive Padding
A review of the policy was undertaken by the compliance team in order to ensure alignment with regulatory requirements. The compliance team reviewed the policy to ensure compliance with regulatory requirements.
Remove Redundant Qualifiers
The final outcome was completely unanimous among all stakeholders. The decision was unanimous.
Reduce Abstract Language
There is a requirement for the submission of documentation prior to commencement. Submit the documentation before starting.

Why This Matters?

Shorter sentences:

      • Reduce cognitive load

      • Improve comprehension

      • Reduce misinterpretation

      • Increase pace and authority

      • Improve audit traceability

In ISO-regulated environments, in defence documentation, in nuclear or PCI-controlled systems, excess wording creates ambiguity. Ambiguity creates risk. Choosing fewer words over length improves accuracy.

      • You do not need more words to sound credible.
        You need better ones. This is why fewer words often have a greater impact.
      • The discipline of a technical author is not just writing.
      • It is subtraction.

A Practical Rule

      • If you can remove a word without changing the meaning, remove it. Seek fewer words rather than more in each phrase.
      • If you can replace three words with one precise term, do it.
      • If a sentence runs over two lines, challenge it.

The strongest documents are rarely the longest ones. Indeed, fewer words often mean greater strength.

As technical authors, our job is not to impress.

It is to make meaning unavoidable.

Technical Authors: How Do You Manage Your Managers?

Technical authors often report to managers who have never worked with documentation as a professional discipline. Rather than confronting the problem directly, experienced authors learn how to manage the relationship quietly and effectively.

Tweet
Pin
Share
0 Shares

In many organisations, technical authors report to project managers who have never worked with documentation as a professional discipline. This creates unique challenges for technical authors managing managers who may lack an understanding of the documentation process.

These project managers usually come from backgrounds such as engineering, project management, product delivery, or operations. Documentation ends up in their remit almost by accident.

As a result, technical authors often find themselves in an unusual position. They must produce structured documentation while reporting to someone who may not fully understand what the work involves.

This creates an interesting professional challenge when working with managers as a technical author.

How do you manage your manager?

Experienced technical authors rarely confront the issue directly. Instead, they rely on quiet competence, structured thinking, and careful communication.

Over time, this approach usually reveals the value of the discipline.

The managers’ technical authors encounter

Technical authors encounter a few recurring types of managers. None of them is necessarily a bad person, but their backgrounds shape how they view documentation and the people who produce it.

The Accidental Documentation Manager

This is the most common type.

They typically come from:

      • Engineering
      • Project management
      • Product delivery
      • Operations

Documentation lands in their area of responsibility almost by accident.

Typical behaviours

They often:

      • believe documentation means writing things down
      • underestimate information architecture and audience analysis
      • Assume good writers can “pick it up”
      • Describe processes that technical authors already use

When they explain their approach to teams, they sometimes unknowingly outline activities such as

      • stakeholder interviews
      • requirements discovery
      • workflow analysis
      • validation of information

These are activities that experienced technical authors already perform.

What is really happening?

They are not dismissive on purpose. They have had no exposure to documentation as a professional discipline.

How experienced authors deal with them

Rather than challenging them directly, technical authors usually:

      • translate their work into risk reduction
      • explain how documentation supports operational clarity
      • demonstrate the thinking behind the documentation process
      • avoid academic terminology

Over time, this approach builds understanding.

The Credit Taker

This manager understands just enough to recognise that documentation has value, but not enough to practice it well.

Typical behaviours

They often:

      • present documentation ideas as management insights
      • Repackage documentation processes as their own improvements
      • explain methods that originated from the technical author’s work

For example, a manager may present a new approach to teams that is actually standard practice among technical communicators.

When a technical author calmly replies:

“That’s the same approach I use when meeting new clients.”

The origin of the idea becomes clear.

What is happening?

These managers often want to appear strategic or authoritative.

How experienced authors deal with them

The best response is usually calm and factual.

Experienced authors typically:

      • remain neutral
      • reference their work without confrontation
      • allow the evidence to speak for itself

Confrontation rarely improves the situation.

The Process Evangelist

Some managers believe strongly in management frameworks such as:

      • Agile
      • Lean
      • Six Sigma
      • ITIL
      • transformation programmes

They sometimes assume these frameworks replace the need for documentation expertise.

Typical behaviours

They often:

      • talk constantly about the process
      • Believing templates and tools solve documentation problems
      • underestimates the analysis required before writing begins

Ironically, technical authors are usually very strong process thinkers.

Understanding workflow, information flow, and validation cycles is central to the role.

Why do these situations occur so often?

Technical authors spend much of their time analysing how work actually happens inside organisations.

They:

      • interview stakeholders
      • Identify process gaps
      • document unclear responsibilities
      • structure operational knowledge

Because of this, technical authors often understand how organisations function more clearly than people realise.

This can occasionally expose gaps in management’s understanding.

When that happens, some managers may become defensive or minimise the role.

Most times, however, the issue is simple unfamiliarity with the discipline.

How Experienced Technical Authors Handle It

Rather than confronting the problem directly, experienced technical authors position their work carefully.

Translate the documentation into management language

Managers respond to outcomes such as:

      • risk reduction
      • delivery efficiency
      • operational clarity
      • knowledge capture

Instead of discussing:

      • information architecture
      • content strategy

It can be more effective to talk about:

      • reducing operational risk
      • improving onboarding
      • supporting project delivery

Make the Thinking Visible

Managers often assume documentation is simply writing because they only see the finished document.

Occasionally, showing the method can change that perception.

For example:

      • stakeholder questions
      • audience analysis
      • workflow diagrams
      • validation loops

This reframes documentation as structured analysis rather than typing.

Let Quiet Competence Do the Work

Sometimes the best response is calm professionalism.

When a technical author says:

“That’s the same process I use when meeting new clients.”

They achieve several things at once:

      • validate the process
      • demonstrate expertise
      • correct the misconception without embarrassment

This approach is often far more effective than arguing.

The Reality of Technical Authoring

Over time, many technical authors realise their role grows beyond writing.

They become:

      • documentation strategists
      • information architects
      • knowledge managers
      • repository designers
      • process analysts

Often this happens quietly.

Which is why many experienced technical authors eventually discover something interesting:

They are not really managing their managers.

They are managing the documentation environment.

And the managers gradually adapt to it.

How to Hire a Technical Author When You’ve Never Worked With One

Hiring a technical author can be challenging if you’ve never worked with one before. This guide explains how project managers and business leaders can evaluate technical authors, understand their skills, and determine whether they are the right fit for a project or organisation.

Tweet
Pin
Share
0 Shares

 

Many project managers and business leaders struggle when hiring a technical author. The difficulty comes from one simple problem: they have never worked with one before.

People often misunderstand technical authors. The title suggests someone who simply writes documents. In reality, the role is far broader. A good technical author analyses complex information, structures knowledge, designs documentation systems, and communicates with specialists across multiple disciplines.

Project managers, hire a technical author
Hiring a suitable Technical Author

Because of this, hiring a technical author requires a different approach from hiring other roles.

Understanding how to evaluate their skills is the first step.

Start by defining the problem you need to solve

Before reviewing candidates, organisations should clarify why they need a technical author. Project managers should do the same.

Different environments require very different documentation. For example:

      • Engineering projects may require procedures, safety documentation, and operational manuals.
      • IT environments may require knowledge bases, configuration guides, and migration documentation.
      • Regulated sectors often require policies, audit evidence, and controlled documentation.
      • Infrastructure programmes may need large volumes of technical documentation to support operations.

Hiring mistakes often occur when organisations advertise for a “technical writer” without defining the real requirement.

A clear job description should include:

      • Types of documentation required
      • Stakeholders involved
      • Documentation systems used
      • Level of governance required
      • Whether the role is strategic or operational

Once this is clear, evaluating candidates becomes much easier.

Evaluate how the candidate approaches information

The strongest technical authors show structured thinking.

Writing is only one part of the job. Most of the work happens before we write the first sentence.

The cost of Technical and Process documentation
The cost of Technical and Process documentation

During interviews, ask candidates how they would approach documenting a system they know nothing about.

Sound answers usually include:

      • discovery interviews with subject matter experts
      • audience analysis
      • document hierarchy and structure
      • information mapping
      • controlled templates
      • review and approval workflows

Candidates who focus only on writing skills may lack experience managing complex documentation environments.

Ask about real documentation environments

Writing samples alone rarely reveal the full picture.

Many technical authors work in regulated industries where documents are available internally only.

Instead of focusing only on samples, ask candidates to explain previous projects.

For example:

      • What documentation problem were they solving?
      • Who were the stakeholders?
      • How did they gather information?
      • How did they structure the documentation?

These answers often reveal far more about their experience than a writing sample.

Assess Communication Skills

Technical authors operate between different professional groups. They may work with engineers, project managers, operations teams, and senior leadership.

The role requires strong communication skills.

Candidates should be able to explain complex ideas clearly and confidently and show experience interviewing subject-matter experts and translating technical information into structured documentation.

A simple test is to observe how clearly they explain their previous work during the interview.

Test their ability to structure information

A practical exercise can reveal how a technical author thinks.

Provide a short set of disorganised notes and ask the candidate how they would structure them into documentation.

You are not looking for perfect writing. Instead, look for evidence that the candidate can organise information logically.

Strong candidates often talk about:

      • document hierarchy
      • workflow structure
      • templates
      • navigation and indexing
      • diagrams or process flows

This shows their ability to design usable documentation.

Check their experience with documentation systems

Modern documentation environments rarely consist of simple folders.

Technical authors often work with systems such as:

      • SharePoint
      • Confluence
      • Asite
      • document management systems
      • knowledge repositories

Ask candidates how they manage document repositories and maintain document integrity.

Experienced authors usually discuss:

      • metadata
      • taxonomy
      • version control
      • document lifecycle management
      • review workflows

These are essential skills for maintaining controlled documentation.

Look for Governance Awareness

The cost of Technical and Process documentation
The cost of Technical and Process documentation

In many industries, documentation supports compliance requirements.

Technical authors often work within frameworks such as:

      • ISO 9001
      • ISO 27001
      • IT service management frameworks
      • internal quality systems

Candidates should understand how documentation supports governance and audit readiness.

This demonstrates that they view documentation as a controlled information asset rather than simply a collection of files.

Contract Roles vs. Permanent Roles

Organisations often hire technical authors in two different ways.

Contract roles focus on projects. They often support system migrations, major programmes, or documentation backlogs.

Permanent roles focus more on long-term governance, knowledge management, and documentation standards.

Understanding the difference helps determine what type of experience is required.

Final Thoughts

Hiring a technical author can be challenging if you have never worked with one before. The key is to focus on how candidates think about information rather than simply evaluating their writing style.

The most effective technical authors combine several skills:

      • structured thinking
      • strong communication
      • documentation governance
      • knowledge management

When these skills are present, documentation becomes more than a collection of files. It becomes a managed knowledge asset that supports projects, operations, and long-term organisational memory.

If you would like help to build or improve your organisation’s documentation environment, visit techwriting.co.uk to learn more about technical authoring and information management services.