The Pyramid Principle for Engineers

Here is a thing that happens constantly in engineering orgs, every single day.

An engineer — a good one, a smart one — spends three weeks deep in a problem. She traces the root cause. She builds a solution. She tests it. She writes it up. And then she sends the email, or posts the doc, or presents in the design review. And nothing happens. The idea goes nowhere. Maybe it gets a few thumbs-up emojis and is never mentioned again. Maybe someone else proposes the same thing six months later and that one gets funded.

The engineer blames org politics. Or her manager. Or the fact that "HiPPO" (Highest Paid Person's Opinion) always wins. She's partly right. But she's also missing something closer to home.

The idea was fine. The structure was broken.

She told the story in the order she lived it. Context first. Background second. Data third. Caveats fourth. Recommendation last — buried at the bottom after most people stopped reading. She wrote the way she thought. And thinking is messy, nonlinear, full of dead ends and qualifications. That's the right way to discover an answer. It is the wrong way to communicate one.

This is not about intelligence. The smartest engineers in the room often communicate the worst. Because they know the most, they feel the obligation to explain all of it — every nuance, every trade-off, every thing they considered and rejected. They confuse thoroughness with clarity. They are not the same thing.

There is a concept, originally from consulting, called the Pyramid Principle. A McKinsey editor named Barbara Minto developed it in the 1970s. It is the most practically useful communication idea that almost no engineer has ever heard of. And once you understand it, you cannot unlearn it — you will see the violation of it everywhere.

The idea is simple. Almost insultingly simple. But most people never do it.

Start with the answer. Then give the supporting arguments. Then give the evidence for each argument.

That's it. That's the pyramid. Your main point is at the top. Everything below it exists to support the thing above it. The reader gets the conclusion first, then the reasoning, then the proof. Never the other way around.

It looks like this as a structure:

Notice what this does for the reader. If they only have 30 seconds, they get the most important thing. If they have 3 minutes, they get the reasoning. If they have 30 minutes and care deeply, they get the full detail. You have given every kind of reader exactly what they need, in the right order.

Compare this to how most engineers actually write — which is the anti-pyramid. They write in the order they thought about the problem. Background, then context, then analysis, then trade-offs, then a tentative conclusion hedged with seventeen qualifications. The reader has to wade through everything to find out what the engineer actually wants. By then, they're tired, or they've stopped reading, or they've formed their own opinion and stopped listening.

Before you send anything — a Slack message, an email, a doc, a slide — ask yourself one question: "If the reader reads only the first sentence of this, what do they know?"

If the answer is "context" or "background" or "the history of how this problem arose" — rewrite it. The first sentence should tell them what you want them to do, know, or decide. Everything else is support.

This is the So What test. It's brutal. It kills a lot of writing. But the writing it kills was never doing anything useful anyway.

That is not a bad email. The reasoning is sound. The data is there. But where is the actual request? In the last sentence. After the reader has already processed seven sentences of context they may not have needed. What if they stopped at sentence five? What if they scan-read like every executive does?

The information is nearly identical. The experience of reading it is completely different. Version B respects the reader's time. It earns their attention rather than demanding it. And critically — if they only read the first sentence, they know what you want. Everything after that is evidence they can choose to examine.

Notice something else. Version B also sounds more confident. The engineer who writes in pyramids sounds like someone who knows what they think. The engineer who buries the conclusion sounds like someone who is still figuring it out. Even if the underlying thinking is identical. Structure signals confidence.

There are three reasons this is so hard, and they are all rooted in real things.

The fix for all three is the same: write the way you think, then rewrite the way your reader reads. First draft is for you. Second draft is for them. Invert the structure. The data still exists. The reasoning is still there. It just moves to where people will look for it — below the conclusion, available on demand.

The pyramid principle does not mean the same thing to a VP, a peer, and a junior IC. The structure is identical — answer first, reasoning second, evidence third — but the content at each level changes dramatically based on who you're talking to and what they care about.

If you send a VP-level message to an IC, they'll think you're being dismissive. If you send an IC-level message to a VP, they'll be grateful you have data and ignore most of it. Learn to read the room before you write the email.

The common mistake is writing for one audience when you have all three in the room. The fix: write a pyramid with multiple entry points. The executive reads the header and the first paragraph and stops — they got everything. The peer reads through the design rationale section. The IC reads the full appendix. One document, structured in layers, serves all three. This is not three documents. It is one document with deliberate structure.

The pyramid lives or dies on the quality of the governing thought — the single sentence at the top. This is harder than it sounds. Most people cheat it.

A weak governing thought is a topic sentence. "This document covers the database migration options." That tells me what you're going to talk about. It tells me nothing about what you think. It's a table of contents pretending to be a point.

A strong governing thought is a claim. "We should migrate to PostgreSQL in Q2, and the window closes after that because of the Q3 traffic surge." Now I know what you think, and I know there's urgency. Every sentence that follows is either proving that claim or giving me what I need to evaluate it.

When you find the governing thought hard to write, that is useful information. It usually means one of three things: you haven't decided yet what you think, you're afraid to state it directly because you might be wrong, or the thing you're writing about doesn't have a single main point and should actually be two documents. All three are fixable, but you have to recognize which one you're facing.

The discipline of writing a governing thought forces you to have an opinion. That is the whole point. Opinionated, well-supported communication is the signature of senior engineers. It sounds like: "I've thought about this, here's where I landed, here's why, change my mind with better data." Tentative, meandering communication sounds like someone who hasn't finished thinking yet.

The pyramid principle is not just for design docs and RFCs. Once you have it, you apply it to everything. And "everything" is a longer list than most engineers realize.

In every single case, the pattern is the same: answer first, support second, detail third. The medium changes. The structure does not.

Here is the practical habit. Implement this and you will feel the difference within a week.

Write the bottom-up version first. Then invert it.

When you need to communicate something important, write it the way your brain wants to — context, background, analysis, conclusion. Let it all come out. This is your first draft. It is also your last draft for you. Now, before you send it, do one thing: cut your last paragraph, turn it into your first sentence, and move everything else below it. That's the whole technique. It takes two minutes and transforms a mediocre communication into a sharp one.

The other habit: before you write a single word, ask yourself the question your reader will ask the moment they finish reading: "So what? What do I do with this?" If you can't answer that question in one sentence, do not start writing. Answer the question first. That answer is your governing thought. Your entire document is just the evidence that the answer is right.

Here is what nobody tells you about this skill.

When you consistently communicate in pyramids — in docs, in Slack, in meetings — something happens to your reputation that has nothing to do with the content of what you're saying. People start to think of you as someone who has clarity. As someone who knows what they think. As someone who is decisive and structured. And in most engineering orgs, that reputation attaches to a mental model: this person is senior.

Your manager will notice. Not because they've read the Pyramid Principle and are explicitly testing you. They'll notice because reading your updates feels easy. Following your proposals feels natural. Listening to you in meetings doesn't require effort. Contrast this with the engineer whose communications make you work hard to extract the point — that engineer feels, regardless of technical ability, like someone who is still developing. Someone who hasn't quite arrived.

Promotion decisions often hinge on whether the people above you can see you in the next role. When they imagine a Staff engineer, they imagine someone who walks into the room with a clear point of view, supports it with good reasoning, and doesn't make others do the mental work. When you communicate in pyramids, you are showing them a preview of that version of you. You are making it easy for them to say yes.

There is also a second-order effect. When you get into the habit of writing the governing thought first, you will find that sometimes you cannot write it. Not because you're bad at writing — but because you haven't actually formed a strong opinion yet. You're still equivocating. The discipline of the pyramid is, in those moments, a forcing function. It makes you confront the fact that you don't have a view. And then you have to go get one. This makes you a better thinker, not just a better communicator. The writing improves the thinking. The thinking improves the communication. It compounds.