Secrets of Effective Business Writing

By Julian Maynard-Smith

International News, January 2022

This article is based on a presentation given to the Society of Actuaries on Oct. 12, 2021.

Think of all the documentation you as an actuary are expected to write: emails, status reports, business plans, white papers, case studies, user guides, pricing and methodology manuals, policies, procedures, regulatory submissions, and more. But while you’ve been formally taught many skills to qualify as an actuary, how to write well is probably not one of them.

Fortunately, writing well is not some esoteric skill only available to those with a gift for it. Sure, a little talent helps—but knowing and applying some tricks from professional writers will greatly enhance your ability to communicate even the most complex ideas clearly and simply.

Start Early

The first secret of writing well is to start early. In a pressured business environment it’s tempting to leave writing to the last minute—but write in a hurry and you risk producing an unstructured “brain dump” that either fails to achieve its purpose or that takes far longer to fix.

In fact, calling it “writing” is misleading because it creates the misperception that what you’re doing is something like this:

... whereas the reality behind successful writing is more like this:

If you think that you can’t afford to invest significant time on all these writing stages, consider the costs of poor documentation.

First, you risk making readers feel bored, confused, frustrated, and (worst of all from your perspective) resistant to your message. Second, resistant or confused readers can lead to project mistakes, rejected proposals, angry customers, missed business opportunities, fines and investigations, and technical debt (an idea from software development that fixing a rushed and bad solution costs more in time and money than fixing problems early).

So invest the time—it’s always worth it.

Planning and Research

At this stage, start by asking the following questions:

• “What outcomes do we want?” For example, do you want to reduce operational failings? Get the correct software built? Get your internal model approved?
• “Who must do what?” Using the examples from “Outcomes” above, your answers might be: our staff must understand their responsibilities; IT must understand actuarial processes; the regulator must trust our model.

Note that neither of these questions starts with “We need to write a policy / functional spec / regulatory submission.” The type of document you write is only ever the means, not the end. By focusing instead on outcomes (question 1) and audience (question 2) you’re far more likely to produce a successful document. In other words, get into the habit of thinking like this:

• “We need to change staff behaviour” (not “We need to write a op-risk policy”)
• “We need to clarify actuarial needs to IT” (not “We need to write a pricing model spec”)
• “We need to convince the regulator” (not “We need to write an IMAP submission”)

Once you’re clear on outcomes + audience, you need to establish what your audience needs and wants—what will motivate them to change their behaviour in the way you want. Good writing gets results because it scores highly on empathy, so ask questions such as:

• “Who exactly are our readers?” For example, knowledge level, job role, age, gender, nationality, ethnicity.
• “Do their needs vary?” For example, does your proposal target both directors (who decide strategy) and actuaries (who implement it)? Does your pricing methodology manual need to explain processes to both actuaries and underwriters? Will your user guide be used by both beginners and advanced users?
• “What’s their likely emotional state?” For example, instructions (anxious), refunds (frustrated), proposals (hesitant), policies (bored), and sales messages (sceptical).
• “Are they specialists or not?” For example, if you’re writing actuary to actuary you might explain why you chose a Student-t rather than Gaussian copula; but if you’re writing for the board they’re likely neither to understand nor care about copula choices—they want an explanation such as, “We chose this method because it better meets regulations, but it does increase our capital requirement.”
• “What’s their language?” For example, if you’re writing in English are some of your readers likely to have English as a second (or even third) language? If so, avoid slang and idioms. Are they non-actuaries? If so, don’t use terms only an actuary would understand. Even U.S. versus U.K. English can make a difference, for example in date formats and spelling.
• “Where and when will they read it?” Here, you need to consider factors such as different time zones—especially important when you’re arranging meetings!

Finally, talk to your audience whenever possible: it’s vital for avoiding wrong assumptions, the curse of knowledge (assuming readers know as much as you) and conflicting messages (different people having different agendas). Another reason for discussion is to build trust: for example, depending on what you’re writing, people may feel they’re being policed or even that their jobs are under threat so you need to reassure them.

You also need to research what materials are available. It sounds stupid but I’ve seen it happen time and time again: people waste time rewriting information that already exists. There’s no point rewriting information already available in the public domain, so check sources such as the Society of Actuaries website, vendor websites, national newspapers and Wikipedia. And for any information that’s specific to your organisation, check your intranet—it’s astonishing how often people reinvent problems that their colleagues have already solved and documented.

But always check with the writers and owners of internal documentation whether it’s up to date and relevant. Earlier in my career I learnt this lesson the hard way by wasting days reworking materials my colleagues later said they’d given me only as “examples.”

Finally, check whether you can generate the information. For example, there’s no point creating a handwritten spreadsheet as your document inventory if you have SharePoint and can auto-generate such a spreadsheet simply by clicking “Export to Excel” to get a point-in-time report on document metadata (names, URLs, owners, review dates, and so on).

Structuring

Before you start writing your draft, find the “story” your document is telling and sketch out the headings that tell that story. Working top-down is far, far easier than diving straight into the writing and hoping that a structure will suggest itself (it won’t, and you’ll waste huge amounts of time sorting out an unstructured mess).

What do I mean by “story”? Well, rather than a fact dump you’re looking to build a structure with a beginning, middle and end; a structure with a strong sense of causality (this because of that). For example, a good business proposal starts with the problem, follows with possible solutions, weighs the benefits and drawbacks of each solution, and finishes with a recommendation. And always start with context (the why) before diving into the details (how): generic before specific, familiar before unfamiliar, simple to complex. And so on.

Your headings give the synopsis of your story, so make them informative. For example, not “Overview” (of what?) but something such as “Why we’re changing our validation process.” Also, make your headings speak directly to your readers’ needs and interests: not “Future trends” (who cares?) but “Automation—is your job at risk?” Another good trick is to use gerunds (–ing words) for headings describing processes or procedures, because gerunds indicate actions (Creating, Defining, Validating, and so on).

Before you move to the next step (drafting), check whether your headings alone clearly show what every section is about and the overarching narrative of your document. If they don’t, keep refining them and their order/hierarchy until they do. It will make life easier not only for your readers but also for you, as we’ll see in the next stage.

Drafting

At the drafting stage, you’ll feel the benefit of having perfected your story and headings. Why? Because headings give you a roadmap: for each section, you know your start point (the heading above) and your destination (the heading below).

The drafting stage isn’t about creating perfect sentences (that’s the editing stage): it’s about getting your ideas down as fluently and naturally as you can. That means writing at speed, to keep up the momentum from idea to idea and to silence your inner critic until it’s time to edit. Also, it’s far easier to edit your document once you’ve completed your first draft and hence have the big picture.

To achieve a natural fluency, imagine a target reader is right in front of you, asking you questions. That way, you’ll avoid the risk of writing nonsense such as “In order to facilitate the ongoing appropriateness of the risk management governance process...” (you’d never say that to someone) and instead write something much more natural, such as “To manage our risks, we...’

Other tricks include always providing context before diving into the details; using paragraphs effectively to group sentences talking about the same thing; and helping readers navigate the direction of your narrative with “transitions”: words such as because (to indicate causes), but (contrasts), for instance (examples), hence (results), and so on.

And returning to the idea of “story,” you want readers to keep turning the pages so steal a trick from novelists and finish sections and chapters on cliffhangers: for example, “Those are the challenges facing actuaries, but how can we solve them? Let’s find out.”

Finally, if you want readers to do something, make sure you tell them what and how (what copywriters refer to as a “call to action”). For example, not “We look forward to talking to you” but “To book your appointment, call...”

Editing

When you’ve just finished drafting it’s easy to become “word-blind” to your own errors. So give yourself some time away from the page or screen before you start editing, so you can review your draft with fresh eyes. But once you’re ready to edit, what should you look for?

First, irrelevant details. Be ruthless in stripping them out, because they slow readers, reduce readers’ ability to act (by overwhelming them with too many choices) and can even lead readers to draw wrong inferences.

Second, sentences missing the doer of an action: not “Validation results must be signed off” (by whom?) but “Senior actuaries must sign off validation results.” More broadly, root out missing assumptions by stress-testing your sentences with “5W1H” (who, what, why, where, when, how): for example, not “A robust validation process must be in place” but “Pricing actuaries must validate their model parameters and data.”

Third, ambiguities: for example, not “Code that is not tested often contains bugs” (what is “often” referring to?) but, depending on which meaning you intended, either “Code that is rarely tested contains bugs” or “Untested code often contains bugs.” Similarly, replace woolly phrases with precise words (for example, not “actuarial function” but “actuaries”; not “adverse weather conditions” but “snow”) and make sure you use words consistently (for example, not “allocation” and “attribution” if you’re talking about the same thing).

Fourth, as well as editing for the best word choice, look to strengthen the structure of your sentences: that usually means subject-verb-object (SVO). For example, not “The risk-assessment process (O) must be documented (V) by actuaries (S)” but “Actuaries (S) must document (V) how they assess risks (O).”

Fifth, check your grammar and spelling—not forgetting punctuation, as wrong punctuation can radically change your meaning. Just compare, “Let’s eat, Grandma” (grandma is being invited to eat) with “Let’s eat Grandma” (a call to cannibalism).

Reviewing and Testing

Now you’re ready to share your draft with reviewers. Here are some tips: tell reviewers what to check and what to ignore (it saves “noise” caused by reviewers focusing on what’s unimportant or subjective); accept comments gracefully (a criticism of your document is not a criticism of you); heed false corrections (what you wrote may be right but still awkwardly or confusingly expressed); recognize subjectivity (you can’t please everyone all the time); and get reviewers together at the same time (it saves misunderstandings, conflicts and wasted time).

Start with reviews from people closest to the material then move outwards to people increasingly remote from it. For example, start with yourself (to check for avoidable errors), then give your document to a peer (to check for accuracy and completeness), then a target reader who’s a non-specialist (to test for comprehension).

Note the word test. Reviews should be more than box ticking—they’re an opportunity for usability testing, for ensuring that your document achieves those outcomes we explored earlier. For example, can someone actually complete an intended task with only your documentation to guide them? A good person for usability testing is a technical writer, as they can quality-assure your document at the same time as they’re testing it.

After usability testing, your document is ready (if necessary) for approval through your normal sign-off channels. Which should be a mere formality, if testing has proved that your document gets the results it’s meant to!

In Summary: Five Key Messages

What have we learnt? A lot, but here are five key messages to summarize the main points:

• Invest time in understanding your outcomes and audience.
• Structure well (think “story”).
• Write naturally and with empathy.
• Edit, edit, edit (then edit again).
• Review—and test.

Statements of fact and opinions expressed herein are those of the individual authors and are not necessarily those of the Society of Actuaries, the editors, or the respective authors’ employers.

---

Julian Maynard-Smith is a technical author who's worked with actuaries at many of the UK's leading insurers, especially on Solvency II programmes. He's also trained many actuaries in business writing. He can be reached at jfmaynardsmith@gmail.com.