Category: knowledge base

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.

The Hidden Cost of Cutting Your Technical Author

The Hidden Cost of Cutting Your Technical Author

When budgets shrink, technical authors and documentation teams are often the first to be cut. It’s easy to justify — “We already have the templates.”
But removing or not replacing your technical author rarely saves money. It hides the cost until it explodes.

1. Knowledge Loss

A technical writer understands how different parts of documentation fit together.
When they leave:

      • Knowledge silos collapse.
      • People work from outdated copies.
      • Time is wasted rediscovering old lessons.

The cost of confusion soon outweighs the saved salary when a technical author is missing.

2. Compliance and Audit Risk

Accurate documentation underpins certifications such as ISO 9001, ISO 27001, PCI DSS, GDPR, and ITIL.
When documents are out of date or mislabelled:

      • Audit evidence disappears.
      • Nonconformities multiply.
      • Certification renewals become a gamble.

Even one mismatched title or missing version record can result in audit failure. Without the oversight of a technical author, these issues are more likely to occur.

3. Operational Inefficiency

Without a technical author:

      • Everyone edits documents their own way.
      • Version control collapses.
      • People spend hours searching instead of producing.

It’s not efficiency — it’s chaos disguised as productivity. A skilled technical author maintains order.

4. Loss of Professional Polish

Documentation is a reflection of your organisation’s competence. When quality drops:

      • Clients notice inconsistent tone and structure.
      • Reports lose credibility.
      • Your brand looks disorganised.

A technical author provides the invisible glue that holds professional standards together.

5. Increased Risk and Cost

When no one owns the documentation:

      • Processes contradict each other.
      • Projects lose traceability.
      • Clients misinterpret requirements.

Eventually, you’ll hire a contractor to rebuild the documentation ecosystem — and pay three times what you “saved.” A technical author prevents these costly mistakes.

6. Demoralised Teams

Without a dedicated author:

      • Engineers are forced to write in their spare time.
      • Quality suffers because writing is not their priority.
      • Ownership disappears — and so does accountability.

Documentation becomes everyone’s side job and nobody’s responsibility. Here, a technical author provides much-needed oversight.

⚙️ In Summary

Short-Term Thinking Long-Term Reality
“We’ll save a salary.” You’ll pay three times more later to fix it.
“Anyone can write.” Not everyone can structure or govern documents.
“We have templates.” Templates without governance are worthless.
“We’ll update later.” “Later” becomes “never” — and non-compliance follows.

My Final Thought

Removing your technical author isn’t cost-saving. It’s cost-shifting.
You’re trading short-term budget relief for long-term operational debt. The moment a compliance audit or client review exposes the cracks, the real bill arrives

Technical Author: How Simple or Easy Is our job?

Let’s start with a question: what skills are essential for excelling in a technical author job?

      1. How many of you have technical authors on your team but do not know what they do?
      2. Have you tried to fit them in somewhere, or wanted to find them a role and failed?
      3. Have you written technical documentation for a client? If so, how did it go?

You may have given up trying to understand their role, thinking you should upskill them to meet your priorities. You might not grasp what technical authors contribute in their jobs and underestimate their potential.

Let’s examine the issue.

Managers often perceive technical authoring as “writing documents.” However, in reality, it is a complex, multidisciplinary role that requires expertise in several areas. One important area is understanding the technical author’s job in depth:

Understanding Technical Information

Technical authors translate complex concepts into clear, user-friendly documentation that is easy to understand. They engage with Subject Matter Experts (SMEs), interpret complex jargon, and ensure the accuracy of the information presented.

Structuring and Standardising Content

They do more than write. Technical writers need to work with formatting, templates, metadata, and indexing, which makes their job complex.

Managing Multiple Stakeholders and Reviews  

Technical authors liaise with stakeholders and end users, each with different priorities and expectations.

The process involves multiple reviews by experts, who underestimate the work required to improve the documents. This aspect is a key part of their jobs.

Adapting to Evolving Tools and Technologies  

From document management systems (DMS) like SharePoint, Confluence, and Asite to API documentation tools, technical authors must stay up-to-date with the constantly evolving industry standards. AI and automation are changing the nature of jobs and making technical writing more complex.

Balancing Quality with Deadlines  

Managers don’t always prioritise documentation, which means writers have to finish it quickly, but still produce great work.

They must work within strict project deadlines while ensuring accuracy, compliance, and usability. These demands highlight the challenges inherent in a technical author’s job.

Why do managers struggle with technical authors and their role? Let me know in the comments.

How do you manage a knowledge base for a project in the development phase.

Managing a knowledge base for a project in development is not just a task, but a crucial step towards empowering every team member with time-saving information. So, how do you efficiently manage a knowledge base for a project in the development phase? Here are some steps to handle this:

  •  Centralised Knowledge Repository
        • Choose a platform: Select a platform that suits your team’s needs. Options include Confluence, Notion, SharePoint, or a well-organised GitHub repository.
        • Organise Information: Create a structured outline with categories, such as
          • project overview,
          • technical documentation,
          • meeting notes,
          • feature specifications, and
          • troubleshooting guides.
  • Documentation Standards
        • Define Standards: Establish documentation standards and templates to ensure consistency. Include guidelines for writing style, formatting, and required sections for each document type.
        • Regular Updates: update documentation to reflect the latest developments and changes in the project.
  • Version Control
        • Track Changes: Remember to use version control for technical specifications and code, using tools like Git or integrated features in platforms like Confluence. Version control enables you to track document changes throughout their lifecycle, making it easier to revert to a previous version if necessary. 
        • Change Logs: Maintain a change log to record significant updates or revisions to the documentation.
  • Access and Permissions
        • Set Permissions: Define who can view, edit, and manage different knowledge base sections to maintain control and prevent unauthorised changes. Do this through the platform’s settings or by assigning roles to team members.
        • Ease of Access: Ensure the knowledge base is easily accessible to all team members, with intuitive navigation and search functionality.
  • Collaboration and Feedback
        • Encourage Contributions: The knowledge base is not just a repository of information, but a collaborative space. It’s a place where every team member can contribute, fostering a sense of camaraderie and shared responsibility. Implement a review process to ensure the accuracy and quality of the contributions. 
        • Feedback Mechanism: allow team members to provide feedback on the documentation, suggesting improvements or reporting issues.
  • Training and Onboarding
        • Onboarding Materials: Create onboarding materials for new team members, including guides on how to use the knowledge base and where to find critical information.
        • Training Sessions: Conduct regular training sessions or workshops to ensure all team members know the knowledge base and its importance.
  • Integration with Development Tools
        • Tool Integration: Integrate the knowledge base with your development tools (e.g., Jira, Slack, Trello) to streamline workflows and ensure documentation is part of the development process.
        • Automation: Automation updates documentation based on project management tools or codebase changes.
  • Regular Audits and Maintenance
        • Periodic Reviews: Schedule regular audits of the knowledge base to ensure the information is still relevant and up-to-date and the accuracy and relevance of the information you rely on.
        • Clean Up: Remove outdated or redundant information to keep the knowledge base lean and valuable.