Month: March 2025

Bob learns to understand his teams titles.

Veteran corporate employee Bob attends a meeting of colleagues with fantastical titles. As introductions begin, Bob’s confusion grows.

First up is Nina, the Service Architect. Bob envisions her wearing a hard hat and drafting blueprints for the office Wi-Fi. In reality, Nina designs IT services to align with business needs. Bob jots down, “Tech blueprint artist.”

Next, Carlos introduces himself as a Change Specialist. Bob pictures him as a life coach, helping employees navigate mid-life crises. However, Carlos manages IT infrastructure changes, ensuring smooth transitions. Bob scribbles, “IT makeover expert.”

Then, Linda, the Incident Manager, speaks up. Bob imagines her in a detective trench coat, investigating office mishaps like missing staplers. Linda addresses IT incidents to restore services quickly. Bob notes, “Digital firefighter.”

Raj, the Release and Change Manager, follows. Bob thinks Raj must be in charge of the company’s press releases. Instead, Raj oversees the deployment of new IT services and their changes. Bob writes, “Tech launch coordinator.”

Tom, the Business Analyst, introduces himself. Bob assumes Tom spends his days with spreadsheets, analysing profits. While partially true, Tom also bridges the gap between business needs and IT solutions. Bob jots, “Corporate translator.”

Finally, Emma, the Technical Author, speaks. Bob pictures her penning sci-fi novels. In reality, Emma creates user manuals and documentation for IT services. Bob concludes, “Tech jargon interpreter.”

As the meeting progresses, Bob’s initial bewilderment turns into amusement. He realises that while traditional titles like electrician or plumber are straightforward, modern corporate roles come with a flair for creativity that requires some decoding.

Now Bob understands modern job titles better, even if they sound unusual.

 Just as he thinks he’s mastered the situation, Sophie, the Digital Strategy Consultant, walks in.

Bob’s mind races: “Digital Strategy Consultant? Is she here to teach us how to win at online chess?”

Sophie states, “I assist organisations in navigating the complexities of the digital landscape, aligning business objectives with technological solutions to foster growth and innovation.”

Bob scribbles in his notebook: “Digital compass bearer—guides us through the wilds of the internet jungle.”

By the end of the meeting, Bob’s head was spinning, but he chuckled to himself.

While traditional roles like electricians and plumbers are straightforward, navigating the modern corporate world feels like assembling a jigsaw puzzle without the picture on the box. Yet, with each piece—be it a Service Architect, Change Specialist, or Digital Strategy Consultant—Bob gains a clearer view of the intricate mosaic that keeps the company thriving in the digital age.

Why do managers struggle to understand their Technical Authors?

A common challenge for tech writers like me is that their managers often do not fully understand our roles. When managers underestimate our abilities, things are easier for them, but challenging for us.

Based on my experience, managers often overlook

    • the critical contribution of documentation to risk reduction, compliance, and operational efficiency.
    • Producing documentation requires significant effort.
    • The cross-functional nature of our work can create confusion about team assignments. Say we have change management experience in the creation of flows and narratives. It led to a placement in business change where we possess the knowledge but not the expertise.
  • Difficulty in Justifying ROI to Clients
      • Clients see documentation as a “nice-to-have” rather than a must-have—until something goes wrong (e.g., legal disputes, compliance failures).

Managers struggle to understand how documentation:

      • Reduces support costs (fewer customer complaints)
      • Ensures compliance (avoids regulatory penalties)
      • Speeds up onboarding (reduces training costs

The misconception that AI or SMEs can replace us by writing documentation, or that AI tools can auto-generate content. Small businesses often don’t have technical writing skills, and AI content needs a person to check it for correctness, meaning, and how easy it is to use.

How can we address these challenges?

  1. Educate Managers on the Value of Documentation
        • Show real-world cost savings (e.g., reduced rework, fewer customer complaints).
        • Highlight case studies where poor documentation caused project delays or legal risks.
    2. Push for Strategic Placement in the Organisation
      • Place this under Quality, Knowledge Management, or Digital Strategy (if it helps the business).
      • Position documentation as a core business function, not as an afterthought.

3. Demonstrate Our Expertise Beyond Writing

      • Emphasise our role in governance, process improvement, content structuring, and compliance.
      • Showcase technical authors as information architects rather than just writers.

Interested in a proposal to improve how your organisation uses technical authors? Ask me?

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.

Originality vs. Repetition in Technical Writing: New Insights or Rehashed Information?

You can’t miss the articles written by new technical authors on LinkedIn. Most of these articles contain the same message I read 20+ years ago. These lack originality; pursuing them risks plagiarism. For instance, many new technical articles repeat the same advice or insights as those published years ago.

I started my career as a technical author over twenty years ago and began blogging when I launched my website in 2004 (www.techwriting.co.uk). These days, I often ponder writing an original article. Can I provide new insights, or is it better to repackage existing knowledge? My recent posts have taken a deeper dive into familiar topics, with explanations that have improved with experience. Reflecting on past technical articles, I often seek ways to add my perspective.

The Stagnation of Fundamental Principles

The way I approach my job and the principles I use as a technical writer have remained unchanged despite technological changes. Between 1997 and 2004, my software work included EDIs. Today, we call them APIs. The design of APIs has remained consistent for the past 20 years, highlighting that originality is more about presentation than content. This is especially evident when you review technical articles published over that time frame.

Common Themes and Content Patterns

Repeated themes are common in technical writing. Many articles cover similar topics, leading to information overload. This issue is especially prevalent in large organisations where teams often duplicate documentation. In many teams, technical articles tend to follow predictable patterns and similar structures throughout.

While on a contract, one developer pointed to duplicate articles aimed at new starters. During my analysis, I discovered new starters were reading the wrong information. They missed the updates because the authors did not announce their publication or location. Duplicating technical articles without proper version control can easily lead to confusion among readers.

Examples of Repetitive Content Patterns:

Overlapping internal documents between departments confuse and slow things down. Repeated legal and safety warnings in technical manuals contribute to monotony. I used to work at a company where each business unit had its own way of managing changes, incidents, and similar tasks. If a company-wide problem occurs, how will different departments coordinate their responses? Clearly, technical articles on these subjects end up echoing the same principles over again.

Managing Repetition: Content Reuse and Modular Writing

Technical writers employ various strategies to manage repetition. I adhere to the “Don’t Repeat Yourself” (DRY) principle, “Don’ts promotes Content reuse over duplication. Using CMS lets me write and reuse content I’ve created anywhere, preventing inconsistencies. Modular writing is another effective technique. For consistent quality, technical articles are often structured around modular writing and content reuse strategies.

This method divides content into reusable parts that can be combined to create different documents. It is employed in healthcare, engineering, and software documentation. As industries evolve, the creation of technical articles has benefitted greatly from modular and reusable writing methods.

Industry-Specific Trends: Finding the Balance

Different industries take varied approaches to balancing originality and repetition in technical writing: – Writers working in software, engineering and medical fields often produce technical articles tailored to regulatory requirements and audience needs.

  • Software Documentation: Because of rapid technological advances, software documentation often requires frequent updates. The structure of API references, user guides, and troubleshooting sections has remained the same over the years. Writers in this field prioritise clear and accessible writing over introducing new ideas. It is not surprising that technical articles tend to preserve similar structures for ease of use.
  • Engineering and Manufacturing: Technical documentation in these sectors prioritises accuracy and compliance over originality. Manuals and safety guidelines must be consistent and precise, which often results in high levels of content reuse. – Therefore, many technical articles across engineering are nearly identical except for specific details.
  • Healthcare and Medical Writing: Medical writers must use consistent wording to meet regulations, even if it limits creativity. Medical technical articles frequently rely on templates and repeated sections.

Striking the Right Balance

While much of technical writing involves repetition, this does not mean that originality is absent. Writers create value not by inventing additional facts but by presenting accessible information. To improve the impact of technical articles, aiming for clarity and thoughtful structure matters more than total originality.

Good tech docs are clear, consistent, and efficient, giving users what they need without repeating information. Readers should find technical articles both reliable and user-friendly.

As the industry strengthens, AI-driven content reuse and intelligent authoring tools make it easier to maintain consistency. Writers should focus on areas where they can offer genuine insights. The key takeaway? Repetition in technical writing isn’t always a flaw, but a necessary element of effective communication. Good technical writers avoid redundancy and offer new viewpoints. Going forward, technical articles will likely keep balancing originality and consistency as foundational goals.