The Minto Pyramid Principle

The Minto Pyramid Principle is the structural backbone of professional writing in management consulting and, increasingly, in tech. Where BLUF tells you to put the main point first, Minto tells you how to organize everything underneath it — as a strict hierarchy of supporting arguments, each of which is itself a mini-pyramid. The result is a document whose structure is a logical tree, traversable at any depth.

Minto Pyramid: main answer at the top, supporting key points beneath, evidence at the base

Origin

Barbara Minto developed the principle at McKinsey & Company in the 1960s and 70s. She was the firm's first female professional hire in 1963 and was tasked with improving the writing of consultants who were technically brilliant but often incomprehensible on paper. Her 1973 book The Minto Pyramid Principle is still, fifty years later, required reading at McKinsey, BCG, Bain, and most other top consulting firms. It has quietly shaped the structure of management memos across most of the Fortune 500.

The Framework

Minto's central insight: ideas have a natural hierarchy, and good writing makes that hierarchy visible.

                        [Governing Thought]
                        (the main message)
                              |
           +------------------+------------------+
           |                  |                  |
      [Key Point 1]      [Key Point 2]      [Key Point 3]
           |                  |                  |
      +----+----+        +----+----+        +----+----+
      |         |        |         |        |         |
   [Sub 1a] [Sub 1b]  [Sub 2a] [Sub 2b]  [Sub 3a] [Sub 3b]

Three rules govern the pyramid:

Ideas at any level must summarize the ideas below them. A parent node is the synthesis of its children, not just a label.
Ideas at the same level must be logically similar (same kind of answer). Do not mix "causes" with "recommendations" as siblings.
Ideas at the same level must be logically ordered. Time order, structural order, or degree-of-importance order — but always explicitly ordered.

The SCQA Introduction

Minto pairs the pyramid with a specific way of opening a document, which she calls SCQA:

S - Situation:      The setup the reader already agrees with
C - Complication:   The tension or change that makes action necessary
Q - Question:       The question the Complication raises in the reader's mind
A - Answer:         Your governing thought — also the apex of the pyramid

SCQA is covered in more detail in the SCQA & PREP subtopic; for Minto, the key point is that SCQA produces the document's opening paragraph, which then leads directly into the pyramid structure.

How to Use It

Building a pyramid is a deliberate process:

1. State the governing thought — the single sentence the reader must agree
   with after reading the whole document.
2. Ask "why does the reader believe this?" or "how do you know?" —
   the answers become the key points (2-4 is ideal).
3. For each key point, ask the same question. The answers become the
   sub-points.
4. Stop when the sub-points are self-evident to the audience.
5. Write the document top-down, so each section announces its conclusion
   and then supports it.

The test of a well-built pyramid: a reader should be able to read just the first sentence of each section and still understand the full argument.

Tech & Company Example

A staff engineer is writing a memo to the VP of Engineering recommending a database migration.

Governing Thought:
  We should migrate from MySQL to Postgres in Q4.

Key Points (why):
  1. The cost of our current database is growing faster than usage.
  2. Postgres removes three specific pain points we hit weekly.
  3. The migration cost is bounded and the risks are manageable.

Sub-points under (1):
  1a. RDS MySQL costs grew 40% YoY while query volume grew 12%.
  1b. Three of the top-10 slow queries are MySQL-specific limitations.
  1c. Our DBA time on MySQL tuning is ~15% of DBA capacity.

Sub-points under (2):
  2a. We need partial indexes, which MySQL lacks.
  2b. Our analytics team re-implements JSON ops MySQL cannot run.
  2c. Logical replication would collapse three ETL pipelines into one.

Sub-points under (3):
  3a. AWS DMS handles our schema; proof-of-concept ran clean in staging.
  3b. We can run dual-write for 2 weeks to de-risk cutover.
  3c. Rollback plan is documented and tested in staging.

Now the memo writes itself:

[SCQA Intro]
S: Our databases have served us well for 5 years.
C: Over the last 18 months, cost and friction have grown beyond ops capacity.
Q: What do we do?
A: Migrate to Postgres in Q4.

[Key Point 1] Our current database is getting economically unsustainable...
[Key Point 2] Postgres solves three specific pain points...
[Key Point 3] The migration is bounded and de-risked...

The reader who skims gets the thesis and the three key points. The reader who reads deeply gets the full argument. Both get the same logical structure.

When It Works

Executive memos, investment theses, and strategy documents
Technical design docs and RFCs (use as the structure for the "why" section)
Long-form internal writing (5+ pages) where structure matters
Any document where the reader needs to be persuaded, not just informed

When It Does Not Work

Short communications — the pyramid is overkill for a 3-paragraph email
Exploratory writing — you need to know the conclusion to build the pyramid
Narrative or emotional content — hierarchy removes the emotional arc
Pure reference material (API docs, runbooks) — structure should be lookup-oriented, not argumentative

Common Failure Modes

False pyramids — sections that look like Minto but where the headers do not actually summarize the contents (headers like "Background" and "Analysis" are warning signs)
Wrong logical grouping — mixing causes, effects, and recommendations as siblings; the MECE principle (Mutually Exclusive, Collectively Exhaustive) is the cure
Too many key points — if you have 7 key points, you actually have 2 key points with 3 sub-points each; find the real groupings
Governing thought is a topic, not a claim — "The database situation" is a topic; "We should migrate the database to Postgres" is a governing thought
Pyramid without SCQA — readers who do not understand why they should care will not read the pyramid, no matter how well structured it is

MECE (Mutually Exclusive, Collectively Exhaustive) — The grouping discipline Minto uses for sibling nodes. Consultant shorthand for "no overlap, no gaps."
SCQA — The introduction pattern that leads into the pyramid.
BLUF — A minimalist cousin; just the apex of the pyramid with no sub-structure.
Amazon 6-pager — Narrative version; the pyramid is implicit in the flow, not made visible with headers.