How to get decisions made

A step-by-step guide on how to get to high-quality, efficient decisions + the frameworks leading companies use for this

👋 Hi, it’s Torsten. Every week or two, I share actionable advice to help you grow your career and business, based on operating experience at companies like Uber, Meta and Rippling.

If you enjoyed the post, consider sharing it with a friend or colleague 📩; it would mean a lot to me. If you didn’t like it, feel free to send me hate mail.

---

Solving problems sounds like it’s mostly about analysis and execution. And while those are key, it’s equally important to get everyone aligned on the path forward.

In a small startup, you might be able to just “go and do things”.

I guess you could say the Joker was the original “high agency individual contributor”

But once your organization hits a few hundred employees, has multiple layers of management and several teams that want to have a say, you need to approach important decisions in a structured way.

That doesn’t necessarily mean you need to introduce a formal decision-making framework like RAPID (we’ll get to these in the end); but it does mean you need to:

1. 🔍 Identify the decision maker

2. 📝 Prepare by aligning with other stakeholders

3. 👩🏻‍🏫 Frame the problem & present your recommendation

4. ⏳ Make sure the decision gets made efficiently and in time

5. 🔒 Make sure the decision doesn’t constantly get reopened

Many projects fail, or take unnecessarily long, because people are unable to tee up a clean executive decision. In this post, we’ll cover how to do it well.

I will first go through what works from my experience, and then cover popular decision-making frameworks that are widely used at top companies.

Note: Similarly to what I wrote in my guide on solving problems, you should only apply a structured approach like the one described in this post for high-stakes decisions. Everything else can be handled using your best judgment.

When in doubt, remember: It’s usually easier to ask for forgiveness than to get permission.

---

As a reminder, this is Part II in a loose series on how to solve problems. If you haven’t yet, check out Part I here:

How to solve problems

---

Step 1: Identifying the decision maker

You can’t make a decision without the decision maker.

What might sound obvious is actually the cause of a lot of failed meetings I’ve been a part of. In my last job, we’d sometimes have heated debates for 45 minutes between Marketing and Sales only to realize that the person who can truly make this decision wasn’t even in the room.

So, how do you figure out who the decision maker is?

In most organizations, it’s the person that is on the hook for the outcome of that decision (if that’s not the case in your company, then you might want to address that). In rare circumstances, it needs to be multiple people (e.g. when transferring ownership of something from one team to another).

Unfortunately, while it’s often immediately clear which team owns the outcome and thus the decision, it’s not always obvious at which level the decision is made.

For example, if you want to get sign-off on testing a new AI agent for customer support, do you approach the support lead on whose team you want to test it? Or does the Head of Customer Support need to sign off?

Most companies don’t have these kind of decision-making rules clearly spelled out.

What worked well for me: Approach the person who directly manages the impacted team and copy leaders 1 - 2 levels above them on the message. That way, there’s a very low risk that the topic will be reopened later because an exec felt like they didn’t have visibility into the decision and don’t want to own it.

---

Step 2: Preparing for the decision meeting

For important decisions, I recommend scheduling the decision meeting first and then working backwards to prepare. This ensures that you get the decision made by when you need it.

Once you have that scheduled, you need to prepare. The easiest way to create chaos is to use a decision meeting with an executive to discuss the topic with other teams for the first time, so you should avoid that at all costs.

Instead of discussing with you how to move forward, they will:

• Ask basic questions about the situation

• Argue about how important and urgent the problem is

And so on.

If you want to have a clean, efficient decision meeting, the only person getting any new information in the meeting should be the executive making the decision

Ideally, you’ve aligned with the other meeting participants on every aspect in advance. But that’s not always possible.

Here’s the hierarchy of what you absolutely need to agree on in advance vs. what can remain up for debate:

• [Must have] You need to agree on what the problem is and that it’s important

• [Very important] You should agree on how to think about the problem (more on that below)

• [Important] Ideally, you should come with a joint recommendation

So, how do you actually do that?

I recommend you meet in person with the team(s) most directly affected (e.g. if it’s a Go-To-Market decision, Marketing & Sales should be in the room).

For everyone else, you can share a brief write-up of what you’re proposing and give them a chance to weigh in with feedback by a certain deadline. That deadline should be at least a few days before the decision meeting so that you have a chance to follow up on any controversial points and resolve them in time.

If you skip this step, you risk a flood of complaints once you announce the decision, which will make it difficult to move forward. So, don’t.

---

---

Step 3: Framing the decision

The executive making the decision is not as in the weeds as you are; in fact, they might not have thought about the topic in question before.

So it’s your job to clearly frame the decision you want them to make. This is not about giving a recap of how the problem came up, or your analysis. It’s about describing in simple terms what has to be decided, and how to think about the decision.

---

Example: Short-form video at Meta

While I worked at Meta, we were in the process of slowly rolling out Reels (Meta’s short-form video product) across Facebook and Instagram.

Initial tests showed revenue drops across the board. If we had evaluated the decision whether to roll out Reels broadly to all users based on normal experiment guidelines, the answer would have been “No”.

However, Reels was a new, unoptimized product and not meaningfully monetized yet. In addition, if Meta didn’t cannibalize its own existing business with this new product, TikTok would. Therefore, the key question for the roll-out wasn’t whether Reels was a net-positive addition at the moment, but rather whether we believed it could, in its end state, be incremental to engagement and revenue.

Leadership decided to make this long-term strategic bet and it paid off: In its Q4 2023 earnings call, Meta announced that Reels had become a net positive contributor to company revenue, and it’s now one of the main drivers behind the continued growth.

---

While it’s important to give context, you need to be concise. In most companies that aren’t Amazon, executives won’t read a multi-page document ahead of the decision meeting. So you need to summarize the key information in an easy-to-digest way.

Give them the information they need to make the decision. Not more, not less.

As a general principle, the framing of the problem should be presented by one person, even if multiple teams are involved. That’s why it’s crucial to agree on a joint framing in advance (see Step 2 above).

Sequencing decisions

Some complex problems require multiple decisions as you’re working through them. The initial decisions guide the rest of the work, so you should get those locked in as early as possible.

Based on the guidance you get, you can then continue the work and come back to frame up another follow-up decision.

For example:

Let’s say you work at a video platform like YouTube and are trying to figure out whether to increase the number of ads.

If you have made similar decisions in the past, you might have a principle in place that tells you how to make this decision. In that case, you just have to present your recommendation and the data that backs it up to get sign-off.

But if this is the first time, you need to start with the fundamentals.

Increasing ads on a media platform is ultimately a trade-off between revenue and user growth. Users don’t like ads, so more ads will results in less engagement or even churn. However, the (remaining) time users spend on the site will generate more revenue.

The first decision you have to tee up is:

“Are we optimizing for revenue or user growth?”

Without clarity on the strategic goal, you can’t decide if (and how much) you should ramp up ads.

➡️ If you’re optimizing for user engagement, you shouldn’t run more ads; the work stream comes to an end

➡️ If you’re optimizing for revenue, increasing ad load is an attractive option. The follow-up decision you then need to tackle is: By how much should you increase ads?

---

Step 4: Presenting your recommendation and the options

Lead with the recommendation

Once you’ve framed the problem, you should share your recommendation.

Why give a recommendation at all?

It’s your job to not just dump information on an exec, but provide a recommendation (for them to agree with or challenge). That’s because:

1. You’re closest to the problem, so you are uniquely positioned to give a recommendation, and

2. Otherwise, you’re leaving all the heavy lifting to them

But why lead with the recommendation?

This is the core idea of the “Pyramid Principle” (if you’re a regular reader of this newsletter, you might have heard about it before 😬).

If you don’t lead with the recommendation, people will be distracted and wonder what it is while you’re presenting the analysis.

In addition, it allows them to interpret the data and arguments you present in the context of the recommendation, making it easier to follow along.

As mentioned before, if there are multiple teams present, you should ideally present a joint recommendation. If you really can’t agree on one, you can present two “competing” recommendations as a last resort. In that case, start with the framing of the problem (which all teams should agree on), and then let each team present their recommendation for what should be done.

Let’s continue with the example from above. For simplicity’s sake, let’s assume your company has determined in the past that it wants to optimize for revenue, and the decision at hand is how much (if at all) you should increase ads.

The recommendation you might present is:

“We should increase ad load (ads / hour) from 5 to 6 by increasing overlay ads”

Following the pyramid principle, you now need to back up that recommendation.

Provide supporting arguments and show alternative options

To be specific, we actually made two separate recommendations, and we need to provide reasoning for both:

1. Recommendation #1: “We should increase ad load from 5 to 6”

2. Recommendation #2: “The increase should come from overlay ads”

Diagrams and graphs come in handy here. A single crisp chart can communicate what might take you multiple paragraphs to explain.

Let’s start with recommendation #1. To explain our reasoning, we could show a chart that shows revenue as a function of ad load (based on experiment data):

This chart clearly explains how we landed on our recommendation and shows the other options (in this case, the spectrum of ad load choices). Our objective is to maximize revenue, and that happens at an ad load level of 6.

Below that, we’re leaving money on the table because our revenue per hour of watch time is not high enough. Above 6, decreases in watch time (users watch less due to ads or churn altogether) outweigh the incremental revenue per hour.

This type of diagram is well-suited for when you’re trying to solve a quantitative problem and decide which point on a spectrum you should pick.

But not all problems are like that. The second part of the question (“Which ad type should we scale?”) requires you to compare several discrete options. In this case, the Traffic Light framework, popularized by Meta, is a good fit.

It’s simple; you just need to:

• 1️⃣ Decide what criteria you care about (that's your y axis)

• 2️⃣ List out all options (that's your x axis)

• 3️⃣ Score each option for each criteria using red / yellow / green color-coding

The result is a simple matrix that lets you quickly see the pros and cons of each option.

The important part: While you should evaluate all options as you’re working through the problem, you shouldn’t present all of them to the decision maker. Your job is to focus the discussion and narrow things down to the most relevant options.

For completeness’ sake, you can add the remaining options to the appendix and link to that.

Lastly, keep in mind that even with color coding, interpreting a list of pros and cons to make a decision still takes some mental effort. As a result, I’ve found it helpful to present your recommendation and the main competing options in plain English:

Other frameworks for presenting recommendations & options

I can’t write an article on framing options without mentioning one of the most useful frameworks ever: The 2x2 matrix.

It might seem simplistic, but that’s the point. There’s a reason why it’s one of the favorite tools of consultants at McKinsey, BCG etc.

It forces you to boil a complex topic down to just two relevant dimensions. The result places all options on a grid with four areas.

Here’s an example. Let’s say your team is responsible for driving user engagement on a social media platform, and you’re on track to miss your goals for the quarter.

Instead of presenting your manager with a long list of projects, ranked by a dozen different criteria, you can create a simple 2x2 matrix:

This presentation makes it easy:

1. You start with the ideas in the top left (high impact, short time to impact)

2. After you exhausted these, you move to the bottom left (lower impact, but can still help you hit your quarterly targets)

3. The ideas in the top right can be revisited in the next planning cycle (high impact, but take too long to help your current situation)

4. The ones in the bottom right you shouldn’t touch

---

Step 5: Moving forward after the decision

You got the decision maker to make a call — great!

But there’s still work left to do. You’ll want to make sure that:

• 🤝 People are bought into the decision (or will at least not actively fight it)

• 🔒 The decision doesn’t get reopened over and over again, and

• ⚙️ People actually execute the plan

Announcing the decision and explaining the rationale

People who were in the decision meeting know what was decided and why.

Everyone else doesn’t have that context. In fact, they might not even know that the decision was made at all!

So, it’s up to you to make sure everyone’s in the loop. Depending on your company’s culture and preferred communication tools, you can send an email, a Slack announcement etc.

The important thing is that 1) it’s in writing and 2) you share the rationale for the decision.

If you don’t share the context, you’ll likely get a lot of pings from people asking whether you considered this or that factor or looked at certain alternatives.

Documenting the decision

Nothing erodes morale faster than constantly revisiting decisions that were already made. When that happens, it doesn’t just feel like you’re not moving forward — it feels like you’re taking a step backwards.

So make sure you’re creating a permanent record of what was decided and why. When someone wants to reopen the topic (for example, new people joining the company tend to do this), you can point them to it.

One thing I find helpful in this regard: Keeping a decision tracker. That way, you can easily dig up the relevant documents.

Enforcing “disagree and commit”

It’s important that everyone gets heard. That doesn’t mean everyone gets what they want all the time.

As long as you give people a chance to give input by a reasonable deadline, you’ve done your job. Even if someone disagrees with the decision: In a functioning organization, they have to accept that and move forward (i.e. support the execution of the plan).

It’s important to be adamant about this, or you’ll set a precedent that anything can constantly be revisited. Even if someone brings up a valid new point that you didn’t consider at the time, it’s usually not worth reopening the discussion. As long as the original decision and rationale are still reasonable, it’s better to keep moving forward.

“A good plan violently executed now is better than a perfect plan next week.” — General George S. Patton

Assigning a party responsible for execution

If you want to get something done, it’s best in my experience to have a single person in charge of coordinating the execution. This can be a PM, BizOps manager, Program Manager etc.

That doesn’t mean they have to do all the work — it just means they are making sure that the right people are working on the right things and any deadlines etc. are hit.

---

A checklist for efficient decisions

Whew, that was a lot. In case you want a TL;DR, here’s a checklist to help you efficiently facilitate decisions:

• 👨‍💼 Decision maker: A single person for most decisions; but give visibility to execs 1 - 2 levels up the chain

• 1️⃣-2️⃣ Sequence decisions: Tee up fundamental decisions (e.g. “What are we optimizing for?”) early on to give clarity & minimize throwaway work

• 🤝 Avoid chaos: Align with other teams in advance to present a joint framing of the problem. Ideally, you present a joint recommendation as well

• 🎯 Lead with your recommendation before diving into supporting data & arguments or alternatives

• 🖼️ Presenting choices:

  • Use graphs to illustrate optimal choices for quantitative problems

  • Use a traffic light matrix for comparing a small set of options across multiple criteria

  • Use a 2x2 matrix to boil an issue down to the essentials

• 📅 Set a deadline: Set a date by when the decision needs to be made, schedule the meeting, and then work backwards from that to prepare

• 💬 Communicate the decision and rationale: People need to know about the decision in order to follow it, and need context so they can get behind it

• 📝 Document the decision: Create a written record of what was decided & why so it doesn’t constantly get reopened. If there are a lot of important decisions, create a tracker for easier reference

---

Popular decision-making frameworks used by top companies

The guide above is a collection of tactics that have worked for me working in tech companies of different stages.

While it’s not based on a particular formalized decision making framework, there is material overlap with some of them. Below, I’m giving an overview of some of the most commonly used ones.

Note: Using formal frameworks like this is typically only a good idea once your org reaches a certain size and level of complexity, and you’ve exhausted other methods of creating clarity (e.g. simplifying the org chart).

For example, Uber only introduced RAPID shortly before the IPO when it became clear that the more informal approach it had applied so far wasn’t working anymore at scale.

Frameworks that help you work through a problem & make a decision

S.P.A.D.E.

S.P.A.D.E. stands for Setting, People, Alternatives, Decide, and Explain. Gokul Rajaram developed and popularized this framework while at Google, Facebook and later Square.

• 🎯 The very first step (not even part of the acronym) is to classify the decision by urgency and importance. Only use the framework for important decisions

• 🖼️ Next, you establish the setting (what, by when, and why)

• 👨‍👩‍👦‍👦 Once you have that laid out, you need to include the right people

  • 1) decision-maker (this person is accountable for the outcome and responsible for execution)

  • 2) approver, and

  • 3) consultants (give input); you should consult as many people as possible

• 💡 Then, you lay out alternatives. These should be feasible, diverse and comprehensive (AKA “MECE”). This should be done via a public brainstorm

• ⚖️ Finally, you decide on the best option (you can hold a private vote beforehand if you want)

• 💬 Once you’ve made your decision, it’s time to explain it. First, you hold a “commitment meeting” with the approver and consultants to get their buy-in. Then, you broadcast the decision to the wider company.

Further reading:

• Gokul Rajaram’s S.P.A.D.E. toolkit

• S.P.A.D.E. template

• S.P.A.D.E. log

• S.P.A.D.E. example #1: ATS selection

• S.P.A.D.E. example #2: Feature naming

Coinbase framework

Brian Armstrong, CEO of Coinbase, walked through how Coinbase makes decisions in this Medium post.

The three key steps are:

1. Set the parameters

2. Deliberate

3. Decide

Step 1: Set the parameters

Define what is being decided, by when, by whom etc.

One unique thing about this framework is that it includes a date by which the decision will be revisited (at the earliest). A neat idea you might want to use even if you don’t apply the whole framework.

Source

Brian Armstrong recommends to get input from 3 - 8 people (in contrast to S.P.A.D.E. that encourages to consult basically everyone).

Ideally, those input providers should represent all teams affected by the decision.

Step 2: Deliberate

Source

You get everyone in a room to share information, brainstorm options and vote. The framework suggests doing one round of voting after collecting all options and data, and a second round after discussing pros and cons to see if anyone could be convinced.

Step 3: Decide

The last step is that the decision maker decides, communicates the decision, and documents it.

Source

Frameworks that mainly clarify roles & responsibilities

RAPID

Many companies, including Uber while I worked there, adopted this framework.

The acronym stands for: Recommend, Agree, Perform, Input and Decide. Its main benefit is to clarify roles during the decision-making process to avoid going in circles.

In chronological order, the decision-making process with RAPID works like this:

Source

• Input: Multiple parties provide input (subject matter experts, the party responsible for execution etc.)

• Recommend: The Recommender drives the process and makes a recommendation (that's where most of the work happens)

• [Optional] Agree: A designated person makes sure the recommendation meets certain requirements (e.g. Legal)

• Decide: One person is responsible for making the decision

• Perform: One person / team implements the decision

DACI

Similar to RAPID, the main purpose of DACI is to clarify the roles in the decision-making process:

• Driver: The person who is in charge of making the decision happen by the date it needs to happen. I.e. they manage stakeholders, organize meetings etc. to make sure the process stays on track

• Approver: This is the person who ultimately makes the decision

• Contributors: These are the subject matter experts that provide input

• Informed: The people who need to be in the loop because they’re affected by the decision (but don’t have a say)

---

---

💼 Featured jobs

Ready for your next adventure? Here are some of my favorite open roles, brought to you by BizOps.careers (sorted from early to late stage):

HeyGen: Special Projects | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: SF / Palo Alto / LA / Toronto | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $150k - $160k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 2+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series A | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: Thrive Capital, Benchmark, BOND

Blackbird Labs: Market GM - San Francisco, CA | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: San Francisco | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $200k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 5+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series A | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: a16z, Union Square Ventures

Inworld AI: BizOps Lead - USA | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: Mountain View, CA | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $170k - $210k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 5+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series B | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: Lightspeed, Kleiner Perkins, Founders Fund

Anduril: Chief of Staff, Software Platform | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: Costa Mesa, CA | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $190k - $285k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 8+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series D+ | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: a16z, Founders Fund, Thrive Capital, General Catalyst

OpenAI: Strategic Finance Generalist | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: San Francisco | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $210k - $265k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 7+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series D+ | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: Khosla Ventures, Thrive Capital, Microsoft

Anthropic: Senior Revenue Operations Analyst | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: San Francisco | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $150k - $190k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 5+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series D+ | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: Menlo Ventures, Amazon, Google

Harvey AI: Business Operations Lead | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: SF / NYC | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $200k - $260k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 6+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series D+ | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: Sequoia, Kleiner Perkins, Google Ventures

ScaleAI: Business Operations & Strategy Manager | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: San Francisco | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $160k - $200k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 4+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Series D+ | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: Index Ventures, Founders Fund, Coatue

---

📢 What I’ve been up to

I recently wrote a guest post for

SeattleDataGuy’s Newsletter

on “How to become the data expert everyone wants to work with”.

Over the last decade, I’ve been on both sides of the collaboration between data & biz teams. During this time, I have noticed a few key patterns that distinguish those working in data that drive outsized business impact from those that don’t.

This article covers 5 skills that I think will help you stand out. Check it out and give the newsletter a read in general;

SeattleDataGuy

puts out some of the best data-related content you can find.

---

📚 What I enjoyed reading this week

• 35 by

  Erik Torenberg
  : 35 pieces of advice for his younger self (that anyone can benefit from)

• Engineer to CEO in 3 years: These key lessons got me there by

  Petti
  &
  Jordan Cutler
  : Three key lessons for accelerated career growth

• Memory in AI Agents by

  Kenn So
  : An insightful discussion of how memory can help improve the performance & user experience of AI agents, and what it takes to make this happen on the technology side

• How to feel bad and be wrong by

  Adam Mastroianni
  : A good read on how our mind tends to substitute hard questions with easy ones (and why we should try to push back on this every now and then)

• Same Data, Different Questions by

  Anastasiya Kuznetsova
  : Great illustration of how presenting the same data in different ways can spark and answer different questions for the business

• Why The Algorithm Hates You by

  Tommy Blanchard
  : A fun illustration of sampling bias in action