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.

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.

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

      

      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.

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

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.

There is a moment every Contractor recognises when someone says, “I’ve created a new template.” You open the file to find it is blank with no:

• • • styles.
    • structure.
    • numbering logic.
    • metadata.
    • revision table.

A white page and misplaced confidence.

This is the story behind Death by Template — and why technical authors must defend documentation infrastructure.

The scenario

When a manager left unexpectedly, he left his PA adrift. However, a new manager reassigned her to another team I worked closely with.

During a Teams call, she asked:

“Why were the templates redesigned without my knowledge?”

She assumed I had redesigned the templates without consent. The reality was different.

The previous templates were unstable. Broken numbering. No style hierarchy. No automated controls. They could not scale.

Managers had already signed off on over fifty documents using the new controlled template.

She wanted to create her own version.

So I asked the obvious question:

“Do you know what’s involved in building a compliant template?”

The answer suggested that she did not.

What a template actually is

In many organisations, “template” means:

A document you type into.

In professional technical authoring, a template means:

• • • Structured style hierarchy (Heading 1–9 mapped correctly)
    • Multilevel numbering linked to styles
    • Automated tables of contents
    • Controlled headers and footers
    • Revision history tables
    • Document metadata fields
    • Cross-reference compatibility
    • Accessibility compliance
    • Stable formatting for version control
    • Reusable front matter and boilerplate

A proper Word template is a lightweight infrastructure, engineered, not decorated.

The blank template

Later that afternoon, she sent the new template.

It was a blank Word document with no:

• • • predefined styles.
    • cover page.
    • numbering schema.
    • structured bullets.
    • defined body text formatting.

When I called her to clarify, she confirmed it was the template.

When I explained what was missing, the tone shifted, and I mentioned the words, ‘out of your depth’. She said she would check with her manager.

I never heard from her again.

Why “Death by Template” happens

This scenario is common across engineering, IT, defence, and infrastructure environments.

Templates are cosmetic

People focus on fonts and margins.

They ignore:

• • • Structural logic
    • Style discipline
    • Automation
    • Version resilience

Documentation becomes fragile because no one respects the architecture.

 Governance is invisible

Once 50 documents receive successful sign-off, no one notices the template unless the formatting fails.

People undervalue infrastructure that works quietly.

Authority outpaces expertise

Well-meaning staff assume that creating a template is straightforward.

They underestimate:

• • • The complexity of Word’s style engine
    • The risk of manual formatting
    • The cost of rework
    • The audit implications of inconsistency

A blank file is not governance.

They bring in technical authors too late.

In many organisations, documentation is reactive.

Templates are “fixed” by non-specialists until someone realises:

• • • Numbering collapses at section 3.2.4
    • Cross-references break
    • TOCs misbehave
    • Audits question consistency

Then a technical author is called in.

The Contractor’s perspective

As a senior technical author working across regulated and high-control environments, I see the same pattern repeatedly:

• • • Templates designed without structured styles
    • Manual formatting instead of enforced formatting
    • No metadata control
    • No document governance policy
    • And then confusion when consistency fails.

A template is not a blank canvas but a controlled system.

If you allow anyone to redesign it based on personal preference rather than architectural principles, the documentation quality will erode quietly.

The real risk

Poor templates do not just look untidy; they are also inefficient.

They create:

• • • Audit risk
    • Rework costs
    • Version control confusion
    • Loss of traceability
    • Inconsistent client-facing documentation
    • Increased onboarding time for new staff

In regulated sectors, it is operational risk.

How to avoid death by template

If you manage documentation governance, ensure:

• • • Someone who understands Word’s style architecture designs templates.
    • Link Multilevel numbering to headings.
    • Control Document properties.
    • Standardise Revision tables
    • Consider Accessibility standards
    • A template change control process exists.
    • Managers understand the difference between formatting and structure.

Most important: Do not treat templates as personal design projects but as infrastructure.

Final Thought

If you are a technical author working alone inside an organisation, protecting documentation standards is part of your role.

You are not just formatting pages; you are protecting information integrity.