Upward: making a case that lands

An engineering lead walks into quarterly planning with the strongest document she has written all year: a proposal to spend thirty percent of next quarter paying down debt in the payments service. She follows the standard advice: she opens with the recommendation, backs it with charts on incident frequency and delivery slowdown, and translates everything into business language. The room listens politely. Someone asks whether this can wait until after the pricing launch, and someone else asks if the team could do a lighter version alongside roadmap work. The meeting ends with "let's revisit next cycle," and the proposal dies without anyone ever saying no to it.

She was not wrong: the service really was dragging the team down, and the numbers were honest. The case failed anyway, and it failed in the first two minutes, because nobody in that room had ever lost sleep over the payments service. She was answering a question they had not asked yet.

Most upward cases die this way: the idea is fine, and the ask is framed wrong. The standard advice on making a case to leadership is genuinely good as far as it goes:

• Lead with the answer. Senior audiences read top down and lose patience with build-up.
• Translate into business terms. Revenue risk and delivery delay, rather than refactoring and test coverage.
• Never surprise your boss in a meeting.

Follow all of it, but each of those rules has a missing piece that nobody mentions, and the missing pieces are where cases die. What follows is the playbook I would hand an engineering leader before their next big ask: six steps, in the order you use them.

Sell the problem before the answer

Leading with the answer works only when the audience already owns the problem; the advice skips that part. When your VP has personally fielded the board question about reliability, open with the recommendation, because build-up at that point is padding. But when the problem lives only in your head and your team's retros, leading with the ask reads like an invoice for a service nobody ordered. The room spends your whole pitch silently asking "why does this matter?" while you walk through implementation detail.

So the first question in any case is: has this audience bought the problem? If yes, answer first. If not, the opening job of the document is to sell the problem, to make them feel the cost and own it, before the recommendation appears at all. Knowing which situation you are in requires keeping track of what leadership currently cares about, which is its own practice.

You can also overdo it: sell a problem the room already owns and you burn their patience and your credibility. Read which case you are in each time rather than settling on a favorite structure.

Write it from the buyer's seat

Translating your case into business terms changes the vocabulary and nothing else: a translated case still argues "here is why my idea is good." A case written from the buyer's seat answers the question the decision maker is sitting with, and that question differs from yours in three ways:

• Opportunity cost. Every funded proposal is an unfunded something else, so your boss weighs your idea against the other asks on their desk this cycle.
• Execution risk. It matters more to them than how good the idea is: a decision maker who has watched good ideas stall in delivery wants to know who specifically will carry this and what happens to their current commitments.
• Their boss. Your boss has a boss: part of what you are writing is the explanation they will give one level up if this goes sideways.

Before drafting your argument, draft the strongest reason your boss should say no, in their words rather than yours. The case is ready when it takes that rejection apart. If the no you rehearsed against is weaker than the no that shows up in the room, you prepared for the wrong fight; a strawman rejection is comfortable to write and worthless to test against. Writing the rejection honestly is hard precisely because it forces you to take the other seat.

Make the number defensible

The standard advice says attach a number, and you should. The part nobody says is what the number is for: executives rarely believe the figure itself, because they have seen too many projections. What they are checking is whether you thought like an owner when you produced it.

Compare two versions of the same claim. One says the debt costs two million in annual revenue at risk. The other says: we average two payment incidents a month, each one pulls four engineers for about two days, and that adds up to two engineer-months per quarter before we count the features that slipped. The first number is bigger, but the second is believed, because the person presenting it can rebuild it out loud when challenged, and every step is something the room can check against their own experience.

Pick the conservative number you can defend over the impressive number you cannot, and show how you got it, rather than the figure alone. A half-believed number does not just weaken one slide; it leaks doubt into everything else in the document. Undersell too hard, though, and your case stops clearing the bar against the other asks on the same desk. Defensible does not mean timid; it means every step survives a follow-up question. The classic test is the debt paydown pitch.

Shrink the yes

Some cases stall not because the audience disagrees but because the ask, as drafted, requires them to commit to everything on day one. Restructure it so the first yes is small and reversible: ask for the pilot or the one quarter, with an end date and a checkpoint where they can stop funding you.

This is not the same as asking for less: the ambition stays on the table, and what shrinks is how hard the first step is to undo. A decision maker who can get out cheaply says yes far more easily, and the checkpoint turns your case from an argument into evidence: the pilot's result is the strongest opening for the next, larger ask.

Shrink too far, though, and the pilot settles nothing: you waste the credibility you spent winning it, and the second ask arrives with no more evidence than the first. The hardest version of this problem is work whose payoff cannot show up inside a quarter at any pilot size, which is its own case to make.

Settle it before the meeting

When the case goes to a planning review or a leadership meeting rather than a single decision maker, the meeting is the wrong place to persuade anyone. Pre-wiring means settling the decision one conversation at a time before the meeting:

1. Walk the case around beforehand, one person at a time.
2. Collect objections privately, where people can voice them without an audience and change their minds without losing face.
3. Fold what you hear back into the document.
4. Walk into the room already knowing each attendee's position.

The meeting's job is to confirm and record a decision that has effectively already been made; the persuasion happened in the conversations before it.

This is where "never surprise your boss" lives, but the real test is sharper than the slogan: if you hear a genuinely new objection in the meeting, you missed a conversation.

All of this is preparation for one specific ask. Making sure leadership always knows where your team is headed is a different practice, and winning over the peers who will sit in that room is its own craft.

Done badly, pre-wiring looks like lobbying: leave someone out, let them discover the decision was settled without them, and the win costs you trust that every future case will need.

Finish cleanly either way

The decision comes back yes or no, and there is a right way to handle each.

If the answer is yes, write the decision down while the room still agrees on what was decided: the ask, the rationale, the checkpoint. People's memories of an approval drift apart surprisingly fast, and the written version is the one that survives.

If the answer is no, choose deliberately between two ways out. One is to commit honestly to the no and mean it. The other is to wait: set the case aside and bring it back when something changes, a budget cycle or an incident that makes the problem vivid. Do not keep re-raising the same ask in every meeting until everyone is tired of it. And read the no correctly: a no to an upward case usually means not now, at this size, from you. Treating it as final gets it wrong, and so does treating it as just round one.

Losing well counts, because you will be back with another case. Each one spends credibility or earns it for the next, and that balance matters more than any one outcome. You do not win upward cases by arguing harder but by making the yes cheap: a problem the buyer already owns, their best rejection already answered, a number they can check, a first step they can reverse, a room that agreed before it ever met.