Category: Technical Writing

Technical Writer, UX Writer or Copywriter: What Writer Are You?

A clear comparison of technical writers, UX writers, copywriters, content strategists, content managers and content writers, with examples of each role.

Tweet
Pin
Share
0 Shares

People often confuse technical and digital writing roles. The job titles sound similar, but the focus, skills, and outcomes can differ significantly. For newcomers to workplace writing, that confusion can make it difficult to understand where they fit.

This guide explains the main differences between technical writers, UX writers, content strategists, content managers, copywriters and content writers.

Technical Writer

Focus: Creating documentation for technical products, services, systems or processes.

Typical work includes:

      • Software user manuals
      • Product guides
      • API documentation
      • Operational procedures
      • Process documentation
      • Policy documentation

Skills: Technical understanding, structured writing, audience awareness, interviewing SMEs, and clearly explaining complex information.

Difference: Technical writers focus on accuracy, usability and operational clarity. The audience may be technical, non-technical or mixed, depending on the document.

Example contexts: Software documentation, infrastructure documentation, maintenance manuals, medical device documentation and regulated process documentation.

UX Writer

Focus: Writing the words users see when interacting with software, websites or apps.

Typical work includes:

      • Button labels
      • Menu items
      • Error messages
      • Onboarding steps
      • Help text within an interface

Skills: User experience principles, concise writing, usability thinking and close collaboration with designers and developers.

Difference: UX writers shape the user’s interaction with a product. Their work is usually short, precise and embedded directly in the interface.

Content Strategist

Focus: Planning how content supports business goals and user needs.

Skills: Content planning, SEO, audience analysis, governance, measurement and lifecycle management.

Difference: Content strategists work at a planning level. They decide why content is needed, who it is for, how it should be managed and how success will be measured.

Example contexts: Website content strategy, brand content planning, governance models, campaign planning and content audits.

Content Manager

Focus: Managing the creation, editing, publishing and maintenance of content.

Skills: Project management, content management systems, editorial planning, SEO awareness, workflow management and governance.

Difference: Content managers oversee content operations. They may not write everything themselves, but they ensure content is produced, reviewed, published, and maintained.

Copywriter

Focus: Writing persuasive marketing and promotional content.

Typical work includes:

      • Advertising copy
      • Website sales copy
      • Email campaigns
      • Landing pages
      • Product descriptions
      • Social media promotions

Skills: Persuasion, brand voice, marketing awareness and writing designed to encourage action.

Difference: Copywriters focus on engagement, conversion and promotion. The purpose is usually to sell, persuade or influence.

Content Writer

Focus: Producing articles, blog posts and other informative content for an audience.

Typical work includes:

      • Blog posts
      • Articles
      • White papers
      • Reports
      • Newsletters

Skills: Research, clear writing, SEO, tone adaptation and audience engagement.

Difference: Content writers inform, educate or entertain. Their work often supports marketing, thought leadership or search visibility.

Which Writer Are You?

The distinctions matter because each role solves a different problem.

      • technical writer reduces confusion around complex information.
      • UX writer improves the user journey.
      • Copywriter persuades.
      • Content strategist plans.
      • Content manager governs. A content writer informs.

Many writers move between these roles, and some jobs combine several of them. The important question is not only what you write, but why the content exists and what outcome it must support.

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.

From Complexity to Clarity: The Technical Authoring Way

Technical authors bridge the gap between complexity and clarity. Learn how structure, empathy, and plain English create documentation people actually use.

Tweet
Pin
Share
0 Shares

Every organisation wrestles with complexity. Systems evolve, processes multiply, and acronyms breed faster than understanding. Technical authoring becomes crucial in such scenarios. Somewhere in that tangle, people stop reading, stop following, and start guessing. That’s when errors creep in, efficiency drops, and the documentation everyone thought existed suddenly becomes “that thing we’ll fix later.”

That’s where the technical author steps in, uniquely skilled in technical authoring to bridge these gaps.

A technical author’s purpose is not only to write — it’s translating complexity into clarity. We work at the intersection of engineering, IT, and communication, ensuring that processes, systems, and knowledge are usable, repeatable, and understood. Our craft is part detective work, part design thinking, and entirely focused on the reader.

Understanding the Reader’s World

Clarity begins with empathy. Technical authors spend much of their time understanding the user’s context — their goals, frustrations, and level of technical knowledge. Whether we’re documenting an API, a SharePoint governance plan, or a safety-critical engineering process, our first question is always the same:

“Who needs this information, and what do they need to do with it?”

That question shapes everything that follows — the structure, language, and format. It’s how we transform information from a data dump into a valuable and actionable resource.

Structure Is Strategy

Good documentation doesn’t happen by chance. Behind every clear paragraph lies a strategy: a taxonomy that defines where information lives, a naming convention that ensures consistency, and metadata that keeps documents findable long after the author moves on.

We know that clarity isn’t just what’s written — it’s how information is organised. That’s why technical authors create templates, workflows, and metadata standards to keep projects aligned. Without that structure, documentation collapses under its own weight.

Plain English Is Powerful English

There’s a common misconception that plain English means dumbing things down. In reality, it’s about respecting the reader’s time, a critical aspect of effective technical authoring.

Technical authors strip away unnecessary jargon, long sentences, and layered clauses. We use verbs instead of nouns, bullets instead of paragraphs, and examples instead of assumptions. Every word earns its place. When you write clearly, you make expertise accessible — and that’s where value lies.

Bringing Order to Chaos

Many projects underestimate the effort required to manage documents. Policies change, templates evolve, and revisions accumulate. The result? Duplicated content, mismatched titles, and version confusion.

Technical authors bring order to this chaos. We align document titles with content, maintain traceability, and ensure that every document serves a defined purpose. When audits come — ISO 27001, PCI DSS, or client compliance — that clarity is the difference between approval and failure, all thanks to proficient technical authoring.

The Hidden ROI of Clarity

Clear documentation saves time, reduces risk, and improves quality. It prevents engineers from reinventing the wheel and keeps managers aligned with process changes. But beyond efficiency, clarity builds trust. When users see well-structured, accessible documentation, they gain confidence in the system and the organisation behind it.

The Technical Authoring Way

The “technical authoring way” isn’t about words — it’s about outcomes. It’s about helping people do their jobs more effectively, efficiently, and with fewer errors. It’s about ensuring that complex systems can be understood, maintained, and improved long after the project closes.

In a world that rewards speed, clarity is still the ultimate accelerator.

Reflective question:

When was the last time your organisation reviewed whether its documentation informs or merely describes?

#TechnicalAuthoring #PlainEnglish #InformationManagement #DocumentationStrategy #ClarityInCommunication #KnowledgeManagement #TechWriting

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.

Technical Authors: Do you need a new job title

Do technical authors need a new title due to changing roles?
Ask a question: When you hear the job title Technical Author, what is the response?
My most recent response emphasised upholding the integrity of the technical documentation.
The crux is that the role of a technical author has shifted in the last 10–15 years. Many find that their day-to-day work no longer matches their job title. Let’s break it down:

The Traditional Job Title

      • A Technical Author meant someone who wrote manuals, user guides, or specifications.
      • The focus was on producing text-heavy deliverables that explained systems, processes, or products.
      • The work was bound and recognisable — you delivered documents.

The Modern Reality

Today, we do far more than write:

      • Information architecture: structuring knowledge bases, designing content workflows, or building taxonomies.
      • Content strategy: deciding what to document, why, and in what format (DMS, CMS, wiki, KB, PDFs, APIs, microcontent).
      • Process design: defining review loops, approval gates, and compliance documentation.
      • Tools & technology: working with Asite, SharePoint, Git, MadCap Flare, Confluence, or API documentation platforms.
      • Training & enablement: running workshops, teaching engineers to write, or creating templates and style guides.
      • Governance & compliance: PCI/DSS, ISO 27001, GDPR, and other regulated frameworks often fall into our remit.
      • In short, the “writing” is still there, but it’s often 20–40% of the role. The rest is closer to content management, knowledge management, or even business analysis.

The Tension

If your business card says Technical Author, but you spend most of your time on:

      • structuring SharePoint sites,
      • managing metadata,
      • training colleagues,
      • support
      • Or developing a documentation strategy,

…then the title undersells both your contribution and your market value. It can also confuse managers, who may assume you’re “just a writer” and overlook your broader impact.

Evolving Job Titles

Some organisations have already rebranded the role. Common alternatives:

      • Technical Writer (US equivalent, though still too narrow).
      • Content Designer (favoured in government/service design circles).
      • Documentation Manager or Information Manager.
      • Knowledge Manager (especially when linked to systems like Confluence or Asite).
      • Content Strategist (if you lead on planning/documentation governance).
      • Information Architect (if your role is very structural and metadata-driven).
      • Document Management (SharePoint) administration

Why a Title Change Matters?

      • Recognition: Reflects the breadth of what you do.
      • Career Progression: Opens paths into strategy, KM, or management.
      • Market Value: Recruiters and hiring managers may undervalue a “technical author” compared to a “knowledge manager” or “content strategist.”
      • Personal Motivation: Titles can shape how you (and others) view your role.

A Balanced View

That said, there’s value in keeping “technical author” alive — it is still a recognised profession, and many industries (engineering, aerospace, IT) rely on that clarity. The trick is whether your work is still 80% authorship or whether the writing part has become a byproduct of a much larger scope.

Conclusion:


If you now spend more time on governance, strategy, architecture, and training than writing, then yes, the title Technical Author may no longer serve you. It hasn’t reached “end of life” as a profession (there’s still plenty of need for core documentation specialists), but your role might have evolved into something broader. The challenge is to choose a new title that captures both your expertise and the value you bring.

Technical Author: Role Evolution

Focus Area
 Typical Tasks Best-Fit Job  Title(s) When to Consider Moving On from ‘Technical Author’
Writing & Editing Creating manuals, procedures, work instructions, help files, API docs Technical Author / Technical Writer When 70–80%+ of your work is direct writing & editing
Content Design Chunking info for different audiences, plain English editing, and UX copy in docs Content Designer When you focus on clarity, accessibility, and user experience more than raw documentation
Information Architecture Designing knowledge bases, metadata, tagging, navigation, and cross-references Information Architect / Documentation Specialist When your most significant value is structuring & organising content
Documentation Management Setting up DMS/CMS (Asite, SharePoint, Confluence), version control, workflows Documentation Manager / Information Manager When you spend more time managing systems and processes than writing
Knowledge Management Building FAQs, wikis, self-service portals, and the reuse of knowledge assets Knowledge Manager When your role is less about producing new docs and more about curating knowledge
Governance & Compliance Writing/maintaining ISO 27001, GDPR, PCI/DSS docs; ensuring audit readiness. Compliance Documentation Specialist / Information Governance Lead When compliance and audit trails dominate your workload
Content Strategy Deciding what to document, defining style guides, setting standards, and aligning with business goals. Content Strategist / Documentation Lead When you’re steering what gets written rather than writing it yourself
Training & Enablement Running workshops, creating templates, and teaching engineers to write in plain English. Documentation Trainer / Writing Coach / Knowledge Enablement Lead When you’re teaching and enabling others more than authoring content
Cross-Discipline Hybrid Doing a mix of writing, managing, training, strategy, and systems work Senior Technical Author / Information Manager / Content Strategist When no single title fits, seniority helps cover the broader remit

Takeaway

  • If most of your time is still spent on writing, “Technical Author” is valid.
  • If you’re spending 40–60% of your budget on architecture, governance, or strategy, a change of title boosts clarity and credibility.
  • If you’re leading systems, compliance, or KM, your role is no longer just authoring — you’re managing knowledge and strategy.

Software Upgrade Amid User Guide Update Challenges

Berkshire-based XYZ Releases Software Upgrade Amid User Guide Update Challenges

In the competitive software market, staying current is crucial, and Berkshire’s own XYZ company has just taken a significant step forward with the release of its upgraded software product, Version 3.0. This upgrade introduces considerable improvements in functionality.

However, they do not mention the associated user guide, which has remained untouched for over seven years.

Critical Need for an Updated User Guide

As XYZ prepares to roll out these enhancements, the spotlight turns to the 200-page user guide—untouched since its creation. They have contracted a local technical author to update and include the software’s expanded capabilities.

Challenges in User Guide Revision

The technical author (TA) faced hurdles from the start. The user guide, written by multiple authors in Germany, is inconsistent and outdated. Poor coordination between writers in the original guide has complicated this update.

Timeline Realities and Project Management Issues

The update is urgent, but the TA estimates 9 to 18 weeks, longer than the three-week deadline before the software’s release. The project sponsor soon learns that writing documentation is a challenging job.

The Conversation

When the TA starts, no one knows the location of the UG, and it takes several hours to track a copy. When he begins his analysis, he notes multiple errors, spelling mistakes and inconsistencies.

Meanwhile, the Project Sponsor (PS) observes the TA and notes his lack of activity. She emails the internal recruiter, who speaks to the TA on his second day about the lack of activity and wants to see progress. The TA confronts the PS at her desk to hear her explain her concerns.

Project Sponsor (PS): Yesterday, you started and sat at that desk and barely moved. We have three weeks to update the user guide, and I expect more progress by now.

TA: Three weeks! The UG contains over 200 pages written by multiple authors. I must review each section to ensure I understand the software.  The document is a mess with multiple mistakes and inconsistencies.

PS: I thought people like you reviewed the document and made the changes quickly.

TA: That user guide requires significant work. I must understand the content, which is not clear in many places. Do you know the reality of updating such a large document?

PS: I have a feeling you are going to tell me.

TA: On top of my head, an estimation of this update could take up to 15 weeks.

PS: 15 weeks. How?

TA: 1-2 weeks to understand the scope, plan the document’s structure, and prioritise sections. I need access to software to take new screenshots and talk to the SMEs. 3-6 weeks to write updates and incorporate new functionalities. Then, reviews, feedback, and revision cycles. Revising over 200 pages is no walk in the park. Then, two weeks for final edits, formatting, and publishing of the updated guide. It will take 9 to 18 weeks to update your user guide.

PS: Can you not do it faster?

TA: No, it’s impossible.

PS: we need another TA. we can’t use you!

TA: Getting a new TA won’t fix your problem. A TA with integrity will tell you the same. Even two TAs could not complete this in three weeks.

PS: This is frustrating. I don’t want to hear about delays. I want a solution.

TA: you should have started this project three months earlier if you wanted it ready for release in three weeks.

PS: (scoffs) The budget wasn’t available then! We wanted a TA a month ago, and you were the only one available.

TA: TAs are in short supply.

PS: (sighing with disbelief at what the TA has told her).

TA: Did you think the problem would solve itself?

PS: That’s not fair! We’ve had a lot of competing priorities.

TA: Not my problem, but it’s a reality. This project had failed before it started. You’ve set yourself up for failure if you don’t prioritise quality documentation. It also reflects on the product and your company’s professionalism. I have a professional reputation, which I will not compromise. I will leave this project to avoid unnecessary pressure because of unrealistic expectations.

PS: So, what are you saying? We can’t accept that we won’t meet the deadline.

TA: Yes, you need to extend the timeline if you want a professional job.

PS: The allocated budget only covers you for three weeks. I can’t accept this. I’ll have to think about it.

TA: Fair enough. But it will take three weeks to outline the document and won’t cover the writing process—the clock ticks. I have done this job long enough to know the timelines, and I’m not exaggerating. You have left this too late.

Essential Points for Efficient Project Outcomes

    1. Early Initiatives: Starting updates early is essential to manage expectations and deliver quality.
    2. Time Demands: Thorough updates for large documents require substantial time.
    3. Realistic Planning: Setting achievable deadlines is critical to avoid rushed jobs and potential frustration.
    4. Quality Focus: High-quality documentation ensures user satisfaction and reduces support costs.
    5. Resource Management: Proactively securing skilled technical authors ensures that documentation keeps pace with software development.
    6. Effective Communication: Clear discussions between project stakeholders prevent misunderstandings and align project goals.
    7. Budget and Resource Planning: Anticipating financial and staffing needs prevents last-minute crises and ensures comprehensive project coverage.

Looking Ahead

As XYZ company navigates these challenges, the lessons learned underscore the importance of strategic planning and realistic project management in software development. Ensuring the user guide matches the software’s quality not only enhances user experience but also reinforces XYZ’s commitment to excellence.

Navigating the Jungle of Contracting: A Tale of Missed Checks and Shouted Specs

Ah, the life of a contractor—where every day is an adventure, and you’re the hero armed with nothing but your wits and a laptop. Like Indiana Jones, I’ve managed client expectations and communication challenges. Here’s the lowdown on surviving the wilds of workplace woes with a grin.

Chapter One: The Case of the Missing Validity Checks

Once upon a time, I suggested to a Project Manager (PM) that we should probably check the content of a PowerPoint display before chucking it into the gaping maw of Confluence. He, in his infinite wisdom, proclaimed such checks unnecessary. “Just migrate it!” he declared. So, migrate I did. Mere days later, he scrapped the content himself because—plot twist!—it was outdated. Who could’ve guessed? Well, me… I did guess. However, in later collaborations, he had a sense of humour failure and raised his voice in frustration more than once.

Chapter Two: The GDPR Fiasco

Imagine, if you will, a GDPR project where the document looked like a horde of angry red pen-wielding vandals had attacked it. I dared to point out that the riot of track changes made the document as readable as ancient hieroglyphs without a Rosetta Stone. The PM’s reaction? A not-so-mighty roar in front of a dozen coworkers. Yikes! One week later, unable to cope, he walked away.

The Golden Rule: Set Expectations Like Setting Traps in the Jungle

To keep the wild beasts at bay (read: client frustrations), start every project by setting crystal clear expectations. Draw them a map with X marks on the spot, showing timelines and task breakdowns. Clients who know what to expect are less likely to go on a rampage when deadlines sneak up on them.

Educating the Natives (I Mean, Clients)

Empowering your clients goes a long way. Show them the path you’ve charted, step-by-step, so they feel part of the journey rather than just baggage being lugged around. It turns suspicious glares into nods of approval and keeps the peace in the village.

Broadcasting Updates: Not Just for Sports Channels

Keeping clients in the loop with regular updates is crucial. It’s like sending smoke signals to assure them that the project is still on fire (in a good way). This constant connection is the secret sauce to a successful client relationship; communication, not telepathy, keeps things smooth.

The Art of Feedback and the Grace of Boundaries

Allow space for feedback—it’s like a safety valve that lets off steam and realigns tracks as needed. Also, be like a serene monk when confrontations arise: acknowledge the thunder, but don’t let it shake you. Stick to your quality guns, and don’t let yourself be rushed.

Dealing with Workplace Wildlife

When faced with a fuming boss or a power-tripping manager, remember, it’s not just about surviving but knowing when to pack up your tent. Whether it’s taking your grievances to HR or simply walking away, choose your battles wisely.

In Conclusion: Be the Contractor Who Wrote the Book

Contracting isn’t just about delivering spiffy spreadsheets and snazzy slides; it’s about crafting an experience so transparent and smooth that even the most demanding clients want to bookmark you for a sequel. So there you have it, a guide to thriving in the contracting jungle—may your communications be clear and your expectations managed like a pro!

How to Win Over Management and SMEs: A Hilarious Guide for Technical Authors

So, you’ve embarked on the noble quest of a technical author. Your mission, should you accept it (and you have no choice), is to convert the mighty management and the enigmatic SMEs (Subject Matter Experts) to your way of thinking. Sounds like a Herculean task? Fear not! Here’s your humorous guide to charming them into submission while keeping your sanity intact. Remember, we’re all in this together, united by the common goal of effective communication. So how to Win Over Management and SMEs to your way of thinking.

Speak Their Language (No, Not Klingon)

Let’s be honest—management speaks in KPIs and ROI, while SMEs converse in an ancient dialect known only to a few. Your first step is to become a polyglot. Learn to weave your documentation magic into business objectives and arcane technical details. It’s like being a translator at the United Nations but with less chance of starting an international incident.

The Art of Presentation: Smoke and Mirrors

With communication, clarity icriticaley. But why stop there? Make your points with the flair of a Las Vegas magician. Use charts, graphs, and infographics that sparkle. And remember, nothing says “I know what I’m talking about” like a well-timed meme. Trust me; pie charts are irresistible to management as cat videos are to the internet. Please don’t overdo it, or you will end up in a meme yourself!

Quick Wins: The Fast and the Furious

Management loves results faster than a pizza delivery. And who’s the hero delivering those results? You, the technical author. Identify accessible opportunities and deliver those quick wins like Vin Diesel in a muscle car. A tiny tweak will save an hour of work each week or a new tool that doesn’t require a PhD. Shout about those victories with the enthusiasm of a game show host handing out prizes. You’re the star of this show.

Collaboration: Herding Cats, but With Treats

Getting management and SMEs to work together is like herding cats, but don’t worry—we have treats! Engage them early with workshops that are part of brainstorming and therapy sessions. Provide plenty of coffee and snacks; they’re more likely to engage if their blood sugar levels are stable. Plus, who argues over a cookie?

Build Relationships: Be the Office Barista

Relationships are everything. Become the office barista—always ready with a listening ear and coffee. Trust and rapport are your best friends. Remember, it’s harder to say no to someone who knows your coffee order by heart.

Highlight Long-term Benefits: The Crystal Ball Approach

Paint a picture of a future so bright they’ll need shades. Highlight how your approach will lead to fewer headaches, lower costs, and maybe even a tropical vacation (we can dream). Show them the long-term benefits with the enthusiasm of a late-night infomercial host. “But wait, there’s more! If you adopt this strategy now, you’ll also get…”

Embrace Technology: The Cool Kid in School

Introduce new tools and technologies like you’re showing off the latest gadget. Be the cool kid who knows all the shortcuts and secret features. Offer training sessions, but make them fun—think less “seminar” and more “techno party.” Bonus points if you can throw in a few tech-related jokes. “Why do programmers prefer dark mode? Because light attracts bugs!”

Example Scenarios:

      • Scenario 1: Management Concerned About Cost: “Dear Management, investing in this new tool is like buying a golden goose. It’s pricey upfront, but think of the endless eggs. In financial terms, that means reduced time, fewer errors, and overall productivity that will make our competitors weep.”
      • Scenario 2: SME Resistance to Change: “Dear SMEs, we know you love your ancient rituals, but imagine a world where documentation is a breeze. Join our workshop—there will be snacks!—and let’s create a workflow so smooth, you’ll forget what life was like before.”

Ultimately, winning over management and SMEs is about strategy, charm, and humour. So, arm yourself with these tips and spread the word about the importance of good documentation. Keep in mind that these strategies have been tried and tested. If all else fails, remember that bribery with baked goods is always an option. With these tools, success is inevitable.

Tales from the Desk of a Technical Author

In the world of technology, unsung heroes lurk in the shadows, wielding their pens (or keyboards) to document the wonders of code, hardware, and software—in my case, training materials, editorial, and consulting. Yes, we’re talking about technical authors—the wizards of words, the maestros of manuals, and the unsung champions of clarity in a sea of tech jargon. The profession of technical authorship has a rich history, dating back to the early days of computing when the need for clear, concise documentation became apparent.

Contrary to popular belief, technical authors have a fun job that goes beyond following rules. So, buckle up and prepare to embark on a journey into the quirky world of technical authorship! To excel in this field, one needs a strong command of language, the ability to understand complex technical concepts, and a knack for simplifying them for a non-technical audience.

First, let’s debunk the myth that technical authors are mere writers. Oh no, my dear reader, we are much more than that. We are the bridge builders of the tech world, straddling the chasm between siloed departments with the finesse of a tightrope walker on caffeine.

Do you need help?

    • To translate developer jargon into plain English? 
    • Are you deciphering the cryptic scribbles of the engineering team? 

Rest assured, we’ve got you covered. Whether it’s translating developer jargon into plain English or deciphering the engineering team’s cryptic scribbles, we are here to unravel the mysteries of their chicken scratch.

But wait, there’s more! We are:

    • The masters of documentation management.
    • The Jedi knights of version control.
    • The guardians of the sacred art of template creation.

Need a document wrangled into submission?

Call us. Need help with the intricacies of your company’s document management system?

Call us, and we’ll swoop in like caped crusaders armed with spreadsheets and flowcharts.

And let’s remember our diplomatic prowess. Amid a heated debate between rival factions over placing a comma in a user manual, who swoops in to save the day? Your friendly neighbourhood technical author, armed with a cup of tea and a voice to calm even the most agitated developer.

That’s right, your friendly neighbourhood technical author, armed with a cup of tea and a voice to calm even the most agitated developer.

But our greatest superpower lies in our ability to transform mortals into document-writing virtuosos. Fear not. When a colleague struggles to string together a coherent sentence, we shall sprinkle our magic writing dust upon them and watch them blossom into wordsmiths.

When you next encounter a technical author, dear reader, consider the depth of their skills and influence as the unsung hero of the tech world. We deliver well-written manuals, crafted templates, and harmonious team collaboration. Our work is not just about writing; it’s about working closely with developers, engineers, and other team members to ensure that the final product is of the highest quality.

Technical Author | learn how to project manage documentation projects

As a technical author expert, I recommend that other technical authors should learn how to plan their documentation projects. One of the most common issues project managers face is underestimating the complexity of documentation projects. This can have negative consequences on the project’s success, as inadequate timelines and impossible targets can be set without consulting professionals for advice.

Tweet
Pin
Share
0 Shares

Technical authors, give your career a shot in the arm. Learn how to plan documentation projects effectively to project manage effectively. Project managers often underestimate the challenges of projects that involve documentation. This leads to limited success because of unrealistic timelines and targets.

I know the process behind the production of multiple documents. Proper project management is crucial, especially when managing complex documentation tasks. While prioritising other aspects of the project over documentation, they fail to ask a professional for their input and guidance. When the technical author(s) arrive and look at the list of documents and the PM timelines, let’s say you can hear our sighs.

We need clear communications if the PM expects to deliver the entire project. How do you manage 60 + documents? How long does it take to write one document? Have it reviewed, but remember that the document might be out of date further along with the project. Clear communication with stakeholders and team members involved in the writing stages is paramount. The project manager must understand the expectations of the technical author(s) they will work with and must effectively project manage to meet those expectations.

Project plans may face issues when updates require time-consuming document review and revision phases. Thus, managing the project efficiently becomes critical.

Project managers and technical writers can work together to succeed on big documentation projects. However, a technical author to lead might be a better idea and offer better results.