Month: October 2025

When being Ignored teaches you everything

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

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

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

Being ignored forced me to grow and build my knowledge in

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

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

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

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

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

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

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

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

Where would I go?

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

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

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

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

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

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

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

When Document Titles Don’t Match Their Content: A Hidden ISO 27001 Audit Risk

In my career I have worked on several contracts correcting documents that failed an ISO27001 audit. I found several change management process documents that were anything but processes. They were plans with a workflow diagram, but the main part of the text explained the planning, not the exact steps.

This mismatch between title and content can undermine an ISO 27001 audit. Users and auditors will struggle if document names don’t match the content, leading to wasted time and a lack of trust in the documentation.

Why It Matters?

ISO 27001 requires documentation to be consistent, accurate, and traceable. Under Clause 7.5, all documented information must be suitable and adequate for its purpose.
If your titles mislead the reader — for instance, labelling a plan as a process — it fails that requirement outright.

Auditors don’t just check boxes; they follow document trails. Incorrectly named or categorised documents suggest your information management and document control are weak. That can lead to a nonconformity finding and a costly re-audit.

The Domino Effect of Wrong Titles

Incorrectly titled documents have consequences beyond compliance:

      • Search confusion: Teams waste time locating or referencing the wrong document.
      • Duplicated effort: Multiple people recreate or update files that already exist, under a different name.
      • Loss of trust: Users stop relying on the repository, assuming it’s unreliable.
      • Audit remediation time: Technical authors must spend months re-titling, rewriting, and re-validating content.

Every mis-titled document represents avoidable technical debt that eventually needs to be paid back — usually as long, tedious remediation work.

The Cost of Inaccuracy

In one project, we discovered over 200 documents whose titles didn’t match their content. Entire categories had to be re-audited, cross-referenced, and reissued.
The team lost weeks, and the company risked missing its ISO 27001 renewal.

This wasn’t a writing issue — it was a metadata and document control failure. Titles, categories, and filenames are all metadata fields that auditors use to navigate your Information Security Management System (ISMS). When those don’t align, your ISMS fails to demonstrate control.

How to Get It Right

  1. Align title and intent
      • If it’s a process, describe repeatable steps.
      • If it’s a plan, define scope, actions, and timelines.
  1. Use controlled metadata
      • Add document owner, version, and approval date.
      • Classify documents by type and purpose.
  1. Include a clear scope statement
      • A single line beneath the title explaining purpose helps readers instantly understand what they’re reading.
  1. Review your taxonomy
      • Periodically audit your repository to ensure naming conventions still reflect actual content.
  1. Engage technical authors early
      • They can design taxonomies, enforce naming conventions, and prevent this issue before it becomes a compliance risk.

Final Thought

A wrong title might not seem serious — until an auditor can’t find what they’re looking for.
When document names and content don’t align, it’s more than a clerical error; it’s a failure of document control.

Accurate titling and classification aren’t just about neatness — they’re a sign that your organisation takes information management, and ISO 27001 compliance, seriously.

If your document library has grown organically over the years, now’s the time to review it.
A few days of focused taxonomy work today can save months of painful remediation tomorrow.

Author Bio:
Michael Clark is a Senior Technical Author and Information Management Specialist at AtkinsRealis, with extensive experience in documentation strategy, metadata design, and ISO 27001 compliance. He writes about documentation standards, information governance, and practical approaches to managing technical content across large organisations.

The Problem: Great Documents, Poor Findability

People often postpone or skip metadata management and taxonomy design. Documents get stored with vague titles like “Final_V2_Approved_Updated_UseThisOne.docx”, and six months later, no one knows which version to trust.

The result? Teams recreate content that already exists, projects fail audits, and valuable knowledge is lost.

Why Metadata Matters

Metadata — the data about your documents — is the DNA of information management.
It tells you what a document is, who owns it, when it was last updated, why it exists, and where it belongs.

Properly designed metadata enables:

      • Searchability – users find what they need instantly.
      • Traceability – auditors can follow the document’s full lifecycle.
      • Compliance – version control and approvals are easy to prove.
      • Automation – workflows trigger based on tags, not guesswork.

Without metadata, your DMS or SharePoint site is just a digital filing cabinet — nothing more.

Taxonomy: The Architecture Behind Order

Taxonomy defines how information is grouped, named, and classified.
It’s the foundation of every successful knowledge system.

A clear taxonomy allows users to:

      • Navigate logically from policies → procedures → templates.
      • Understand relationships between document types and departments.
      • Apply consistent naming that prevents duplication.

Poor taxonomy, on the other hand, turns repositories into mazes — full of outdated files, irrelevant folders, and frustrated users.

The Technical Author’s Role

This is where technical authors shine — and where managers often don’t listen.
An experienced author doesn’t just write; they design the structure that holds the organisation’s knowledge together.

They understand how metadata fields map to templates, how naming conventions affect automation, and how taxonomy supports compliance with ISO 9001, ISO 27001, or client-driven governance models.

Ignoring their input is like ignoring the blueprint when building a data centre — it might stand up for a while, but chaos is inevitable.

A Call for Metadata Governance

Every organisation should define:

      1. Mandatory metadata fields (title, author, version, classification, review date).
      2. Controlled vocabularies (standard terms for project, client, and discipline).
      3. Naming conventions (no more “final_final_v3”).
      4. Review and archiving rules to keep libraries clean.

These aren’t “nice to haves” — they’re the foundation of digital trust.

Final Thought

Metadata and taxonomy don’t make noise. They don’t shout for attention.
But without them, your entire documentation system collapses into confusion.

If you want your documents to work for you — not against you — invest time in getting metadata right.
It’s the silent architecture of every successful knowledge ecosystem.

The Hidden Cost of Ignoring Your Technical Author

Why documentation fails when managers don’t listen

The real problem isn’t the writing — It’s not listening to experience.

Management’s lack of focus, not a writer’s skill, causes projects to be poorly documented. A seasoned author can design a structure, build consistency, and maintain control over hundreds of evolving documents.

Yet, repeatedly, managers bypass their input:

      • They hand over blank Word files and call them “templates.”
      • They expect one-off deliverables rather than an ongoing lifecycle.
      • They set unrealistic deadlines that ignore review, approval, and publishing time.

When leadership dismisses this expertise, documentation quickly becomes a liability.

Ignored expertise, predictable problems

When you ignore a technical author’s recommendations, you’ll eventually see:

      • Version Confusion: No one knows which file is the current one.
      • Template Drift: Every department uses its own layout.
      • Audit Failures: Documents lack metadata or controlled approval trails.
      • Lost Knowledge: Critical information walks out the door with departing staff.
      • Rework Costs: Teams rewrite what already exists — again and again.

Documentation doesn’t happen by accident. It’s engineered through planning, governance, and review.

The Author’s Perspective: More Than a Writer

The best authors think like strategists.
They understand:

      • ISO 9001/27001 compliance needs
      • Metadata and taxonomy for search and retrieval
      • Information architecture for user navigation
      • System integrations with DMS platforms like Asite or SharePoint

In short, they build the bridge between information and understanding.
Ignoring that expertise is like ignoring the architect when building your house — you might save a few days, but you’ll pay for it later.

The Cost of Not Listening

The fallout can be subtle or severe:

      • Staff waste hours searching for outdated documents.
      • Projects fail audits for poor control and traceability.
      • Clients lose confidence in your quality assurance.

Listening early avoids all of this.
A short meeting with your technical author at the planning stage can save weeks of remediation later.

A Simple Shift in Thinking

The next time you start a project, ask:

“What’s our documentation strategy?”
“Who owns the lifecycle?”
“How will we manage updates after go-live?”

If those questions draw blank faces, it’s time to let your technical author lead the way.

Because documentation isn’t an afterthought — it’s part of your operational DNA.
Ignore it, and you’ll eventually pay the price.

Why Great Writing Alone Won’t Save Your Documentation

Good writing is not enough. Without a document management strategy, even the best technical documents become outdated, untraceable, and unreliable. Learn why managing your documentation lifecycle — from draft to archive — matters more than ever.

Tweet
Pin
Share
0 Shares

Managing technical documents takes more than good writing — it takes strategy.

Many organisations still overlook document management. Great writing means little if your technical documents are untracked, outdated, or scattered. Learn why every organisation needs a strategy to manage technical content from draft to archive.

The Hidden Problem Behind Great Documentation

Scroll through LinkedIn and you’ll find plenty of posts about how to write better — use plain English, know your audience, structure information, and so on.
All valid advice.

But here’s the uncomfortable truth:
Writing better isn’t enough if your organisation can’t manage its documents.

Behind every good document lies a structure — a lifecycle — that keeps it current, traceable, and trusted. Yet, in too many organisations, that structure doesn’t exist. The result? Dozens, sometimes hundreds, of outdated or duplicated files that no one knows who owns or when they were last approved.

The Lifecycle That Few Talk About

A professional documentation strategy should follow a defined sequence:

      1. Start (Writing Phase) – Drafting begins, metadata is captured, ownership and purpose are defined.
      2. Editorial Review – The document is checked for clarity, consistency, and compliance with style guides.
      3. Approval – Stakeholders and SMEs validate content accuracy and completeness.
      4. Publishing – The approved version is released, version-controlled, and stored in a secure repository.
      5. Maintenance & Review – Scheduled reviews ensure documents remain current, compliant, and usable.

Without this lifecycle, documents quickly lose credibility.
And once trust is gone, users revert to emailing old copies or creating their own “unofficial” versions — the beginning of document chaos.

Who’s Managing It All?

In theory, the Information Management (IM) department should handle this.
In reality, many IM teams lack the practical experience to manage complex technical documentation environments.

That’s where technical authors often step in — not just as writers but as custodians of the documentation lifecycle.
They understand metadata, approvals, publishing platforms, and how to structure information so it remains usable years later.

But this shouldn’t be left to one person. Document management is not an afterthought — it’s a full-time discipline.

The Cost of Neglect

Out-of-date documentation isn’t a minor issue. It can lead to:

      • Project delays are due to a reliance on obsolete procedures.
      • Compliance failures during audits.
      • Increased risk when teams use unverified instructions.
      • Loss of client confidence when “final” documents contradict each other.

If your teams don’t know which version to trust, you don’t have a documentation problem — you have a governance problem.

A Call to Action

So ask yourself:

      • Do you have a defined documentation lifecycle?
      • Who owns your documentation strategy?
      • When did you last review  your key documents?

If you can’t answer confidently, it’s time to rethink your document management approach.

    • Good writing builds clarity.
    • Good management builds trust.
      Without both, your documentation will fail — no matter how well it’s written.

Using Your Technical Authors as Strategists, Planners, and Consultants

Many businesses still misunderstand what a technical author can deliver.
They see a writer — not a strategist. A formatter, not a planner. A proofreader — not a consultant.

When used correctly, technical authors bring structure, compliance, and clarity to every stage of the information lifecycle. They turn documentation into a strategic enabler that supports ISO certification, ITSM frameworks, and information governance.

I didn’t gain this experience by taking on low-level contracts.
I built it by accepting complex, high-expectation assignments that demanded expertise — not routine.
Projects governed by ISO 27001, ISO 9001, PCI DSS, GDPR, and ITIL-aligned IT Service Management (ITSM) systems, where documentation wasn’t an afterthought, but a control in its own right.

From Document Writer to Information Strategist

Early in my career, I learned that a procedure is only as good as the system it supports.
As I advanced, I began designing those systems — integrating documentation with SharePoint, Asite, and enterprise knowledge bases to create traceable, auditable, and user-friendly environments.

That shift — from producing documents to architecting knowledge — is what separates an average writer from a documentation strategist.

Embedding ISO and Regulatory Frameworks

ISO 9001 — Quality Management

ISO 9001 demands consistency, clarity, and control. Technical authors design document templates, review workflows, and approval paths that prove process reliability. Well-structured documentation becomes part of the organisation’s quality evidence during internal and external audits.

ISO 27001 — Information Security

Under ISO 27001, documentation itself is a security control. Policies, risk registers, and incident procedures must align with the ISMS.
Experienced authors ensure classification, access permissions, and audit records are built into the documentation framework, not bolted on afterwards.

PCI DSS — Payment Card Security

PCI DSS requires clear operational documentation to evidence data protection. Authors provide traceable, reviewed, and controlled documents that survive audit scrutiny and demonstrate compliance with strict data-handling protocols.

GDPR — Data Protection and Privacy

GDPR compliance relies on transparency and accountability. Technical authors transform complex regulation into usable, plain-English policies: data-retention schedules, subject-access request processes, and breach-notification guides that staff can actually understand and apply.

Aligning Documentation with ITIL and ITSM

In IT environments, documentation underpins every ITIL and IT Service Management process:

      • Incident Management: Documenting escalation paths and resolution steps for service continuity.
      • Change Management: Recording change requests, approvals, and rollback plans to ensure traceability.
      • Problem Management: Capturing known errors and lessons learned to improve service quality.
      • Configuration & Asset Management: Maintaining controlled, versioned records of infrastructure and applications.
      • Service Continuity: Creating and maintaining recovery and resilience documentation aligned with ISO 22301.

A technical author versed in ITIL ensures that every process has the appropriate governance and documentation frameworks to meet compliance, audit, and service-delivery standards.

Aligning with Information Management and Document Control

Technical authors sit at the crossroads of Information Management (IM) and Document Control (DC) — translating policies into practice and ensuring that every piece of information has purpose, ownership, and lifecycle control.

      • In Information Management, authors define how data becomes information — creating naming conventions, metadata structures, taxonomies, and templates that keep repositories usable and compliant.
      • In Document Control, they understand versioning, approval hierarchies, baselining, and retention schedules — the mechanisms that give documentation its legal and operational validity.
      • Together, these functions ensure that knowledge doesn’t just exist, but is managed, retrievable, and auditable across departments, projects, and systems.

Where Information Management provides governance and Document Control enforces consistency, technical authors provide the structure and clarity that make both work.

The Modern Technical Author’s Toolkit

Today’s senior technical author is:

      • A strategist, aligning documentation with ISO, GDPR, ITIL, and corporate frameworks.
      • A planner, integrating documentation into project and service lifecycles.
      • A consultant, advising leadership on governance, information management, and document control.
      • A knowledge manager, ensuring content remains accurate, traceable, and secure.
      • A systems designer, configuring SharePoint or Asite to automate metadata, version control, and review cycles.

When you position your technical authors at this level, you gain more than documentation — you gain information assurance.

Experience Earned Through Expertise

Every project I’ve worked on — from ISO 9001 audits to 27001 ISMS documentation, from GDPR compliance to ITIL process alignment — has reinforced one truth:
Documentation is infrastructure.

It connects people, process, and technology.
It demonstrates governance and compliance.
And when managed properly, it becomes the backbone of every successful audit and transformation.

Final Thought

Technical authors who have grown through challenging environments understand how documentation supports the wider information ecosystem — policy, process, system, and control.

They close the gaps between communication and compliance, between information and evidence.

So before assigning your technical authors to “tidy up templates,” ask instead:

“Can this person help us align ISO, ITIL, and Information Management requirements into a single, coherent documentation strategy?”

If the answer is yes, you’re not hiring a writer.
You’re engaging a strategic partner in governance, compliance, and service excellence.

Beyond the Dash Debate: How AI Is Reshaping Writing and Technical Authoring Careers

Beyond the Dash Debate: How AI Is Reshaping Writing and Technical Authoring Careers

Writers and technical authors often debate AI’s punctuation quirks — from dash usage to tone. But while we’re arguing over commas, something larger is happening.
Artificial intelligence is not changing how we write; it’s changing why we write — and what value we bring when machines can generate text faster than we ever could.

The question isn’t whether GPT overuses em dashes.
It’s whether we’re ready to evolve beyond them.

1. From Author to Information Architect

AI can produce paragraphs in seconds, but it can’t design the logic behind them.
Tomorrow’s writers won’t just create content — they’ll become information architects who define structure, intent, and compliance.

In regulated environments such as the defence, nuclear, or financial sectors, AI still needs guidance on how to ensure documents comply with frameworks such as ISO 27001, ISO 9001, or PCI DSS.
Writers who understand these standards — and who can teach AI systems to follow them — will remain essential.

2. From Content Creation to Documentation Governance

The flood of AI-generated content means accuracy, version control, and authorship assurance have become critical.
This is where documentation governance takes centre stage.

Technical authors can pivot from writing to governing:

      1. Reviewing AI output for factual and procedural accuracy.
      2. Enforcing metadata and lifecycle rules within DMS tools like Asite or SharePoint.
      3. Building automated checklists and templates that ensure consistent document quality.

AI can draft — but humans must validate.

3. Human Interpretation Still Matters

AI can mimic tone and style, but it cannot sense how a message lands.
When a document must persuade, reassure, or instruct, context becomes everything.
Writers with empathy, domain understanding, and communication insight remain vital to bridging human and machine.

The technical author’s future lies in translation and interpretation: turning data into understanding, and ensuring meaning survives automation.

4. Ethics, Attribution, and AI Literacy

As organisations adopt AI-assisted documentation, they’ll face new ethical challenges:

      1. Who owns AI-generated content?
      2. How do we ensure traceability of information sources?
      3. How do we prevent bias and misinformation?

Writers and documentation specialists can lead the development of AI content policies, establishing governance frameworks and training programmes that uphold accuracy and transparency.

Becoming an AI-literate communicator is now as valuable as being a clear writer.

5. Adaptation, Not Extinction

AI doesn’t erase writing jobs — it redefines them.
Those who adapt will move from creators to curators, validators, and strategists.

Future-ready writers will:

      1. Design content architectures rather than just fill them.
      2. Develop governance systems that manage AI output.
      3. Train teams in writing assurance and ethical documentation.
      4. Blend communication, compliance, and creativity.

In short, they’ll stop being hands-on writers and start being writing strategists.

Conclusion: Evolving Beyond the Dash

So yes — debate GPT’s dash usage if you like.
But remember: punctuation debates won’t protect your profession.
Evolution will.

Writers who move toward governance, structure, and strategy will not just survive AI — they’ll define how it’s used.
The end of writing isn’t coming.
It’s simply the beginning of a new chapter.

Call to Action

If you’re a technical author or documentation manager looking to future-proof your role, start building skills in information architecture, AI literacy, and documentation governance.
Follow techwriting.co.uk for upcoming guides on adapting your documentation strategy in the AI era.