How to Manage “Signal” and “Noise” in Technical Documents

How to define “signal” and “noise” is at the heart of this frustrating and persistent problem

Here is an uncomfortable fact of technical document management: as much as we’d like to base our decisions on hard evidence and numbers, we still make a number of judgment-calls that rest on nothing more than a seat-of-the-pants “this feels okay,” this sounds just right to me” or “I’m not okay with this,” “this doesn’t quite feel right to me.”

For example, imagine you asked your writers to submit those dreaded “time estimates” for the projects they are working on. How can a writer justify the hours he or she says will take to finish that user guide? “Past experience,” is one of the answers frequently given. Other typical answers: “I know I can do it by this date,” “I feel this is plenty time to get it done” etc.

Jesse Collins

Yet such estimates always set up a writing team for a binary outcome: either one misses the mark and “fails” or hits the mark and “succeeds.” But that success is a passive one. It more feels like “surviving” a multiple choice quiz where questions have only two answers: Fail, Not Fail.

(Here I’m not even going to address the related issue of padding the time estimates to make sure that “success” is but a certainty, which of course leads to wasting precious resources.)

When we “survive” such estimates or marketing specs, what do we do? Simple: nothing! Success in such cases is a license to not touch the process and ask no questions.

If on the other hand we “fail,” usually there are again no questions that lead to analysis but a simple promise and determination “to do better next time.” It’s all subjective.

In both cases, the outcome is a bit of a letdown because it tells us nothing about the objective process underlying the documentation project. Whether we succeed or fail, we never exactly know why.

We run hard after the “Voice of the Customer” (the document specs handed down to us) with little idea about the “Voice of the Process,” that is, the characteristics/components of the process with which documents are actually produced.

Waldemar Brandt

Signal or Noise?

I think at the heart of the issue is our failure to distinguish a “signal” from a statistical “noise” in our documentation efforts. This leads to false identifications when we think a signal is noise, and vice-versa. But first, let’s state our assumptions and define our terms:

Assumption 1: Not everything is explainable in life. Some things are inexplicable and remain so. We are not studying why that is the case. We are not trying to overcome that fact and find a solution to it by converting “things unknowable” into “things known.” We are just going to assume that this is so, as much a fact as the sun rising from the East every day.

Assumption 2: Every process will create some results that cannot be explained by the process itself. For example, every school will have dropouts, no matter how good the school is. Out of every thousand cars manufactured, some will break down within the first month, no matter how well the cars are manufactured. Some poems will never get published or read, no matter how beautiful they are.

Definition 1: We will call such inexplicable outcomes (as described in Assumption 2) “noise.”

Definition 2: Everything produced by a process and which is not a “noise,” we will call a “signal.”

If we could determine what range of variations are “acceptable” since they are the “noise” of the process, then I believe we could decide better “how we’re doing,” regardless of the “customer or marketing specs” under which we are laboring.

If on the other hand, we detect a signal, that is, a variation that cannot be explained by the normal “random chatter/noise” of the system, then we would inquire what happened and when to generate such an out-of-range result.

Without such an understanding of when and why systems (including technical writing departments) sometimes step beyond the usual “noise” of daily life, and issue a “signal,” how can we expect to fix the process and improve the outcome?

This is too involved a topic to conclude here in a single blog post. I’ll just say that I’m in the process of writing an ebook and developing a workshop on this same issue.

I believe there can be a quantitative solution to the problem of identifying “noise” vs. “signal”. The solution depends on the skill with which we use Shewhart Control Charts as a document management tool. That’s the key.

More on this subject later on. I welcome all your comments and suggestions.

An excellent book to read on the subject is Donald Wheeler‘s classic Understanding Variation: The Key to Managing Chaos. Highly recommended. It has changed the way I’m thinking about pretty much everything these days. It’s a true eye-opener.

For free technical writing tips and tutorials visit




Top Medium Writer in Writing category. Fortune 100 writer. Top Quora author. Online course creator. Father. Husband. Brother. Mentor.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Every AWS customer finds themselves in the EC2 console, starting an instance, trying to choose an…

Native vs PWA apps — A complete Guide — TekRevol

Modify SVG with CSS Variables

Case Study: Diversey Solutions Delivery Systems Reporting Tool

Understanding Nested Forms and Routes

Oracle APEX Tutorial by Javainhand

Tkinter Entry Widget in Python

Design 101 : Why do we need Abstract Factory Pattern now?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ugur Akinci

Ugur Akinci

Top Medium Writer in Writing category. Fortune 100 writer. Top Quora author. Online course creator. Father. Husband. Brother. Mentor.

More from Medium

5 benefits of hiring freelancers for startups and scale-ups

hiring freelancers for startups

How To Build Trust With Your Target Audience And Clients

David Greenbaum on the Kruze Consulting podcast

A 3 Minute Guide To Understand Data Centres And Why Your Business Needs One