AI : Friend or Foe

Featured

From Contract to Permanent

my transition from contractor to perm

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.

Featured

Technical Authors what we are and what we are not

Unveiling the True Potential of Technical Authors: More Than Just Writers

Don’t let the title of Technical Author fool you. Regardless of your opinion, do not underestimate us. We have the potential to offer unexpected help in more ways than one. Allow me to dispel the myth regarding our identity.

Misconceptions About Technical Authors

Not Just Software Developers

If I had proficiency in BASIC, C/C++, Java, etc., I would earn significantly more as a developer. While I receive calls for API documentation, a skill requiring familiarity with code, my primary focus remains on creating clear and concise technical documents.

Not Project Managers

I am not a project manager certified through Prince2, Agile Scrum, or similar programs. My project management skills are specific to technical documentation, where I manage schedules and meetings with subject matter experts (SMEs) and other stakeholders. My role does not include:

  • Detailed project planning, progress evaluation, risk management, or issue resolution. For these tasks, a full-time project manager is essential.
  • Secretarial duties such as organising colleagues’ schedules or taking minutes. I record my meetings and extract the relevant information for documentation purposes.

Not Departmental Experts

While familiar with the terminology, I am not an expert in every department. I learn on the job, facilitating communication and collaboration through practical verbal and written skills. My goal is to support and encourage achieving organisational goals without making the process daunting.

The True Role of a Technical Author

An External Consultant with a Plan

As an external consultant, I often use the MoSCoW method to categorise initiatives into must-haves, should-haves, could-haves, and will-not-haves (or wishful thinking). This approach ensures a structured and prioritised documentation process.

Documentation Management

Upon joining, I sift through all available documentation to identify gaps and areas for improvement. I manage documents and content using tools like SharePoint and Confluence, ensuring efficient information management for your teams.

Project Management Skills in Context

My project management skills, while not as extensive as those of a certified project manager, include:

  • Designing new templates and improving the structure of existing documents.
  • Documenting processes across several categories and arranging meetings with SMEs.
  • Planning, writing, reviewing, publishing, and maintaining content using tried and tested methods.

Extensive Experience and Resourcefulness

With over 23 years of experience, I possess an extensive library of generic documentation and various templates. This resourcefulness lets me tweak documents to meet your business profile, saving time and money.

ITIL and ITSM Expertise

I have experience producing IT Service Management (ITSM) documents based on ITIL best practices, including:

  • Service Design, Service Transition, Service Operation, and Continual Service Improvement.
  • Delivery and Service Support, Availability, Capacity, and IT Service Continuity Management.
  • Incident, Problem, Change, Release, Configuration Management, and Service Desk documentation.
  • Policy, Process & Standards documentation for ISO27001/9001 compliance, GDPR, PCI/DSS, and security projects.
  • Disaster recovery scenario documentation.
  • Infrastructure documentation to support large-scale networks and recently migrated infrastructures.

Editing and Enhancing Existing Content

I can enhance existing content by adding VISIO drawings, new screenshots, rewording policies, adding narratives, and creating new templates. I am also skilled at ensuring consistency and structure in Word documents.

Tools and Techniques

I keep projects on track using spreadsheets, MS Word, PowerPoint, and VISIO. I also suggest ways to maintain up-to-date and current documentation, treating information as an invaluable asset.

SharePoint and Confluence Management

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

If you lack a documentation strategy, I can create a plan tailored to your needs. Proper management includes ensuring documentation is available to all staff, appropriately updated, rewritten, and archived. Ownership, version control, and historical control are critical aspects of effective

documentation management.

Key Benefits of Effective Technical Documentation

Implementing adequate technical documentation can lead to the following:

  • Reduced costs.
  • A more responsive help desk/support system.
  • Better-informed staff and confidence in performing procedures.

By recognising the true potential of Technical Authors, organisations can leverage their skills to achieve greater efficiency, clarity, and overall

success.

Featured

Get a head start

Templates with generic content

Do you have a documentation project lurking in the background and you are yet to get to grips with the detail? I have available many templates which contain generic policies, processes, and standards content relating to the following documentation:

      • PCI/DSS
      • ISO27001
      • ITIL
      • ITSM

If you are embarking on a project for any of the above from scratch, you can save time measuring into months by using the relevant template.

Consider the fact it can take upwards of six weeks to produce one document of between 20 to 30 pages, imagine the scale of the work if you have more than sixty titles to write from scratch.

The content within the documents will require tweaking to make them relevant to your company, such as Team names and Team members, Technical terms and branding.

However, be aware I do not own a comprehensive list of Policy and Process documents. My library covers the documents that will take time to produce.

VISIOs

I own VISIO drawings covering the following and many more:

      • Incident management
      • Change management
      • Problem management
      • Document lifecycle

Templates with Headings only

You may require a set of pre-headed templates to help you document your Network. You can use these templates to document your servers and use the documents for many purposes.

Training: help new starters gain knowledge about the Network.

Audit: Have to hand information that can help you manage your Network over the long term.

Data Centres: Use the templates to plan a data centre migration.

      • Operating documents
      • Installation guides
      • Profile documents (5-Pages)
Featured

Technical Writing: The Survivior’s Guide

Have you ever thought about the role of a technical writer? This booklet based on my Blogs will give you the highs and the lows of the job.  You might learn something useful.

To buy a copy click on the link below.

Featured

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.

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.

Featured

Give us a break

Give us a break. We need it. I write with authority and experience with over 25 years of experience as a technical author. My enthusiasm for delivering clearly defined documentation/content strategy has never diminished. Yet, two common issues remain for which I have no answer:

      • management expects a quick return on their budget, and
      • meeting people who think our role is a waste of time.

Our role is vital, and without us, standards of written and oral communications will forever diminish. Like many technical writers, I have various skills which overlap into different roles. I may operate under the title, technical author, but I have many more job titles under my belt. What skills do you ask? I communicate with many experts and produce relevant policy and operational process documents regarding maintaining a network. While I may not have the technical knowledge, I could step into a role and manage the infrastructure by working with technical teams. 

What can I tell you?

  • Despite the title, we are not technical experts.
        • we are documentation experts; we have an innate ability to understand the technology and explain with help from an SME how it works,
        • analyse workflows and write complex processes with drawings to help teams work more efficiently.
  • our job is never straightforward as we rely on many factors that hinder progress,
  • A change to one document means changes to related documents that contain exact content; writing is not easy:
      • Try writing 300 words about yourself. When done, look closer; how many errors can you see, and what changes will you make?
  • We work with people who are not technical writers.
      • And people who do not understand documentation but have an opinion on how to write and manage documentation.
  • We are not miracle workers:
      • If you expect to see results within a short period based on an issue that has continued unchecked for many years, you will be disappointed.

Many assume we do a cut-and-paste job and do not know that writing and managing reams of content is a fundamental role. If not, companies would not need people like me to make sense of the problem, offer a solution, and complete the job.

What do we do?

I have worked with developers, engineers (of varying shades), and experts in IT subject matter. The majority either:

        • Regard documentation as a luxury,
        • write their documentation, or
        • I do not see the point,

The developers I have met consider technical writing below their pay grade. If you think we are below your pay grade, you need to understand our role and responsibilities. 

What do we offer? 

We link the business and the users by describing the product’s potential. Knowledge management: if the knowledge resides in a team member’s head, get it out before that head moves on. That knowledge is an asset. A skilled communicator is essential to get this work done. We create critical information that is subject to an audit.

        • Writers can help with ITIL, security standards ISO27001 with quality, processes and procedures.
        • They can also help marketing teams with collaterals, white papers, marketing materials.
        • They can create newsletters—internal and external.

Who cares? No one reads it! 

Try telling that to your customers who spend more time calling your helpdesk. If your documentation is not updated and compatible with their version, you will hear loud and clear complaints. 

Businesses forget their T&Cs contain a clause that explicitly clarifies providing documentation. 

Relax at work! 

We get little time to relax because we’re always looking at ways to improve the documentation quality. It is not a standstill role. As colleagues overlook us in many stages of the development, the release phase can be daunting due to:

      • Last-minute functionality changes,
      • managing un-realistic situations,
      • unrealistic deadlines,
      • Multitasking—working on other vital projects.

This profession has a high level of stress due to a lack of communication. Managers expect the documentation to be ready and available within a few hours. Sorry, unless you have a mega team of technical writers, that will never happen.

Documentation review can wait. 

If that is the case, you must make documentation an integral part of the software development life cycle (SDLC). It will help to:

      • Include the documentation review in the schedules of the reviewers.
      • return review comments to writers on time,
      • Writers are aware of necessary changes before deadlines to make the required modifications.

People assume technical writers only write and think it’s a straightforward job. The importance of technical writing will come when they understand:

      • The actual work we do, as technical writers,
      • the management of multiple issues to enable the completion of a project,
      • the process of documentation is also a process of quality control.

Be aware of your technical writer(s) and what they do to make you look good. Do technical writers work? A technical writer performs many other tasks and related activities as a part of the documentation process:

      • Multitask: work on multiple projects at different stages of completion. 
      • Organise: keep projects to prioritise the work,
      • Be patient: deal with deadlines,
      • Manage: track multiple documents and content.
      • Training: train staff in communication and writing skills.

An SME can do the job just as well. That is debatable:

      • SMEs have their responsibilities, and documents are way down their list
      • gaps in the content are common because they don’t believe certain functions are worth mentioning.
    • A technical writer will revisit the documentation, test for cracks, and add missing content.
        • professional technical writers are: 
        • more efficient, 
        • produce high-quality documentation,
        • structure documents for consistency,
    • design easy-to-use information, and
    • Perform other related writing activities.

My advice, take technical writers seriously, and everyone will be happy.

Featured

Project Managers and Technical Writers

Project managers and technical writers are two distinct roles. One of my many skills as a technical writer is organisation. We juggle many tasks and switch between them with ease. People skills are essential when speaking with coders, engineers, and technicians of various shades. In the meantime, we manage a ream of documentation while taking instructions from SMEs. Occasionally, we meet a project manager who has had minimal exposure to technical documentation during a project.

techwriting
Project Managers and Technical Writers

If you’ve never planned the tech writing part of a project, ask your technical writer for help. When project managers and technical writers work together, it helps the project succeed (because it’s well documented) and improves support for everyone.

If you are one of the many project managers who have never worked with technical writers, remember that we are professionals. We will not tolerate technical documentation that fails to meet the needs of others.

Techwriting
Project Managers and Technical writers

So, if you have no direct experience with documentation or technical writers, consider:

      • Please talk with your TW(s) because their experience will provide you with a much-needed background in document management.
      • To help plan the documentation, avoid creating timelines as you progress the project.
      • TAs cannot pull documentation from a hat or generate a document from code.
      • Please speak to the TW(s) to gauge how long it will take to review/write/edit a document. In my experience, many project managers overestimate timelines or, worse, underestimate deadlines. Always build in flexibility to allow for problems in the documentation process.
      • Reviewing a document intended for transformation that exceeds 20 pages will take time (the general rule of thumb is 1 hour per page).
      • The time required for writing
      • Peer reviews
      • Time to have the content technically reviewed
Featured

Technical Writing | Interviewing SMEs

One of the many skills a technical writer needs is the ability to form relationships with SMEs. An experienced writer talks to subject matter experts to gather insights for a document. Without their input, the writer will face difficulties producing documents. On one project, I worked with two technical writers. They had their styles of approach, and I have mine.

One of our team members, x,x, had a style and approach that rubbed many SMEs the wrong way. I have a laid-back approach. If the SME could not talk because of urgent work, then that’s fine—we can reschedule the conversation. X.X found it difficult to communicate with technical SMEs, which made it challenging to gather the information. He had never worked in the technical field coming not from a technical background, but a process background where people are polite.

Approaching and Interviewing  SMEs 

  1. Ensure you schedule a meeting with the SME in advance. Please do not turn up at their desk and expect to talk.
  2. If you collaborate with other technical writers, review the project plans and inquire whether they have contacted the subject matter expert (SME) regarding topic XYZ. If they have, verify the information is what you need. In such cases, refrain from requesting the SME to reiterate the information.
  3. I use a dictaphone to record interviews because I can always run the recording back if I have any queries. To date, no SME has objected to me recording the conversation.

    approaching and interviewing subject matter experts
    approaching and interviewing subject matter experts

    • If they DO, it will mean listening intently and writing the information
  4. Approach the Interview at the appointed time:
    • Do not be surprised if the SME cancels the meeting because of other demands,
    • If so, reschedule the meeting
  5. Always regard the interview as another knowledge-capture exercise that adds to your experience. Do not assume you know everything before you get there, even if you do.
  6. The SME will assume you understand their language; if not, stop the interview and request a less technical explanation or reassess your ability to do the job if you still do not understand.
  7. Schedule only an hour for the interview, but be clear that you will need to reschedule more time if specific points are unclear.
  8. Be transparent – there will be a peer review required, but you will let them know in advance when the document is ready for review
  9. approaching and interviewing subject matter experts
    approaching and interviewing subject matter experts

    If the SME is not aware of your role or why you need their comments to introduce the project, and if you have not already done so, introduce yourself

  10. The SME may not know everything and will refer you to another SME for information
  11. When you return to your desk, start writing the document. Do not wait for a few days, even if you have recorded the interview.
  12. Carry a pad and pen. You may need to ask the SME to draw the infrastructure.
Featured

Technical Writing | Professional vs Amateur, its a matter of choice

A LinkedIn connection shared a poster, which read: Professional vs Amateur; If you think it’s expensive to hire a professional, wait until you hire an amateur.

In 2004 I had an interview in Watford and later Cambridge with software companies looking for a Technical Writer. During the second interview, I had this feeling of deja-vu in that it followed a similar line to the Watford interview. The hiring managers seemed uncertain. The feedback was both companies appointed an internal resource to save money.

Later that year the Watford company after a management buy-out sacked the TA because the documentation failed to meet standards. I was later contacted by an agent after the Cambridge internal appointment failed to deliver.

A previous client called as one of their technical writers had left with work to complete. Once I analysed the work, I made it clear that I had no time to rewrite the work. The manager to keep costs down employed ‘technical writers’ with negligible experience on a high-profile project for a major Telco client.

I can appreciate the fact when times are tough companies like to make a few savings. However, the difference between employing a professional vs. amateur can be stark regarding cost.

Professional vs Amateur, it’s a matter of choice

What you need to consider is the result. Do you want a professional job or a makeshift effort by an amateur? Many experienced technical writers will point out that you get what you pay for. My advice is to be ready to pay the going rate to attract an experienced technical writer who is more than capable of doing the job. In terms of time and delivery, it will save you a lot of time and energy and negate the need to pay twice for the same job.

Featured

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.

Featured

Technical Writing | The Risks of Poor Document Management in Today’s Workplace

Poor document management is one of the hidden risks slowing down modern businesses. Lost files, outdated versions, and messy shared drives don’t just waste time—they undermine compliance, increase costs, and frustrate employees.

If you’ve ever panicked while searching for the “latest version” of a critical policy document before a big meeting, you’ve experienced the problem firsthand. Without a structured approach to the document lifecycle, companies quickly slide into chaos. The good news? With the right strategy—and the expertise of a skilled technical author—you can transform your documents into reliable, business-critical assets.


A Familiar Scenario

You’re sitting at your desk when your manager asks:

“Can you send me the latest version of our critical policy document? I need it now for a meeting.”

You search SharePoint. It’s not in the correct folder. A keyword search returns hundreds of results. You open several files only to find outdated versions. Panic sets in—your manager is calling again, already late for her meeting.

Most professionals have lived with this frustration. Documents still get lost. Outdated versions pile up, employees create their own file-naming systems, and critical knowledge gets buried. The truth is: traditional file storage is failing your business.


Why Poor Document Management is Costly

Failure to treat business documents as vital assets can lead to:

      • Diminished document utility – staff waste time searching or working with outdated files.
      • Decreased business efficiency – collaboration slows down when knowledge is hard to find.
      • Increased operational risk and cost – mistakes happen, compliance slips, and reputational damage follow.

These risks grow as document libraries expand without control.


Document Lifecycle Management: The Modern Approach

Effective document lifecycle management (DLM) ensures that every business document is valid, compliant, and accessible throughout its lifespan. This approach aligns with industry standards such as ISO 9001, ISO 27001, and ITIL frameworks, which increasingly demand traceability, version control, and accountability.

A modern document management process should cover:

      • Quick access – a centralised repository with search, tagging, and metadata.
      • Frequent review and updating – scheduled reviews to keep documents accurate.
      • Distribution – controlled sharing with the right stakeholders.
      • Conversion – ensuring compatibility across formats.
      • Archiving – moving obsolete versions into a secure archive.
      • Governance – applying version history, approvals, and sign-off processes.

The Role of Technical Authors in Document Management

In today’s workplace, technical authors are more than writers. They are custodians of clarity, consistency, and compliance. A good technical author:

      • Design document templates that meet ISO and ITIL requirements.
      • Establishes metadata fields for versioning, approvals, and document history.
      • Creates plain-English policies and procedures that employees actually use.
      • Trains staff on how to manage documents when no dedicated document controller is available.

By treating documentation as business-critical knowledge assets, technical authors help organisations stay compliant, agile, and productive.


Moving Forward

If your organisation’s document library is growing without control, now is the time to act. Consider investing in a Document Management System (DMS) such as Asite, SharePoint, or Confluence. Pair it with transparent governance and skilled technical authorship, and your documents will support—not hinder—your business.


Key Takeaway

Poor document management isn’t just an inconvenience—it’s a risk to business performance and compliance. By adopting structured document lifecycle management and empowering technical authors, organisations can ensure their knowledge assets remain accurate, accessible, and valuable.

Contact us to learn how we can transform your document management.

Featured

Technical Writing | Disaster Recovery Plan

Document the Disaster Recovery Plan

Remember, to be effective you must be prepared to document the plan. Without the documentation you risk the possibility of NOT recovering from a disaster, therefore placing the entire company at risk.

If you have no existing documentation that describes the functions of the company’s servers and their hosted Applications, consider writing relevant Operating Document. In the event of a disaster, without knowing the role and the purpose of a server, as well as the Operating system – it could delay recovery.

A list of your critical systems

All companies will have a set of applications hosted on servers, which, are crucial to the business such as financials.

List your servers by priority and the criticality of the hosted Application – that is the amount of time the server and its applications can remain non-functional before it severely disrupts operations.

Create a disaster recovery plan for each critical system

This returns to the Operating document. To recover the system during a Disaster could take time, more so if the Owner is not available during the disaster to help login and failover the system then failback the system.

Therefore Keep documents simple, direct and to the point and written in such a way that anyone can understand the process, not just the SMEs who designed and built the system.

Who is responsible
Delegated participants must know and understand their responsibility should a disaster happen. Engage them in areas where they will know what to do and act accordingly. When compiling such lists make sure there are Team Leads, and Deputies should the first choice not be available during a disaster.

Make Backups
In this context be sure that if you use allocated drive space that your staff are backing up valuable information and documents to that allocated space.

Do you have an Off-site backup
Store all data in an Off-site Common.

Store Backups off-site in a location away from the same grid as the originals.

Test the Plan
On completion of the written plan, you enter the test phase. Make a plan to failover your infrastructure and then failback the infrastructure.

Take notes along the way to strengthen the areas in the plan which need more validation. Note where there is a need to access backup data time how quickly it takes to restore the system.

Keep the plan safe
Store a paper copy of the plan in a safe place. Remember: during a Failover, the online version could be unavailable.

When it comes to planning your Disaster Recovery strategy, do not forget the disaster recovery documentation. It may be the last project on your mind but could prove to be your company’s one lifesaver.

Disaster Recovery never stops and undergoes modifications every six months or twelve months.

Featured

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.

Featured

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.

Featured

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.

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.

Featured

Technical Writing | A brief guide to documentation projects for Project Managers

A brief guide to managing documentation projects for Project Managers will demonstrate that when done correctly will produce long-term benefits.

Here are some examples to help keep your documentation on track.

The original writer is not the best person to check their documentation because they very rarely spot their mistakes.

  • Arrange for a peer review and/or technical review of all changes
  • establish a review process to make sure the documentation is both factually correct and consistent.

All documentation requires ongoing review once or twice a year.

  • If your company use a Document Management system to store documentation, make use of the “metadata” windows to describe the content changes to make the review process easier and consistent.
  • If you are so inclined adding an index to your document, especially when it is a large document will enhance the documents usability

Like everything else, documents become living information that:

  • Maintaining the documentation represents a significant challenge
  • Without a management policy or agreed procedure, the Documentation you are creating will cease to have any value if it is not updated
  • Documentation requires dedicated resources, in which some companies will not invest
  • In other words, use or contract an experienced Technical Writer
Featured

Technical Writing | Why your business needs technical documentation

IT Managers often undervalue the importance of technical documentation until they realise its absence. Listed below are six reasons why your business needs technical documentation.

      1. If you don’t have technical documentation, there won’t be any records of past projects in the company.
      2. You have no metrics against which to measure current projects
      3. You have no information which outlines the lessons learned, and the lessons failed
      4. The team is guessing their way through the upgrade project. . . it also means the project will take much longer to complete, stretching the budget
      5. What documentation there is lies scattered over several drives and only makes sense to the author
      6. Your valued tech staff have left the company, taking information with them in their heads

Now you know why Technical Documentation is essential; if you recognise one or more of the points above . . . what’s your next move?

Featured

Documentation projects, before, during and after

Documentation Projects

Many Project Managers and Subject Matter Experts fail to understand the challenges posed by documentation projects. To lead such a project, you need to know what is important and how you will achieve the goal. What preparations should you make to ensure you complete the project within budget?

Here follows the best advice on the documentation projects, before, during and after.

There are many types of technical and process documentation. If the project is compliance based (PCI, GDPR) concentrate resources on the documentation. Consider hiring a Technical Writer quickly for advice.

Capture the data/content

  • Check the availability of the Subject Matter Experts as well as other team members critical to the project
  • Consider the audience for the documents as that will determine the level and detail of the material.
  • Remember the level of content and information is only as useful as its source and the ability of non-technical audiences to use and follow the instructions/processes

Organise the document and content

Create a standard template with Heading and instructions regarding the level and type of material the TWs need to gather. As a guide use the following headings:

  • Work History
  • Versioning control
  • Scope/Out of Scope
  • Document Purpose
  • Document ObjectiveIntegrate Level 1 to 3 Headings to outline the topics.
    • You can base these decisions according to prerequisite documentation knowledge to provide the master plan for all future written work.
  • Does it require VISIOs/Screenshots?
  • Appendixes

Do NOT waste time creating project timelines to write and produce the documentation.

Until the information and gathering phase begins, do not even consider a guess about how long it will take to complete the documentation.

As the list of titles grows, Management may need to consider extending the budget to finance the project. Abandoning the documentation when it is ‘Nearly there’ will be waste of money, time and resources.

Decide the output format

When the Technical Writer has written the documents, consider which of the following formats will suit the company’s requirements.

  • MS Word stored in a Document Management System
  • PDF stored in a Document Management System
  • *.CHM files created by using such application as RoboHelp
  • Wiki formats: A Wiki provides the user community with the opportunity to provide documentation feedback

Future Review Requirements

Do not overlook the future requirements of any project. All documentation is an ongoing project. Establish a workflow between the IT teams/Process teams and the documentation department to update documentation.

  • Update the documentation when:
  • the IT teams upgrade or modify the Server/Application/technology
  • document all changes, using a change management process to prevent any repeat the configuration
  • align the documentation and the project

Revise the Project

On completion of the project Use the documentation to:

  • reflect the changes and updates
  • test to ensure instructions are clear, concise and correct
  • Avoid considerable time, frustration, and future expense by correctly applying documentation strategies to:
  •  . . . ensure that users can follow the instructions
  • . . . provide a historical record of the changes made during the project

Manage documentation projects before, during and afterClick To Tweet

Featured

Technical Writing | The cost of Technical and Process documentation

Why is it that companies view the cost of Technical and Process documentation as an unnecessary expenditure rather than viewing documentation as a centre of knowledge? Management seems to have a blind spot with documentation and conveniently forgets the role of documentation.

Techwriting | Technical and Process Documents

When redundancies beckon, I know how quickly management will sacrifice the technical documentation department. When management seeks layoffs, the technical author(s) will be amongst the first out the door. Months later a member of staff points out that the documentation is out of date and follows up by asking: do we have anything up to date we can use?

In sacking the technical documentation team, no one assumed responsibility. Keeping it up to date is left to those least inclined to keep it up to date. They are the people who would benefit most from its upkeep.

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

Within a software environment, we easily forget that as the developers progress their software application, it also becomes more complex. Failing to supply up-to-date documentation means customers can overlook many of the improvements and advanced features. We could say the same of any IT department. As the network grows, there are more questions and fewer answers. No one has a good overall knowledge of the network because of the lack of documentation.

Where does that leave technical writers?

However, you refer to us, be it technical authors, communicators, documentation staff or as the font of all knowledge. Never doubt our experience, our people skills, our ability to write clear instructions.  We can explain complex technical terms in easy-to-read formats. Who else will put up with blank stares, sarcastic comments and listen to comments such as “whaddya want now?’ to get what your company needs; usable documentation.

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

Remember, it is not about the cost of hiring a technical author. It is about our value to your organisation. Our documentation will keep your staff informed and up to date. There is a point to keeping your processes up to date as your working environment changes. It is also about keeping that software guide up to date enabling your customers to use your product more efficiently and know they invested in a superb product.

Finally, don’t forget that a technical author will not only you save money now but also at a later date and will keep on saving you money, therefore, over the long term justifying their value to your business.

The cost of Technical and Process documentationClick To Tweet

Featured

Technical Writing | Hiring a Technical Writer

Budgets for the job

When you start the process of Hiring a Technical Writer, my advice is this: do not cut corners when sourcing a budget:

  • Check the daily rates/hourly rates. Do not expect an experienced technical writer if the daily rate is derisory.
  • If your rate is low, you will attract Technical Writers with less experience whereby the result could be a disjointed document with no formatting and poor English
  • A good TW who charges a higher rate may save you money by taking less time to do the job.

Your Technical Writer in the flesh

hiring a technical writer
Hiring a technical writer for your project

Many TWs will have worked in a variety of environments. In due course, we gain knowledge that could provide a solution to other long-running problems. Hence why managers should never underestimate TWs.

What will you need?

Before you actively engage the TW on your site, do you have all equipment ready:

  • One of the most common problems is no laptop on the day they start
  • That their profiles to log in to the network are set up
  • If they are reviewing existing documentation make sure it is available

When you start explaining the work to a TW in company-specific jargon, do not assume they understand you. There is a good chance that the TW during an interview may mention that what one company knows as “XYZ” may not be the same as yours.

What should you do?

  • Be certain the SMEs or others with whom the TW will engage are aware of the appointment and know the goals of the project
  • If you are the primary contact do not disappear without the TW knowing where you are or who is second in command
  • Do not assume the TW is less than proactive if you cannot see them writing down a list of questions and talking to the appropriate people. If they are reviewing existing documentation, they may need a few days to understand the content before they start acting pro-actively

Techwriting Hiring a Technical Writer
Hiring a Technical Writer

If after settling on a start date

If a problem arises let the TW know in advance because:

  • You may need to change the start date or find another job for the TW to assess.
  • Delays will only diminish your budget if the TW is on-site with nothing to do.
  • If the problems are likely to be ongoing be honest and let the TW know – do not consistently change the start dates because it is not very professional and TWs do talk to fellow TWs.
  • Be consistent with the project, its objectives, and deadlines
  • Do not change the parameters of the project by allowing project scope creep.
  • Communicate with the TW as S/he may not have the time to stay beyond the current time allotted for the project.
  • Make contingencies if you need to extend the contract

What will the Technical Writer do for you?

Supply a project plan. Do not expect one within a matter days. if they own a generic copy, they can adapt it for the project; else create one from scratch.

The project plan should include a documentation schedule, including milestones and how progress can be measured.

On longer projects, TWs will complete a weekly project management report, which will outline problems, issues, bottlenecks, etc.

If the contract states that travel abroad or within the UK is necessary, make sure they are available to go.

Foreign travel as part of the contract

Some companies expect contractors to pay their expenses up front on foreign trips.

Might I suggest that they:

  • Can afford to do so without getting into debt.
  • Know the procedure to claim their expenses
  • Be clear on when the payment will be paid
    • I once submitted expenses, which, due to a misunderstanding took three months to process.

Featured

Technical writing | Now that you have Technical Documentation

So, after the initial shock of discovering what happens when you have no technical documentation, what can you achieve now that you have technical documentation?

1: Have you employed/contracted a Technical Author . . . Great!! If not what’s holding you back . . . remember we bring value

2: If you cannot see your technical author at their desk you’ll no doubt find him/her performing Vulcan mind melds and extracting the necessary technical information from the heads of your development/infrastructure staff (if it looks painful don’t worry, the job is mandatory!)

3:  Start a discussion about what you need and I’m certain your technical author will only be too happy to help?

4: Once you have technical documentation there is no more guesswork as you have plenty of reliable data against which to measure the progress of future projects

5: You can also employ a project manager who can plan ahead because you know everyone who needs it!

6: Documentation is no longer a problem and what you require is what you will get . . . Congratulations!

Featured

Technical Writing | The Problem with Shared Drives

It is not unusual to find companies still use Shared Drives to store their documentation. As many Technical Writers will point out, the problem with shared drives is that they are neither secure nor searchable.

What is the problem with shared drives?

  • The folder structure has too many levels meaning documents are difficult to find
  • There are information gaps as users keep copies of documentation locally and not on the shared drive
  • There is no formal ownership of the documents
  • The title and subject of the document does not accurately reflect the content
  • Document versioning is not used meaning the latest version is  . . .  Where?
  • There are many copies of the same document
  • The failure to maintain a workable Archiving policy means many documents with the same title contain unchecked updates
  • There is no historical tracking of documents to keep integrity of the content
  • Searching for documents on a shared drive will raise many unrelated results

Using a non configured Document Management System (DMS)

It would seem ironic that companies do spend a large amount of budget on installing a DMS such as SharePoint but fail to task an experienced employee to set it up correctly. So what happens when the DMS is left to grow without the correct administration?

  • Failure to lock down user privileges means it becomes a free for all  with no proper administration
  • Check In, Check Out, Document Versioning and Security are not configured meaning user’s drop off documents where they see fit
  • There is no historical tracking of documents to keep integrity
  • Users create folders without proper titles and lose their document
  • Backup of the DMS is irregular

If you want to manage your documentation in a way in which it cannot become a free for all you need to consider a form of document control and establish a policy and a set of rules to keep your documentation in check.

Technical and Process Documentation is an asset, and your staff should treat it as such. Look after it, and it will look after your business.

How to Handle Managers Who Misunderstand Technical Writing

Managers often misunderstand technical writing. This article explains how to clarify the role, work with SMEs and protect the value of documentation expertise.

Many managers misunderstand the role of technical writing. They may assume technical authors are administrators, general writers or people who should become subject matter experts before they can write effectively.

That misunderstanding creates avoidable tension. Technical authors are already specialists. Our expertise is in documentation, structure, audience analysis, clarity, governance and making complex information usable. We work with subject matter experts; we do not replace them.

Why the Misunderstanding Happens

In many organisations, people treat documentation as something anyone can do if they have time. That view ignores the skill involved in turning fragmented knowledge into useful, accurate and maintainable content.

Managers may also work in environments where people wear multiple hats. As a result, they may expect technical authors to become experts in ISO 27001, ITIL, engineering, infrastructure or compliance, rather than recognising that our role is to extract, structure and communicate information from the people who own those subjects.

Common Misconceptions About Technical Authors

    • Documentation is just writing. In reality, it involves research, analysis, structure, validation and maintenance.
    • The writer must be the subject matter expert. Technical authors need enough understanding to ask the right questions, but the SME remains responsible for technical accuracy.
    • Certification in every subject makes a better writer. Relevant knowledge helps, but unrelated certification can pull the writer away from the documentation role.
    • Documentation is administrative work. Good documentation supports risk management, compliance, onboarding, service continuity and operational control.
    • Anyone can tidy up documents. Cleaning up documents without addressing structure, ownership and audience rarely solves the real problem.

The Consequences of Getting It Wrong

When managers misunderstand technical writing, they often misuse the technical author. That can lead to weak documentation, wasted effort and poor collaboration with SMEs.

      • Technical authors are pulled away from their core strengths
      • SMEs avoid ownership because they think the writer should know everything
      • Documents become polished but inaccurate
      • Projects lose time because expectations were never agreed
      • The organisation undervalues a role that protects knowledge and reduces risk

How to Address the Misconception

Clarify the role early

Explain that technical authors make complex information understandable, usable and maintainable. We are documentation specialists, not replacement engineers, auditors or service managers.

Define SME responsibility

Make it clear that SMEs provide and validate the technical content. The technical author structures, challenges, edits and presents that information for the intended audience.

Show the value of documentation expertise.

Highlight the work that often goes unseen: information architecture, audience analysis, terminology control, document governance, plain language, version control and review management.

Recommend relevant training

If a manager suggests unrelated certification, redirect the conversation. Training in structured authoring, information architecture, UX writing, accessibility, or content governance may be more relevant than certifying in every subject a project touches.

Final Thought

Technical authors do not need to become every type of SME to add value. Our value lies in making specialist knowledge usable, accurate and accessible.

Managers who understand that distinction get better documentation, stronger collaboration and fewer misunderstandings.

Why Comprehensive Documentation Matters for Business Success

Comprehensive documentation improves business clarity, reduces risk, supports governance and helps organisations make better decisions from reliable information.

Comprehensive documentation matters because organisations cannot manage what they cannot understand. Clear, accurate, well-structured documentation helps people make decisions, reduce risk, transfer knowledge, and keep work moving when key people are unavailable.

Yet documentation is often underestimated. People treat it as administration, tidying up, or something to do after the real work is finished. In practice, poor documentation creates hidden costs: repeated questions, duplicated effort, weak handovers, audit problems and decisions based on incomplete information.

My experience as a technical author and contractor has shown me that comprehensive documentation is not a luxury. It is a business asset.

Why Comprehensive Documentation Is Often Undervalued

Technical authors are sometimes misunderstood because good documentation looks simple when it is finished. People see the final document, but not the analysis, questioning, structuring, validation and review work behind it.

On one contract, after I had explained a network back to an engineer, he admitted he had assumed I was a secretary. On another project, I joined a group of long-term employees for lunch. When they asked what I was doing, I said I was tidying up the documentation. They laughed and said, “We’ve tried. What makes you think you’ll make it work?”

Those comments reveal a common problem. Many organisations do not recognise documentation as a specialist discipline until poor documentation starts causing visible problems.

The Business Value of Comprehensive Documentation

Comprehensive documentation gives an organisation a reliable reference point. It turns scattered knowledge into information people can find, trust and use.

Strong documentation helps organisations:

      • Reduce dependency on individual knowledge holders
      • Improve decision-making with accurate information
      • Support audits, governance and compliance
      • Speed up onboarding and handover
      • Improve operational consistency
      • Reduce rework and repeated questions
      • Identify gaps, duplication and unclear ownership

The value isn’t just in the documents themselves. The value is in the clarity they create.

What Happens When Documentation Is Weak?

Weak documentation rarely causes one dramatic failure. More often, it creates friction that accumulates slowly.

      • People rely on memory instead of agreed processes
      • Different teams describe the same thing in different ways
      • New starters struggle to understand how work is done
      • Managers cannot see where responsibilities begin and end
      • Audits take longer because evidence is difficult to find
      • Projects repeat mistakes because lessons are not captured properly

These problems cost time and money. They also damage confidence. If people cannot trust the documentation, they stop using it. Once that happens, the organisation falls back on informal knowledge, private notes and individual memory.

When Documentation Proves Its Worth

In one contract, a senior executive was visibly frustrated because he could not get clear answers. The information existed, but it was scattered, inconsistent and difficult to use.

Once he received a properly structured set of documents, the situation changed. The documents gave him the answers he needed and helped him identify other areas where better documentation could solve similar problems.

That is often the turning point. Documentation shifts from background work to a practical business tool.

Comprehensive Documentation Is More Than Writing

Good technical documentation is not just well-written text. It also requires structure, ownership, purpose and maintenance.

A technical author will usually consider:

      • Who the document is for
      • What problem the document solves
      • Which information must be included or excluded
      • Who owns the content
      • How the document will be reviewed and updated
      • Whether the structure helps people find what they need
      • How the document fits into the wider documentation set

This is why comprehensive documentation often reveals deeper problems. A missing process, unclear responsibility or inconsistent definition may sit unnoticed for years until a documentation project exposes it.

Documentation Supports Governance and Compliance

For regulated or process-heavy organisations, documentation also serves as a governance tool. Policies, procedures, standards, and operational guides show how the organisation works and how it controls decisions.

If documentation is incomplete, out of date or difficult to navigate, governance becomes harder to demonstrate. Audit preparation takes longer. Compliance evidence becomes harder to locate. Staff may follow different versions of the same process without realising it.

Comprehensive documentation reduces that risk by creating a clearer, more consistent information base.

How to Improve Business Documentation

Improving documentation doesn’t mean creating more documents for their own sake. It means making the documentation useful, reliable and maintainable.

Start with these questions:

      • Which documents do people actually use?
      • Which documents are duplicated, outdated or contradictory?
      • Who owns each document?
      • When was each document last reviewed?
      • What information do people keep asking for?
      • Where are the gaps that create operational risk?

These questions help turn documentation from a storage problem into an information management exercise.

Further Reading

Final Thought

Comprehensive documentation helps an organisation understand itself. It captures how things work, why decisions matter and where risks sit.

Clear documentation leads to better decisions. When it is neglected, the organisation pays for it through rework, confusion, delay, and risk.

That is why comprehensive documentation matters for business success.

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.

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.

Why SharePoint Fills Up With Useless Documents

Many organisations fill SharePoint and other document management systems with repeated, low-value content. The problem is not usually deliberate duplication. It is poor ownership, weak governance and a failure to define the source of truth.

Following on from my article suggesting technical authors/writers should avoid publishing articles on LinkedIn that cover repeated topics (many times over), let’s focus on the wider problem.

What happens when SharePoint becomes a dumping ground by accident? It happens one unnecessary document at a time. The culprits are duplicate documents in SharePoint.

So, before you sit down to write a document, ask yourself one question: What existing information does this replace, improve, or retire?

In SharePoint and other DMS environments, duplication happens for several common reasons.

1. People write to prove activity, not to solve a problem

Many documents exist because people require proof that they have completed a task (hey, look at me!). They use the document to show we followed the rules, which is something the project will finish, or results from a meeting. Its purpose is not always to inform the reader. Its purpose is to exist.

This leads to documents stating:

We reviewed the process.
We identified improvements.
We recommend further engagement.

Which usually means:

We have written a document to show we are moving something forward, even though nothing practical has changed.

2. Contributors do not search before writing

Many contributors do not treat the DMS as a knowledge source. They treat it as a dumping ground. Before writing, they do not ask:

      • Has an SME written this already?
      • Is there an existing approved version?
      • Is this a replacement, supplement, update, or duplicate?
      • Who owns the current source of truth?

Someone creates another document because writing from scratch feels easier than updating the original.

3. No one knows what the “source of truth” is

This is the major failure. If the organisation has five versions of a process, which is the source of truth?

People create another one because they think:

“The existing document is old.”
“That version is for another team.”
“I need one that fits my project.”
“I was asked to produce my own version.”
“I don’t know whether I’m allowed to change the existing one.”

The result is not knowledge management, but document inflation.

4. People confuse variation with value

An editor does not add knowledge to an existing document by changing words. They have added another route to the same information.

This is common with LinkedIn-style articles, too. Many repeat the same safe observations:

      • Communication matters.
      • AI will change documentation.
      • SMEs need to collaborate.
      • Plain English is important.
      • Documentation must be user-focused.

All true. But if the article does not add evidence, it is noise and clutter.

5. There is no editorial control

Most DMS platforms are not the problem. SharePoint, Asite, Confluence, Teams, and other systems can hold solid information. But without governance, they become storage cupboards.

Who is asking the hard questions before accepting new content?

      • What is this document for?
      • Who is the audience?
      • What decision or task does it support?
      • Does it duplicate existing content?
      • Does it replace another document?
      • Who owns it?
      • What is the review period?
      • What should be archived when this is published?

Without that discipline, every project, team, and manager produces another version of the same thing.

6. People write around uncertainty

Sometimes duplication is a defensive act. People are unsure what is current, so they produce their own document to protect themselves.

It says:

“This is what our team is doing.”

But underneath it means:

“I do not know whether the official process is reliable, so I am creating something I can point to later.”

That is an organisational trust problem, not a writing problem.

7. Documents are easier to create than to maintain

Writing a new document gives people a sense of progress. Maintaining an old one requires discipline.

Maintenance involves:

      • verifying accuracy,
      • consulting with owners,
      • removing obsolete content,
      • fixing links,
      • updating screenshots,
      • reviewing metadata, and
      • archiving superseded material.

That is less glamorous than publishing something new, but is where proper information management happens.

The technical author’s view

A technical author or information manager should not ask, “Can you write this?”

They should ask:

“What existing information does this replace, improve, or retire?”

That one question would stop a large amount of useless documentation.

When organisations reward production over usefulness, they count documents, uploads, articles, and deliverables, but rarely measure whether anyone used, trusted, or needed them.

A controlled DMS isn’t a place for everyone to upload additional information. Instead, it is a managed environment where only the appropriate information remains, while the unnecessary data is challenged, merged, archived, or removed.

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.

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.

Why Most Information Management Systems Fail?

Most information management systems do not fail because of the technology. They fail because organisations place the wrong people in charge of them.

It might sound tough, but I’ve seen the same issues over and over in documentation, governance, migration, and digital transformation projects for years.

A company buys a shiny new platform. Perhaps it is SharePoint, Asite, OpenText, Confluence, or some other enterprise repository promising collaboration, governance, and a “single source of truth.” Senior management signs off on the budget. Consultants arrive. Workshops take place. PowerPoint slides appear with words like transformation, efficiency, and digitisation.

Then reality arrives.

The people tasked with implementing the system often do not understand:

      • Information architecture
      • Metadata strategy
      • Document lifecycle management
      • Governance
      • Retention
      • Taxonomy
      • Search behaviour
      • Classification
      • User behaviour
      • Migration risk
      • Audit requirements

Instead, the responsibility falls to:

      • Project managers are trying to keep timelines alive
      • Administrators are learning the system as they go
      • Engineers or operational staff are given “document duties”
      • Junior analysts following configuration guides
      • Contractors brought in late with no authority
      • Teams follow instructions without understanding why the rules exist

The result is predictable.

Folders become dumping grounds. Metadata becomes inconsistent. Naming conventions collapse within months. Nobody owns review cycles. Duplicate files spread everywhere. Obsolete documents survive for years. Search becomes unreliable. Staff stop trusting the repository and return to shared drives, desktops, Teams chats, and email attachments.

The system technically works.
The information ecosystem does not.

One of the biggest problems is the culture of “learning on the job” without experienced guidance. There is nothing wrong with learning. Every profession requires it. The danger appears when organisations assume complex information governance can be improvised by whoever is available.

Information management is not merely administration.
It is a discipline.

A proper information manager understands:

      • Governance structures
      • Risk
      • Regulatory obligations
      • User behaviour
      • Retrieval logic
      • Version control
      • Controlled publishing
      • Retention schedules
      • Audit defensibility
      • Migration integrity
      • Operational continuity

Without that knowledge, teams often follow instructions mechanically.

“Upload the files.”

“Apply metadata.”

“Move everything into SharePoint.”

“Create the folders.”

“Archive old material.”

But few stop to ask:

      • Why are we storing this?
      • Who owns it?
      • Who reviews it?
      • Is it duplicated elsewhere?
      • Is it authoritative?
      • What is the retention requirement?
      • What business process depends on this information?
      • What happens if somebody follows the wrong version?

That lack of understanding is where many systems quietly begin to decay.

The harsh truth is that some organisations confuse software knowledge with information management expertise. Knowing how to create a SharePoint library does not make someone an Information Manager, just as knowing how to use Word does not make someone a technical author.

Technology alone cannot compensate for weak governance.

Another recurring issue is leadership detachment. Senior management often sees Information Management as an IT deployment rather than an operational control mechanism. Once the platform is installed, they assume the job is complete.

It is not.

The difficult work starts afterwards:

      • Governance
      • Ownership
      • Review enforcement
      • Classification
      • Rationalisation
      • Training
      • Audit checks
      • Lifecycle management
      • Repository discipline

Without these controls, entropy takes over.

This is why many migrations fail to improve anything. Organisations transfer chaos from one platform to another. The old shared drive becomes a badly organised SharePoint site. The same ROT — redundant, obsolete, and trivial information — survives the migration untouched.

A poorly governed system can often outperform an excellent platform without it.

The uncomfortable conclusion is this:

Most information management failures are not technical failures.
They are failures of leadership, governance, experience, and understanding.

Until organisations place experienced people in charge of their information estates — people who understand both systems and governance — many so-called digital transformations will continue to become expensive storage exercises disguised as progress.

Why SharePoint Becomes a Document Graveyard

As a technical writer, I know most organisations don’t lack documents, but they do struggle to find a specific document. We will hear them muttering, “Where is it?” as they search. After hours of hunting, they finally located the document buried in an obscure location in their SharePoint. This represents a failure in information control.

I once worked for a government quango. One of the IT staff moaned about SharePoint: “It’s useless,” he said, “I uploaded a document and lost it.”

I faced him and asked a question. “Did you create a folder?”

“Yes.”

“What’s the name of the folder?”

“Don’t know.”

“Title of the document?”

“Something to do with the network.”

After fifteen minutes, I found it in an obscure folder hidden among many others.

That is why so many SharePoint environments become digital graveyards. I conducted an analysis of a client’s document system and Confluence and found.

      • Thousands of files
      • Endless folders
      • Duplicate content with no owner
      • Outdated procedures
      • Unowned documents
      • Broken permissions
      • Conflicting versions
      • No trust in the information

The problem is not SharePoint, but how teams use it, because companies do not learn how it should work and train people.

People treat SharePoint like a filing cabinet.

Many businesses deploy Microsoft SharePoint, expecting it to solve:

      • Knowledge management
      • Collaboration
      • Governance
      • Information retrieval
      • Document control
      • workflows

But SharePoint is a platform. Not an information strategy.

Without governance, people recreate old network-drive behaviour:

      • Department folders
      • Personal silos
      • Random naming conventions
      • “Final_v2_REAL_FINAL”
      • Uncontrolled uploads
      • Duplicate libraries

The organisation digitises its chaos.

Nobody owns the information lifecycle

While documents are easy to create, they are much harder to maintain.

Most organisations focus on:

      • Creating information
      • Migrating information
      • Storing information

Very few focus on:

      • Reviewing information
      • Archiving information
      • Retiring information
      • Validating accuracy
      • Removing ROT

Technical authors and information managers often use the acronym:

ROT

    • Redundant
    • Outdated
    • Trivial

Over time, ROT spreads everywhere.

And because nobody wants to delete anything:

      • Old procedures remain searchable
      • Obsolete guidance survives indefinitely
      • Legacy templates continue circulating
      • Users lose confidence in what they find

Eventually, staff stop trusting SharePoint altogether.

Search Becomes Meaningless

Search only works well when information is:

      • Structured
      • Tagged properly
      • Consistent
      • Governed
      • Maintained

Most SharePoint environments contain:

      • Poor metadata
      • Inconsistent titles
      • Duplicate terminology
      • Mixed file standards
      • No taxonomy strategy

So users search for:

“VPN process”

And receive:

      • 47 documents
      • 12 outdated procedures
      • 6 duplicates
      • 3 archived versions
      • 1 incomplete draft

At that point, people stop searching and start asking colleagues instead.

Tribal knowledge replaces controlled information.

SharePoint often mirrors organisational dysfunction

One uncomfortable truth:

Poor SharePoint environments usually reflect a poor organisational information culture.

Common symptoms include:

      • Departments protecting silos
      • No governance authority
      • No content standards
      • No review ownership
      • No retention discipline
      • No metadata strategy
      • No information architecture

The technology exposes the underlying disorder.

Projects Flood SharePoint with Dead Content

Large IT and engineering projects generate enormous amounts of:

      • Drafts
      • Working papers
      • Design discussions
      • Meeting outputs
      • Temporary deliverables
      • Review copies
      • Migration files

Much of this content has only short-term value.

But organisations rarely clean up after projects end.

So SharePoint accumulates digital sediment year after year.

Nobody archives because:

      • They fear deleting something important
      • Ownership disappeared after restructuring
      • Contractors left
      • Teams changed
      • Governance was never defined

The result is institutional hoarding.

Permissions Create Invisible Chaos

Another major issue:
Overcomplicated permissions.

Many SharePoint environments evolve into:

      • Broken inheritance structures
      • Conflicting access rights
      • Locked-down libraries nobody can use
      • Open libraries nobody should access

Eventually, users bypass governance by:

      • Saving files locally
      • Emailing attachments
      • Creating unofficial repositories
      • Using Teams chats as storage
      • Maintaining shadow systems

The platform fragments further.

AI May Make the Problem Worse

AI search and summarisation tools sound attractive.

But AI trained against unmanaged repositories can amplify confusion:

      • Surfacing obsolete content
      • Repeating inaccurate procedures
      • Mixing draft and approved information
      • Generating false confidence in poor data

AI cannot distinguish:

      • Operationally valid content
      • Regulatory accuracy
      • Controlled documentation
      • Organisational truth

Information architecture scaled through AI becomes faster misinformation.

SharePoint works well — When information is managed

Well-run SharePoint environments can work, but require:

      • Governance
      • Taxonomy
      • Ownership
      • Review cycles
      • Metadata discipline
      • Archiving policies
      • Information architecture
      • Content lifecycle management

Most importantly:
They require organisations to treat information as an operational asset — not digital clutter.

Because without governance, SharePoint does not become a knowledge hub.

It becomes a corporate attic full of forgotten documents nobody trusts.

Organisations need to step up, invest in training, and employ an information manager.

Why Technical Authors are disappearing from IT Projects

Technical authors are vanishing from many IT projects.

Project managers, hire a technical author
Hiring a suitable Technical Author

Not because documentation is no longer needed.

But because organisations convinced themselves that:

      • Agile removed the need for documentation
      • SMEs could “just write it”
      • Developers could document as they build
      • Wikis replaced structured information management
      • AI can now generate everything automatically

The result?

Documentation did not disappear. Ownership disappeared.

The Agile Misinterpretation

IT misunderstood Agile, believing it meant:

Less documentation.

What Agile challenged was:

      • Excessive bureaucracy
      • Huge unused specification sets
      • Documentation written for sign-off instead of operational value

But somewhere along the line, many organisations translated this into:

We no longer need technical authors.

So documentation responsibilities were fragmented across:

      • Developers
      • Business analysts
      • Product owners
      • Service managers
      • Support teams

Everyone became partially responsible.

Which usually means nobody became fully accountable.

IT Projects Still Produce Complexity

Modern IT environments are not simpler but more complex than they were 20 years ago.

Today’s projects involve:

      • Cloud platforms
      • APIs
      • Identity management
      • Cybersecurity controls
      • SaaS integrations
      • DevOps pipelines
      • Automation
      • Data governance
      • Compliance obligations
      • Hybrid infrastructure
      • AI systems

Yet many projects still assume documentation can “emerge naturally.”

What usually emerges is:

      • Scattered Confluence pages
      • Outdated SharePoint libraries
      • Tribal knowledge
      • Slack conversations acting as operational memory
      • Contradictory procedures
      • Uncontrolled revisions

Eventually, operational support inherits the chaos.

The “SMEs Will Write It” Fantasy

Subject Matter Experts are essential.

But SMEs are not usually:

      • Information architects
      • Editors
      • Audience analysts
      • Metadata specialists
      • Structured writing professionals
      • Governance specialists

Most SMEs focus on:

      • Delivering systems
      • Solving technical problems
      • Meeting deadlines

Documentation becomes secondary.

Postponed until the last phase of a project — when schedules collapse, and budgets tighten.

That is where technical authors historically added value:

      • Extracting knowledge
      • Structuring information
      • Standardising terminology
      • Identifying gaps
      • Challenging ambiguity
      • Creating usable operational guidance

Without that role, knowledge quality declines rapidly.

Documentation became Invisible Work.

In many IT organisations, documentation is now treated as:

      • Administrative overhead
      • Non-billable effort
      • A project afterthought
      • Something AI can “tidy up later”

Yet the same organisations later struggle with:

      • Failed handovers
      • Poor onboarding
      • Repeated incidents
      • Knowledge loss
      • Service desk dependency
      • Operational inconsistency
      • Audit failures

Because undocumented systems create operational drag.

The irony is simple:
The more complex IT becomes, the more valuable structured information becomes.

AI is speeding up the illusion

AI has amplified the belief that technical writing is “generating text.”

But experienced technical authors are not typists.

They managed:

      • Information quality
      • Knowledge structures
      • Content governance
      • Audience interpretation
      • Process consistency
      • Lifecycle control
      • Information retrieval
      • Operational usability

While AI can produce drafts quickly, it does not inherently:

      • Understand organisational risk
      • Detect conflicting operational procedures
      • Validate technical accuracy
      • Govern document lifecycles
      • Manage controlled information environments

Many times, AI speeds up the production of unmanaged content.

The Hidden Shift

Interestingly, technical authors have not entirely disappeared. We have changed titles:

Across IT projects, former technical authors now operate as:

      • Information managers
      • Knowledge managers
      • Content strategists
      • Service transition analysts
      • Governance specialists
      • Digital adoption consultants
      • Documentation engineers
      • Information architects

The writing component became only one part of a broader information role.

The Long-Term Risk

IT projects can survive in the short term without dedicated technical authors.

Until:

      • Key staff leave
      • Systems fail
      • Audits occur
      • Services scale
      • Migrations happen
      • Security incidents arise
      • Regulatory scrutiny increases

Then organisations rediscover the same truth:

      • Operational resilience depends on reliable information.
      • And reliable information rarely happens accidentally.
      • The disappearance of technical authors from IT projects may save money on a spreadsheet.
      • But over time, many organisations discover that they have not removed the need for technical authors.
      • They merely removed the people responsible for keeping organisational knowledge usable.

When the ROT sets, what next?

Most organisations don’t notice document ROT setting in. In fact, document ROT can undermine confidence in your information over time.

It creeps in under the radar with:

      • Duplicate documents. This is often a visible symptom of document ROT in repositories.
      • Outdated procedures. Outdated guidelines also contribute to increased document ROT.
      • Content no one trusts, but no one deletes.

Then one day, someone asks a simple question: “Which version is correct?” Yep, you’ve heard it before, and no one can answer the question. This is a classic sign of your organisation struggling with document ROT.

And no one knows.

That’s when you realise you don’t have a documentation problem but a control problem. That’s the moment you understand you’re facing document ROT.

I’ve seen this in SharePoint sites, shared drives, knowledge bases, and even in controlled environments that claim alignment to ISO 27001 or ISO 9001. Ultimately, if left unmanaged, document ROT will impact all these settings.

You see, dear readers, the problem is neither the technology nor the process; it’s ownership.

Hang on, I forgot to say what ROT is. Here goes ROT (Redundant, Outdated, Trivial content). Don’t forget about the risks of document ROT now.


ROT commencement: Your steps:

Stop team members from adding more documents to the DMS until you know their value. Otherwise, document ROT can escalate quickly.

Adding more content to a broken system accelerates its decay, further magnifying the document ROT issue.

Instead:

1. Surface the estate
Find everything and don’t allow people to restrict your view. It is for their benefit and helps identify ROT in documents early.

2. Classify forcefully.
Redundant. Outdated. Trivial.
No sentiment. No to the suggestion that we might need it. If it hasn’t been opened or referenced for months, get rid of it—classic symptoms of document ROT in play.

3. Rationalise before migration
If you lift and shift, you formalise the mess and transfer the document ROT problem as well.

4. Rebuild structure
Clear document types. Controlled locations. Metadata that means something. By doing so, you reduce the risks associated with document ROT.

5. Assign real ownership
Named individuals. Review cycles. Accountability. These combat documents ROT more effectively.

6. Put governance in place
Not a heavy process. Just enough control to stop the slide into document ROT.


Here’s the part most organisations don’t grasp: dealing with document ROT is an ongoing responsibility.

If no one owns documentation, it will decay again.
Every time, you’ll see document ROT coming back.

Usually, within 12–18 months, unmanaged document ROT returns.


The shift you must make

If teams are writing, ROT will outpace them. Addressing document ROT needs ongoing attention.

This is where the role changes. Document ROT management becomes a critical function.

You become:

      • Information architect—seeking document ROT to resolve.
      • Governance designer
      • Content auditor
      • Risk mitigator

Because ROT isn’t about writing. Therefore, managing document ROT is vital for any business that relies on high-quality information.

It’s what happens when documentation becomes an afterthought instead of an asset—an all too typical result of ignoring document ROT.


Question:
When ROT set in on your last project, did you fix the content … or fix the system affected by document ROT?

Hashtags:
#TechnicalWriting #Documentation #ContentStrategy #KnowledgeManagement #InformationManagement #SharePoint #DocumentControl #ISO27001 #ISO9001 #DigitalTransformation #ContentGovernance #TechCom

 

Why I Didn’t Pursue ISO 27001 or ITIL Certification as a Technical Author (And Why That Matters)

Do technical authors need ISO 27001 or ITIL certification? This article challenges the assumption, explaining why real-world experience often delivers more value than foundation-level qualifications—and when certification actually makes a difference.

Introduction

Over the years, interviewers have asked me the same question. One topic that often comes up is the debate between technical author vs certification, which frequently leads to interesting discussions about their respective merits.

“You’ve worked with ISO 27001, ITIL, GDPR, PCI… why didn’t you complete the certifications?”

On the surface, it looks like a gap. Technical Authors v Compliance.

It reflects a deliberate decision about where the role of a technical author begins—and where it should not drift.


The Assumption Behind Certification

Many organisations assume that working alongside standards such as:

      • ISO/IEC 27001
      • ITIL
      • GDPR
      • PCI DSS

naturally leads to certification.

Foundation becomes Practitioner.
Practitioner becomes Expert.

This progression makes sense for:

      • Information Security Managers
      • Service Delivery Leads
      • Compliance Officers

But it does not automatically apply to technical authors.


The Role of the Technical Author in Compliance

A technical author does not own the framework.

The role is to:

      • Translate requirements into structured documentation
      • Align content with controls and governance models
      • Ensure documentation supports audit evidence
      • Create a single, coherent source of truth

In simple terms:

The framework defines what must exist.
The technical author ensures it is documented, usable, and defensible.


What Experience Delivers That Certification Does Not

After working across multiple compliance-driven projects, patterns become clear:

      • Policies that do not reflect actual operations
      • Processes that lack sequence or ownership
      • Controls that exist conceptually but not in documentation
      • Repositories with no lifecycle, governance, or consistency

These are not theoretical problems.

They are the reasons organisations fail audits.

Understanding how to fix them comes from:

      • exposure to failed documentation environments
      • Rebuilding

        The compliant Technical Author
        The complaint technical author

        structures under pressure

      • aligning documentation to real-world operations

This is applied capability, not classroom knowledge.


The Certification Trade-Off

Certifications do provide value.

They:

      • Improve credibility with recruiters and procurement
      • Help pass automated CV filtering
      • Provide standardised terminology

However, they also introduce a shift in perception.

If I had progressed to practitioner level, there is a strong likelihood:

I would no longer be seen as a technical author.

Instead, I would be positioned as:

      • a compliance specialist
      • a governance lead
      • a service manager

That is a different role, with different expectations.


The Reality in Delivery Environments

There is an uncomfortable but consistent observation across projects:

Some certified professionals struggle to produce:

      • clear policies
      • usable processes
      • audit-ready documentation

Experienced technical authors often:

      • stabilise failing documentation environments
      • restructure repositories
      • enable organisations to pass audits

without holding formal certifications.


Knowing Enough to Deliver

There is a phrase that often needs clarification:

“I know enough.”

This does not imply limited understanding.

It means:

      • understanding the intent behind standards
      • knowing how to translate that intent into documentation
      • ensuring that documentation stands up to audit scrutiny

It also means recognising boundaries.

A technical author’s strength lies in application, not ownership.


When Certification Does Make Sense

There are situations where certification adds clear value:

      • Building a consultancy offering
      • Productising compliance services
      • Working in procurement-heavy environments
      • Increasing commercial positioning for senior roles

In these cases, certification supports:

      • trust
      • marketability
      • pricing leverage

Cost vs Return

Foundation certifications typically cost:

      • £500 to £1,500 per course

Covering multiple frameworks can exceed:

      • £3,000 to £4,500

For knowledge that often overlaps with existing experience.

The return is therefore not always proportional—particularly for experienced practitioners.


The Positioning That Matters

The distinction is important:

A certified professional understands the framework.
A technical author ensures the organisation can prove it is working.

These are complementary roles—but not the same role.


Conclusion

When asked why I did not pursue certifications, the answer remains consistent:

My value does not come from owning the framework.
It comes from making it work—through structured, controlled, audit-ready documentation.

In environments where documentation determines the success or failure of an audit, that distinction matters.