Category: Document strategy

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.

Why Technical Authors are disappearing from IT Projects

Technical authors are vanishing from many IT projects.

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

Not because documentation is no longer needed.

But because organisations convinced themselves that:

      • Agile removed the need for documentation
      • SMEs could “just write it”
      • Developers could document as they build
      • Wikis replaced structured information management
      • AI can now generate everything automatically

The result?

Documentation did not disappear. Ownership disappeared.

The Agile Misinterpretation

IT misunderstood Agile, believing it meant:

Less documentation.

What Agile challenged was:

      • Excessive bureaucracy
      • Huge unused specification sets
      • Documentation written for sign-off instead of operational value

But somewhere along the line, many organisations translated this into:

We no longer need technical authors.

So documentation responsibilities were fragmented across:

      • Developers
      • Business analysts
      • Product owners
      • Service managers
      • Support teams

Everyone became partially responsible.

Which usually means nobody became fully accountable.

IT Projects Still Produce Complexity

Modern IT environments are not simpler but more complex than they were 20 years ago.

Today’s projects involve:

      • Cloud platforms
      • APIs
      • Identity management
      • Cybersecurity controls
      • SaaS integrations
      • DevOps pipelines
      • Automation
      • Data governance
      • Compliance obligations
      • Hybrid infrastructure
      • AI systems

Yet many projects still assume documentation can “emerge naturally.”

What usually emerges is:

      • Scattered Confluence pages
      • Outdated SharePoint libraries
      • Tribal knowledge
      • Slack conversations acting as operational memory
      • Contradictory procedures
      • Uncontrolled revisions

Eventually, operational support inherits the chaos.

The “SMEs Will Write It” Fantasy

Subject Matter Experts are essential.

But SMEs are not usually:

      • Information architects
      • Editors
      • Audience analysts
      • Metadata specialists
      • Structured writing professionals
      • Governance specialists

Most SMEs focus on:

      • Delivering systems
      • Solving technical problems
      • Meeting deadlines

Documentation becomes secondary.

Postponed until the last phase of a project — when schedules collapse, and budgets tighten.

That is where technical authors historically added value:

      • Extracting knowledge
      • Structuring information
      • Standardising terminology
      • Identifying gaps
      • Challenging ambiguity
      • Creating usable operational guidance

Without that role, knowledge quality declines rapidly.

Documentation became Invisible Work.

In many IT organisations, documentation is now treated as:

      • Administrative overhead
      • Non-billable effort
      • A project afterthought
      • Something AI can “tidy up later”

Yet the same organisations later struggle with:

      • Failed handovers
      • Poor onboarding
      • Repeated incidents
      • Knowledge loss
      • Service desk dependency
      • Operational inconsistency
      • Audit failures

Because undocumented systems create operational drag.

The irony is simple:
The more complex IT becomes, the more valuable structured information becomes.

AI is speeding up the illusion

AI has amplified the belief that technical writing is “generating text.”

But experienced technical authors are not typists.

They managed:

      • Information quality
      • Knowledge structures
      • Content governance
      • Audience interpretation
      • Process consistency
      • Lifecycle control
      • Information retrieval
      • Operational usability

While AI can produce drafts quickly, it does not inherently:

      • Understand organisational risk
      • Detect conflicting operational procedures
      • Validate technical accuracy
      • Govern document lifecycles
      • Manage controlled information environments

Many times, AI speeds up the production of unmanaged content.

The Hidden Shift

Interestingly, technical authors have not entirely disappeared. We have changed titles:

Across IT projects, former technical authors now operate as:

      • Information managers
      • Knowledge managers
      • Content strategists
      • Service transition analysts
      • Governance specialists
      • Digital adoption consultants
      • Documentation engineers
      • Information architects

The writing component became only one part of a broader information role.

The Long-Term Risk

IT projects can survive in the short term without dedicated technical authors.

Until:

      • Key staff leave
      • Systems fail
      • Audits occur
      • Services scale
      • Migrations happen
      • Security incidents arise
      • Regulatory scrutiny increases

Then organisations rediscover the same truth:

      • Operational resilience depends on reliable information.
      • And reliable information rarely happens accidentally.
      • The disappearance of technical authors from IT projects may save money on a spreadsheet.
      • But over time, many organisations discover that they have not removed the need for technical authors.
      • They merely removed the people responsible for keeping organisational knowledge usable.

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.

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?