February 23, 2020

Use BLUF to improve your written communication

Bottom Line Up Front (BLUF) is a technique for improving the speed at which written communication can be conveyed. It places the conclusions and recommendations at the beginning of a document, instead of at the end. By using BLUF, you can convey the most salient part of your document in the least amount of time.

The importance of communication

I believe that in any organization beyond a certain size, communication becomes one of the most important factors for that organization’s success. For example, it’s unlikely that as a company, you’ll solve business or technical problems without effective communication regardless of how much raw talent or business acumen you have.

An important aspect of communicating effectively is communicating quickly. For written communication, this is especially important, as documents which take too long to read are less likely to be read and hence, understood. Thus, it is important to convey the most important part of your document as soon as is possible.

I am going to focus on written communication here, because you may not be able to meet face-to-face with all the people in an organization that you wish to convey your ideas to. Thus, effective written communication is essential to getting your point across.

An example of BLUF

BLUF is most applicable when you have to present the results of something, e.g. a recommendation, decision or outcome. By starting with a BLUF, you place the most important information first. Someone who doesn’t want to read the entire document can get a good overview by reading the BLUF opening; someone who wants to dive deeper can get a good background that will prepare them to understand the rest of the details in the document.

Here is an example:

Our existing SOAP API was an impediment to onboarding new customers because few of them have familarity with this older protocol. To provide a path forward for these clients, we have decided* to adopt GraphQL for the next version of our API. This will greatly reduce their onboarding friction, and has the potential to benefit existing customers as well.

The alternatives we considered are outlined below, along with our reasoning for choosing GraphQL over them.

REST: While REST is ubiquitous, it had several drawbacks for our use cases that GraphQL did not. Namely, …
…

XML-RPC: This was not seriously considered, because it was essentially the precursor to SOAP, and hence our clients unfamiliar with SOAP would be unfamiliar with this as well.
…

* May be replaced with “we recommend” if you are not in a decision-maker role

The opening paragraph above provides the BLUF: It begins with a concise explanation of the situation and problem, and then jumps right into what was decided or recommended. The reader is then directed towards further details to support the decision. While this is admittedly a bit of a contrived example, I’ve found that many documents can be rephrased in this manner.

Contrast the BLUF example above, with this decidedly non-BLUF document:

To replace our SOAP API, which has been the basis for our API since its original inception, we investigated several alternatives:

REST: REST stands for REpresentational State Transfer and is a defacto standard when it comes to web APIs. For this reason, it was our initial first choice. However, when we started looking at GraphQL, it became clear that …
…

GraphQL: GraphQL is a relatively new language that has several advantages over REST. These advantages are: …
…

XML-RPC: This standard is even older than SOAP, and has few benefits…
…

Based on the reasoning provided above, it is clear that GraphQL provides the most flexibility and furthermore, is well understood by our API partners, clients, and customers. By contrast, SOAP is an outdated protocol understood by few nowadays. By adopting GraphQL in the next version of our API, we will be able to reduce onboarding time, enabling new customers to begin using our service without much technical support from our team. Therefore, we decided to use GraphQL for V2 of the API.

While this document eventually conveys all the same information as the previous, the order in which the information is presented does not make it easy to digest. The first line indicates that we are “replac[ing] our SOAP API”, but why is this being done? No context is provided. Also, it’s unclear whether this document is going to just list some suggestions, or give a recommendation. Furthermore, you are forced to read through a list of all the alternatives in order to understand which one was selected.

This document flows more like a stream-of-consciousness that was written as the process unfolded. While there is nothing wrong with keeping notes (you should!), you should also take the time to edit those notes into a cohesive document.

Use BLUF to provide context

The golden rule of technical writing is to put yourself in the reader’s shoes: If you did not have context on the situation, but needed to be informed of an important development, what would be the most clear way to have that explained to you?

This is actually harder than it seems. It is easy to forget that the context we have may not be the context that the reader has. We have become too involved in the particular details of the task that we take for granted the background knowledge that others may not have. (“Of course the SOAP API needs to be replaced! It’s SOAP and no one uses that!") You need to take a step back, and try to understand your audience before you start writing - because you are writing for them, not for yourself.

Providing sufficient BLUF context without drowning the reader in details is tricky, which is why I recommend you ask someone to review your BLUF opening. It shouldn’t take them too long. If it does, you probably have too much in your BLUF opening! You need only to provide enough context so that the explanation of your decision (the BLUF) makes sense to the reader.

Use BLUF whenever possible

BLUF excels when you need to convey recommendations, conclusions, or the outcomes a decision. As such, it’s applicable for a wide range of technical communication:

Design Documents: What problem is the given design trying to address? Why was it selected? What assumptions were made when this decision was made?
These are some aspects that can be included in a BLUF here.
Post-Mortems: When a service disruption happens, you often want to review how the situation was handled after it was resolved.
A post-mortem should start off with a summary that can act as the BLUF: It should address, at a minimum: What happened? Why did it happen? What could we have done better? What actions will we take to reduce the chance of this happening again? The body of the document can then dive into each of these in detail.
Furthermore, for post-mortems to be effective in the long-run, they should be blameless.
Emails requesting an action by the reader: What needs to be done? Why does it need to be done? When does it have to be done by?
A BLUF in this sort of email can begin with a short explanation of each of the above, and then provide further details below.

Using a BLUF style is also important when you collectively need to make a decision. For example, under the RAPID Framework, the Decider (the “D” in RAPID) will need to get accurate information from the other participants (in particular, the Recommenders) to inform their ultimate choice. Being able to communicate quickly and effectively is thus paramount in these situations.

Further technical writing tips

Writing, like almost any skill, takes practice to improve. By continually writing and getting feedback from others, you will be able to improve your writing, and hence your ability to communicate technically. Using a BLUF style can be one effective tool in your writing kit, but it is far from the only one.

I would also consider studying the topic of writing itself. For example, if you’ve taken a writing course, you may have heard about the four main types or styles of writing: Expository, Descriptive, Persuasive, and Narrative. In technical writing, you are usually concerned with the expository (explaining concepts and facts) and persuasive (arguing for your point-of-view) types.

While you generally won’t be writing in a narrative style, you still have to ensure that your document flows properly. Now, whether a document flows well is a bit of a subjective matter, but here are some points to consider:

Transitions: Does the presentation of subject matter transition logically from one concept to another? For example, if you are describing a proposed change in a system, the reason for why the change is needed should have already been communicated. The reader shouldn’t be wondering why.
Section ordering: Does the reader have to flip back and forth between multiple sections in order to understand a concept you’re explaining? If so, can that be eliminated or reduced by changing the ordering of sections?
Be consistent, and avoid ambiguity: If you refer to a concept by a certain name (e.g. “the FooBar component”), use the exact same name in all other references to avoid creating confusion. Furthermore, any terms you use in your document that don’t have a common meaning (or that differ from the common meaning) should be clearly defined.

Your aim should be to ensure that a reading of your document produces no surprises; the reader should not have to wait until the very end to understand where you are going with your text. This is in contrast to a story, where you usually want to build suspense, and slowly reveal details until drawing back the curtains on the exciting conclusion; in technical writing, you should aim for the opposite!

(Note: Sometimes telling a personal anecdote is great way to create a hook into your topic - but this should be used sparingly and with great care, and is better suited as the intro to a technical presentation, rather than in purely written communication.)

Conclusion

I’ve tried to keep this article focused on just the BLUF style, but went a bit off track on providing other writing tips that I’ve felt were useful. Part of the reason for this is that writing is something that is interesting to me, and is also a skill that I’m working on to improve.

I believe it’s important to build a culture that values written communication, and a big part of that is making sure that everyone can write effectively.

A full overview of technical writing is well beyond the scope of this article, and so if you are interested in more, here are some references I’ve used:

I hope that you enjoyed this article, and thanks for taking the time to read!