Tag: technical author

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.

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?

When being Ignored teaches you everything

If your employer ignores you most of the time, then they turn their attention towards you, never in a way that helps. They expect you to mend years of neglect. They want you to perform miracles without context and then ask why you haven’t fixed it already. You explain — again — that you’ve asked for help, for guidance, for support, but were ignored because everyone else was “too busy.” That’s when you realise: they don’t want a technical author; they want a miracle worker. Demanding scenarios test the technical author’s resilience.

I’ve lived through that more times than I care to count. I’ve served under managers who were bullies. They took credit for my work and left me to take the blame when their own ideas fell apart. I’ve been sacked twice because I became the scapegoat for a junior manager eager to broaden his horizons without knowing how to do it the right way. Somehow, I managed to survive, demonstrating technical author resilience under pressure.

After the shock of those experiences, I tried to leave the profession altogether. But escape was impossible. Technical communication isn’t just a job you walk away from — it becomes part of how you think, how you analyse, how you explain. Still, the idea lingered: perhaps I could find a new path, somewhere I didn’t have to fight to be heard.

Being ignored forced me to grow and build my knowledge in

      • document control,
      • SharePoint,
      • metadata,
      • ISO standards, and
      • information management strategy.

Every new skill became a means of self-preservation and a step towards independence. My strength wasn’t just writing documents, but creating clarity in confusion. I turned chaos into structure. This growth marked a new level of resilience for me as a technical author.

Over the years, I’ve met many technical authors who perform communication miracles. Often introverted by nature, they bridge the gaps between.

      • development,
      • product management,
      • marketing, and
      • compliance.

They mediate conflicts, resolve ambiguities, and keep projects moving. They balance diplomacy and precision. Yet despite this, recognition remains elusive. Juggling all those pressures while being expected never to drop a ball is the unique burden of our profession. It truly tests our resilience.

When I look back, I can see how much those early challenges shaped me. The failures, the bullying, the long stretches of being overlooked — they all built resilience and empathy. They taught me how to read a room, how to listen, and how to pick my battles.

In later years, even as contracting became my refuge, the dream of escape began to fade.

Lone desk lamp symbolising resilience and focus in an overlooked workplace
Lone desk lamp symbolises resilience and focus in an overlooked workplace

Where would I go?

Who else would understand this strange blend of discipline, communication, and problem-solving?

This is where the resilience of a technical author comes in.

On more than one occasion, a recruitment agency shared something with me that has stuck in my mind:

“You’d make a great recruiter — you’re easy to talk to, confident, and you make even the most complex role sound exciting.”

Perhaps they were correct. During this time, I truly mastered translation—not just between systems and users, but also between individuals and possibilities.

My article appears after reading Dr Harald Schenda’s linked article. It resonated with me, and here is my response with his acknowledgement.

https://www.linkedin.com/posts/harald-schenda_technicalwriting-technicalcommunication-technischekommunikation-activity-7389332802388848640-01t8?utm_source=share&utm_medium=member_desktop&rcm=ACoAAADzAZwBkR4cshHQHZzdgski5orzlKnCer0

Technical Writing | What is technical writing and why you need it

What is Technical Writing?

Technical writing is a skill and should you hear a Project Manager or Subject Matter Expert say: ‘anyone can write so “why do you need a Technical Writer?” continue reading.

Technical Writing like many jobs has many facets. The fact you see Writer in the job title suggests to the uninitiated that primarily we write. You could not be more wrong! The writing takes only a fraction of the time allocated to the project.

Let’s get to the point

Our time is taken with analysing content and listening to Subject Matter Experts.

Our Writing is concise and to the point. We are not novelists describing a beautiful character down to her laughter lines. A poorly written novel will not hold the attention of a reader; the same goes for poorly written technical documentation. A user wants to read the document and understand say – the function of multiple servers and Operating systems within a significant infrastructure. Know how to follow a process or service within a few sentences. We can create a document from the viewpoint of the reader by listening to the user and offering document(s) based on the best solution.

Technical Writing is – as it explains in the box – technical. We speak to Subject Matter Experts and translate their language into content that a technophobe will understand.

We produce documentation in several formats in such a way, to get the message across to our many audiences. What I have written – you too will be an expert. Give yourself a hand.

Key elements of technical writing

Using a consistent language with regards to terminology.

Creating Glossaries to help readers understand the terminology used within the document.

Formatting document headers with the same font size and tables and drawings labelled the same way are important.

From using Excel spreadsheets, Template creation, document versioning, documentation content and types of material, clear document titles and subjects – working with either a shared drive or a document management system and talking to SMEs every day your average technical author is a ‘rare breed’ indeed.

If you have not already read my post titled “Technical Authors are not easy to find’ we do not attract many candidates.