Category: Technical Writer

How to Handle Managers Who Misunderstand Technical Writing

Managers often misunderstand technical writing. This article explains how to clarify the role, work with SMEs and protect the value of documentation expertise.

Tweet
Pin
Share
0 Shares

Many managers misunderstand the role of technical writing. They may assume technical authors are administrators, general writers or people who should become subject matter experts before they can write effectively.

That misunderstanding creates avoidable tension. Technical authors are already specialists. Our expertise is in documentation, structure, audience analysis, clarity, governance and making complex information usable. We work with subject matter experts; we do not replace them.

Why the Misunderstanding Happens

In many organisations, people treat documentation as something anyone can do if they have time. That view ignores the skill involved in turning fragmented knowledge into useful, accurate and maintainable content.

Managers may also work in environments where people wear multiple hats. As a result, they may expect technical authors to become experts in ISO 27001, ITIL, engineering, infrastructure or compliance, rather than recognising that our role is to extract, structure and communicate information from the people who own those subjects.

Common Misconceptions About Technical Authors

    • Documentation is just writing. In reality, it involves research, analysis, structure, validation and maintenance.
    • The writer must be the subject matter expert. Technical authors need enough understanding to ask the right questions, but the SME remains responsible for technical accuracy.
    • Certification in every subject makes a better writer. Relevant knowledge helps, but unrelated certification can pull the writer away from the documentation role.
    • Documentation is administrative work. Good documentation supports risk management, compliance, onboarding, service continuity and operational control.
    • Anyone can tidy up documents. Cleaning up documents without addressing structure, ownership and audience rarely solves the real problem.

The Consequences of Getting It Wrong

When managers misunderstand technical writing, they often misuse the technical author. That can lead to weak documentation, wasted effort and poor collaboration with SMEs.

      • Technical authors are pulled away from their core strengths
      • SMEs avoid ownership because they think the writer should know everything
      • Documents become polished but inaccurate
      • Projects lose time because expectations were never agreed
      • The organisation undervalues a role that protects knowledge and reduces risk

How to Address the Misconception

Clarify the role early

Explain that technical authors make complex information understandable, usable and maintainable. We are documentation specialists, not replacement engineers, auditors or service managers.

Define SME responsibility

Make it clear that SMEs provide and validate the technical content. The technical author structures, challenges, edits and presents that information for the intended audience.

Show the value of documentation expertise.

Highlight the work that often goes unseen: information architecture, audience analysis, terminology control, document governance, plain language, version control and review management.

Recommend relevant training

If a manager suggests unrelated certification, redirect the conversation. Training in structured authoring, information architecture, UX writing, accessibility, or content governance may be more relevant than certifying in every subject a project touches.

Final Thought

Technical authors do not need to become every type of SME to add value. Our value lies in making specialist knowledge usable, accurate and accessible.

Managers who understand that distinction get better documentation, stronger collaboration and fewer misunderstandings.

Why Comprehensive Documentation Matters for Business Success

Comprehensive documentation improves business clarity, reduces risk, supports governance and helps organisations make better decisions from reliable information.

Tweet
Pin
Share
0 Shares

Comprehensive documentation matters because organisations cannot manage what they cannot understand. Clear, accurate, well-structured documentation helps people make decisions, reduce risk, transfer knowledge, and keep work moving when key people are unavailable.

Yet documentation is often underestimated. People treat it as administration, tidying up, or something to do after the real work is finished. In practice, poor documentation creates hidden costs: repeated questions, duplicated effort, weak handovers, audit problems and decisions based on incomplete information.

My experience as a technical author and contractor has shown me that comprehensive documentation is not a luxury. It is a business asset.

Why Comprehensive Documentation Is Often Undervalued

Technical authors are sometimes misunderstood because good documentation looks simple when it is finished. People see the final document, but not the analysis, questioning, structuring, validation and review work behind it.

On one contract, after I had explained a network back to an engineer, he admitted he had assumed I was a secretary. On another project, I joined a group of long-term employees for lunch. When they asked what I was doing, I said I was tidying up the documentation. They laughed and said, “We’ve tried. What makes you think you’ll make it work?”

Those comments reveal a common problem. Many organisations do not recognise documentation as a specialist discipline until poor documentation starts causing visible problems.

The Business Value of Comprehensive Documentation

Comprehensive documentation gives an organisation a reliable reference point. It turns scattered knowledge into information people can find, trust and use.

Strong documentation helps organisations:

      • Reduce dependency on individual knowledge holders
      • Improve decision-making with accurate information
      • Support audits, governance and compliance
      • Speed up onboarding and handover
      • Improve operational consistency
      • Reduce rework and repeated questions
      • Identify gaps, duplication and unclear ownership

The value isn’t just in the documents themselves. The value is in the clarity they create.

What Happens When Documentation Is Weak?

Weak documentation rarely causes one dramatic failure. More often, it creates friction that accumulates slowly.

      • People rely on memory instead of agreed processes
      • Different teams describe the same thing in different ways
      • New starters struggle to understand how work is done
      • Managers cannot see where responsibilities begin and end
      • Audits take longer because evidence is difficult to find
      • Projects repeat mistakes because lessons are not captured properly

These problems cost time and money. They also damage confidence. If people cannot trust the documentation, they stop using it. Once that happens, the organisation falls back on informal knowledge, private notes and individual memory.

When Documentation Proves Its Worth

In one contract, a senior executive was visibly frustrated because he could not get clear answers. The information existed, but it was scattered, inconsistent and difficult to use.

Once he received a properly structured set of documents, the situation changed. The documents gave him the answers he needed and helped him identify other areas where better documentation could solve similar problems.

That is often the turning point. Documentation shifts from background work to a practical business tool.

Comprehensive Documentation Is More Than Writing

Good technical documentation is not just well-written text. It also requires structure, ownership, purpose and maintenance.

A technical author will usually consider:

      • Who the document is for
      • What problem the document solves
      • Which information must be included or excluded
      • Who owns the content
      • How the document will be reviewed and updated
      • Whether the structure helps people find what they need
      • How the document fits into the wider documentation set

This is why comprehensive documentation often reveals deeper problems. A missing process, unclear responsibility or inconsistent definition may sit unnoticed for years until a documentation project exposes it.

Documentation Supports Governance and Compliance

For regulated or process-heavy organisations, documentation also serves as a governance tool. Policies, procedures, standards, and operational guides show how the organisation works and how it controls decisions.

If documentation is incomplete, out of date or difficult to navigate, governance becomes harder to demonstrate. Audit preparation takes longer. Compliance evidence becomes harder to locate. Staff may follow different versions of the same process without realising it.

Comprehensive documentation reduces that risk by creating a clearer, more consistent information base.

How to Improve Business Documentation

Improving documentation doesn’t mean creating more documents for their own sake. It means making the documentation useful, reliable and maintainable.

Start with these questions:

      • Which documents do people actually use?
      • Which documents are duplicated, outdated or contradictory?
      • Who owns each document?
      • When was each document last reviewed?
      • What information do people keep asking for?
      • Where are the gaps that create operational risk?

These questions help turn documentation from a storage problem into an information management exercise.

Further Reading

Final Thought

Comprehensive documentation helps an organisation understand itself. It captures how things work, why decisions matter and where risks sit.

Clear documentation leads to better decisions. When it is neglected, the organisation pays for it through rework, confusion, delay, and risk.

That is why comprehensive documentation matters for business success.

Technical Writer, UX Writer or Copywriter: What Writer Are You?

A clear comparison of technical writers, UX writers, copywriters, content strategists, content managers and content writers, with examples of each role.

Tweet
Pin
Share
0 Shares

People often confuse technical and digital writing roles. The job titles sound similar, but the focus, skills, and outcomes can differ significantly. For newcomers to workplace writing, that confusion can make it difficult to understand where they fit.

This guide explains the main differences between technical writers, UX writers, content strategists, content managers, copywriters and content writers.

Technical Writer

Focus: Creating documentation for technical products, services, systems or processes.

Typical work includes:

      • Software user manuals
      • Product guides
      • API documentation
      • Operational procedures
      • Process documentation
      • Policy documentation

Skills: Technical understanding, structured writing, audience awareness, interviewing SMEs, and clearly explaining complex information.

Difference: Technical writers focus on accuracy, usability and operational clarity. The audience may be technical, non-technical or mixed, depending on the document.

Example contexts: Software documentation, infrastructure documentation, maintenance manuals, medical device documentation and regulated process documentation.

UX Writer

Focus: Writing the words users see when interacting with software, websites or apps.

Typical work includes:

      • Button labels
      • Menu items
      • Error messages
      • Onboarding steps
      • Help text within an interface

Skills: User experience principles, concise writing, usability thinking and close collaboration with designers and developers.

Difference: UX writers shape the user’s interaction with a product. Their work is usually short, precise and embedded directly in the interface.

Content Strategist

Focus: Planning how content supports business goals and user needs.

Skills: Content planning, SEO, audience analysis, governance, measurement and lifecycle management.

Difference: Content strategists work at a planning level. They decide why content is needed, who it is for, how it should be managed and how success will be measured.

Example contexts: Website content strategy, brand content planning, governance models, campaign planning and content audits.

Content Manager

Focus: Managing the creation, editing, publishing and maintenance of content.

Skills: Project management, content management systems, editorial planning, SEO awareness, workflow management and governance.

Difference: Content managers oversee content operations. They may not write everything themselves, but they ensure content is produced, reviewed, published, and maintained.

Copywriter

Focus: Writing persuasive marketing and promotional content.

Typical work includes:

      • Advertising copy
      • Website sales copy
      • Email campaigns
      • Landing pages
      • Product descriptions
      • Social media promotions

Skills: Persuasion, brand voice, marketing awareness and writing designed to encourage action.

Difference: Copywriters focus on engagement, conversion and promotion. The purpose is usually to sell, persuade or influence.

Content Writer

Focus: Producing articles, blog posts and other informative content for an audience.

Typical work includes:

      • Blog posts
      • Articles
      • White papers
      • Reports
      • Newsletters

Skills: Research, clear writing, SEO, tone adaptation and audience engagement.

Difference: Content writers inform, educate or entertain. Their work often supports marketing, thought leadership or search visibility.

Which Writer Are You?

The distinctions matter because each role solves a different problem.

      • technical writer reduces confusion around complex information.
      • UX writer improves the user journey.
      • Copywriter persuades.
      • Content strategist plans.
      • Content manager governs. A content writer informs.

Many writers move between these roles, and some jobs combine several of them. The important question is not only what you write, but why the content exists and what outcome it must support.

Why SharePoint Fills Up With Useless Documents

Many organisations fill SharePoint and other document management systems with repeated, low-value content. The problem is not usually deliberate duplication. It is poor ownership, weak governance and a failure to define the source of truth.

Tweet
Pin
Share
0 Shares

Following on from my article suggesting technical authors/writers should avoid publishing articles on LinkedIn that cover repeated topics (many times over), let’s focus on the wider problem.

What happens when SharePoint becomes a dumping ground by accident? It happens one unnecessary document at a time. The culprits are duplicate documents in SharePoint.

So, before you sit down to write a document, ask yourself one question: What existing information does this replace, improve, or retire?

In SharePoint and other DMS environments, duplication happens for several common reasons.

1. People write to prove activity, not to solve a problem

Many documents exist because people require proof that they have completed a task (hey, look at me!). They use the document to show we followed the rules, which is something the project will finish, or results from a meeting. Its purpose is not always to inform the reader. Its purpose is to exist.

This leads to documents stating:

We reviewed the process.
We identified improvements.
We recommend further engagement.

Which usually means:

We have written a document to show we are moving something forward, even though nothing practical has changed.

2. Contributors do not search before writing

Many contributors do not treat the DMS as a knowledge source. They treat it as a dumping ground. Before writing, they do not ask:

      • Has an SME written this already?
      • Is there an existing approved version?
      • Is this a replacement, supplement, update, or duplicate?
      • Who owns the current source of truth?

Someone creates another document because writing from scratch feels easier than updating the original.

3. No one knows what the “source of truth” is

This is the major failure. If the organisation has five versions of a process, which is the source of truth?

People create another one because they think:

“The existing document is old.”
“That version is for another team.”
“I need one that fits my project.”
“I was asked to produce my own version.”
“I don’t know whether I’m allowed to change the existing one.”

The result is not knowledge management, but document inflation.

4. People confuse variation with value

An editor does not add knowledge to an existing document by changing words. They have added another route to the same information.

This is common with LinkedIn-style articles, too. Many repeat the same safe observations:

      • Communication matters.
      • AI will change documentation.
      • SMEs need to collaborate.
      • Plain English is important.
      • Documentation must be user-focused.

All true. But if the article does not add evidence, it is noise and clutter.

5. There is no editorial control

Most DMS platforms are not the problem. SharePoint, Asite, Confluence, Teams, and other systems can hold solid information. But without governance, they become storage cupboards.

Who is asking the hard questions before accepting new content?

      • What is this document for?
      • Who is the audience?
      • What decision or task does it support?
      • Does it duplicate existing content?
      • Does it replace another document?
      • Who owns it?
      • What is the review period?
      • What should be archived when this is published?

Without that discipline, every project, team, and manager produces another version of the same thing.

6. People write around uncertainty

Sometimes duplication is a defensive act. People are unsure what is current, so they produce their own document to protect themselves.

It says:

“This is what our team is doing.”

But underneath it means:

“I do not know whether the official process is reliable, so I am creating something I can point to later.”

That is an organisational trust problem, not a writing problem.

7. Documents are easier to create than to maintain

Writing a new document gives people a sense of progress. Maintaining an old one requires discipline.

Maintenance involves:

      • verifying accuracy,
      • consulting with owners,
      • removing obsolete content,
      • fixing links,
      • updating screenshots,
      • reviewing metadata, and
      • archiving superseded material.

That is less glamorous than publishing something new, but is where proper information management happens.

The technical author’s view

A technical author or information manager should not ask, “Can you write this?”

They should ask:

“What existing information does this replace, improve, or retire?”

That one question would stop a large amount of useless documentation.

When organisations reward production over usefulness, they count documents, uploads, articles, and deliverables, but rarely measure whether anyone used, trusted, or needed them.

A controlled DMS isn’t a place for everyone to upload additional information. Instead, it is a managed environment where only the appropriate information remains, while the unnecessary data is challenged, merged, archived, or removed.

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 SharePoint Becomes a Document Graveyard

As a technical writer, I know most organisations don’t lack documents, but they do struggle to find a specific document. We will hear them muttering, “Where is it?” as they search. After hours of hunting, they finally located the document buried in an obscure location in their SharePoint. This represents a failure in information control.

I once worked for a government quango. One of the IT staff moaned about SharePoint: “It’s useless,” he said, “I uploaded a document and lost it.”

I faced him and asked a question. “Did you create a folder?”

“Yes.”

“What’s the name of the folder?”

“Don’t know.”

“Title of the document?”

“Something to do with the network.”

After fifteen minutes, I found it in an obscure folder hidden among many others.

That is why so many SharePoint environments become digital graveyards. I conducted an analysis of a client’s document system and Confluence and found.

      • Thousands of files
      • Endless folders
      • Duplicate content with no owner
      • Outdated procedures
      • Unowned documents
      • Broken permissions
      • Conflicting versions
      • No trust in the information

The problem is not SharePoint, but how teams use it, because companies do not learn how it should work and train people.

People treat SharePoint like a filing cabinet.

Many businesses deploy Microsoft SharePoint, expecting it to solve:

      • Knowledge management
      • Collaboration
      • Governance
      • Information retrieval
      • Document control
      • workflows

But SharePoint is a platform. Not an information strategy.

Without governance, people recreate old network-drive behaviour:

      • Department folders
      • Personal silos
      • Random naming conventions
      • “Final_v2_REAL_FINAL”
      • Uncontrolled uploads
      • Duplicate libraries

The organisation digitises its chaos.

Nobody owns the information lifecycle

While documents are easy to create, they are much harder to maintain.

Most organisations focus on:

      • Creating information
      • Migrating information
      • Storing information

Very few focus on:

      • Reviewing information
      • Archiving information
      • Retiring information
      • Validating accuracy
      • Removing ROT

Technical authors and information managers often use the acronym:

ROT

    • Redundant
    • Outdated
    • Trivial

Over time, ROT spreads everywhere.

And because nobody wants to delete anything:

      • Old procedures remain searchable
      • Obsolete guidance survives indefinitely
      • Legacy templates continue circulating
      • Users lose confidence in what they find

Eventually, staff stop trusting SharePoint altogether.

Search Becomes Meaningless

Search only works well when information is:

      • Structured
      • Tagged properly
      • Consistent
      • Governed
      • Maintained

Most SharePoint environments contain:

      • Poor metadata
      • Inconsistent titles
      • Duplicate terminology
      • Mixed file standards
      • No taxonomy strategy

So users search for:

“VPN process”

And receive:

      • 47 documents
      • 12 outdated procedures
      • 6 duplicates
      • 3 archived versions
      • 1 incomplete draft

At that point, people stop searching and start asking colleagues instead.

Tribal knowledge replaces controlled information.

SharePoint often mirrors organisational dysfunction

One uncomfortable truth:

Poor SharePoint environments usually reflect a poor organisational information culture.

Common symptoms include:

      • Departments protecting silos
      • No governance authority
      • No content standards
      • No review ownership
      • No retention discipline
      • No metadata strategy
      • No information architecture

The technology exposes the underlying disorder.

Projects Flood SharePoint with Dead Content

Large IT and engineering projects generate enormous amounts of:

      • Drafts
      • Working papers
      • Design discussions
      • Meeting outputs
      • Temporary deliverables
      • Review copies
      • Migration files

Much of this content has only short-term value.

But organisations rarely clean up after projects end.

So SharePoint accumulates digital sediment year after year.

Nobody archives because:

      • They fear deleting something important
      • Ownership disappeared after restructuring
      • Contractors left
      • Teams changed
      • Governance was never defined

The result is institutional hoarding.

Permissions Create Invisible Chaos

Another major issue:
Overcomplicated permissions.

Many SharePoint environments evolve into:

      • Broken inheritance structures
      • Conflicting access rights
      • Locked-down libraries nobody can use
      • Open libraries nobody should access

Eventually, users bypass governance by:

      • Saving files locally
      • Emailing attachments
      • Creating unofficial repositories
      • Using Teams chats as storage
      • Maintaining shadow systems

The platform fragments further.

AI May Make the Problem Worse

AI search and summarisation tools sound attractive.

But AI trained against unmanaged repositories can amplify confusion:

      • Surfacing obsolete content
      • Repeating inaccurate procedures
      • Mixing draft and approved information
      • Generating false confidence in poor data

AI cannot distinguish:

      • Operationally valid content
      • Regulatory accuracy
      • Controlled documentation
      • Organisational truth

Information architecture scaled through AI becomes faster misinformation.

SharePoint works well — When information is managed

Well-run SharePoint environments can work, but require:

      • Governance
      • Taxonomy
      • Ownership
      • Review cycles
      • Metadata discipline
      • Archiving policies
      • Information architecture
      • Content lifecycle management

Most importantly:
They require organisations to treat information as an operational asset — not digital clutter.

Because without governance, SharePoint does not become a knowledge hub.

It becomes a corporate attic full of forgotten documents nobody trusts.

Organisations need to step up, invest in training, and employ an information manager.

When the ROT sets, what next?

Most organisations don’t notice document ROT setting in. In fact, document ROT can undermine confidence in your information over time.

It creeps in under the radar with:

      • Duplicate documents. This is often a visible symptom of document ROT in repositories.
      • Outdated procedures. Outdated guidelines also contribute to increased document ROT.
      • Content no one trusts, but no one deletes.

Then one day, someone asks a simple question: “Which version is correct?” Yep, you’ve heard it before, and no one can answer the question. This is a classic sign of your organisation struggling with document ROT.

And no one knows.

That’s when you realise you don’t have a documentation problem but a control problem. That’s the moment you understand you’re facing document ROT.

I’ve seen this in SharePoint sites, shared drives, knowledge bases, and even in controlled environments that claim alignment to ISO 27001 or ISO 9001. Ultimately, if left unmanaged, document ROT will impact all these settings.

You see, dear readers, the problem is neither the technology nor the process; it’s ownership.

Hang on, I forgot to say what ROT is. Here goes ROT (Redundant, Outdated, Trivial content). Don’t forget about the risks of document ROT now.

ROT commencement: Your steps:

Stop team members from adding more documents to the DMS until you know their value. Otherwise, document ROT can escalate quickly.

Adding more content to a broken system accelerates its decay, further magnifying the document ROT issue.

Instead:

1. Surface the estate
Find everything and don’t allow people to restrict your view. It is for their benefit and helps identify ROT in documents early.

2. Classify forcefully.
Redundant. Outdated. Trivial.
No sentiment. No to the suggestion that we might need it. If it hasn’t been opened or referenced for months, get rid of it—classic symptoms of document ROT in play.

3. Rationalise before migration
If you lift and shift, you formalise the mess and transfer the document ROT problem as well.

4. Rebuild structure
Clear document types. Controlled locations. Metadata that means something. By doing so, you reduce the risks associated with document ROT.

5. Assign real ownership
Named individuals. Review cycles. Accountability. These combat documents ROT more effectively.

6. Put governance in place
Not a heavy process. Just enough control to stop the slide into document ROT.

Here’s the part most organisations don’t grasp: dealing with document ROT is an ongoing responsibility.

If no one owns documentation, it will decay again.
Every time, you’ll see document ROT coming back.

Usually, within 12–18 months, unmanaged document ROT returns.

The shift you must make

If teams are writing, ROT will outpace them. Addressing document ROT needs ongoing attention.

This is where the role changes. Document ROT management becomes a critical function.

You become:

      • Information architect—seeking document ROT to resolve.
      • Governance designer
      • Content auditor
      • Risk mitigator

Because ROT isn’t about writing. Therefore, managing document ROT is vital for any business that relies on high-quality information.

It’s what happens when documentation becomes an afterthought instead of an asset—an all too typical result of ignoring document ROT.

Question:
When ROT set in on your last project, did you fix the content … or fix the system affected by document ROT?

Hashtags:
#TechnicalWriting #Documentation #ContentStrategy #KnowledgeManagement #InformationManagement #SharePoint #DocumentControl #ISO27001 #ISO9001 #DigitalTransformation #ContentGovernance #TechCom

 

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

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

Tweet
Pin
Share
0 Shares

Introduction

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

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

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

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

The Assumption Behind Certification

Many organisations assume that working alongside standards such as:

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

naturally leads to certification.

Foundation becomes Practitioner.
Practitioner becomes Expert.

This progression makes sense for:

      • Information Security Managers
      • Service Delivery Leads
      • Compliance Officers

But it does not automatically apply to technical authors.

The Role of the Technical Author in Compliance

A technical author does not own the framework.

The role is to:

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

In simple terms:

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

What Experience Delivers That Certification Does Not

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

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

These are not theoretical problems.

They are the reasons organisations fail audits.

Understanding how to fix them comes from:

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

        structures under pressure

      • aligning documentation to real-world operations

This is applied capability, not classroom knowledge.

The Certification Trade-Off

Certifications do provide value.

They:

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

However, they also introduce a shift in perception.

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

I would no longer be seen as a technical author.

Instead, I would be positioned as:

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

That is a different role, with different expectations.

The Reality in Delivery Environments

There is an uncomfortable but consistent observation across projects:

Some certified professionals struggle to produce:

      • clear policies
      • usable processes
      • audit-ready documentation

Experienced technical authors often:

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

without holding formal certifications.

Knowing Enough to Deliver

There is a phrase that often needs clarification:

“I know enough.”

This does not imply limited understanding.

It means:

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

It also means recognising boundaries.

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

When Certification Does Make Sense

There are situations where certification adds clear value:

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

In these cases, certification supports:

      • trust
      • marketability
      • pricing leverage

Cost vs Return

Foundation certifications typically cost:

      • £500 to £1,500 per course

Covering multiple frameworks can exceed:

      • £3,000 to £4,500

For knowledge that often overlaps with existing experience.

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

The Positioning That Matters

The distinction is important:

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

These are complementary roles—but not the same role.

Conclusion

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

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

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

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

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

Tweet
Pin
Share
0 Shares

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

We do:

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

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

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

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

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

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

Three words instead of one

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

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

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

Why This Matters?

Shorter sentences:

      • Reduce cognitive load

      • Improve comprehension

      • Reduce misinterpretation

      • Increase pace and authority

      • Improve audit traceability

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

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

A Practical Rule

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

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

As technical authors, our job is not to impress.

It is to make meaning unavoidable.

Technical Authors: How Do You Manage Your Managers?

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

Tweet
Pin
Share
0 Shares

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

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

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

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

How do you manage your manager?

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

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

The managers’ technical authors encounter

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

The Accidental Documentation Manager

This is the most common type.

They typically come from:

      • Engineering
      • Project management
      • Product delivery
      • Operations

Documentation lands in their area of responsibility almost by accident.

Typical behaviours

They often:

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

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

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

These are activities that experienced technical authors already perform.

What is really happening?

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

How experienced authors deal with them

Rather than challenging them directly, technical authors usually:

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

Over time, this approach builds understanding.

The Credit Taker

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

Typical behaviours

They often:

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

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

When a technical author calmly replies:

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

The origin of the idea becomes clear.

What is happening?

These managers often want to appear strategic or authoritative.

How experienced authors deal with them

The best response is usually calm and factual.

Experienced authors typically:

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

Confrontation rarely improves the situation.

The Process Evangelist

Some managers believe strongly in management frameworks such as:

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

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

Typical behaviours

They often:

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

Ironically, technical authors are usually very strong process thinkers.

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

Why do these situations occur so often?

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

They:

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

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

This can occasionally expose gaps in management’s understanding.

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

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

How Experienced Technical Authors Handle It

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

Translate the documentation into management language

Managers respond to outcomes such as:

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

Instead of discussing:

      • information architecture
      • content strategy

It can be more effective to talk about:

      • reducing operational risk
      • improving onboarding
      • supporting project delivery

Make the Thinking Visible

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

Occasionally, showing the method can change that perception.

For example:

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

This reframes documentation as structured analysis rather than typing.

Let Quiet Competence Do the Work

Sometimes the best response is calm professionalism.

When a technical author says:

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

They achieve several things at once:

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

This approach is often far more effective than arguing.

The Reality of Technical Authoring

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

They become:

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

Often this happens quietly.

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

They are not really managing their managers.

They are managing the documentation environment.

And the managers gradually adapt to it.