SOCCR: the framework I use for decision briefs

In my previous article, I wrote about gathering consensus before a big decision. A couple of folks asked for more detail about how these consensus-gathering and decision briefings actually work, so here goes:

There’s a structure I use when I need to write a decision briefing. It’s a five-part decision briefing structure:

1. Situation: what are the basic facts and background that bring us to needing a decision?
2. Options: what are the potential things we could do?
3. Criteria: the ways/criteria that I’ll use to compare these options
4. Comparison: the actual nitty-gritty of the comparison
5. Recommendation: my final recommendation

I use the acronym SOCCR to remember this format.

I’ve been using this format for over ten years, and it works for me. In writing this post, I tried to figure out where I learned it, but Google turns up nothing! I think perhaps it may have originally come from this episode of Manager Tools, except that presents a slightly different model (SOCRR). Perhaps I started with that MT model and modified it for my personal use?

Ultimately, it doesn’t much matter. There are many other good models one could use - my friend Craig recommends Barbara Minto’s SCQA. For me, the useful part is having a framework that guides my thinking and helps communicate it effectively. All models are wrong; some are useful. This is my model, hope it helps.

A running example

To help illustrate what this looks like in practice, I’m using a fictional example from work. Imagine that one of our startups is starting to gain traction, and we need to bring on dedicated engineering staff to help them deliver. Throughout this post, I’ll show slides from the deck I’d make if I were giving a decision briefing on this event.

Slides aren’t the only way to present this information - a narrative written document is common, too. However you do it, it’s very important to have some sort of written collateral so that you’ve got something concrete to share as you gather consensus and then ask for a final decision. A written document helps others prepare and understand your proposal; it ensures that the decision is documented so you can look back on it later; and without a written document, you risk not communicating as clearly as you’d like.

Situation

To begin, explain the situation and background, as objectively and succinctly as possible:

Your goal here isn’t to make an argument (yet); you just want to describe where we are and how we got here. The goal should be to explain the situation such that nobody disagrees with your explanation (even if they’ll disagree with the comparison and recommendation to come).

(Sometimes it’s useful to telegraph the ultimate recommendation right at the beginning. See below for a discussion of when to do this.).

Options

Next, lay out the options you’ll present and compare:

It’s usually a good idea to present maintaining the status quo as an option (as I do above). Organizational inertia can be very powerful, so organizations can sometimes default to “no action”. This often feels less risky than making a solid choice, but often “do nothing” is a actually the riskiest choice! Presenting “no action” as one of the options forces an explicit choice, and not a quiet default.

It’s important not to overwhelm people with too many options. A briefing where you present a dozen different options is likely to get out of hand quickly. There’s no hard and fast rule about how many options is too many, but, for me, if I’m getting up above five or so options it’s probably a sign I need to work harder to distill things down to fewer reasonable choices before asking for a decision.

Finally, remember that whatever choice is made, you’re going to need to get behind it! You should be able to make a compelling positive case for any of the options you present. If there’s an option you can’t support, don’t present it¹.

In the case of the example above, while I’m eventually going to recommend Option 2, hiring a team, I’m perfectly comfortable with the other options. I can explain exactly why we would and wouldn’t choose each one, and I’m prepared to implement any of them.

Criteria

Next, I like to explain what criteria I’ll use to compare these options:

Some common criteria are:

• cost
• effectiveness
• time / speed of execution
• relative degree of difficulty
• risk (security, financial, operational, technical, etc.)
• quality of results

Sometimes, criteria and comparisons can be collapsed into a single step. If the criteria are fairly obvious and non-controversial, and if you’re trying to be as succinct as possible, you can just present the comparison and criteria together.

But, if the decision is likely to be somewhat fraught, I find it really useful to separate out the criteria from the actual comparison. This helps the content slowly build from objective towards subjective, from facts that everyone can agree on slowly towards the more contentious parts. Each steps builds on an agreement from the last: e.g. if stakeholders don’t agree on the criteria, they almost certainly won’t agree on your comparison. So, unless the decision is fairly easy, I’ll present the framework for comparison before the actual comparison itself.

Comparison

Now we get into the meat of things: given the criteria from the previous step, show how they apply to each option. Usually, this is in the form of a table:

You should still try to be even-handed at this phase – remember that if you’re doing this correctly each option should be one you can find reasons to get behind – but it’s sometimes inevitable that you’ll start telegraphing your recommendation at this point. E.g., if cost is one of your main criteria, and your recommendation is based on one option costing a whole lot less, it’ll start being clear that you’re heading that way. That’s fine, but it’s still important to present all the options fairly.

Recommendation

Finally, make your recommendation:

This, finally, is where you propose your specific course of action, and give a brief explanation about why. This is the moment to be assertive and direct about your opinion (unlike the previous sections, where your goal is to be as fact-based and non-opinionated as possible). If you’re a person who has a tendency to use minimizing speech patterns, try not to do that here. E.g., say “we should choose option 2” instead of “I think we should probably choose Option 2”.

The recommendation is the part that can be the most nerveracking, but if you’ve pre-wired the meeting correctly, you should have a pretty good idea of how it’ll be relieved. You should know you’ll have support, and be prepared to answer questions and objections.

But should you BLUF?

In most cases, I’m a major proponent of BLUF — “Bottom Line Up Front” — in which you present your conclusion first, then rewind and explain how you got there. (Think of it as the inverted pyramid of business communication).

You’ll notice, though, that my example in this post holds off on the recommendation until the very end, a violation of the BLUF principle. Why? Well, when dealing with decisions where there are several tradeoffs and many stakeholders, this format where you build from agreed-upon facts up to a final recommendation is very useful. The SOCCR structure introduces any potentially-controversial parts slowly, step-by-step, and helps make sure you get to the recommendation part without getting derailed. And remember - your recommendation shouldn’t be a surprise to anyone because you pre-wired, right?

But, some of the time, holding off on the recommendation until the end can feel needlessly coy. In some cases I will talk about this in a BLUF-style. I might open by saying something like:

NewCo has several contracts lined up, and needs to staff up to meet those milestones. I’m going to recommend that we hire a team of 3-4 engineers to support this effort. Let me explain…

… and then get into the rest of the briefing.

But I’ll only do this in a few circumstances:

• If I expect the decision to be relatively non-controversial, and I’ve already got near consensus on my recommendation.
• If the decision is mostly mine to make – i.e. if I’m mostly briefing other stakeholders for their awareness and feedback, but where I expect to be able to implement any plan I choose (within reason).
• If I know I have a lot of trust from the group of stakeholders. If I have strong relationships with everyone I’m briefing, and there’s strong shared trust, the cautious nature of the slow build to a recommendation isn’t as important.

So, while I generally recommend BLUF-style communication as the most effective way to communicate at work, decision briefs are a notable exception.

Wrap up

This was a long post – longer, in fact, than most decision briefs I write! There’s a reason I like to use slides as a written document for these things: the constraint of 5-7 slides and not a lot of text pretty closely matches the level of effort these usually require.

Remember that the real work here is the consensus gathering exercise; if you skip that part it doesn’t matter how fancy your slides are.