How Square Makes Tough Decisions

Explore

Gokul's S.P.A.D.E. Toolkit: How to implement Square's famous decision-making framework
Gokul's S.P.A.D.E. Toolkit: How to implement Square's famous decision-making framework

A technique for making difficult decisions—formed in my time as a Google and Facebook exec, and widely deployed at Square.

A technique for making difficult decisions—formed in my time as a Google and Facebook exec, and widely deployed at Square.

Jonathan Kogan

For ten years and three jobs, I've obsessed over how to make important decisions. A few years ago, my colleagues at Square and I developed the S.P.A.D.E. framework, which has been successfully deployed throughout both Square and Caviar. I've given a few talks about itー

like this one from First Round⁠

ーand now I've compiled this comprehensive guide so you can apply S.P.A.D.E. to your own decision-making, complete with examples, tools, and templates.

A little background...

I always start with the following anecdote: It was 2006; I was working on display advertising at Google. And my team and I were presenting a difficult problem to Larry, Sergei, and Eric Schmidt. As we were explaining, Eric stopped us mid-sentence and bellowed, "STOP. Who is responsible for this decision?" Three of us independently raised our hands, then looked at each other embarrassed. "I'm ending this meeting right now and don't come back until you have a clear decision-maker."

That meeting catalyzed a long obsession with how decisions are made, and a realization that consensus doesn't work.

Consensus doesn't work.

A lot of forward-thinking companies practice consensus. Google is famous for it. But consensus is impractical and ineffective for one clear reason: consensus means no ownership. What is important isn't that everyone agrees, it's that everyone is listened to. And then the right person makes a decision, communicates it clearly, and rallies everyone around it.

When I started at Square, the company surveyed employees about their number one frustration. They said decision-making. And I bet if you survey any company in the Valley, or even the country, you'd see similar answers. It's not the decisions themselves employees are frustrated with, it's the lack of transparency around how decisions are made. And employees crave transparency.

A couple Square colleagues and I decided to come up with a new decision-making framework, an alternative to consensus built on accountability and clarity, where the person responsible for executing the decision would be the one who decides.

Remember: Hard decisions only.

Our framework isn't meant for every situationーit's meant for hard decisions, things that would have real consequence for a company or group. Not all decisions are important. At Square, we used to jokingly call the chart below the "Kombucha scale," which captures two variables: importance and urgency.

⁠

If the choice is as simple as selecting a flavor of Kombucha, everyone can save the time and effort spent on a thorough decision-making process. Once you've established the importance and urgency of a problem, it's time to make a S.P.A.D.E..

Hard decisions need sharp tools: Meet the S.P.A.D.E. Toolkit.

For years I've applied S.P.A.D.E. in Google Docsーwith a separate document created for each decision. Which was fine for rolling out the process initially, but can have some challenges once you start using S.P.A.D.E. for everything (we've completed hundreds!). And over the past year, I've gotten exposed to new tools like

Coda⁠

ー a new all-in-one doc that's been spreading like crazy at Square ー which inspired me to take S.P.A.D.E. to the next level.

Why upgrade the S.P.A.D.E. process? A few things this toolkit can do:

An all-in-one S.P.A.D.E. destination: This doc is structured so you can actually keep all of your S.P.A.D.E.s related to a project together as a record others can quickly refer to, while minimizing crazy sprawl. You can create sections for different discussions, an area for a reminder of the process (this section), a log of past S.P.A.D.E.s, etc. And within each S.P.A.D.E., rather than linking out to the relevant slide-deck or write-up, you can just embed it directly.

Add consistency without sacrificing flexibility: A lot of S.P.A.D.E. is a playbook for how to make decisions, but each stage can be completed in different ways to achieve the objective. For example, I believe it's important to produce an exhaustive list of alternatives, and to find ways to solicit feedback without getting group-think. This toolkit contains a few

Helpful Add-ons⁠

ー small experiences you can include in your S.P.A.D.E. process, encouraging your unique approach to live alongside the finished S.P.A.D.E. result.

I'm really excited to share this updated approach to S.P.A.D.E.. Tools can't make decisions for you, but this one definitely takes some of the guesswork out of the process and removes burden in sharing the result. Let me know what you think!

⁠

S.P.A.D.E.: Setting, People, Alternatives, Decide, and Explain.

I'll walk you through each step, along with their underlying principles and common pitfalls.

S is for Setting

For many, what is the only decision to be made. What product should we launch? What country should we launch in? But focusing on what alone can lead to one-dimensional decision making. In S.P.A.D.E., a Setting comprises three primary dimensions: What, When, and Why. Each requires diligence.

Precisely define the “what.”

You’d be amazed at how many people can't articulate what the decision is in a precise way.

For example, I've seen decisions articulated in the following manner: "The ‘what’ is figuring out the next country to launch in." If you have exactly one product, that’s okay. But say you’ve got multiple products, the 'what' is not just what country to launch in, but what product to launch and in what country to launch it. It's two axes not just one — and if you dig deeper, there’s probably more dimensions to the decision.

Be very precise about what choiceーor set of choicesーyou’re making.

⁠

The

S.P.A.D.E. Template⁠

gives a clear structure for framing the topic.

Note that you can embed relevant materials (e.g. a slide deck) by pasting it in.

Show the why of the “when.”

Open your calendar and get exact. Deadlines can seem arbitrary, even if they aren't. Your decision's when should reflect the timeline itself as well as the reasoning behind it. Why that date? Why that duration? Providing the extra context of when helps decision stakeholders connect the dots between the what and why.

If someone says a decision must be made by October 15th, 2015, why must that be? Does it matter? Say a product needs to launch on November 15th, 2015, and therefore I need its name determined by October 15th. Why? So this name can flow through in the collateral, into the website, and into the app. I need four weeks for that. That logic helps people understand the when, and the ‘why’ of the ‘when.’

⁠

Visualizing timelines can be tricky. Coda makes this easy as you can see here.

Clarify the “why.”

Clearly establishing the why is the key to the setting. Start by asking why the decision matters and defining the value of the choice. With stakeholder priorities articulated, the decision making process can move forward with minimal conflict. It explains what you’re optimizing for and reveals why the decision matters.

I'll give you an example: I'm an advisor to a startup at which the head of product management and the head of product marketing had a massive blow-up. They disagreed about how to price a product. Working through it, we realized the conflict stemmed from a fundamental misalignment around the goals of pricing. The product manager saw it as a way to optimize market share, while the product marketer viewed it as a way to maximize revenues. Neither of them had articulated that, nor had the company’s founder. As soon as we figured out this was the root of the conflict, it became easier to get to the decision.

P is for People

As with everything in an organization, people come first. (PSADE isn't as catchy an acronym as S.P.A.D.E. or we'd call it that.) The first thing you do for every S.P.A.D.E. is identify the people who should consult (give input), approve, and most importantly, a single person who is responsible.

⁠

@mention your decision-making group to notify everyone of their role.

Responsible means accountable.

While some decision-making frameworks separate the person responsible for deciding and the person accountable for the decision, in S.P.A.D.E., accountability and responsibility are combined. The person who makes the final decision is empowered to own both the execution and success of the choice. Similar to DRI, with S.P.A.D.E., the person who's responsible for making the decision is the person who's accountable for its execution and success. Accountability and responsibility are synonymous.

Conversely, you should never make a decision and then hand it down for someone else to execute and usher to success. That person will likely feel frustrated, powerless or disengaged. The goal of S.P.A.D.E. is to avoid that. When the decision maker is both accountable and responsible, it's more fulfilling and empowering.

Consult maximally.

Consultants are people who are active participants in the decision. One of the most common decision-making pitfalls is under-consulting. There are always more people who need to be listened to than you think. Open channels to openly solicit feedback and carve out enough space to consult maximally.

I remember one instance that had to do with the change in policy for how engineers wrote unit tests for software. The decision maker, an engineering lead, had consulted with several of his fellow engineering leads and felt comfortable with his decision. Then he sent an email with the policy update decision to all of Square’s engineers. Within 30 minutes, a dozen people replied, many of them disagreeing vehemently with the decision. To his credit, the lead took ownership. He froze the decision and invited every engineer at Square who agreed or disagreed with the decision to meet with him over the next week. I think a dozen people took him up on it and went to his office hours. A week later, he sent his new decision out by email. Guess what? It was exactly the same decision as the last time. But this time, nobody complained. Why? Because they all had been listened to.

Listening matters much more than you think.

A is for Alternatives

Feasible, diverse, and comprehensive.

Ultimately, an alternative is a view of the world on uncertain things. It’s the job of the Responsible person — the decision maker — to come up with a set of alternatives that are feasible and realistic; diverse — they should not all be micro-variants of the same situation; and comprehensive — they should maximally cover the problem space.

Brainstorm publicly.

Gather all the folks who are in the consulted group in a room and conduct an open brainstorm. This keeps them engaged and injects new alternatives into the conversation. Classically, we would put all alternatives on a whiteboard. Coda lets you capture the brainstorming process in a sortable, votable way.

⁠

Generating a list of alternatives in Coda can be a collaborative exercise.

Use the + button to add a Topic Voting template.

As a discrete set of alternatives start to emerge, I strongly suggest quantitatively modeling out the impact of each one and revisit your Setting — specifically the why, the optimization function. It can be very hard with ambiguous decisions to get down into the numbers, but it’s very valuable to do so. Figure out your value metric, your success criteria.

You see the best quantitative evaluation for M&A (Merger and Aquisition) deals. Why? It's a make-or-break company decision. And corporate development professionals are used to evaluating the sell, buy, and partner scenarios along with the associated economic benefits to the company over five years or ten years. Their job is to consider probability of success, resources invested and opportunity costs.

I try to employ the level of diligence, metrics, and stakeholder engagement as if I were doing an M&A deal. After all, what are big decisions other than a merging of your past and present.

D is for Decide

Once you've laid out all the alternatives—complete with their respective pros and cons and quantitative modelsーit's time to get your consultants to vote.

Get feedback privately.

Difficult decisions can have controversial solutions, which is why casting your vote privately is so important. It ensures the feedback is impartial and not influenced by corporate hierarchy or groupthink.

You can do it by email, Slack, or SMS. Even better, you can do it directly in the S.P.A.D.E. doc by using a Voting Table, filtered so that attendees can only see their answer. Tell everyone to add a line or two with their reasoning.

Then it's up to you to decide.

⁠

Add a sentiment module in Coda using the + button. Hide everyone's ratings until everyone is done!

E is for Explain

Once you've decided, now the real work begins. Go to the approver and lay out the alternatives and your argument. If you created a high-quality decision framework, they're unlikely to veto it.

Call a commitment meeting.

Now call a meeting and explain to everyone your decision. There might be grumbling or disagreements, but this is the moment when you explicitly endorse an alternative, and lay out your reasoning and the implications. The more information, the better.

Then go around the room and have every single consultant say if they agree or disagree. Andy Grove calls this a commitment meeting. When you commit to supporting a decision in the presence of your peers, you're much more likely to support and execute. I've also seen this part done directly in a Coda doc, using an aforementioned "Sentiment Tracker."

Broadcast your decision.

After the commitment meeting, you need to to figure out how next steps will be delegated and executed. The decision maker must summarize the S.P.A.D.E. behind the decision in a one-page document. This brief should be emailed out by the decision maker to the rest of the company or to as broad of an audience as possible. Why? Because the company needs to see what and how decisions are being made.

At Square, we send our S.P.A.D.E. summaries to an email alias, so the whole company can register the framework and see the diligence of decision-making across the organization. By doing S.P.A.D.E. publicly and frequently, you encourage others to confront difficult decisions and share how they made them.

⁠

See the

S.P.A.D.E. Log⁠

section for a way to auto-send these summaries in Coda

Add it to the S.P.A.D.E. log.

Once you've sent a S.P.A.D.E. around, there's one last step: Archive it. Keep a log that links to your S.P.A.D.E. and marks the date of the decision. It will be much easier than relying on Gmail search or Slack when you want to reference or amend a past decision.

⁠

Make a copy and get started!

This doc is meant to be used as a full toolkit - just copy the doc on your desktop and get started! Here's an outline of the different parts of this toolkit:

Apply the framework

⁠

S.P.A.D.E. Template⁠

: to duplicate for each decision

⁠

S.P.A.D.E. Log⁠

: to keep track of all decisions

⁠

Helpful Add-ons⁠

: tools for feedback and collaboration

Example S.P.A.D.E.s

⁠

ATS Selection⁠

: example S.P.A.D.E. for picking ATS software

⁠

Feature Naming⁠

: example S.P.A.D.E. for naming a feature

⁠

Behind the scenes

Take a look at the making-of video:

⁠

👉 Begin with the
`S.P.A.D.E. Template`⁠
section!

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

Gokul's S.P.A.D.E. Toolkit: How to implement Square's famous decision-making frameworkGokul's S.P.A.D.E. Toolkit: How to implement Square's famous decision-making framework