Durable Decisions

One of my favorite internal posts at Facebook outlined a framework on making sticky decisions. This post is a rewrite of that original "Durable Decisions" post by Ficus Kirkpatrick, in turn based on  ideas and input from Nikhil Chandhok. The credit for the idea and framework go to them; this post is written by me since I have more cycles to write.

Your team needs to decide whether to focus on making your product faster or building a feature that is going to be the next Big Thing. The team follows best practices, does its homework, runs it by you. Decision made. We are focusing on building the feature.

Fast forward two weeks, and you hear rumblings. The star engineer on the team is working on speed. The feature isn't making as much progress as everyone would like. Three weeks in, the team has started to work on speed and drop the feature altogether. It just happened. Four weeks in, the feature is not built, and the product isn't significantly faster either. Oops.

So, what happened? We made a decision four weeks ago. Then something changed. And the decision unmade itself over the course of a month. Can this be avoided? How?

Enter durable decisions.

A durable decision is one that doesn't change if its inputs haven't changed.

Inputs

1. Goals

What are the goals of the project? What are non-goals? Is a project results-bound (done when metric X is at threshold Y?), delivery-bound (done when feature 𝝰 is shipped), or time-bound (done in a month)?

The goal discussion is almost always the right place to start. Disagreements at this phase result in significant downstream thrash. Have precise goals (and non-goals) and write them down.

2. Assumptions

We are baking in many assumptions when we come up with various options. Time, money, technical capability (CPU, GPU, RAM, disk, network), people (how many people, how much bandwidth), this list goes on. 

Assumptions are the second biggest reason (after unclear goals) for decisions to fall apart. People either assumed different things, or those assumptions changed. Exhaustively documenting every assumption is not a good use of time; documenting the major assumptions, those that are likely to break or cause disagreements is a good use of time.

3. Options

Come up with a good list of options, including tradeoffs between them, or the rationale to choose one over another. Take care to not get too attached to one option over another; we are human, and this is natural. A mentor gave me a pretty good trick to get over this attachment. He said: 

You don't understand your opponent's argument until you can argue their points, just as strongly, on their behalf, without them being in the room.

Understand your options thoroughly and *drumroll please* write them down.

4. Decider(s)

Be explicit about who is making the decision: some person, some committee. When things change in the future, you'll want to know whom people should go to talk.

Gathering Inputs

To make a sticky decision, get everyone's buy-in. The best way to get them bought in is to get them involved in making the decision early on. You need to consult people to gather input, to build your set of options, to understand all the assumptions that are being baked in. 

Consult the stakeholders. Talk to everyone that is likely going to get affected by a significant decision. More buy-in at this stage reduces the chances of follow-on debates.

And finally, *surprise!*, Write It Down. Somewhere where everyone can see, read, comment, access. Be transparent, disseminate all your materials widely. Remember: there are going to be people who're not even on the team yet, that will want to know "why did we do X" in the future. This document will explain things clearly, including the conditions, set of choices, and the decision making rationale.

Make The Decision

This post isn't about how to make the decision itself. There are scores of books written on this subject; my favorite is Chip and Dan Heath's Decisive. This book lays out a useful 4 step framework to make sure you're defending against your own biases, considering all the information, and giving your slow brain a chance to think. This post is a good summary, along with their WRAP cheat sheet.

Regardless of the framework or process you use, this is the time to make the decision. You have all the inputs, the assumptions, the options. Make a call.

Communicate, Communicate, Communicate

Communicate the decision: quickly, clearly, and as widely as possible. Repete thyself: people are unlikely to understand everything on the first try. For strategies on effective communication, see "Communication is The Job," by Boz, an excellent communicator and head of AR/VR at Facebook, where he lists out eight strategies he uses.

Did I mention that you should write it down?

From Durable Decisions to Disagree and Commit

The start of this article defined durable decisions. The side effect of making durable decisions is that if the inputs don't change, the decision shouldn't change either.

Often, there will be a set of people that disagree with the decision. It is tempting to grumble about this, let it lie for a bit, and then re-open the debate and revisit the decision at a later point in time, with the hope of overturning it.

If the decider lets a decision by revisited, without substantial new input, the whole system falls apart. 

Even worse, people stop believing that decisions are sticky and put less effort into the decision making process because they know those decisions aren’t final. 

Having durable decisions means that they cannot get overturned if nothing has changed. This principle forms the basis of "Disagree and Commit": you may disagree with a decision but have to be fully committed to making the product/team/company successful by going along with the implications of the decision.

The hardest decisions are typically the closest calls. Knowing that you'll revisit the decision if the circumstances change will give you the confidence to get behind it. We make the most progress when we're running together at full speed, not pulling against each other in doubt.

About

Hey! I’m your host, Rushabh Doshi. After spending nearly a decade managing some of the brightest engineering teams at Facebook and YouTube, I’m taking a break and doing some writing, spending time with my family and figuring out my next thing.

If you enjoy these articles, please drop me a line and let me know. You can find me on Twitter @radoshi. If you’d rather get these posts in your mail, you can subscribe to my newsletter.