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?

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.

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?