Tag: documentation 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.

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?

Is Your Job Title Holding You Back as a Technical Author?

Technical authors often sit at the centre of multiple content and information disciplines. This visual shows how closely our work aligns with roles such as Content Designer, UX Writer, Information Manager, and Documentation Strategist. Many of these job titles describe work that experienced technical authors already perform daily—metadata design, information architecture, content strategy, documentation governance, and user-focused writing.
The overlap raises an important question for our profession: is the title “Technical Author” reflecting the full scope of what we do, or is it quietly holding us back?

Tweet
Pin
Share
0 Shares

Is the Technical Author Job Title Limiting Your Career?

tecnical cross over

Here’s a hard truth. Most experienced technical authors acknowledge that there is only so far you can go while keeping the technical author job title.

I contracted for a variety of reasons: exposure and opportunities that permanent roles rarely offer. But after 18 years, another realisation emerges:

The job title itself can become a barrier.

The work is not limited; rather, the perception of our title is.

When Your Title No Longer Matches Your Skills

After years in the field, you notice something interesting:

People with far more impressive job titles are performing tasks you’ve been doing for years:

      • Information Managers
      • Content Designers / Content Strategists
      • Documentation Project Manager
      • Knowledge Managers
      • UX Writers
      • Content Operations Leads
      • Information Architects

And you wonder:

What are they doing that I haven’t done?
What specialism do they possess that a seasoned technical author doesn’t?

More often than not, the answer is:
very little. Sometimes, nothing at all.

Technical authors often perform similar tasks, using diverse labels.

The Hidden Skill Set of an Experienced Technical Author

Most technical authors—especially those with 10, 15, or 20+ years’ experience—already operate far beyond “writing user guides.”

They work across.

      • Information Structure & Strategy
      • Information architecture
      • Metadata and taxonomy design
      • Naming conventions and file governance
      • Knowledge base design
      • Documentation life cycle models
      • SharePoint, Confluence, and DMS structuring

Process Writing & Compliance

      • ISO 27001 documentation
      • ITIL-aligned processes (incident, change, problem)
      • GDPR, PCI/DSS, risk and policy frameworks
      • Governance workflows

Digital Content & UX

      • Content design
      • User journey mapping
      • Plain English and accessibility
      • User research and SME interviews

Project & Stakeholder Management

      • Documentation strategy
      • Template development and automation
      • Editorial oversight
      • Managing SMEs, engineers, and senior stakeholders

These are not junior writing tasks—this is information management and content strategy in practice.

Yet the title “Technical Author” hides this complexity.

Why Other Job Titles Are Perceived Differently

The difference is rarely in capability.
It’s framing, branding, and expectation.

      • A Content Designer suggests UX alignment.
      • A Knowledge Manager suggests ownership of information ecosystems.
      • A Documentation Manager suggests governance, leadership, and structure.
      • An Information Architect suggests digital systems thinking.
      • A Documentation Strategist suggests planning, analysis, and long-term direction.

The work may be the same, but the title expands your perceived value.

Meanwhile, “Technical Author” still signals one thing to many people:

“The person who formats documents and writes instructions.”

Nothing could be further from the truth—but titles shape perception.

When Your Title Becomes a Career Constraint

After a long time in the role, many technical authors reach a point where:

      • They manage information, not just documents.
      • They build documentation ecosystems, not just templates.
      • They lead strategy, not just writing.
      • They’re treated as senior contributors, but their titles don’t reflect that.

This mismatch can stop progression into:

      • leadership roles
      • consulting opportunities
      • digital content positions
      • information governance roles
      • strategic documentation work
      • higher-pay permanent posts
      • In many organisations, everything hinges on the title.

So should you change your job title?

Yes — but do it strategically.

Choose a title that reflects the true scope of your knowledge:

      • Documentation Strategist
      • Information Manager
      • Knowledge Manager
      • Content Architect
      • Technical Content Lead
      • Documentation Programme Manager
      • Content Operations Lead
      • Information Architect

These titles communicate your role extends beyond writing into:

      • structure
      • governance
      • strategy
      • lifecycle management
      • digital ecosystems
      • content design
      • compliance
      • tooling
      • information flow
      • Exactly the things you already do.

A Final Question for Fellow Technical Authors

Before you update your CV, LinkedIn, or next job application, ask yourself:

      • Is your current job title helping you progress — or holding you back?
      • And if it’s the latter, what title reflects the work you already do?

Process, Procedure, Work Instruction, Plan, Strategy and Standards — Know the Difference

Clear documentation depends on understanding the difference between processes, procedures, work instructions, plans, strategies and standards. This article explains how each fits into a structured documentation framework.

Tweet
Pin1
Share
1 Shares

Many organisations use the terms process, procedure, work instruction, plan, and strategy interchangeably. They are not the same. This article explains the key points to help clarify these differences.

Confusion between these terms leads to poor documentation, unclear responsibilities, and inconsistent delivery.

If you work in technical authoring, information management, or governance, understanding the difference is essential.

A good documentation framework clearly separates these elements and ensures people know what they must do and why.

What is a process?

A process is a set of interrelated activities that turn inputs into outputs.

A process describes a complete business activity from beginning to end.

You must:

      • Learn the process
      • Understand why it exists
      • Perform it end-to-end

A process is:

      • A high-level description of work
      • Cross-functional
      • Ongoing and repeatable
      • Updated periodically
      • Supported by policies and standards

A process answers the question:

“How does the business operate?”

What is a procedure?

A procedure provides more detail than a process but less detail than a work instruction.

It explains how to perform sequential tasks to achieve a defined outcome.

A procedure usually:

      • Follows a logical sequence
      • Has an obvious start and finish
      • Can be completed in one working session
      • Describes responsibilities

A procedure answers:

“How do we complete this activity?”

What are work instructions?

Work Instructions (WI) describe exactly how to perform a specific task.

They provide step-by-step guidance with no ambiguity.

A work instruction:

      • Describes one task
      • Contains detailed steps
      • May include screenshots or diagrams
      • Removes interpretation

Work instructions answer:

“How do I do this task?”

What is a plan?

A plan is not a process.

Many organisations confuse the two.

A management plan describes what will be done, not how work is performed.

A plan typically includes:

    • Objectives
    • Resource allocation
    • Timescales
    • Responsibilities
    • Risk considerations
    • Contingencies

A plan shows how an organisation will move from Point A to Point B.

It supports the strategy by describing how resources will achieve the aim.

A plan answers:

“What are we going to do?”

What is a strategy?

A strategy explains how an organisation will move from Point A to Point B.

It defines direction rather than detailed actions.

A strategy typically includes:

      • Current position (Point A)
      • Desired position (Point B)
      • Problems and constraints
      • Opportunities
      • Tools and approaches
      • Decision principles

A strategy considers obstacles and risks that may slow progress.

Strategy answers:

“Where are we going and why?”

Your strategy defines what you want to achieve.

Understanding the difference between a strategy and a plan allows organisations to make better decisions.

What is a standard?

Standards define mandatory rules and behaviours.

They support policies and ensure consistency across the organisation.

Standards are:

      • Mandatory
      • Enforceable
      • Organisation-wide
      • Consistent
      • Long-term

Define expected behaviour, for example:

      • Email signatures
      • Naming conventions
      • Approved hardware and software
      • Document templates
      • Security controls

Must be enforced to be effective.

This applies equally to policies and standards.

Why does this matter?

When organisations confuse these terms, documentation becomes chaotic:

      • Plans get mistaken for processes
      • Procedures become incomplete
      • Work instructions disappear
      • Strategies become wishlists
      • Standards are ignored
      • Clear documentation separates these layers and ensures:
      • Consistent delivery
      • Clear responsibilities
      • Better governance
      • Easier audits
      • Stronger information management

This structure is the foundation of a well-run documentation system.

The Hidden Cost of Poor Project Management on Technical Documentation

Poor project management can derail even the best documentation. Learn how planning, collaboration, and respect for technical authors’ timelines help deliver successful projects and user-ready content.

Tweet
Pin
Share
0 Shares

If you don’t plan properly, you’ll drown in documentation while everyone else enjoys a beer.
That’s the reality when poor project management collides with technical documentation.

When planning is weak or missing, documentation quickly becomes chaotic. This article explores how effective project management safeguards documentation quality and keeps technical authors productive — not firefighting.

Put a Plan Around a Project — or a Project Around a Plan

Without a structured project plan, technical documentation is at high risk of failure.
Good project management defines objectives, sets expectations, and prevents unqualified team members from altering scope or priorities.

Documentation cannot replace a plan — but it can rescue a project in trouble. Analysing existing documentation early can highlight risks, reduce rework, and improve overall quality.

Frustration Builds When Planning Fails

Experienced technical authors become frustrated when timelines are unrealistic or when writing is treated as a “quick task.” Common problems include:

      • Non-writers assuming documentation is easy to produce.
      • Unrealistic deadlines that sacrifice quality and accuracy.
      • A lack of understanding of research, review, and editing cycles.

Key takeaway:

Rely on your technical author’s expertise to plan, schedule, and prioritise documentation deliverables.

If deadlines are genuinely tight, create a documentation priority list to ensure users can adopt the product effectively before expanding the scope.

Building Realistic Timelines for Technical Documentation

Every documentation project should include the following core stages:

      1. Research: Understand the technology, product, and user needs.
      2. Writing: Produce structured, clear, and user-focused content.
      3. Editing: Copyedit for consistency, readability, and accuracy.
      4. Review: Validate technical accuracy with subject matter experts (SMEs).
      5. Approval: Integrate revisions and finalise the deliverables.

Skipping these steps leads to poor quality and rework that costs time and money later.

(Internal link suggestion: Link to your blog post on “The Document Lifecycle and Knowledge Management” for context.)

Allow Sufficient Ramp-Up Time

Technical authors need ramp-up time to familiarise themselves with the system or product. Proper project management helps by ensuring:

      • Hardware and software access are granted early.
      • Usernames, passwords, and permissions are available on day one.
      • Time is allocated for learning product behaviour and dependencies.

Ramp-up time is not downtime — it’s a crucial investment in documentation accuracy and long-term efficiency.

(Internal link suggestion: Link to “Maximising Technical Authors’ Skills in the Workplace” for additional insight.)

Review the Reviewers

An organised review cycle ensures documentation is technically sound and consistent. Include these checkpoints in your schedule:

      • Review sessions: Technical staff and project managers validate draft content.
      • Revision cycles: Writers implement feedback before sign-off.
      • Final review: Confirm version control and publish-ready content.

This structured review approach prevents errors, missed updates, and last-minute crises.

Can Project Managers and Technical Writers Get Along?

Absolutely — when both sides understand each other’s contribution.
Project managers bring scheduling and coordination; technical authors bring clarity, structure, and content strategy.

When collaboration works, it results in high-quality documentation that empowers customers to resolve issues independently — reducing support calls, improving user satisfaction, and strengthening organisational trust.

(Internal link suggestion: Link to your upcoming article “Using Technical Authors as Strategic Planners.”)

Final Thought

Poor project management doesn’t just delay documentation — it damages credibility and product success.
When technical authors are integrated into project planning and treated as strategic partners, documentation becomes a competitive advantage instead of a last-minute burden.