The Pyramid Principle by Barbara Minto is a very short book on writing and thinking in a structured and logical manner. This review focuses on the first half of the book, which deals with how to structure writing.
The book's advice is meant for business documents. It is not general-purpose writing advice but should apply to any non-fiction writing where clarity is important.
This is a summary of the advice in the book The Pyramid Principle by Barbara Minto.
While I attempt to apply the principles here, I am still learning, so this document may not properly reflect the material in that book.
Document Structure (Chapter 1)
Documents should be structured in a summary-to-main points pyramid using the following 3 rules.
- Any point higher in the pyramid should be a summary of the points grouped below.
- Siblings in a group should all be of the same kind
- Apples and pears being fruit is a good grouping, and chairs and table being furniture is a good grouping, but apples and chairs are too disparate to reliably link together in a single concept usually.
- Topics or concepts in each group should be logically ordered. There are only four types of ordering:
- Deductively - major premise, minor premise, conclusion (Men are mortal. Socrates is a man. Socrates is mortal.)
- Chronologically - first, second, third
- Structurally - this is possibly the most arbitrary of the groupings and is based on context
- Comparatively - most important to least important
These are the only four groupings that the mind can conceive: reasoning deductively, establishing cause-and-effect, breaking a whole into its parts, and categorizing.
Determining Document Structure (Chapter 2)
It is nearly impossible to know the structure of the document beforehand. It is therefore useful to explore the relationships of your points and the introductory narrative to discover the structure of your ideas.
Documents will have points that spread in two directions.
- Vertical relations that tie together points and sub-points
- Horizontal relations that tie together similar points
Vertical Relationships
Vertical relations between subjects are modeled in question/answer pairs. The subject of a level should raise a question in the reader's mind, and subsequent paragraphs and sections should explore the answers to that question, posing more precise questions until the answers in the bottom of the pyramid.
Here is an example explaining why humans should explore space.
This diagram was taken from https://www.consultingmethodology.com/wp-content/uploads/Pyramid-principle_v2.1.pdf, which is a summary of the book reviewed here.
The tree alternates between propositions and questions, with the final layers providing the answers to what are hopefully final questions that the reader will have.
Horizontal Relationships
Most subjects require multiple points to fully answer a question. These points must be related. As shown in the diagram above, these are horizontally related.
The subjects of the points are related in one of two ways, deductively or inductively. Chapter 1 lists four ways; the first way is the deductive manner (using Socrates is mortal), and the other 3 are inductive. The inductive relations can usually be described by a plural noun e.g. reasons, steps, problems.
Example of Vertical and Horizontal
An example of a vertical relationship above is the "Earth will eventually end." The two supporting reasons are "The sun will end." and "Disaster will happen." These two reasons are vertical to the main reason "Earth will eventually end." and are horizontal to each other. In turn, each is vertical to further sub-points, which are in turn horizontal to each other (despite being arranged vertically in the diagram.)
Introductory Narrative
The introduction is especially important in this structure. It establishes the reason for reading the document and thus needs more than just posing a question at the top of the document.
Instead, the familiar story structure is used to give the reason enough information to decide if the document is worth reading.
The story structure is:
- Situation - the history or events that lead to the document being necessary.
- Complication - the change in the situation that occurred
- Question - the question(s) raised by the complication
- Answer - the summary of the answer that the document provides to the question.
One of the things that I have done, and I see in other documents, is to "hide" the answer until later in the document. I'm not sure why this is; perhaps to provide some sort of suspense or reason for reading the document. However, providing answers in summary form up front prevents wasting time in understanding the purpose of the document.
This link does a good job of elaborating the SQCA format for business writing.
In formulating the question in response to the complication, the question often is simply "How do we solve this complication?" or "Why did this complication arise?" The question often is a restated version of the complication.
Creating the Structure (Chapter 3)
You have an interesting topic, and you know what you want to write about. However, the subjects and topics don't automatically organize themselves vertically and horizontally as described in previous chapters. How do you get what is in your head onto paper properly structured? This chapter is about how to initially organize the information you have.
There are two methods described: a top-down approach and a bottom-up approach. Both of these result in a good document, but the top-down approach is recommended by the author. For myself, I think the bottom-up approach might be a better starting place.
Top Down Approach
The top-down approach is much like it sounds. Starting from more general topics, and proceeding to more specifics until all details are explained. But these points don't usually spring from the imagination onto the page.
The author suggests using a diagramming approach. Drawing boxes, form a tree, starting at the top with the general subject of the document, with edges posing questions that need to be answered. The result might look like the diagram above in the Chapter 1 summary.
The top box is your introduction. In it, you should be able to identify the situation, complication, question, and answer.
The top-down approach is useful when you know the subject (what you wish to talk about), but perhaps don't know all the details. It helps elucidate the questions that need to be answered, which then lets the writer drill down to answering those specific questions.
Bottom Up Approach
The bottom-up approach is useful when you perhaps don't have a clear understanding of what should be at the top. Undoubtedly you have some idea of what you should be writing about, or you wouldn't be writing the document. And you have points that you wish to make, but it's the connections between the points that aren't clear.
The simplest way to start is to simply write what you know about the subject.
The second step is to write what your audience is expected to already know (the situation, and perhaps the complication, of the introduction).
Next, group these points by similarity. Where connections don't exist, these should likely be in separate sections.
Think of the question that each point might be answering. These questions become the basis of the summary points that head each section.
Using this iterative approach, you can build on each layer, moving from specific to general. But don't be surprised or disappointed if the structure doesn't immediately appear. This is an iterative approach, which will often require several passes.
Like with the top-down approach above, you can start diagramming with boxes and edges, each box making a point and the edges asking questions that lead to those points, similar to the diagram in the summary of Chapter 1. Just prepare to either use your eraser or have scissors (digital or physical) ready to cut and rearrange.
Eventually, you might end up with a diagram for functional programming that looks like this.
Each layer is a more specific reason for using functional programming.
Introductions (Chapter 4)
Introductions are the most important paragraph in the document.
It must tell the reader what they already know, and then weave a story about why they want to read this document.
As mentioned in Chapter 1, the introduction consists of 3 parts.
- Situation - the current status
- Complication - the predicament that the situation presents
- Question - directs the expectations for what the document answers
- Key Line - the thesis statement for the solution that is described in the document
How Long?
The introduction can be any length, though succinct is better. Typically for short documents, it is a sentence for each part, and longer documents might be a few paragraphs.
Feel free to use more as necessary, but you really shouldn't need more than 3-4 paragraphs unless the topic is very complicated.
Situation
The situation presents a stable state, either currently or wished for. It is the basis from which deviation requires the document.
Hooks
A hook is a literary device to pique the reader's interest as quickly as possible.
By telling the reader something they already know, they can immediately establish the relevance of the document to themselves.
A good hook is also specific to the reader and their interests. It's even better if you can relate it with specific mentions of people or groups that the reader is familiar with. Nothing engages the reader more than familiarity.
Wide Audiences
When writing an introduction to a large audience, it is difficult to be specific.
Instead of writing something that tells the audience what they already know, it is easier to plant a question in the reader's mind.
Example Situation
As an example of a Situation, use the above diagram as inspiration.
- Functional programming is becoming more popular as software has struggled to adapt from faster single processors to multiple cores.
Hopefully, if you're a software developer, it's not controversial to state that speed increases in CPUs have stalled so vendors have compensated by adding more cores; and software that has to coordinate between multiple processors is more complicated than single processor software.
The key is that the Situation "is that they leave you expectant for further information."
Complication
The complication infers a question that must be answered. It describes either something that happened, is about to happen or could happen that would move the situation to an undesired outcome. (Typically the outcome is desired, but it could be desired, in which case the complication might be how to ensure it happens.)
The general format of complication and the inferred question are summarized below.
Complication | Question |
Something went wrong | What do we do? |
Something could go wrong | How can we prevent it? |
Something changed | What should we do? |
Something could change | How should we react? |
Here’s what you might expect to find in it | Do we find it? |
Here’s someone with a different view | Who is right? |
We have three alternatives | Which one should we take? |
This table is in the Pyramid Principle, Exhibit 12 in Chapter 2.
Key Line (Answer)
The key line is the succinct answer to the complication, and it hints at the remainder of the document's structure.
The key line is typically a single sentence, but if more points must be made, a bullet list is a good way to make sub-points. However, sub-points should be directly related to the main thesis, and not points that are explained later in the document.
Order in the Introduction
The introduction consists of Statement → Complication → Key Line. However, they don't have to be expressed necessarily in this order.
Altering the order can alter the tone of the document.
Setting the prescribed order, Statement → Complication → Key Line, creates a considered tone. An example of this tone might be as follows.
Until the last decade, software was typically run on a single CPU and could rely on hardware advances to increase performance. Moore's Law has slowed though, and the free ride of increasing performance is over. Hardware has compensated by including more cores to improve the (potential) performance of CPUs. Software using multiple cores is more complicated as it must coordinate multiple activities. Functional programming makes writing software that uses multiple cores easier at the expense of enforced discipline by the engineers writing the code.
Altering the order to the prescribed order, Solution → Situation → Complication will give a more direct tone.
Functional programming makes writing software using multiple cores easier and prevents categories of bugs associated with sharing state between multiple cores. As multiple cores have become the norm, software programs have had to improve performance and capability by coordinating across these cores. Coordinating imperative programs across cores requires a shared state, with locks or other mechanisms to ensure that this state stays in sync. This added complexity makes defects virtually inevitable in already too-complicated software.
A concerned tone can be struck by using the order Complication → Situation → Solution.
As CPUs no longer get faster each year, hardware has compensated by adding cores to CPUs. This has made writing traditional imperative software more complicated, requiring locks and other mechanisms to manage shared state. Software before did not have to worry about shared state as most software was run on a single core, which benefited from hardware improvements to speed and performance each year. Functional programming provides a pattern to structure software so that shared state is no longer a problem, and multiple cores can run software without worrying about race conditions or complicated sharing schemes.
Summary for Introductions
The introduction is the entrance to engaging people with your document. The principles to best encourage that engagement are the following.
- Remind your reader of something they already know.
- Three sections in the introduction should form a story.
- The length is contingent on the complexity of the topic.
- The tone can be set by varying the order of the story.
Transitions and Summaries
This section is not relevant to the introduction necessarily, but it was placed here. I believe it is misplaced, but this is an example of how even expert writers on writing do not always make the most obvious choices. This is of course highly subjective.
Transitions are fairly straightforward. By referencing a key point in a previous section, then the author can recall to the reader a concept or fact mentioned before. This is usually done to reinforce something in the current context that is related.
Summaries are effectively the adage, "Tell them what you've told them." They are effective when the writing is long or complicated. Reminding the reader where they've been is helpful in these cases.
Conclusions are summaries that restate what the writer wants the reader should have already determined, and reinforce this. Ostensibly the conclusion is not necessary, as the writing has been logically structured so the reader would reach the conclusion, but human nature is such that writing a conclusion is desirable.
Deduction and Induction (Chapter 5)
There are only two types of logical reasoning, deductive and inductive.
Deductive Reasoning
Deductive is what most people are familiar with, the most famous example being "Men are mortal. Socrates is a man. Therefore Socrates is mortal."
The format for deductive logic is a major premise, a minor premise, and a conclusion on how the premises are related.
When writing though, purely deductive arguments can sound trite or obvious.
- Any company with these three traits would be worth buying
- Company A has these 3 traits
- Therefore, we should buy Company A
Instead, you can frame a deductive argument inductively by simply flipping the conclusion and premises.
- We should buy company A
- Company A has these 3 traits
- Each trait makes a company worth buying.
This fits more in line with the general to specific advice that this book recommends in the previous chapters
Inductive Reasoning
While a deductive argument can be written inductively, this is not the same as inductive reasoning.
Inductive reasoning is the relating of a group to disparate concepts. It reasons from the specific to the general.
To find a grouping within, find a keyword that is a plural noun. It will be a noun because the idea is a thing. It will be plural since it appears in each group.
An example might be:
- There are more business registrations for SaaS businesses
- There are more searches on how to start a business
- There have been more layoffs and hiring freezes in the tech sector
- Therefore, more tech-savvy people are starting their own businesses
There is no guarantee that the reasoning is correct, but it should be evident that the specific points lead to the general conclusion.
Inductive reasoning can be applied to writing, but the conclusion should be framed first, with more specific points following afterward.
How to Highlight The Structure (Chapter 6)
This section seems the most dated. The general advice is good, but the particulars are outmoded.
The author mentions three styles, of highlighting structure, but I found one particular relevant, headings.
Headings
The key points for including headings are the following:
- Never use only one element in a section.
- Headings should call attention to a group of ideas, not a single idea
- Parallel ideas should be grouped at the same level.
- It helps to use the same format for each heading or highlight. If they start with verbs, using a predicate-subject format is consistent and should be maintained.
- Limit the wording to the essence of the thought.
- A heading should reference the subject, not be the subject or first sentence
- Don't regard the heading as part of the text, as the example below shows.
Functional Programming This paradigm will help….
- Don't reference the headings as part of the text as done above. Restating the heading is acceptable. People don't read the heading as part of the text.
Decimal Points
I think where the author mentions decimal points, one could substitute bullet points and the advice would be just as good, if not better.
Contrary to what the author suggests, I wouldn't go any deeper than 3 levels, and only if there is a very good reason. A single list of bullet points should be the ideal, and a sub-bullet point should only either reinforce the higher level point or introduce an exception.
Underlining
Don't. Just don't. Unless it's a link. Underlining today indicates a link. Italics can be substituted but should be used sparingly.
Conclusion
This book is a good reminder that structure is king in good technical writing.
Following the advice of your grade school writing class on outlining for research papers is still good advice for technical writing. Going from general or high-level to specific or low-level is a clear way to express ideas.
However, some of the advice is fit for a different age, when attention wasn't so fleeting. Absent are many items that would be appropriate for length and style for writing on the Internet.
I recommend this book, as it's an easy read, but consider adding more contemporary advice from books such as Smart Brevity.