Throwing an Exception: 3 types of decision and what to do in each case.

Mar 14, 2023

TL;DR:

Decisions you know you can make → communicate.
Decisions you know you can’t make → escalate.
Decisions you’re not sure you can take → give leaders an opportunity to “throw an exception”.

Making decisions is one of the most important activities in business.

Great organisations are really, really good at quickly making good decisions that stick, unblocking progress and enabling teams to move fast. The benefits are non-linear, they compound.

The most frustrating orgs I’ve worked in are those that don’t have a strong decision-making culture. You’ll have seen the symptoms: a tendency to involve lots of people, lack of clarity as to who the actual decision-maker is, requests for “more data” before we decide, lots of meetings/discussions but little progress. Meanwhile, your competitors (who have their shit together) are making decisions and moving onto the next set of problems. They’re pulling away from you.

There’s lots of reasons why orgs end up with bad decision-making cultures (e.g. fear of failure) but one problem I’ve observed is that often people don’t know what decisions they can make, and what decisions they can’t — so they default to the safest option: not making a decision.

But this isn’t a trivial question to answer - it’s hard (often impossible) to write objective, declarative rules as to what decisions a team can make and what decisions they need to escalate.

One solution I’ve seen work really well is to not consider this as a binary thing, and instead classify decisions into three buckets.

Decisions you know you or your team can make.
Decisions you know you or your team can’t make (i.e. you know you need input from leadership).
Decisions you’re not sure you or your team can make.

#1 and #2 are fairly obvious, but #3 is the fun one, and where a lot of things get stuck.

Let’s look at each.

1/ Decisions you know you can make.

These are things you’re confident you have the power, capability, or mandate to decide. You may know it from experience (we’ve made decisions like this before) or because you’ve been told you can (“anything under $10k you can approve on your own”).

In this case, your approach is to make the decision and then communicate it.

Decision-making is inherently exclusionary. Not everyone can be involved, and not everyone will be satisfied. So your job in this case is to communicate:

What was the problem / situation / decision to be made?
What were the options you considered?
What were the competing equities and tradeoffs you considered?
What was the decision, and what’s the rationale for that decision?

In my experience, when there’s objection to a decision, it’s 9 times out of 10 because the objector didn’t understand all the factors used to make the decision. By communicating your process and rationale, those objections fall away. People may still disagree with your decision, but at least they understand it.

2/ Decisions you know you can’t make.

These are things you know you need to escalate up the leadership chain for resolution. This may be because:

Your leadership team has told you they want to make this decision, or;
This is a high-stakes or 1-way-door decision and you want explicit approval, or;
There’s a disagreement you can’t resolve within your team (or between your team and another team) - so you need more senior people to break the tie.

Your approach in this case is to escalate.

Escalation generally involves putting together a document (doc, email, deck etc) which describes the problem, the options, the tradeoffs, and the recommendations of the various interested parties - and then probably having a meeting about it (where ideally the decision gets made!).

Some people see escalation as failure (“we couldn’t figure this out ourselves, we must be bad at our jobs”) - but escalation is good; it’s healthy. If you’re taking bold decisions, it’s inevitable you’ll find conflict. Organisation hierarchies exist to make ever-higher-stakes decisions.

As someone who’s both escalated things, and been escalated to — I can tell you I’d much rather a team escalate early and often than get stuck in the mud, unable to make progress.

Big plug for the Traffic Light Framework from Guy Rosen, which is the best decision-making framework I’ve ever used. It’s especially powerful in escalations where you need to distill a decision down to it’s critical elements to enable a leadership team (who’ll have less context than you) to quickly form an opinion.

The big upside of escalations are that (ideally) you get a clear decision that sticks. The downside is that it takes time and effort.

3/ Decisions you’re not sure you can make.

#1 and #2 are the “easy” options - it’s clear what to do.

But in my experience, it’s not always obvious if you can make the decision, or if your leadership team would want or need a say.

If you get it wrong you either:

Get reprimanded by your leadership team who feel they should have been consulted or…
Waste your time and your leadership team’s time preparing and driving an escalation when you could have just made the decision yourself and moved on.

In this case, I advise my teams to make the decision, but give leadership the opportunity to “throw an exception”.

“Throw an exception” is a term from software engineering. You run some code, but if there’s a problem, the code “throws an exception”; it stops running and triggers something else to happen instead.

Here’s what you do:

Document the decision as you would in #1 or #2 (what’s the problem, what are the options, what are the tradeoffs).
State your “recommendation” — the option you want to go with.
Email this to your leadership team (include a traffic light!)
Tell them you’ll move forward with this decision unless you hear otherwise in some time period (typically 48 hours).
1. If you don’t hear back, the decision is made.
2. If you do hear back, you can go into “escalate” mode.

You would not believe how effective this is!

Teams are empowered to make decisions without everything being a costly escalation.
Leadership is empowered to intervene if they’re worried about the direction the team is headed in.
The team learns, over time, which decisions they can take (#1) and which need leadership involvement (#2).

However, if you’re on the leadership team - you’ve gotta watch your inbox. If a decision comes across your desk that you don’t agree with and you don’t “throw an exception” then you’re tacitly approving the decision.

It’s important to note that this tactic may not work well in every company. You need to be in a culture where teams are empowered to make decisions, and leadership trusts their teams to pull them in where needed (vs where leadership expect to sign-off on every decision). In this case, my recommendation would be to talk to your leadership team and say something like:

We’d like to move faster by talking more decisions within the team. We think this will be better for our customers and our business. We’d like to make sure you’re involved in the big decisions, but for some decisions, we’d like to start emailing you with the decision, and giving you 48 hours to let us know if you disagree. Here’s some example decisions we’d make using this process. Does this sound right to you? Can you give us any guidance of the kind of things you’d like us to escalate to you vs make ourselves?

Then, at first, use #3 (throw an exception) liberally — both to get your team and the leadership team used to it, and so both sides can fine tune their understanding of where line between #1 and #2 really lies.

But in the organisations I’ve worked in, I’ve found this works really well. In very few cases have I or my leadership team thrown an exception — but in the cases they did, it saved significant thrash on both sides.

How do you decide between #1, #2, and #3?

The lines are often blurry - otherwise why would I have written this post! It also depends a lot on your team, what you’re working on, the culture of your organisation, and the trust you have between you and your leadership team. There’s no formula.

And even in cases where there is some objective formula (like the budget example above), there’s sill cases where you may need to move fast (#2 is best) but are outside those rules (#1 technically applies). What if, for example, you need to make an urgent payment out of budget to prevent something breaking, or prevent a security incident? In these cases, #3 is also your friend.

The real answer is: talk to your leadership team. It’s their job to empower you, but their it’s also their job to be responsible stewards of the business. If teams within their purview are acting recklessly, that may not be acceptable to their leadership team.

Conclusion

This is a very simple framework, but in my experience it works wonders. Teams get to move fast, and leadership get a way to ensure they’re aligned with what their teams are doing, without significantly slowing things down.

Next time you’re making a high-stakes decision, offering your leadership team the opportunity to “throw an exception” should help you move faster.

I tried really hard to find a word that meant the same as “throw an exception” that ended in ‘-ate’. Then we’d have had communicate, escalate, somethingelse-ate. But I came up dry. If you can think of a word that fits, please let me know, it would make me very happy, and this blog post 33% better!

Thanks to Shachar Meir and Tim Adnitt for reviewing early drafts of this post and for their excellent feedback.