Following last year's small-business primer, I have been thinking about the discipline of writing for non-technical audiences. It is meaningfully different from the technical writing that dominates this notebook.
Worth writing about explicitly.
What is different
Three things.
The shared vocabulary is smaller. When writing for technical readers, I can assume familiarity with most terms — TCP, HTTP, DNS, SSH. When writing for non-technical readers, every technical term has to be either defined or avoided. The defining is awkward; the avoiding is challenging.
The motivation is different. Technical readers want to understand the mechanism of a problem. Non-technical readers want to understand the consequence and the response. The structure of the post differs — non-technical posts work better as "here is the bad thing that can happen and what you should do".
The trust requirement is higher. Technical readers can verify what I write by checking it against their own knowledge. Non-technical readers have to trust me. This places a higher burden on me to write carefully — overconfidence costs more in this register.
What I have learned from writing the primer
Three specific things from the experience.
Concrete examples beat abstract principles. The non-technical reader engages with "do not click links in emails" much more than with "the trust model of email is structurally inadequate for sensitive communication". Both are true; the first is operationally useful.
The list of things to do should be short. Five items in part one of the primer, five in part two. Ten items total. This is at the upper edge of what a non-technical reader will actually engage with. Longer lists get skimmed; shorter lists are not comprehensive enough.
The framing of motivation matters. "Your business depends on technology that has weaknesses" works better than "there are bad actors on the internet". The first is an observable fact; the second sounds either alarmist or unrelated to the reader's concerns.
What I have not yet done well
A few honest gaps.
Specific tool recommendations. I have been deliberately vague about specific tools (specific antivirus products, specific routers). The reader, however, often needs specific guidance. Avoiding the specifics serves my own discomfort with making product recommendations more than it serves the reader.
Cost framing. I have been light on the cost-benefit framing of specific defences. A non-technical reader making decisions about security investment needs to understand which defences are cheap and which are expensive, in actual money or actual time.
Accountability framing. Many non-technical readers are reading the primer because they are responsible for the security of an organisation they do not personally manage. The discussion of how to delegate, how to verify, how to oversee security work is sparse in my writing.
What I want to do next
Three commitments for the rest of 2002:
Specific recommendations. Where appropriate, I will name specific tools and explain the trade-offs. The cost is that I will sometimes be wrong about the specific tool; the benefit is that the reader can act on the advice.
Cost-explicit framing. Where I recommend a defence, I will indicate roughly what it costs (in money, time, ongoing maintenance burden). The reader can then make informed decisions.
Delegation guidance. Specific writing for the non-technical reader who is managing security people rather than doing the work themselves.
A small reflection on the discipline
Writing for non-technical readers is genuinely harder than writing for technical readers. The compression of complex ideas into accessible form is a skill that requires practice. The audience is, on the whole, more forgiving — but the trust they extend is also more fragile.
For my own work: I will keep doing both. The technical posts are the bulk of the notebook; the non-technical writing is a complementary discipline. Neither is sufficient on its own; both together cover more of the audience that benefits from this work.
More as the year develops.