Tag: Technical writing

Why People Resist Writing Technical Documents

People do not avoid technical documentation simply because they dislike writing. They often resist because documentation exposes knowledge, risk, gaps, ownership, and accountability. This article explores the psychology behind that resistance and explains how technical authors and information managers can make knowledge sharing safer, easier, and more useful.

Tweet
Pin
Share
0 Shares

The psychology behind writing technical documents is not about writing. It is about identity, control, risk, confidence, workload, and trust.

Resistance to operational documentation stems from people’s awkwardness. They resist it because documentation exposes what they know, what they do not know, and how well their work holds up in writing.

Why are people reluctant to share knowledge?

1. Knowledge is power

In many organisations, people become valuable because they are the only person who knows how something works.

      • They know the system’s history.
      • the workaround.
      • which server talks to which database
      • “don’t touch that on a Friday” rule.

Writing that can feel like giving away their leverage. Documentation makes some people fear they will become less important.

That is rarely true, but the fear is real.

2. They fear being judged

When knowledge stays in someone’s head, others cannot challenge it. Once it is written, others can question it.

People may worry:

      • “What if I explain it badly?”
      • “What if someone spots a gap?”
      • “What if I have been doing it wrong?”
      • “What if this becomes evidence against me later?”

Technical documentation makes hidden practice visible. That can feel threatening.

3. Experts often do not know how much they know

A subject matter expert may say, “It’s obvious.”

It is obvious to them because they have years of context in their head. They forget what it was like not to know.

This is called the curse of knowledge. Experts skip steps, assume background understanding, and leave out dependencies because those things have become automatic to them.

That is why asking an expert to “write the process” often fails. They know the process too well to see where a new user will fall over.

4. They think writing is not their job

Engineers, analysts, developers, support staff, and project teams often see writing as admin. They may think:

“My job is to fix the thing, not write about the thing.”

This is where organisations go wrong. Documentation is not clerical work. It is part of operational control, support, continuity, audit readiness, training, and risk reduction.

The problem is that many organisations only value documentation after something breaks.

5. They have been burned before

Some people have contributed to documents in the past and seen nothing happen.

      • They gave information.
      • No one reviewed it.
      • No one published it.
      • The document disappeared into SharePoint.
      • Six months later, someone asked them the same questions again.

After that, they stop engaging.

Reluctance is sometimes not laziness but disappointment.

6. They do not trust how the information will be used

People may worry that documentation will be used to:

      • blame them after an incident
      • prove non-compliance
      • expose shortcuts
      • remove their ownership
      • offshore or automate their role
      • support a restructure

If the culture is punitive, people will protect themselves. They will give partial answers, vague explanations, or just enough information to appear cooperative.

7. Writing creates cognitive load

People underestimate how hard it is to explain work clearly.

Doing the task and explaining the task are different skills. A person may be excellent at resolving a complex system issue but poor at turning that knowledge into a structured procedure, support guide, recovery plan, or knowledge article.

They may not be unwilling. They may simply not know where to start.

What information managers and technical authors can do

The answer is not to keep saying, “Can you send me the process?”

That rarely works.

The better approach is to extract, shape, validate, and govern knowledge.

1. Stop asking people to “write the document”

Ask them to explain the work instead.

A technical author or information manager should make the task easier by saying:

“You do not need to write this. Talk me through what happens, what can go wrong, and who needs to know. I will structure it.”

This removes the pressure. The SME becomes the source of truth, not the person responsible for producing polished documentation.

2. Use structured interviews

Do not ask broad questions such as:

“How does the system work?”

Ask controlled questions:

      • What triggers this process?
      • Who owns it?
      • Who performs it?
      • What systems are involved?
      • What access is required?
      • What are the dependencies?
      • What happens if this step fails?
      • What evidence proves the task is complete?
      • What must never be done?
      • Who needs to be notified?
      • What is the escalation route?
      • What documents or records are produced?

Good documentation comes from good questioning.

3. Make knowledge sharing safe

People share more when they know the purpose.

Explain that documentation is not there to catch them out. It is there to protect the organisation and reduce repeated interruptions.

A useful message is:

“The aim is not to audit your memory. The aim is to stop the business depending on memory.”

That distinction matters.

4. Turn experts into reviewers, not writers

Most SMEs are better at reviewing than drafting.

A practical model is:

      1. Technical author interviews the SME.
      2. Technical author drafts the document.
      3. SME reviews for accuracy.
      4. Information manager checks structure, metadata, ownership, and control.
      5. Document owner approves.
      6. Document enters the review cycle.

This respects the SME’s knowledge without forcing them to become a writer.

5. Show people what poor documentation costs

People respond better when documentation is linked to real pain.

For example:

      • repeated support calls
      • failed handovers
      • slow onboarding
      • avoidable incidents
      • audit findings
      • change failures
      • disaster recovery confusion
      • project delays
      • dependency on one person
      • duplicated or contradictory processes

The argument should not be “we need documents.”
The argument should be “this is the risk we carry without them.”

6. Make contribution easy

Do not give SMEs a blank Word document.

Give them prompts, templates, checklists, diagrams, or short forms.

For example:

Instead of asking Ask this
Write the procedure. Give me the trigger, steps, exceptions, and escalation route.
Document the system. List the components, owners, dependencies, interfaces, and support contacts.
Update the knowledge base. Tell me what has changed, who it affects, and what users need to do differently.

People will contribute when the task is specific.

7. Use workshops, not email chains

Email is often a poor way to gather knowledge.

A short workshop can achieve more than three weeks of chasing. Put the right people in a room and map the process live.

Use:

      • process maps
      • whiteboards
      • dependency diagrams
      • RACI tables
      • system flow diagrams
      • incident timelines
      • “what happens if…” scenarios

The technical author captures the conversation and turns it into controlled documentation afterward.

8. Recognise the contributor

Knowledge sharing should carry status.

A simple contributor section, review credit, or acknowledgement can help. People are more likely to share knowledge when they feel their expertise is being recognised, not harvested.

The message should be:

“Your knowledge is important enough to become the organisation’s standard.”

That is a very different message from:

“We need you to fill in this template.”

9. Link documentation to governance

Information managers should make documentation part of normal business control.

That means every critical document needs:

      • an owner
      • version control
      • review date
      • approval route
      • classification
      • metadata
      • retention rules
      • change history
      • access control
      • review evidence

Without governance, knowledge sharing becomes a one-off exercise. With governance, it becomes part of how the organisation operates.

10. Use AI carefully

AI can help turn rough notes, transcripts, and SME interviews into a first draft. But it must not become a substitute for validation.

A good model is:

      • record or summarise the SME discussion
      • use AI to create a structured draft
      • technical author edits for clarity and usability
      • SME validates accuracy
      • document owner approves
      • information manager controls publication and review

AI helps with speed. It does not replace ownership, accuracy, context, or accountability.

The real role of the technical author

The technical author is not merely “the person who writes it down.”

A good technical author acts as:

      • interviewer
      • translator
      • editor
      • sceptic
      • user advocate
      • information architect
      • risk spotter
      • governance partner

They turn messy, partial, expert knowledge into something usable, controlled, and repeatable.

The information manager then ensures that the document does not decay into another forgotten file.

The key point

People are reluctant to share knowledge because knowledge is personal, political, and protective.

The answer is not to shame them into writing. The answer is to create a process where sharing knowledge feels safe, useful, recognised, and structured.

Technical authors and information managers should not ask, “Why won’t people write?”

They should ask:

“What is stopping people from sharing what they know, and how do we remove that friction?”

That is where documentation begins.

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?

Why Companies Struggle with Infrastructure Documentation—and Why It Matters

Why Infrastructure Documentation Is Your Most Overlooked Security Asset

Many companies struggle to document their IT infrastructure effectively.
As a seasoned technical author, I’ve seen firsthand how well-written Infrastructure documentation transforms chaos into clarity—helping teams work smarter, faster, and more securely.

Documentation: Your Strategic Advantage

Infrastructure documentation isn’t just admin paperwork — it’s a strategic business asset.

When your documentation is accurate, structured, and up to date:

      • Teams resolve incidents faster.
      • New staff onboarded seamlessly.
      • Projects maintain continuity and compliance.
      • Prevent costly errors before they occur.

In short, infrastructure documentation drives operational excellence — saving time, reducing risk, and strengthening your organisation’s resilience.

The Rising Challenge of Security & Compliance

In today’s digital landscape, businesses face intense security and compliance pressures. Frameworks such as ISO 27001, NIST, and GDPR set clear expectations for protecting sensitive data and improving cyber resilience.

But here’s the problem:
These frameworks don’t tell you how to write, update, or manage the documentation that underpins compliance.

That’s where organisations often fail. Outdated documents, missing ownership, and inconsistent version control can derail even the best security strategies.

To succeed, you must treat documentation as a living, evolving resource — not a one-time deliverable.

Building a Well-Managed Documentation Repository

Drawing on NIST, ISO 27001, and GDPR guidelines, I’ve helped organisations create robust documentation frameworks that withstand audit and operational scrutiny.

Hiring a skilled technical writer is a small investment compared to the cost of failure. Consider this:

IBM’s Cost of a Data Breach Report (2023) put the average cost of a data breach at £3.8 million.

Would you rather invest a fraction of that in proactive documentation—or risk the aftermath of a ransomware attack or compliance breach?

Documentation That Drives Operational Excellence

High-quality documentation isn’t just about compliance. It’s the foundation of operational efficiency.

Imagine a single source of truth that everyone can access—accurate, consistent, and regularly updated. The results:

      • Faster issue resolution.
      • Reduced reliance on informal knowledge.
      • Lower risk from staff turnover.
      • No time wasted reinventing processes.

Good documentation = Sustainable operations.

Here’s what effective documentation management looks like:

      • Defined policies and processes.
      • Accessible, searchable repositories.
      • Regular reviews and updates.
      • Quality checks for clarity and consistency.

The Bottom Line

Poor documentation isn’t just inconvenient — it’s a serious business risk.
The cost of bad writing far outweighs the price of hiring a professional technical author.

Don’t let your organisation fall behind.
Invest in structured, secure, and well-maintained documentation — and protect your business for tomorrow.

From Contract to Permanent

my transition from contractor to perm

Tweet
Pin
Share
0 Shares

In 2004, while facing redundancy for the third time, I accepted a six-month contract with BT to fill a potential gap until a permanent role became available. A former colleague told me that contracting can be a long-term career choice. He offered various reasons, but I went ahead; I couldn’t afford to be out of work.

trnsition from contract to perm

My first two contracts were with BT in London and at its HQ in Ipswich. Then came T-Mobile (now EE), NTTE, and Capita. Before I knew it, five years had passed, and recruitment agents were calling with contract and permanent job opportunities. 

However, some agents were reluctant to forward a contractor to a client wanting a permanent technical author. Recruitment agents had stories of contractors accepting a permanent role and quitting after a month (or a week) to return to the contract market. Yet, while I interviewed for several permanent positions, none matched what I wanted.

I moved between tasks, meeting TAs who shared work stories each year. 

Note: To be a technical author, you need a sense of humour and a sharp wit.

However, I never got to grips with the gaps between contracts. While the money was above average, it allowed me to pay myself an inconsistent amount every month. During the 2008 financial crisis, my earnings dropped by a massive 33%, which was further exacerbated by a four-month contract gap. During that period, BlackBerry offered me a permanent role. Unfortunately, I didn’t stay long because of an overzealous  Canadian-based micro-management team leader. So desperate to make her mark, she called me as soon as she arrived at her office in Waterloo, Ontario. She said during one call, I must learn to manage my stress. Yet, she caused me stress by constantly interfering and telling me how to do my job—her two years of experience against my 13 years.

Yet, look on the bright side: with more contracts under my belt, I developed more skills: 

  • SharePoint (Document Management)
  • Confluence
  • Help Desk support, transition from contractor to perm
  • policy & process writing, 
  • VISIO process flows
  • ITIL (incident and change management), 
  • ITSM. 
  • PCI/DSS, 
  • ISO 27001 Audits and 
  • operations manuals for data centre migrations and
  • project management

Goodbye to software environments and hello to the broader world of technical authoring. Not only did I broaden my experience, but I also travelled to Pune in India, as well as to Germany, Belgium, and Canada. 

I have started, but cannot finish.

The cost of Technical and Process documentation
The cost of Technical and process documentation

A common trend with contracts is poor budget allocation. In one PCI/DSS project, I worked with two technical authors on a 10-week assignment. By then, the PM had used most of the budget to prepare for an audit by hiring an expensive external consultant.

We needed to prepare the groundwork, identify SMEs, and divide the sixty titles between us. After five weeks, we began speaking with SMEs and drafting the documents. The task exceeded our capabilities; it involved a great deal of labour and an inadequate duration. Although the company in question went bankrupt during the pandemic, it had no connection to the project. 

Hiring managers and project managers often struggle with the dynamics of documentation projects. Many project managers assume that documentation is a straightforward task. It rarely works out that way.

On my journey to a permanent role, the points below formed the basis of my decision. If you are a contractor considering a change towards a permanent position, consider what you could offer as a permanent employee.

  • I could concentrate on doing what I’m good at rather than spending gaps and seeking new freelance jobs.
  • Working as a freelancer has allowed me to improve my flexibility and adapt to new situations. Technical authors require an understanding of adaptability, as well as the capacity to operate effectively individually or within group settings. 
  • I respond to many people, environments, and attitudes. This experience has enabled me to work effectively with diverse management styles and personalities.
  • Can they manage me? Even as a freelancer, my role is to contribute to a team. And as a freelancer, I have always been “managed…” by my clients.
  • How would you benefit our clients? If you would like me to be involved in client contact, I can assist with their needs, leveraging my knowledge and experience to provide effective documentation solutions. 

We are also

    • I am confident that our considerable Skill Set will shine through.
    • Understand the issues and be prepared to address them head-on. 
    • experience of multiple environments
    • recognition of common problems
    • Understanding of project needs
    • broad experience
    • Renewed enjoyment of teamwork

What are you thinking? 

Perhaps you’re wondering, how can I transition from contract to permanent and take a significant financial hit? As a contractor, my earnings fluctuated, with no consistent monthly payments due to:

    • The time between contracts is a few weeks to a couple of months.  
    • Increasing administration and overheads through my limited company. 
        • unemployment insurance (£150 per month to cover me in case of an injury or debilitating illness),
        • personal and public liability insurance (£10m in value £160 p/a), 
        • private medical for quick treatment (£1200 p/a)
        • accounting fees (£1200+ p/a)
        • Travel costs were deductible. 
          • Car mileage
          • Air Fares between Brussels and Gatwick
          • Hotels and meals while working away from home in the UK
    • Increased Taxation on Dividends
    • The Government fails to grasp that risk-takers often lack holiday pay, sickness benefits, and company benefits.

Before the pandemic, I received about five calls a week from agents checking my availability for work. Meanwhile, I maintained a growing Excel spreadsheet of calls, listing potential clients, and updated my CV every six months.

During the 2020 pandemic, I was out of work from March to October. My company’s accounts for 2020 showed a £ 5,000 loss, and a £ 3,000 loss in 2021.

In April 2021, to circumvent IR35, I joined an umbrella organisation.

Post-pandemic, IR35 has played havoc with the contract market, causing an enormous drop in calls from recruitment agents. 

Here's a fun fact. In eighteen years as a contractor, I worked at 45 different companies. That doesn't include about ten companies where I walked away after a few days to avoid a disaster in the making.

Why did I walk?

The hiring manager sold me a dud while management expectations were unrealistic..

Between 2004 to 2021 over 300 hiring managers received my CV and more than half interviewed me.

The last journey

In 2021/22, after I completed a long-term contract project, I focused on finding a permanent role. The HR department of a County Durham-based bank (my home county) offered me an interview. However, HR rejected me because of my contracting background. So, if you are reading this, take note. I am now a permie, see what you missed. 

transition from contracting to perm

While I had three more interviews, the sticking point was the salary. A business owner, a lady, contacted me after finding my CV online and offered me a permanent role paying £ 35,000 after a five-minute discussion.

And Finally…

So, when I read the Atkins job description, I thought, let’s give it a go, with nothing to lose. During the interview, the interviewer asked the inevitable question. I refer the reader to the first three paragraphs of this post. 

After quitting the contract market, I am no worse off when considering my salary and the benefits I receive. I no longer worry about tax bills, dividend taxes, accounting fees, and various insurance costs that can be a fortune. A permanent role has worked for me and might work for you. Never say never.

Process, Procedure, Work Instruction, Plan, Strategy and Standards — Know the Difference

Clear documentation depends on understanding the difference between processes, procedures, work instructions, plans, strategies and standards. This article explains how each fits into a structured documentation framework.

Tweet
Pin1
Share
1 Shares

Many organisations use the terms process, procedure, work instruction, plan, and strategy interchangeably. They are not the same. This article explains the key points to help clarify these differences.

Confusion between these terms leads to poor documentation, unclear responsibilities, and inconsistent delivery.

If you work in technical authoring, information management, or governance, understanding the difference is essential.

A good documentation framework clearly separates these elements and ensures people know what they must do and why.

What is a process?

A process is a set of interrelated activities that turn inputs into outputs.

A process describes a complete business activity from beginning to end.

You must:

      • Learn the process
      • Understand why it exists
      • Perform it end-to-end

A process is:

      • A high-level description of work
      • Cross-functional
      • Ongoing and repeatable
      • Updated periodically
      • Supported by policies and standards

A process answers the question:

“How does the business operate?”

What is a procedure?

A procedure provides more detail than a process but less detail than a work instruction.

It explains how to perform sequential tasks to achieve a defined outcome.

A procedure usually:

      • Follows a logical sequence
      • Has an obvious start and finish
      • Can be completed in one working session
      • Describes responsibilities

A procedure answers:

“How do we complete this activity?”

What are work instructions?

Work Instructions (WI) describe exactly how to perform a specific task.

They provide step-by-step guidance with no ambiguity.

A work instruction:

      • Describes one task
      • Contains detailed steps
      • May include screenshots or diagrams
      • Removes interpretation

Work instructions answer:

“How do I do this task?”

What is a plan?

A plan is not a process.

Many organisations confuse the two.

A management plan describes what will be done, not how work is performed.

A plan typically includes:

    • Objectives
    • Resource allocation
    • Timescales
    • Responsibilities
    • Risk considerations
    • Contingencies

A plan shows how an organisation will move from Point A to Point B.

It supports the strategy by describing how resources will achieve the aim.

A plan answers:

“What are we going to do?”

What is a strategy?

A strategy explains how an organisation will move from Point A to Point B.

It defines direction rather than detailed actions.

A strategy typically includes:

      • Current position (Point A)
      • Desired position (Point B)
      • Problems and constraints
      • Opportunities
      • Tools and approaches
      • Decision principles

A strategy considers obstacles and risks that may slow progress.

Strategy answers:

“Where are we going and why?”

Your strategy defines what you want to achieve.

Understanding the difference between a strategy and a plan allows organisations to make better decisions.

What is a standard?

Standards define mandatory rules and behaviours.

They support policies and ensure consistency across the organisation.

Standards are:

      • Mandatory
      • Enforceable
      • Organisation-wide
      • Consistent
      • Long-term

Define expected behaviour, for example:

      • Email signatures
      • Naming conventions
      • Approved hardware and software
      • Document templates
      • Security controls

Must be enforced to be effective.

This applies equally to policies and standards.

Why does this matter?

When organisations confuse these terms, documentation becomes chaotic:

      • Plans get mistaken for processes
      • Procedures become incomplete
      • Work instructions disappear
      • Strategies become wishlists
      • Standards are ignored
      • Clear documentation separates these layers and ensures:
      • Consistent delivery
      • Clear responsibilities
      • Better governance
      • Easier audits
      • Stronger information management

This structure is the foundation of a well-run documentation system.

Technical Writing | Sourcing a technical writer

When sourcing a technical writer, ensure their experience matches your requirements. The best candidate will have the correct background and expertise. Listen carefully to their answers as many like me at the interview dispense advice and why a particular route may not work. If they don’t talk through that experience, keep searching until you do.

Productive years as a Technical Writer

An experienced Technical writer can only be an asset to your team or project. The longer their career in various businesses, the broader and more in-depth their experience will be. However, the only way to be confident is to read their CVs carefully.

Read the CV, and discuss the project. My rule is this: if you cannot see it on my CV, then I haven’t done it. That does not mean I will turn down unfamiliar tasks.

Do they use Social Media or have a website?

Check out LinkedIn for their profile; If you cannot find it or a website describing their experiences, what have they be doing?

During the interview, did they communicate?

During an interview, be wary of a candidate who sits, listens, and says very little. An experienced TW will respond to your questions and offer suggestions on elevating the project with innovations you may not have considered.

Effective communication

An essential part of our job is communicating with SMEs to gather the right level of detail for the documentation. If you have a TW and the documentation appears vague, it might be time for a chat.

Do you want a contractor or permanent TW?

Do you want to build a team that includes a TW to keep the documentation up to date, a person who will grow into the environment? However, I caution against hiring a permanent Technical Writer unless you are sure there will be ongoing work.

Work cycles can dip, so be careful how you use the Technical Writer. During one of my earliest contracts, the project engineer referred to me as a secretary and treated me as one, as did the rest of the team. In a much earlier role, my line manager used me as a general dogsbody.

A proactive Technical Writer between writing, researching and interviewing could improve the company’s documentation. However, once they get on top of the tasks, the role could become routine and repetitive. There will be an odd spurt of activity within the working life cycle; hence, the position of Technical Writing lends itself more to contract work than permanent work.

To summarise: if you hire a permanent Technical Writer to ensure you have plenty of contingencies to avoid your TW developing itchy feet, I suggest you discuss additional tasks that may add value to their experience. Allowing a member of staff use them for jobs for which you employ an office junior will not go down too well.

A word of caution

Unfortunately, our profession attracts its fair share of triers. You can reasonably expect CVs from candidates who have had minimum experience preparing ad hoc documentation on projects at work. Unfortunately, that minimal experience does not translate to full-scale projects requiring a technical writer. In many cases, it turns into an expensive flop.

Many recruiting agents have a minimum expertise sourcing Technical Writers. When they speak to prospective candidates, they hear a few buzzwords and place candidates forward for a role for which they are not suitable. Be sure to check that they have the right experience and background.

To avoid problems, apply the following advice:

Be careful hiring a Junior Technical Writer or one that has worked in a permanent position for the last five years.

Why: a permanent position can be very repetitive, which limits the Technical Writer’s experience. That also goes for junior writers. For high-profile projects, hire a seasoned contracting professional who can talk through the project with you.

Finally, budgets – ensure you are buying the experience you need. In the world of Technical Writing, the price you pay determines the standard you accept. Hiring the wrong candidate could be a costly mistake.

Where else can you source a Technical writer?

You have found me. However, I may not be suitable for the role. Check LinkedIn, Social Media sites and online Job Boards. Ask other companies and fellow professionals if they have used Technical Writers and, if so, what was their experience. They may have recommendations that, in the long run, could save you money.

Technical Writing | Technical documentation vs Helpdesk

technical documentation vs helpdesk
technical documentation vs helpdesk

Technical Documentation vs. Helpdesk—Despite the reluctance to invest in technical documentation, many managers need to pay more attention to a proven way to reduce calls to the Helpdesk.

It is common for helpdesks to provide excellent service and manage users’ demands. Technical documentation, such as user guides, often needs to be corrected. Documentation needs to flow and provide practical tips on how to get the most from the software. If your customers had well-written and comprehensive documentation, you could cut back on costly calls to your helpdesk.

Technical documentation vs Helpdesk

technical documentation vs helpdesk
technical documentation vs helpdesk

I have experience in customer service, handling angry customers complaining about the company and its software. They made comments like:

      • The product is bordering on rubbish, and it doesn’t work, is it bugged?
      • annoyed with the company because the software is garbage
      • I can’t follow the user guide because it doesn’t belong to my version of the software
      • I can’t follow the instructions

When documentation cannot deliver the answer, the Helpdesk records a steep curve in calls. Customers who feel forced to call the Helpdesk Support can hold mixed feelings about the product and company.

Frequently Asked Questions (FAQs)

technical documentation vs helpdesk
technical documentation vs helpdesk

Customers are the lifeblood of any organisation, and their demands can vary. I added a feedback option to help users highlight the vague sections of the documentation.

The developers and helpdesk provided a more detailed solution based on their knowledge and experiences. I created an FAQs knowledge base (or Wiki) for external users and placed the information in the back of the document. The internal staff received the content via a RoboHelp *.chm file.

The FAQs were a success and helped cut calls to support by 80%. I had created searchable information that was easy to find and accessible to all staff.

Experienced technical writers can produce audience focussed documentation that helps customers maintain productivity.

Technical documentation vs Helpdesk

Treat your documentation and information as valuable assets and dedicate resources to upkeep them. The savings could be significant meaning satisfied customers.

Technical Writing | What is technical writing and why you need it

What is Technical Writing?

Technical writing is a skill and should you hear a Project Manager or Subject Matter Expert say: ‘anyone can write so “why do you need a Technical Writer?” continue reading.

Technical Writing like many jobs has many facets. The fact you see Writer in the job title suggests to the uninitiated that primarily we write. You could not be more wrong! The writing takes only a fraction of the time allocated to the project.

Let’s get to the point

Our time is taken with analysing content and listening to Subject Matter Experts.

Our Writing is concise and to the point. We are not novelists describing a beautiful character down to her laughter lines. A poorly written novel will not hold the attention of a reader; the same goes for poorly written technical documentation. A user wants to read the document and understand say – the function of multiple servers and Operating systems within a significant infrastructure. Know how to follow a process or service within a few sentences. We can create a document from the viewpoint of the reader by listening to the user and offering document(s) based on the best solution.

Technical Writing is – as it explains in the box – technical. We speak to Subject Matter Experts and translate their language into content that a technophobe will understand.

We produce documentation in several formats in such a way, to get the message across to our many audiences. What I have written – you too will be an expert. Give yourself a hand.

Key elements of technical writing

Using a consistent language with regards to terminology.

Creating Glossaries to help readers understand the terminology used within the document.

Formatting document headers with the same font size and tables and drawings labelled the same way are important.

From using Excel spreadsheets, Template creation, document versioning, documentation content and types of material, clear document titles and subjects – working with either a shared drive or a document management system and talking to SMEs every day your average technical author is a ‘rare breed’ indeed.

If you have not already read my post titled “Technical Authors are not easy to find’ we do not attract many candidates.

Hire a Technical Author sooner, rather than later

Documentation projects rarely fail at the writing stage—they fail during planning. Poor scoping, unrealistic timelines, and lack of technical author input lead to delays, rising costs, and incomplete deliverables. Here’s how to avoid it.

Tweet
Pin
Share
0 Shares

Documentation project planning

As a technical writer with over twenty years of experience, I have seen project managers repeat the same mistakes across multiple projects. The root cause points to poor documentation planning. It is a problem that often goes unnoticed until a professional steps in and identifies it.

If you have delivered a project involving PCI, GDPR, ISO27001, ITIL, or policy and process documentation, ask yourself:

Did the project deliver all the required documentation?
If not, do you know why?

In my experience, the failure begins in the planning stages.

The First Mistake: Not Consulting a Technical Author Early

Did you speak to a technical author for a realistic appraisal?

If the answer is no, there lies your answer.

Managers treat documentation as a downstream activity. Something to complete once systems, processes, or controls are in place.

That assumption is wrong. Documentation is a structured discipline involving:

      • discovery
      • analysis
      • stakeholder engagement
      • controlled writing
      • review cycles
      • approval workflows

Without this understanding, planning becomes guesswork.

The Second Mistake: Underestimating Time and Budget

Another common issue:

The budget is short, and the timelines are optimistic.

Project managers frequently underestimate the effort required to produce controlled documentation.

A simple question often arises:

“How long does it take to write a document?”

The honest answer is:

“It depends.”

Because writing is only one part of the process.

What Actually Takes Time in Documentation Projects

For a typical documentation project, the effort is distributed across:

      • Information gathering
      • SME interviews
      • Conflicting opinions and interpretations
      • Writing and structuring
      • Multiple review stages
      • Amendments and rework
      • Final approval and sign-off

Here’s a realistic outcome to consider:

      • 30-page process document
      • 3+ Visio diagrams (10–30 steps each)
      • 3+ process narratives
      • 2+ appendices

Expected effort: 8–12 weeks before review.

That is one document.

Scaling the Problem: Compliance Projects

Compliance frameworks significantly increase the scope.

If starting from scratch:

      • 60+ documents is not unusual
      • 12–18 months of work is typical
      • 24 months is a safer estimate

If documentation already exists, fragmented across drives, emails, and legacy systems: Do not expect timelines to reduce; the first phase becomes:

      • consolidation
      • standardisation
      • validation

This alone can take months.

The Knowledge Gap in Planning

A major contributor to failure is a lack of understanding of:

      • The difference between a policy, a process, and plan
      • The document lifecycle (draft → review → approval → maintenance)
      • The complexity of controlled documentation environments

Delays are inevitable when managers cannot understand these fundamentals during planning.

Why do documentation projects fail?

Documentation projects typically fail due to:

      • Poor planning
      • Lack of documentation expertise
      • Unrealistic timelines
      • Insufficient budget
      • No defined ownership or review structure

Why Documentation Projects Succeed

Successful projects have:

      • Early involvement of a technical writer
      • Clear understanding of the documentation lifecycle
      • Realistic timelines based on effort
      • Defined ownership and governance
      • Structured review and approval processes

Hire a Technical Writer at the Start — Not the End

A common mistake is hiring a technical writer when:

      • deadlines are approaching
      • Documentation is incomplete
      • Exhausted budgets
      • At that point, recovery is expensive.

A technical writer engaged at the start can:

      • Identify risks early
      • define a realistic scope
      • structure documentation outputs
      • manage stakeholder expectations
      • prevent rework

Resourcing Considerations

Technical writers require:

      • Time to understand the project
      • Training on tools and environments
      • Access to SMEs
      • Availability for review cycles

You must also account for:

      • holidays
      • illness
      • unplanned absences
      • staff turnover
      • These are not exceptions. They are normal project variables.

Quality vs. Quantity: Use Prioritisation

When timelines are tight, prioritise deliveries using the MoSCoW Method:

      • Must have
      • Should have
      • Could have
      • Won’t have (this time)

Or classify documents as:

      • Required
      • Nice to have
      • Not important

Focus on delivering usable, controlled documentation, not volume.

Additional Planning Factors Often Ignored

      • Travel: Will the technical writer need to travel?
      • What can you reuse?
      • Review structure: Who reviews and who signs off?
      • Scope changes: How to control expansion?

Final Thought

When your project requires documentation, why is so much of the budget allocated to everything except documentation?

Documentation is not an afterthought. It is the mechanism that explains, controls, and sustains your operations.

Remove it—or underfund it—and the cost will surface later.

Usually, when it matters most.