Tag: knowledge management

Why People Resist Writing Technical Documents

People do not avoid technical documentation simply because they dislike writing. They often resist because documentation exposes knowledge, risk, gaps, ownership, and accountability. This article explores the psychology behind that resistance and explains how technical authors and information managers can make knowledge sharing safer, easier, and more useful.

Tweet
Pin
Share
0 Shares

The psychology behind writing technical documents is not about writing. It is about identity, control, risk, confidence, workload, and trust.

Resistance to operational documentation stems from people’s awkwardness. They resist it because documentation exposes what they know, what they do not know, and how well their work holds up in writing.

Why are people reluctant to share knowledge?

1. Knowledge is power

In many organisations, people become valuable because they are the only person who knows how something works.

      • They know the system’s history.
      • the workaround.
      • which server talks to which database
      • “don’t touch that on a Friday” rule.

Writing that can feel like giving away their leverage. Documentation makes some people fear they will become less important.

That is rarely true, but the fear is real.

2. They fear being judged

When knowledge stays in someone’s head, others cannot challenge it. Once it is written, others can question it.

People may worry:

      • “What if I explain it badly?”
      • “What if someone spots a gap?”
      • “What if I have been doing it wrong?”
      • “What if this becomes evidence against me later?”

Technical documentation makes hidden practice visible. That can feel threatening.

3. Experts often do not know how much they know

A subject matter expert may say, “It’s obvious.”

It is obvious to them because they have years of context in their head. They forget what it was like not to know.

This is called the curse of knowledge. Experts skip steps, assume background understanding, and leave out dependencies because those things have become automatic to them.

That is why asking an expert to “write the process” often fails. They know the process too well to see where a new user will fall over.

4. They think writing is not their job

Engineers, analysts, developers, support staff, and project teams often see writing as admin. They may think:

“My job is to fix the thing, not write about the thing.”

This is where organisations go wrong. Documentation is not clerical work. It is part of operational control, support, continuity, audit readiness, training, and risk reduction.

The problem is that many organisations only value documentation after something breaks.

5. They have been burned before

Some people have contributed to documents in the past and seen nothing happen.

      • They gave information.
      • No one reviewed it.
      • No one published it.
      • The document disappeared into SharePoint.
      • Six months later, someone asked them the same questions again.

After that, they stop engaging.

Reluctance is sometimes not laziness but disappointment.

6. They do not trust how the information will be used

People may worry that documentation will be used to:

      • blame them after an incident
      • prove non-compliance
      • expose shortcuts
      • remove their ownership
      • offshore or automate their role
      • support a restructure

If the culture is punitive, people will protect themselves. They will give partial answers, vague explanations, or just enough information to appear cooperative.

7. Writing creates cognitive load

People underestimate how hard it is to explain work clearly.

Doing the task and explaining the task are different skills. A person may be excellent at resolving a complex system issue but poor at turning that knowledge into a structured procedure, support guide, recovery plan, or knowledge article.

They may not be unwilling. They may simply not know where to start.

What information managers and technical authors can do

The answer is not to keep saying, “Can you send me the process?”

That rarely works.

The better approach is to extract, shape, validate, and govern knowledge.

1. Stop asking people to “write the document”

Ask them to explain the work instead.

A technical author or information manager should make the task easier by saying:

“You do not need to write this. Talk me through what happens, what can go wrong, and who needs to know. I will structure it.”

This removes the pressure. The SME becomes the source of truth, not the person responsible for producing polished documentation.

2. Use structured interviews

Do not ask broad questions such as:

“How does the system work?”

Ask controlled questions:

      • What triggers this process?
      • Who owns it?
      • Who performs it?
      • What systems are involved?
      • What access is required?
      • What are the dependencies?
      • What happens if this step fails?
      • What evidence proves the task is complete?
      • What must never be done?
      • Who needs to be notified?
      • What is the escalation route?
      • What documents or records are produced?

Good documentation comes from good questioning.

3. Make knowledge sharing safe

People share more when they know the purpose.

Explain that documentation is not there to catch them out. It is there to protect the organisation and reduce repeated interruptions.

A useful message is:

“The aim is not to audit your memory. The aim is to stop the business depending on memory.”

That distinction matters.

4. Turn experts into reviewers, not writers

Most SMEs are better at reviewing than drafting.

A practical model is:

      1. Technical author interviews the SME.
      2. Technical author drafts the document.
      3. SME reviews for accuracy.
      4. Information manager checks structure, metadata, ownership, and control.
      5. Document owner approves.
      6. Document enters the review cycle.

This respects the SME’s knowledge without forcing them to become a writer.

5. Show people what poor documentation costs

People respond better when documentation is linked to real pain.

For example:

      • repeated support calls
      • failed handovers
      • slow onboarding
      • avoidable incidents
      • audit findings
      • change failures
      • disaster recovery confusion
      • project delays
      • dependency on one person
      • duplicated or contradictory processes

The argument should not be “we need documents.”
The argument should be “this is the risk we carry without them.”

6. Make contribution easy

Do not give SMEs a blank Word document.

Give them prompts, templates, checklists, diagrams, or short forms.

For example:

Instead of asking Ask this
Write the procedure. Give me the trigger, steps, exceptions, and escalation route.
Document the system. List the components, owners, dependencies, interfaces, and support contacts.
Update the knowledge base. Tell me what has changed, who it affects, and what users need to do differently.

People will contribute when the task is specific.

7. Use workshops, not email chains

Email is often a poor way to gather knowledge.

A short workshop can achieve more than three weeks of chasing. Put the right people in a room and map the process live.

Use:

      • process maps
      • whiteboards
      • dependency diagrams
      • RACI tables
      • system flow diagrams
      • incident timelines
      • “what happens if…” scenarios

The technical author captures the conversation and turns it into controlled documentation afterward.

8. Recognise the contributor

Knowledge sharing should carry status.

A simple contributor section, review credit, or acknowledgement can help. People are more likely to share knowledge when they feel their expertise is being recognised, not harvested.

The message should be:

“Your knowledge is important enough to become the organisation’s standard.”

That is a very different message from:

“We need you to fill in this template.”

9. Link documentation to governance

Information managers should make documentation part of normal business control.

That means every critical document needs:

      • an owner
      • version control
      • review date
      • approval route
      • classification
      • metadata
      • retention rules
      • change history
      • access control
      • review evidence

Without governance, knowledge sharing becomes a one-off exercise. With governance, it becomes part of how the organisation operates.

10. Use AI carefully

AI can help turn rough notes, transcripts, and SME interviews into a first draft. But it must not become a substitute for validation.

A good model is:

      • record or summarise the SME discussion
      • use AI to create a structured draft
      • technical author edits for clarity and usability
      • SME validates accuracy
      • document owner approves
      • information manager controls publication and review

AI helps with speed. It does not replace ownership, accuracy, context, or accountability.

The real role of the technical author

The technical author is not merely “the person who writes it down.”

A good technical author acts as:

      • interviewer
      • translator
      • editor
      • sceptic
      • user advocate
      • information architect
      • risk spotter
      • governance partner

They turn messy, partial, expert knowledge into something usable, controlled, and repeatable.

The information manager then ensures that the document does not decay into another forgotten file.

The key point

People are reluctant to share knowledge because knowledge is personal, political, and protective.

The answer is not to shame them into writing. The answer is to create a process where sharing knowledge feels safe, useful, recognised, and structured.

Technical authors and information managers should not ask, “Why won’t people write?”

They should ask:

“What is stopping people from sharing what they know, and how do we remove that friction?”

That is where documentation begins.

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.

The Quiet Expansion of the Technical Author Role

Many technical authors quietly move into project management and governance roles without the title ever changing. Experienced technical authors often coordinate work, manage risks, and design documentation strategies. Is the job title technical author holding the profession back?

Tweet
Pin
Share
0 Shares

Some months ago, I suggested that our job title does not support a technical author’s career progression as we take on additional tasks, such as project management.

It defines us as writers, even though many of us have quietly become something much broader.

My question:

How many technical authors have gradually taken on additional responsibilities without ever changing their job title?

And how many of us have done project management work simply because no one else understood how documentation actually works?

It happens more often than people realise.

Technical authors rarely stay confined to writing manuals.

Over time, most experienced technical authors develop deep knowledge of systems, processes, and operational environments. That knowledge naturally pulls them into wider roles.

Research shows that technical writing is often a springboard into roles such as project management, product management, quality assurance, and business analysis because writers accumulate extensive organisational and technical knowledge.

Many technical authors never formally move into new roles; we simply absorb extra responsibilities.

Documentation work is already project management

Much of what experienced technical authors do already overlaps with project management.

Senior documentation roles often include:

      • Prioritising work
      • Defining documentation strategy
      • Coordinating contributors
      • Managing review cycles
      • Reporting progress

These are recognised project-management responsibilities in documentation environments.

Many technical authors manage:

      • Documentation schedules
      • Review cycles
      • Deliverables
      • Risks
      • Dependencies
      • Stakeholders

Without ever being called project managers.

The skills overlap is not accidental

Project management research identifies core skills such as:

      • Communication
      • Organisation
      • Leadership
      • Technical understanding

These are the same skills technical authors use every day.

Technical authors succeed because they:

      • Interview subject matter experts
      • Coordinate contributors
      • Structure complex information
      • Track document progress
      • Identify gaps
      • Solve process problems

These are not purely writing activities.

They are delivery activities.

The reality on many projects

Project managers often understand delivery milestones but not documentation lifecycle requirements.

This creates a gap into which technical authors step.

Many of us have found ourselves responsible for:

      • Incident management documentation
      • Disaster recovery documentation
      • Operations manuals
      • ITIL-aligned processes
      • ISO 27001 documentation
      • ISO 9001 quality documentation
      • Data centre migration documentation
      • Knowledge repositories

Not because it was in the job description. Because someone had to do it.

The Unofficial Project Manager

It is not unusual for a technical author to become the unofficial project manager for documentation.

Technical writers may even move formally into project management or leadership roles, or manage documentation teams and projects as their careers progress.

But many never do.

The title stays the same.

The responsibilities expand.

When the project manager doesn’t understand the documentation

One common situation is where:

      • The project manager understands schedules and budgets
      • The technical author understands deliverables and structure

When documentation is poorly planned, the technical author often becomes the person who:

      • Defines what must be delivered
      • Structures the repository
      • Establishes review routes
      • Identifies missing inputs
      • Keeps documentation moving

Without that intervention, documentation often becomes chaotic.

The hidden expertise

Experienced technical authors often know far more than their job titles suggest.

Years of working across projects create knowledge in areas such as:

      • IT service management
      • Information governance
      • Document control
      • Audit preparation
      • Operational readiness
      • Knowledge management

This knowledge is rarely visible on an organisation chart.

But projects depend on it.

Know your Technical Author

Many organisations underestimate technical authors because of the title.

“Author” sounds narrow.

“Writer” sounds administrative.

The reality is usually very different.

Some technical authors have quietly been:

      • Documentation strategists
      • Information managers
      • Process designers
      • Governance specialists
      • Delivery coordinators

And sometimes project managers in everything but name.

The real question

So here is the real question:

How many technical authors have been doing project management work for years without being recognised for it?

And perhaps an even better question:

Is the title technical author no longer big enough to describe the role?

Don’t Overlook the Technical Author: A Question for Project Managers

Project managers often bring technical authors in too late. Experienced technical authors can reduce delivery risk by shaping documentation early—supporting IT audits, ITIL-aligned processes, ISO 27001/ISO 9001 controls, disaster recovery packs, incident and change management, and operations manuals. Know your technical author before you assume their limits.

Tweet
Pin
Share
0 Shares

Here is a question for project managers:

How many projects did you manage where the team treated the technical author as an afterthought or excluded them entirely?

It happens more often than it should. Project managers view documentation as something to “do at the end”, once the teams finish the proper work and the delivery pressure is at its peak.

That is when teams discover the cost of leaving documentation too late.

By the time the project is in closure mode, you have already missed the point where a technical author adds the most value.

The mistake: assuming the technical author is “just a writer”

Many project managers underestimate what an experienced technical author actually does. They think we:

      • only polish text,
      • rewrite technical material in plain English,
      • only fix formatting.

That is only one part of the job.

Technical authors understand IT operations and governance. They have documented services for years. This experience extends to audits. They know how to gather evidence.

What an experienced technical author may already know

A technical author may already have delivered documentation for:

      • IT audits and compliance preparation
      • Disaster recovery (DR) documentation
      • Operations manuals and runbooks
      • Incident, problem, and change management processes
      • Service transition documentation
      • Knowledge base and repository design
      • Information governance and document control
      • Data centre migration documentation
      • ITIL-aligned documentation structures
      • ISO 27001 and ISO 9001 aligned document frameworks

These are not theoretical skills. They come from being repeatedly embedded in delivery and operational environments across different organisations and clients.

The risk: documentation gaps that become delivery risks

When you exclude technical authors from early planning, projects often run into the same problems:

      • They discovered the documentation gaps late.
      • Missing operational detail that prevents handover
      • Inconsistent terminology and process steps
      • Rework caused by unclear ownership and review routes
      • Poorly structured repositories that no one can navigate
      • Evidence gaps that become audit risks
      • Last-minute “document sprints” that no one has time for

These issues are rarely “writing problems” but planning problems which are avoidable.

Know your technical author before you assume their limits

Every technical author has a unique history. Some come from engineering, some from software and infrastructure, some from compliance-heavy environments, and some from service operations.

You will not know what capabilities you have access to unless you ask.

Here is a simple, early-project habit that saves pain later:

Sit down with the technical author and establish what they’ve done before.

Ask questions like:

      • What types of projects have you supported?
      • What frameworks do you work with (ITIL, ISO 27001, ISO 9001)?
      • What operational documentation have you delivered (DR packs, ops manuals, runbooks)?
      • What documentation risks do you expect on a project like this?
      • What do you need from the team to avoid last-minute document chaos?
      • You may find they know more about documentation governance, operational readiness, and audit evidence than you expected.

Documentation is not an output. It is part of the delivery.

Documentation is not a box to tick at the end.

It is part of how projects:

      • reduce operational risk
      • pass audits
      • transfer knowledge
      • support teams
      • enable safe change
      • transition into BAU without firefighting

A technical author is not “just the person who writes things down”.

A strong technical author is often one of the few people on a project who thinks in terms of:

      • structure
      • lifecycle
      • traceability
      • usability
      • governance
      • evidence

Last point: never overlook the technical author

If you want better delivery outcomes, involve documentation earlier and treat it as a work stream with ownership and design—not a clean-up job.

Never overlook the technical writer.

Because the best technical authors are not just documenting your project.

They can make it work.

Have you ever consulted your technical author on previous deliverables to identify and reduce project risks?

Document Strategy vs Document Plan: Why Most Organisations Get It Wrong

Introduction

In the world of technical authoring and information management, people often use two terms interchangeably, but understanding your document strategy is key to approaching both effectively.

      1. Document strategy
      2. Document plan

They are not the same.

Confusing them is one of the main reasons documentation becomes reactive, inconsistent, and vulnerable to managerial interference.

If management treats documentation as administrative output rather than a governed asset, it will always sit at the whim of whoever speaks loudest.

This article explains:

      1. What a document strategy actually is
      2. What a document plan does
      3. Why governance matters?
      4. What must senior technical authors implement to protect documentation assets?

What is a document strategy?

A document strategy defines how documentation supports organisational objectives. It is not:

      • a list of deliverables.
      • a collection of templates.
      • a SharePoint structure.

It answers fundamental questions:

      • Why does documentation exist in this organisation?
      • What risk does it mitigate?
      • What decisions must it support?
      • What compliance obligations must it satisfy?
      • Who owns it?

In regulated environments, document strategy connects directly to standards such as

      • ISO 9001 (Control of Documented Information)
      • ISO/IEC 27001 (information security controls)
      • ITIL (service documentation and knowledge control)

If documentation is required for audit, certification, or regulatory compliance, you must govern it strategically.

What a proper document strategy includes

A credible document strategy defines:

1. Governance Model

      • Clear document ownership
      • Defined author vs reviewer vs approver roles
      • RACI alignment
      • Escalation routes

2. Lifecycle Control

      • Create → Review → Approve → Publish → Maintain → Retire
      • Mandatory review cycles
      • Version control standards
      • Archiving criteria

3. Classification and Security

      • Controlled vs uncontrolled documents
      • Public vs restricted
      • Security classification tiers

4. Architecture and Structure

      • Taxonomy
      • Metadata standards
      • Naming conventions
      • Document numbering schemas

5. Decision Framework

      • What qualifies as controlled documentation?
      • What does not?
      • When documentation is proportionate
      • When a knowledge article is sufficient

Without these elements, documentation becomes personality-driven rather than policy-driven.

What is a document plan?

A document plan is operational.

It applies the strategy to a specific project, programme or service.

Where strategy defines governance, the plan defines delivery.

It answers:

      • What documents are required?
      • Who is writing them?
      • When are they due?
      • What reviews are mandatory?
      • What approvals are needed?
      • How do they align with stage gates?

In complex programmes — such as digital transformation, DMS rollout, or security accreditation — a document plan ensures traceability and sequencing.

Without a document plan, documentation is:

      • Rushed at the end
      • Inconsistent across work streams
      • Duplicated across teams
      • Politically rewritten

Why Documentation Falls “at the whim of managers”

Documentation becomes unstable when:

      • There is no documentation policy
      • Templates are uncontrolled
      • Metadata is optional
      • No audit mechanism exists
      • No one owns lifecycle enforcement

In that vacuum, managers step in.

They introduce:

      • New templates
      • Personal preferences
      • Structural changes
      • Ad hoc requirements

The result is entropy.

Governance prevents that.

What technical authors must do beyond writing

Senior technical authors must move beyond content production.

They must act as:

      • Information architects
      • Governance stewards
      • Lifecycle controllers
      • Risk mitigators

Below are the controls that protect documentation assets.

1. Establish documentation governance

Create:

      • Documentation Policy
      • Document Control Procedure
      • RACI matrix
      • Change management workflow for templates

Ensure:

      • Template changes require approval
      • New document types require justification
      • eliminate uncontrolled versions

2. Enforce metadata and taxonomy

Metadata is not optional in mature environments.

Define mandatory fields such as:

      • Document Owner
      • Service Area
      • Security Classification
      • Review Date
      • Version Number

Implement enforcement within:

      • SharePoint libraries
      • Asite or DMS platforms
      • Controlled repositories

If you do not enforce metadata, the structure collapses.

3. Institute review discipline

Set:

      • Annual review cycles (minimum)
      • Risk-based review frequency
      • Automated reminders
      • Expiry flags

Outdated documentation creates audit exposure.

4. Run documentation audits

Introduction:

      • Quarterly sampling
      • Annual full audit
      • Traceability verification
      • Redundancy elimination

Without an audit, decay is inevitable.

5. Design templates that enforce structure

Most engineers and technicians do not read style guides.

They follow structure.

Well-designed templates:

      • Force styles
      • Control numbering
      • Embed guidance
      • Reduce formatting drift
      • Prevent structural inconsistency

Templates are governance tools disguised as formatting aids.

6. Define what not to document

Over-documentation creates noise.

A strong document strategy specifies:

      • What must you control?
      • What belongs in a knowledge base?
      • What remains in the service tools?
      • What is transient and disposable?
      • Clarity reduces clutter.

Document strategy maturity model

Organisations typically sit at one of these levels:

Level Description
Level 1 Ad hoc and personality-driven
Level 2 Template-based but uncontrolled
Level 3 Defined lifecycle and metadata
Level 4 Audited and measured
Level 5 Strategically aligned to risk and performance

Most organisations sit between Level 1 and Level 2.

A mature technical author moves them to Level 3 and beyond.

The critical distinction

      • Document Strategy = Governance + Risk Alignment + Structure
      • Document Plan = Delivery + Scheduling + Accountability
      • Ongoing Stewardship = Control + Audit + Discipline

Writing is only part of technical writing.

Control is the real work.

Final Thought

If A.N. Other can alter documentation at will, it is neither governed nor strategic.

And if it is not strategic, the user will not treat it as a corporate asset.

Why You Should Listen to Your Technical Author — Even When You Think You Know Better

Ever get the sense that when you speak as a technical author, people politely nod but don’t actually hear what you’re saying? If so, some wise documentation advice could enhance both the clarity and impact of your communication.

It’s not imagination. Proper guidance on documentation advice can counter this tendency.

This is a subtle bias, such as believing Bob is correct because of familiarity, even if he lacks tech doc knowledge.

In most organisations, people listen to familiar voices. They trust people they know well. However, when a technical writer gets involved, things change due to the rules, organisation, and clear communication they bring. Suddenly, everyone becomes an expert in “how to write.” This is where following the documentation advice becomes crucial.

The comfort of familiarity

Humans trust familiar things naturally. If a colleague has been around long enough, their opinions feel like facts. When a technical author points out that a process flow doesn’t align with the policy, or that a new template lacks metadata, the instinctive reaction is often:

“We’ve always done it this way.”

That’s the corporate equivalent of saying, “Don’t confuse me with logic.” Yet, sound advice regarding documentation can mitigate this.

But the technical author isn’t there to disrupt for the sake of it. They are there to create order, consistency, and the ability to track things, which helps avoid problems such as failed audits, redoing work, and project mix-ups.

The illusion of expertise

Documentation seems simple until it’s wrong. Then everyone notices.
Yet when a technical author raises a flag — about inconsistent titles, uncontrolled templates, or missing versioning — it’s often brushed aside. Why? Because others rely on their own facts, shaped by limited experience rather than informed standards.

A common refrain goes something like:

“I’ve written plenty of reports. How hard can it be?”

The problem is, it isn’t about writing. It’s about information architecture, compliance, usability, and lifecycle management. A technical author doesn’t just type; they engineer clarity according to effective documentation advice.

Bias in action

Here’s a real-world pattern you might recognise:

      1. You warn that storing final documents in personal drives will cause chaos later.
      2. It’s ignored.
      3. Months later, someone panics because no one can find the latest approved version.
      4. Suddenly, you’re called in to “fix” it — usually under time pressure.

When people rely on bias and familiarity rather than expertise, the organisation ends up paying twice:

      • once for ignoring the advice, and
      • for cleaning up the mess.

Why listening matters?

Listening to your technical author isn’t about deference — it’s about recognising value.
Your TA sits at the intersection of compliance, clarity, and communication. They understand how documents are consumed, how information flows, and how version control saves reputations. They spot inconsistencies before auditors do by relying on documentation advice.

In short, sound advice for documentation protects you from the chaos that happens when assumptions override process.

Closing thought

So next time your technical author speaks up, pause before deflecting with “We’ll handle it our way.”
The suggestion you’re brushing off could be the difference between passing an audit and receiving a formal corrective action.

In a world full of noise and opinions, the technical author’s voice is one of the few based on structure, clarity, and evidence. It’s not bias. It’s informed by sound documentation advice and expertise.

Beyond the Dash Debate: How AI Is Reshaping Writing and Technical Authoring Careers

Beyond the Dash Debate: How AI Is Reshaping Writing and Technical Authoring Careers

Writers and technical authors often debate AI’s punctuation quirks — from dash usage to tone. But while we’re arguing over commas, something larger is happening.
Artificial intelligence is not changing how we write; it’s changing why we write — and what value we bring when machines can generate text faster than we ever could.

The question isn’t whether GPT overuses em dashes.
It’s whether we’re ready to evolve beyond them.

1. From Author to Information Architect

AI can produce paragraphs in seconds, but it can’t design the logic behind them.
Tomorrow’s writers won’t just create content — they’ll become information architects who define structure, intent, and compliance.

In regulated environments such as the defence, nuclear, or financial sectors, AI still needs guidance on how to ensure documents comply with frameworks such as ISO 27001, ISO 9001, or PCI DSS.
Writers who understand these standards — and who can teach AI systems to follow them — will remain essential.

2. From Content Creation to Documentation Governance

The flood of AI-generated content means accuracy, version control, and authorship assurance have become critical.
This is where documentation governance takes centre stage.

Technical authors can pivot from writing to governing:

      1. Reviewing AI output for factual and procedural accuracy.
      2. Enforcing metadata and lifecycle rules within DMS tools like Asite or SharePoint.
      3. Building automated checklists and templates that ensure consistent document quality.

AI can draft — but humans must validate.

3. Human Interpretation Still Matters

AI can mimic tone and style, but it cannot sense how a message lands.
When a document must persuade, reassure, or instruct, context becomes everything.
Writers with empathy, domain understanding, and communication insight remain vital to bridging human and machine.

The technical author’s future lies in translation and interpretation: turning data into understanding, and ensuring meaning survives automation.

4. Ethics, Attribution, and AI Literacy

As organisations adopt AI-assisted documentation, they’ll face new ethical challenges:

      1. Who owns AI-generated content?
      2. How do we ensure traceability of information sources?
      3. How do we prevent bias and misinformation?

Writers and documentation specialists can lead the development of AI content policies, establishing governance frameworks and training programmes that uphold accuracy and transparency.

Becoming an AI-literate communicator is now as valuable as being a clear writer.

5. Adaptation, Not Extinction

AI doesn’t erase writing jobs — it redefines them.
Those who adapt will move from creators to curators, validators, and strategists.

Future-ready writers will:

      1. Design content architectures rather than just fill them.
      2. Develop governance systems that manage AI output.
      3. Train teams in writing assurance and ethical documentation.
      4. Blend communication, compliance, and creativity.

In short, they’ll stop being hands-on writers and start being writing strategists.

Conclusion: Evolving Beyond the Dash

So yes — debate GPT’s dash usage if you like.
But remember: punctuation debates won’t protect your profession.
Evolution will.

Writers who move toward governance, structure, and strategy will not just survive AI — they’ll define how it’s used.
The end of writing isn’t coming.
It’s simply the beginning of a new chapter.

Call to Action

If you’re a technical author or documentation manager looking to future-proof your role, start building skills in information architecture, AI literacy, and documentation governance.
Follow techwriting.co.uk for upcoming guides on adapting your documentation strategy in the AI era.

Why Isn’t Technical Authoring Taken as Seriously as Business Analysis?

Business analysis has established itself as a standard in structured career paths. Business analysts operate within a framework that includes certifications from BCS and IIBA, as well as a global knowledge base represented by the BABOK. They play a vital role in driving business success. However, why hasn’t technical authoring training kept pace with the discipline and received the same level of recognition?

Yes, there are training courses for technical authors—but for those of us with real-world experience, most courses offer little new. They often cover areas we’ve long since mastered: writing, using templates, and understanding basic tools. That leaves a pressing question:

Why hasn’t the technical writing profession grown to support mid- to senior-level authors with meaningful, strategic development?

The Perception Problem: Writers vs. Strategists

Part of the issue lies in perception. People often view technical writing as a “support function”—a downstream activity added after the “real” work is done. In contrast, business analysts work upstream, shaping project and product design.

Because of this, organisations rarely invest in upskilling technical writers beyond entry level. We receive tool-specific training, such as MadCap Flare, FrameMaker, and DITA, as well as refresher courses on grammar and plain English. Training in information strategy, content governance, and integrating documentation with Agile processes is essential, yet it is rare. These skills are vital for technical writers to excel in high-performing digital teams.

Why Experienced Technical Authors Avoid Most Training

As a senior technical author, I know training courses are available on the market, but I’ve yet to find any that add value to what I already know.

Here’s why most courses don’t appeal to experienced writers:

      • Too basic, they cover foundational topics like sentence clarity, structure, and Microsoft Word formatting.
      • Tool-led, not strategy-led: Courses focus on software, not how to use documentation to improve business outcomes.
      • One-size-fits-all: Most assume a junior audience, not someone managing document lifecycles or architecting knowledge bases.

This gap motivated me to independently pursue learning through peer networks, mentoring, and cross-disciplinary knowledge, often without formal recognition or support.

What Training for Technical Authors Should Look Like

If we’re to upskill and advance, we need training that goes beyond surface-level writing mechanics.

High-Value Topics for Mid-to-Senior Technical Authors:

Focus Area Why It Matters
Information Architecture & UX Writing Create usable, intuitive, and findable documentation across systems and platforms.
Agile/DevOps Documentation Integration Align with sprint cycles and release documentation iteratively.
Content Governance & Strategy Build scalable systems for content reuse, version control, and quality assurance.
Metadata and Taxonomy Design Essential for working in SharePoint, Asite, or any modern content repository.
API & Developer Docs More projects now require integration-level documentation and OpenAPI familiarity.
AI-Assisted Authoring learn  how to partner with, not be replaced by, content generation tools.
Accessibility and Inclusive Writing Meet compliance, usability, and ethical standards for broader audiences.

The Bigger Issue: Lack of a Unified Knowledge Base

Business analysts have the BABOK, project managers have PRINCE2 and PMBOK, and technical authors? We have fragmented resources, small communities, and ad hoc training.

There is currently no universally accepted body of knowledge that technical authors follow. No recognised framework exists that organisations can use to:

      • structure roles,
      • develop teams, or
      • plan career paths for technical writers.

Until we establish such a structure, we will continue to be seen as individual contributors rather than strategic enablers.

What Needs to Change

To elevate the profession of technical authoring, we need:

      • Advanced Masterclasses for experienced authors.
      • Courses that blend strategy, tech, and communication, not just software skills.
      • Advocacy from inside the profession—to influence HR, procurement, and leadership views.
      • Recognition of our roles in content strategy, product success, and compliance.

Final Word: It’s Time to Professionalise the Profession

Training for technical authors exists, but unless it reflects the real-world complexity of our roles, it won’t be worth our time or investment.

Technical authors are no longer just documenters—we’re architects of information. Our training, recognition, and role in organisations must reflect that.

Let’s continue the conversation

Have you taken a valuable course? Do you want to help shape better training for technical authors? Let’s talk.

Technical Writing | The Risks of Poor Document Management in Today’s Workplace

Poor document management is one of the hidden risks slowing down modern businesses. Lost files, outdated versions, and messy shared drives don’t just waste time—they undermine compliance, increase costs, and frustrate employees.

If you’ve ever panicked while searching for the “latest version” of a critical policy document before a big meeting, you’ve experienced the problem firsthand. Without a structured approach to the document lifecycle, companies quickly slide into chaos. The good news? With the right strategy—and the expertise of a skilled technical author—you can transform your documents into reliable, business-critical assets.

A Familiar Scenario

You’re sitting at your desk when your manager asks:

“Can you send me the latest version of our critical policy document? I need it now for a meeting.”

You search SharePoint. It’s not in the correct folder. A keyword search returns hundreds of results. You open several files only to find outdated versions. Panic sets in—your manager is calling again, already late for her meeting.

Most professionals have lived with this frustration. Documents still get lost. Outdated versions pile up, employees create their own file-naming systems, and critical knowledge gets buried. The truth is: traditional file storage is failing your business.

Why Poor Document Management is Costly

Failure to treat business documents as vital assets can lead to:

      • Diminished document utility – staff waste time searching or working with outdated files.
      • Decreased business efficiency – collaboration slows down when knowledge is hard to find.
      • Increased operational risk and cost – mistakes happen, compliance slips, and reputational damage follow.

These risks grow as document libraries expand without control.

Document Lifecycle Management: The Modern Approach

Effective document lifecycle management (DLM) ensures that every business document is valid, compliant, and accessible throughout its lifespan. This approach aligns with industry standards such as ISO 9001, ISO 27001, and ITIL frameworks, which increasingly demand traceability, version control, and accountability.

A modern document management process should cover:

      • Quick access – a centralised repository with search, tagging, and metadata.
      • Frequent review and updating – scheduled reviews to keep documents accurate.
      • Distribution – controlled sharing with the right stakeholders.
      • Conversion – ensuring compatibility across formats.
      • Archiving – moving obsolete versions into a secure archive.
      • Governance – applying version history, approvals, and sign-off processes.

The Role of Technical Authors in Document Management

In today’s workplace, technical authors are more than writers. They are custodians of clarity, consistency, and compliance. A good technical author:

      • Design document templates that meet ISO and ITIL requirements.
      • Establishes metadata fields for versioning, approvals, and document history.
      • Creates plain-English policies and procedures that employees actually use.
      • Trains staff on how to manage documents when no dedicated document controller is available.

By treating documentation as business-critical knowledge assets, technical authors help organisations stay compliant, agile, and productive.

Moving Forward

If your organisation’s document library is growing without control, now is the time to act. Consider investing in a Document Management System (DMS) such as Asite, SharePoint, or Confluence. Pair it with transparent governance and skilled technical authorship, and your documents will support—not hinder—your business.

Key Takeaway

Poor document management isn’t just an inconvenience—it’s a risk to business performance and compliance. By adopting structured document lifecycle management and empowering technical authors, organisations can ensure their knowledge assets remain accurate, accessible, and valuable.

Contact us to learn how we can transform your document management.