Upward: making a case that lands

Picture an engineering lead walking 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, 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, someone else asks whether the team could do a lighter version alongside roadmap work, and the meeting ends with "let's revisit next cycle," which is how a room says no when nobody wants to be the one who pays for saying it.

She was not wrong. The service really was dragging the team down and the numbers were honest, but the case failed in the first two minutes anyway, because nobody in that room had ever lost sleep over the payments service, and the document spent its whole length 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, and then notice what each rule leaves out, because 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, which is the part the advice skips. When your VP has personally fielded the board question about reliability, open with the recommendation, because build-up at that point is padding. 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, and the room spends your whole pitch silently asking "why does this matter?" while you walk them through implementation detail.

So the first question in any case is whether this audience has bought the problem. If they have, answer first, and if they have 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 means 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 along with your credibility, so 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, so 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, and treat the case as ready only 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 it tells you nothing. 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, but the number is doing a different job than the advice implies. 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 counting the features that slipped. The first number is bigger, and the second one gets believed, because the person presenting it can rebuild it out loud when challenged and every step is something the room can check against its own experience.

Pick the conservative number you can defend over the impressive number you cannot, and show how you got it rather than presenting 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, so defensible cannot 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.

Shrinking the yes is not 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, because 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 one did. 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, though the test I would apply is sharper than the slogan: a genuinely new objection in the meeting means there was a conversation you skipped.

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, and to the person you left out it is lobbying: they 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, each in whatever direction favors the person doing the remembering, 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. What does not work is re-raising the same ask in every meeting until everyone is tired of hearing it. And read the no correctly: a no to an upward case tends to mean not now, at this size, from you, so treating it as final gets it wrong, and so does treating it as just round one.

Losing well counts, because you will be back in front of the same people with another case, and each one spends credibility or earns it for the next, which matters more than the outcome of any single meeting.