Three things I do before a high-stakes call: a one-page pre-mortem, a guardrail register, and a decision journal that survives Monday-morning quarterbacking.

The one-page pre-mortem memo

When I can't defend a forecast without doing interpretive dance, I stop pretending the spreadsheet is the boss and I write a pre-mortem memo. One page, no attachments. The rule is simple: assume it's 12 months later and the decision turned into a mess. Not a small mess. A career-sticky mess that shows up in a board deck with a red circle around it. Then I list the five to seven most believable ways we got there.

Believable is the whole trick. I don't write movie-plot failures like "a competitor suddenly appears". I write things that match how companies fail in real life: we overestimated sales enablement capacity, the rollout got stuck behind security review, a key partner slowed procurement, churn ticked up and quietly ate the net-new, margins got pinched because the "temporary" discount became the price. If I'm doing this right, every bullet makes at least one person in the room shift in their chair.

Then I force each failure mode into three lines: the early signal I'd see in the first 30 to 60 days, who would notice it first (finance, support, legal, a regional GM), and the fastest reversible move. This is where executive decision-making frameworks earn their keep. You're not predicting the future, you're building a sensor network and a set of small levers.

I usually read it out loud in the meeting, because the tone matters. If it sounds like a risk section copied from an S-1, people tune out. If it sounds like a leader who has cleaned up enough messes to know the smell, you get better objections, and earlier. That's the win: the debate happens before you hire, sign, and announce.

Guardrails, not goals: the register I won't skip

I learned this the hard way: when an outcome is impossible to price cleanly, teams will negotiate themselves into fuzzy language. We'll watch the metrics. We'll be disciplined. We'll revisit in Q2. None of that survives the first month of sunk cost. So I write a guardrail register before we vote. Not after.

A guardrail register is a short list of thresholds that trigger a decision, not a dashboard of everything we could measure. Think of it as the opposite of OKRs. Goals are what we want. Guardrails are what we're not willing to tolerate while we chase it. I keep it to four buckets because leaders will remember four and ignore fourteen: cash, time, customer impact, and people load.

• Cash: "If non-headcount spend exceeds X before we see Y, we pause." If you can't name the spend category (agency, cloud, contractor, incentives), it's not real.
• Time: "If legal review isn't complete by date Z, we don't pull forward launch." This prevents the classic move where schedule pressure becomes a security decision.
• Customer: "If support tickets about the new flow exceed N per week for two consecutive weeks, we roll back." This is blunt on purpose.
• People load: "If the on-call rotation hits more than M pages per person per week, we cut scope." It's amazing how quickly this one reveals whether the plan is fantasy.

Notice what's missing: I don't write guardrails as averages or lagging quarterly metrics. I write them so an operator can spot the breach on a Tuesday. And I assign an owner to each one. Not the team. A person with a calendar and a phone.

This framework changes the tone of the room. Instead of arguing about whose model is smarter, we're agreeing on the conditions under which we keep going, slow down, or stop. That sounds procedural, but it's emotional insurance. When the heat shows up, you can point to the register and say, "We said we'd stop if this happened. It happened." Nobody has to be the villain, and you avoid the quiet failure where everyone sees the problem and nobody wants to be first to name it.

Decision journal, with receipts (so you can update your instincts)

The fastest way to get worse at hard calls is to never audit your own thinking. Not in a punitive way. In a craft way. When outcomes are noisy, your brain will happily rewrite history and tell you you were right all along. So I keep a decision journal, and I keep it embarrassingly plain.

One entry, one page. I date it. I list the decision, the options we seriously considered, and the option we picked. Then I write three sections that I can review later without needing to reconstruct the entire quarter from Slack archaeology:

1. What would have to be true: I write the two to four assumptions we're leaning on. Not ten. The sharp ones. Example: "Sales cycle won't extend more than two weeks" or "We can staff the migration without pulling senior engineers off reliability work."
2. What we saw: This is where the receipts go. A customer email excerpt, a screenshot of pipeline notes, a short summary of what finance flagged, a line about what the security lead said in the review. No fake precision, but also no vibes.
3. What would change my mind: I name the data or event that would make me reverse the call. If I can't name it, I'm not deciding, I'm declaring.

Here's the part that makes it an executive framework instead of a diary: I schedule a 20-minute revisit on my calendar for 6 to 8 weeks out. Not a big retro, not a blame session. Just me (and sometimes one other leader) reading the entry and answering two questions: were our assumptions wrong, or did we execute poorly? Those are different problems, and they require different fixes.

Over time, the journal teaches you where your instincts are systematically off. Maybe you're consistently too optimistic about integration work. Maybe you're too conservative about pricing tests. You only see that pattern if you keep the paper trail. And when someone comes in hot with Monday-morning certainty, you can pull up the entry and say, "This is what we knew then, and this is why we moved." The room gets calmer immediately.