How to make Intentional Decisions

Getting teams to get to the point

Over the years, I’ve run a lot of complicated teams and projects. I was Google’s Chief Architect of Social in the Google+ days, I’ve run giant search engines and planet-scale storage systems and legal departments and security incidents, and in general I’ve had to herd more cats than I could easily count. In the process, I’ve found that good decision-making methods can really make all the difference.

What do I mean by “good?” I mean methods where —

• Ideas from everyone get heard, not just a few people;
• Going from “wacky idea” to “we’re actually doing it” is easy, encouraging good plans to be adopted;
• Conversely, it’s also easy for anyone to raise red flags and be heard — which is particularly important with decisions that might affect people who aren’t in an easy position to speak up;
• There isn’t any confusion about what we’ve actually decided to do; and
• If we need to revisit a decision later, it’s easy to do so, and understand why the original decision happened the way it did so we can see and focus on what’s changed.

This is the way I approach it — a method I call “Intentional Decisions.”

(Many thanks to Shauna Wright for not only helping me name this, but teaching me how to name things in general!)

Intentional Decisions

This is a method I’ve used in everything from very formal contexts (project planning at large companies) to very informal ones (making complicated plans with groups of friends). The level of formality varies, (intentionally, as we’ll discuss below!) but the basic principles stay the same.

The key role in an intentional decision is the “coordinator” — the person who’s making sure the decision gets made. It’s always part of a team leader’s job to do this, but there are plenty of situations (like groups of friends) where there’s no leader, but someone can still step up to coordinate making a particular decision. Formal authority is definitely not required.

The process basically has three steps: someone has an idea and writes it up; the coordinator drives a discussion to figure out if there’s any reason not to do it, making sure all the relevant voices are heard; and then the decision is announced and people can get to doing. It’s not complicated, but there are important details to each step.

1. From idea to writeup

Someone says “hey, wouldn’t it be neat if we (something) .” My response is “Cool idea! Can you write it up so we can all be on the same page about exactly what you’re thinking?”

The write-up serves a few purposes.

• First, it’s a chance for the person to think through and clarify their own ideas — sometimes, people get halfway through writing it and realize they don’t like the idea after all, and other times, they think of a bunch of improvements.
• Second, it makes it easy for everyone to be sure they’re discussing the same idea. I’ve seen spectacular disasters unfold when everyone had a slightly different interpretation of what they were agreeing to. Having it on paper (or on electrons) simplifies that.
• Third, it makes it easy to collaborate even if everyone isn’t in a single room at once — very useful in a globalized, distributed age. That also includes collaboration across time, such as when you’re trying to come back to a question or idea later.

In a more formal work context, I often create template docs for people to use when writing up ideas. These templates are very simple but serve two important functions in a larger group:

• First, putting everything in a common format makes it easier for people to read a bunch of ideas and not have to figure out where each writer put their key concepts.
• Second and more importantly, the template allows me to make sure that the most important questions about the idea that would allow us to talk about it are addressed.

Usually, my template just has three questions: What problem are we trying to solve? Who is it that has this problem (and do they agree that this is the problem)? And what is the proposed solution?

This may seem like a kind of simple thing to make a template for, but you would be shocked at the number of times I’ve seen people invest years of work and tremendous resources in a project only to realize they were never quite clear on who their customer was or what the goal was to begin with. Very simple questions are helpful, and a template nudges people towards them.

2. We discuss

The coordinator’s main job is to make sure that a conversation now happens. The basic question is, “can anyone think of a good reason why we shouldn’t do this?”

At this stage, it’s critical to ensure that everyone speaks up, and this is the coordinator’s job.

• Who are the people who might be affected by this decision? Are all the stakeholders involved?
• If we’re trying to solve a problem for someone other than ourselves, have they confirmed that this is actually a problem they want solved, and that the proposed solution would do what they want? (I can’t emphasize enough how important this bit is, especially if the people affected are very different from the people planning. If you think you know what someone needs better than they do, you are almost certainly wrong.)
• Are there people around (in the team or nearby) who might have an important thought but aren’t speaking up for some reason? Go out and explicitly solicit their opinions. My own worst mistakes have come from skipping this step.
• Are there subject-matter experts (SME’s) whose eye is needed? The thing about avoiding disasters is that what you don’t know very much can hurt you, so having specialists give an extra eyeball is very useful.

Note: In a formal context, I tend to make the list of SME’s to consult part of the template, and even have process to ensure they signed off. This is because missing an important input can lead to major disaster, and because individual teams may have incentives that don’t align with the organization as a whole — e.g., being rewarded for launching something even if that launch costs the company badly down the road — and so may skip talking to an SME who’s likely to raise concerns. Formal process is a way to check that.

Even though the question is framed as a negative (“why not?”), that doesn’t mean you should use it to steamroll people with “silence = consent;” the goal of the negative framing is to bias towards making ideas come to life, not to ignore people. If you (as coordinator) are suspicious that someone’s lack of comment is from lack of attention or lack of understanding the significance of something, it’s on you to make sure that there is genuine agreement going on. Otherwise you’ll be left with a “false consensus” that people are trying to back out of later.

Collect each objection, and lead a conversation (over whatever channel is appropriate) about each, again focusing on drawing out everyone’s opinion. There are basically three possible outcomes for each issue raised:

1. The group realizes “crap, that’s a problem!” and the proposal is abandoned. A useful lesson has been learned and disaster averted.
2. The proposal is updated — some ideas changed, new things added, etc. The issue that led to this should be called out explicitly in the doc, so we don’t forget why those things were done later!
3. The group concludes that this was a good question to raise and, on inspection, it isn’t a problem after all. In this case, add the issue raised and the key bits of this discussion to the document — that way, if it comes up again, you don’t have to repeat the conversation.

During this phase, it’s good to nudge the team to refine the proposal. Add details about how it’s going to be done and by whom, and get comment and agreement on that part, too.

3. Make it so!

Once this has happened, that’s it — there’s no need for further messing about. Announce that the proposal is accepted, broadcast that out to everyone affected, and start executing. The announcement is people’s license to proceed.

If you’re in a group that has formal tracking of “what we’re doing,” resource allocation, or the like, now is the time to update it.

That’s it. That’s the whole process.

Why this way?

This entire process was designed by trial and error, but it has some repeated ideas in it.

• Soliciting feedback and input actively — so you get people’s ideas, so that you don’t miss something, so that everyone feels they have a voice and thus has reason to come up with ideas.
• Being very explicit, so that there’s never confusion about what’s on the table or what happens next.
• Making “yes” easy so that people can easily experiment and iterate.

The levels of formality can vary; in my experience, the more formal structure is useful when so many people are involved and making decisions that repeatability is useful, mistakes are inevitable, and process helps avoid both. So among a group of friends there’s no need for templates, but if I’m running a team of even a hundred people they’re great, and for a thousand people they’re completely essential. It’s also useful for me as a coordinator — if I’ve got twenty pending decisions, I can easily list them, know which state each one is in, and jump from discussing one to the other.

(There is always a challenge when introducing formality to a group for the first time, because many people are afraid that process means paralysis. In my experience the way around this is to simply do it, and show them that it doesn’t mean that at all. After all, Formula 1 pit crews have very detailed processes, and they would not go faster without them.)

None of this is magic; most of it is just common sense, mixed with the scars of having screwed this up in various ways over the years. But I find the method is easy for teams to understand, and it’s easy for people to grasp its value once they’ve been through it a few times. And if you’re trying to get things done, it can really simplify your life.