Month: February 2026

The Quiet Expansion of the Technical Author Role

Many technical authors quietly move into project management and governance roles without the title ever changing. Experienced technical authors often coordinate work, manage risks, and design documentation strategies. Is the job title technical author holding the profession back?

Tweet
Pin
Share
0 Shares

Some months ago, I suggested that our job title does not support a technical author’s career progression as we take on additional tasks, such as project management.

It defines us as writers, even though many of us have quietly become something much broader.

My question:

How many technical authors have gradually taken on additional responsibilities without ever changing their job title?

And how many of us have done project management work simply because no one else understood how documentation actually works?

It happens more often than people realise.

Technical authors rarely stay confined to writing manuals.

Over time, most experienced technical authors develop deep knowledge of systems, processes, and operational environments. That knowledge naturally pulls them into wider roles.

Research shows that technical writing is often a springboard into roles such as project management, product management, quality assurance, and business analysis because writers accumulate extensive organisational and technical knowledge.

Many technical authors never formally move into new roles; we simply absorb extra responsibilities.

Documentation work is already project management

Much of what experienced technical authors do already overlaps with project management.

Senior documentation roles often include:

      • Prioritising work
      • Defining documentation strategy
      • Coordinating contributors
      • Managing review cycles
      • Reporting progress

These are recognised project-management responsibilities in documentation environments.

Many technical authors manage:

      • Documentation schedules
      • Review cycles
      • Deliverables
      • Risks
      • Dependencies
      • Stakeholders

Without ever being called project managers.

The skills overlap is not accidental

Project management research identifies core skills such as:

      • Communication
      • Organisation
      • Leadership
      • Technical understanding

These are the same skills technical authors use every day.

Technical authors succeed because they:

      • Interview subject matter experts
      • Coordinate contributors
      • Structure complex information
      • Track document progress
      • Identify gaps
      • Solve process problems

These are not purely writing activities.

They are delivery activities.

The reality on many projects

Project managers often understand delivery milestones but not documentation lifecycle requirements.

This creates a gap into which technical authors step.

Many of us have found ourselves responsible for:

      • Incident management documentation
      • Disaster recovery documentation
      • Operations manuals
      • ITIL-aligned processes
      • ISO 27001 documentation
      • ISO 9001 quality documentation
      • Data centre migration documentation
      • Knowledge repositories

Not because it was in the job description. Because someone had to do it.

The Unofficial Project Manager

It is not unusual for a technical author to become the unofficial project manager for documentation.

Technical writers may even move formally into project management or leadership roles, or manage documentation teams and projects as their careers progress.

But many never do.

The title stays the same.

The responsibilities expand.

When the project manager doesn’t understand the documentation

One common situation is where:

      • The project manager understands schedules and budgets
      • The technical author understands deliverables and structure

When documentation is poorly planned, the technical author often becomes the person who:

      • Defines what must be delivered
      • Structures the repository
      • Establishes review routes
      • Identifies missing inputs
      • Keeps documentation moving

Without that intervention, documentation often becomes chaotic.

The hidden expertise

Experienced technical authors often know far more than their job titles suggest.

Years of working across projects create knowledge in areas such as:

      • IT service management
      • Information governance
      • Document control
      • Audit preparation
      • Operational readiness
      • Knowledge management

This knowledge is rarely visible on an organisation chart.

But projects depend on it.

Know your Technical Author

Many organisations underestimate technical authors because of the title.

“Author” sounds narrow.

“Writer” sounds administrative.

The reality is usually very different.

Some technical authors have quietly been:

      • Documentation strategists
      • Information managers
      • Process designers
      • Governance specialists
      • Delivery coordinators

And sometimes project managers in everything but name.

The real question

So here is the real question:

How many technical authors have been doing project management work for years without being recognised for it?

And perhaps an even better question:

Is the title technical author no longer big enough to describe the role?

Don’t Overlook the Technical Author: A Question for Project Managers

Project managers often bring technical authors in too late. Experienced technical authors can reduce delivery risk by shaping documentation early—supporting IT audits, ITIL-aligned processes, ISO 27001/ISO 9001 controls, disaster recovery packs, incident and change management, and operations manuals. Know your technical author before you assume their limits.

Tweet
Pin
Share
0 Shares

Here is a question for project managers:

How many projects did you manage where the team treated the technical author as an afterthought or excluded them entirely?

It happens more often than it should. Project managers view documentation as something to “do at the end”, once the teams finish the proper work and the delivery pressure is at its peak.

That is when teams discover the cost of leaving documentation too late.

By the time the project is in closure mode, you have already missed the point where a technical author adds the most value.

The mistake: assuming the technical author is “just a writer”

Many project managers underestimate what an experienced technical author actually does. They think we:

      • only polish text,
      • rewrite technical material in plain English,
      • only fix formatting.

That is only one part of the job.

Technical authors understand IT operations and governance. They have documented services for years. This experience extends to audits. They know how to gather evidence.

What an experienced technical author may already know

A technical author may already have delivered documentation for:

      • IT audits and compliance preparation
      • Disaster recovery (DR) documentation
      • Operations manuals and runbooks
      • Incident, problem, and change management processes
      • Service transition documentation
      • Knowledge base and repository design
      • Information governance and document control
      • Data centre migration documentation
      • ITIL-aligned documentation structures
      • ISO 27001 and ISO 9001 aligned document frameworks

These are not theoretical skills. They come from being repeatedly embedded in delivery and operational environments across different organisations and clients.

The risk: documentation gaps that become delivery risks

When you exclude technical authors from early planning, projects often run into the same problems:

      • They discovered the documentation gaps late.
      • Missing operational detail that prevents handover
      • Inconsistent terminology and process steps
      • Rework caused by unclear ownership and review routes
      • Poorly structured repositories that no one can navigate
      • Evidence gaps that become audit risks
      • Last-minute “document sprints” that no one has time for

These issues are rarely “writing problems” but planning problems which are avoidable.

Know your technical author before you assume their limits

Every technical author has a unique history. Some come from engineering, some from software and infrastructure, some from compliance-heavy environments, and some from service operations.

You will not know what capabilities you have access to unless you ask.

Here is a simple, early-project habit that saves pain later:

Sit down with the technical author and establish what they’ve done before.

Ask questions like:

      • What types of projects have you supported?
      • What frameworks do you work with (ITIL, ISO 27001, ISO 9001)?
      • What operational documentation have you delivered (DR packs, ops manuals, runbooks)?
      • What documentation risks do you expect on a project like this?
      • What do you need from the team to avoid last-minute document chaos?
      • You may find they know more about documentation governance, operational readiness, and audit evidence than you expected.

Documentation is not an output. It is part of the delivery.

Documentation is not a box to tick at the end.

It is part of how projects:

      • reduce operational risk
      • pass audits
      • transfer knowledge
      • support teams
      • enable safe change
      • transition into BAU without firefighting

A technical author is not “just the person who writes things down”.

A strong technical author is often one of the few people on a project who thinks in terms of:

      • structure
      • lifecycle
      • traceability
      • usability
      • governance
      • evidence

Last point: never overlook the technical author

If you want better delivery outcomes, involve documentation earlier and treat it as a work stream with ownership and design—not a clean-up job.

Never overlook the technical writer.

Because the best technical authors are not just documenting your project.

They can make it work.

Have you ever consulted your technical author on previous deliverables to identify and reduce project risks?

Death by Template: When a Blank Word File Becomes “Governance”

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.

Document Strategy vs Document Plan: Why Most Organisations Get It Wrong

Introduction

In the world of technical authoring and information management, people often use two terms interchangeably, but understanding your document strategy is key to approaching both effectively.

      1. Document strategy
      2. Document plan

They are not the same.

Confusing them is one of the main reasons documentation becomes reactive, inconsistent, and vulnerable to managerial interference.

If management treats documentation as administrative output rather than a governed asset, it will always sit at the whim of whoever speaks loudest.

This article explains:

      1. What a document strategy actually is
      2. What a document plan does
      3. Why governance matters?
      4. What must senior technical authors implement to protect documentation assets?

What is a document strategy?

A document strategy defines how documentation supports organisational objectives. It is not:

      • a list of deliverables.
      • a collection of templates.
      • a SharePoint structure.

It answers fundamental questions:

      • Why does documentation exist in this organisation?
      • What risk does it mitigate?
      • What decisions must it support?
      • What compliance obligations must it satisfy?
      • Who owns it?

In regulated environments, document strategy connects directly to standards such as

      • ISO 9001 (Control of Documented Information)
      • ISO/IEC 27001 (information security controls)
      • ITIL (service documentation and knowledge control)

If documentation is required for audit, certification, or regulatory compliance, you must govern it strategically.

What a proper document strategy includes

A credible document strategy defines:

1. Governance Model

      • Clear document ownership
      • Defined author vs reviewer vs approver roles
      • RACI alignment
      • Escalation routes

2. Lifecycle Control

      • Create → Review → Approve → Publish → Maintain → Retire
      • Mandatory review cycles
      • Version control standards
      • Archiving criteria

3. Classification and Security

      • Controlled vs uncontrolled documents
      • Public vs restricted
      • Security classification tiers

4. Architecture and Structure

      • Taxonomy
      • Metadata standards
      • Naming conventions
      • Document numbering schemas

5. Decision Framework

      • What qualifies as controlled documentation?
      • What does not?
      • When documentation is proportionate
      • When a knowledge article is sufficient

Without these elements, documentation becomes personality-driven rather than policy-driven.

What is a document plan?

A document plan is operational.

It applies the strategy to a specific project, programme or service.

Where strategy defines governance, the plan defines delivery.

It answers:

      • What documents are required?
      • Who is writing them?
      • When are they due?
      • What reviews are mandatory?
      • What approvals are needed?
      • How do they align with stage gates?

In complex programmes — such as digital transformation, DMS rollout, or security accreditation — a document plan ensures traceability and sequencing.

Without a document plan, documentation is:

      • Rushed at the end
      • Inconsistent across work streams
      • Duplicated across teams
      • Politically rewritten

Why Documentation Falls “at the whim of managers”

Documentation becomes unstable when:

      • There is no documentation policy
      • Templates are uncontrolled
      • Metadata is optional
      • No audit mechanism exists
      • No one owns lifecycle enforcement

In that vacuum, managers step in.

They introduce:

      • New templates
      • Personal preferences
      • Structural changes
      • Ad hoc requirements

The result is entropy.

Governance prevents that.

What technical authors must do beyond writing

Senior technical authors must move beyond content production.

They must act as:

      • Information architects
      • Governance stewards
      • Lifecycle controllers
      • Risk mitigators

Below are the controls that protect documentation assets.

1. Establish documentation governance

Create:

      • Documentation Policy
      • Document Control Procedure
      • RACI matrix
      • Change management workflow for templates

Ensure:

      • Template changes require approval
      • New document types require justification
      • eliminate uncontrolled versions

2. Enforce metadata and taxonomy

Metadata is not optional in mature environments.

Define mandatory fields such as:

      • Document Owner
      • Service Area
      • Security Classification
      • Review Date
      • Version Number

Implement enforcement within:

      • SharePoint libraries
      • Asite or DMS platforms
      • Controlled repositories

If you do not enforce metadata, the structure collapses.

3. Institute review discipline

Set:

      • Annual review cycles (minimum)
      • Risk-based review frequency
      • Automated reminders
      • Expiry flags

Outdated documentation creates audit exposure.

4. Run documentation audits

Introduction:

      • Quarterly sampling
      • Annual full audit
      • Traceability verification
      • Redundancy elimination

Without an audit, decay is inevitable.

5. Design templates that enforce structure

Most engineers and technicians do not read style guides.

They follow structure.

Well-designed templates:

      • Force styles
      • Control numbering
      • Embed guidance
      • Reduce formatting drift
      • Prevent structural inconsistency

Templates are governance tools disguised as formatting aids.

6. Define what not to document

Over-documentation creates noise.

A strong document strategy specifies:

      • What must you control?
      • What belongs in a knowledge base?
      • What remains in the service tools?
      • What is transient and disposable?
      • Clarity reduces clutter.

Document strategy maturity model

Organisations typically sit at one of these levels:

Level Description
Level 1 Ad hoc and personality-driven
Level 2 Template-based but uncontrolled
Level 3 Defined lifecycle and metadata
Level 4 Audited and measured
Level 5 Strategically aligned to risk and performance

Most organisations sit between Level 1 and Level 2.

A mature technical author moves them to Level 3 and beyond.

The critical distinction

      • Document Strategy = Governance + Risk Alignment + Structure
      • Document Plan = Delivery + Scheduling + Accountability
      • Ongoing Stewardship = Control + Audit + Discipline

Writing is only part of technical writing.

Control is the real work.

Final Thought

If A.N. Other can alter documentation at will, it is neither governed nor strategic.

And if it is not strategic, the user will not treat it as a corporate asset.

When Is a Document Strategy Not a Strategy?

A practical guide for organisations that want governance to work

Tweet
Pin
Share
0 Shares

A practical guide for organisations that want governance to work

In many organisations, a document strategy looks impressive.

      • It has executive sponsorship.
      • It references digital transformation.
      • It talks about lifecycle, governance, compliance, and knowledge reuse.

And yet — nothing changes.

      • Documents are still duplicated.
      • Templates are ignored.
      • Review cycles drift.
      • Audit findings repeat.

At that point, the issue is not the document strategy itself. The issue is how the organisation treats the strategy document as the outcome, rather than as a mechanism for decision-making.

This article examines when a document strategy stops being strategic — and how to recognise the difference between a living governance framework and a glossy artefact.

What is a document strategy?

A document strategy should define:

      • How information is created

      • How it is controlled

      • How it is reviewed

      • How it is distributed

      • How it is kept or archived

      • Who is accountable at each stage?

In regulated environments — particularly those aligned with ISO 27001, ISO 9001, PCI-DSS, nuclear, defence, or financial services — this is not optional. Documentation underpins audit defensibility and operational resilience.

However, a document strategy becomes ineffective when it fails to influence real-world behaviour.

1. If it avoids constraints, it is not a strategy

A genuine strategy makes trade-offs.

It defines constraints such as:

        • Budget limits

        • Tooling capability

        • Cultural maturity

        • Political appetite for enforcement

        • Regulatory exposure

If a document strategy attempts to optimise for:

        • Speed

        • Full compliance

        • Zero friction

        • Maximum flexibility

        • Minimal cost

Simultaneously, it is not strategic. It is aspirational.

For example:

      • You cannot have complete audit traceability without adding some process overhead.

      • You cannot maintain full template discipline while allowing unlimited author freedom.

      • You cannot achieve a single source of truth without closing down local storage practices.

Strategy requires subtraction. If nothing is excluded, nothing is prioritised.

2. If it does not change governance, it is Theatre

A document strategy must show up in operational systems.

You should see its fingerprints in:

      • Metadata schemas

      • Document numbering conventions

      • Version control rules

      • Approval workflows

      • Access permissions

      • Review cycles and SLAs

      • Archival and retention schedules

If your strategy claims to be a “single source of truth” but documents continue to sit on local drives, shared mailboxes, and uncontrolled Teams folders, then the strategy has not reshaped behaviour.

If it promises improved knowledge reuse but there is no taxonomy, no tagging discipline, and no ownership of content review, it remains rhetoric.

A useful test is this:

      • Did the strategy alter the document lifecycle?

      • Did it remove duplicate repositories?

      • Did it redefine what “approved” means?

      • Did it assign clear accountability?

If not, it is governance theatre.

3. If it cannot be operationalised, it is Philosophy

Strategic language often becomes abstract.

      • “Drive digital transformation.”

      • “Enhance collaboration.”

      • “Embed knowledge excellence.”

These statements are ambitions, not mechanisms.

Operational strategy answers concrete questions:

      • Who owns lifecycle integrity?

      • What is the RACI model?

      • What happens when review deadlines are missed?

      • What constitutes a controlled document?

      • What is the escalation path for non-compliance?

      • What is the maximum tolerated duplication level?

If delivery managers and technical authors cannot convert the strategy into day-to-day rules, then it is conceptual rather than actionable.

In high-compliance sectors, this gap becomes visible during audits. Auditors increasingly test evidence of implementation, not the existence of documentation.

4. If it does not influence decisions, it is Decorative

A real document strategy shapes:

      • Recruitment decisions

      • Tool selection

      • Investment priorities

      • Change control

      • Incident response

      • Audit preparation

If no board paper references it, if no funding decision cites it, and if no hiring decision reflects it, then it is decorative.

A strategy that is only opened during audit season is not embedded.

5. If it is written only for executives, it will fail

Authors write strategies in executive language:

“We will implement a structured document lifecycle aligned to industry best practices.”

Delivery teams interpret this as:

“Another template change.”

If engineers, technicians, and operational staff cannot explain what the strategy means for their daily work, the communication has failed.

Clarity is structural. Not cosmetic.

In environments where engineers write occasionally rather than professionally, a well-designed template with enforced styles often achieves more than a 30-page style guide.

If the strategy does not account for real author behaviour, it will be bypassed.

6. If it ignores culture, it is naive.

People do not resist governance for ideological reasons. They resist friction.

If your document strategy increases:

      • Form complexity

      • Metadata burden

      • Approval latency

      • Review bottlenecks

Without demonstrating value, users will route around it.

A realistic strategy accounts for:

      • Author maturity

      • Training capability

      • Tool usability

      • Political support for enforcement

It does not assume ideal behaviour.

The Digital Strategy Problem

Digital strategies often attempt to solve everything at once:

      • Content management

      • Knowledge management

      • Collaboration

      • Automation

      • AI

      • Governance

      • Records management

      • Compliance

      • Cultural change

This breadth dilutes focus.

A disciplined document strategy might say:

For the next 24 months, our priority is lifecycle control and audit defensibility. Automation and AI integration are out of scope.

That level of constraint is strategic clarity.

A Practical Test for Organisations

To assess whether your document strategy is real, ask three questions:

      1. What decision did we make differently because of this strategy?

      2. What did we deliberately choose not to do?

      3. Who would notice if we ignored it?

If no one would notice, it is not a strategy.

What a real document strategy looks like

A credible document strategy:

      • Defines constraints

      • Forces trade-offs

      • Embeds into tooling configuration

      • Alters decision rights

      • Clarifies accountability

      • Survives audit scrutiny

      • Is understood at operational level

      • Drives measurable change

In regulated and compliance-heavy environments, strategy is not narrative. It is architecture.

If it does not reshape structure, authority, and process, it is branding. Branding is not a strategy.