Making Decisions:

First decide how to decide: “one weird trick” for easier decisions

In my previous post I wrote about a common decision-making framework that doesn’t work. This which naturally leads to the question: “ok, what does work”? So, I’ll put my money where my mouth is and describe a decision-making process that I’ve seen be effective. This process, which I think of as the “Dogwood Decision-Making Process”, is a “document-discuss-decide” process that I called for at the end of part 1.

The most important part of this process — its “one weird trick”, if you will – is the way it includes a “how shall we decide?” step. This separates out the meta-question of the decision-making process from the decision itself, which (I’ve found) makes decisions much easier. The rest of the process is relatively straightforward and obvious – document the proposal, identify stakeholders, discuss, decide – and can easily be tailored to various organizations and types of decisions. But this “trick” of deciding-how-to-decide is so useful that it forms the centerpiece of nearly every decision-making framework I’ve helped build.

Background

I first encountered this framework at Heroku, in the “Dogwood” project. “Dogwood”¹ was the codename for what eventually became Heroku Enterprise. When that project started, it was deeply controversial: there was broad agreement that our current architecture wasn’t working for many use cases, but there was very little consensus about why, what to do about it, technical direction, and so on.

At the time, Heroku’s decision-making process was more or less an RFC process, which wasn’t working super-well for many of the reasons I wrote about previously. I think there was a realization that without clear decision-making, Dogwood would stall, and there was a strong desire to keep moving. Thus, a new decision-making process was developed for Dogwood. (I’ve long since forgotten who specifically was responsible for creating this process, and where (if anywhere) they drew inspiration. If any of my former collegues are reading this and know, please reach out so I can properly attribute!)

Since then, I’ve used a variant of this process – and in particular its one weird trick – everywhere I’ve needed to build a decision-making framework. I’ve made a number of changes over the years, but I’ll always think of this as “The Dogwood Decision-Making Process”.

“One Weird Trick”: Decide How To Decide

The heart of this process – the move that I think makes it work so well – is that in includes an explicit step to first decide how to decide. That is: when a decision appears that it’ll be controversial or difficult to make, instead of immediately starting to discuss the matter at hand, the stakeholders first come to an agreement about how they’ll eventually decide. In fact, this happens twice: first at the macro scale when the organization agrees to adopt this process overall, and then in the micro scale, for each individual decision.

This “decide how to decide” step can seem a bit too “meta”, a bit too “process for process’s sake”, but I’ve seen it work, over and over again. It seems to really help people feel comfortable with the result of a decision, even if it wasn’t the one they advocated for. They can feel comfortable with the process, regardless of the outcome.

The Dogwood Decision-Making Process

When you identify that a decision is going to be complex, controversial, difficult, or otherwise will require some discussion, the steps in this process are:

1. Document the proposal. I don’t think the format here matters much, but having some sort of template to help guide people is helpful. This is the part that can most closely follow the RFC format, if that’s a context and background that people have and want to bring to bear.

2. Share the document with a guiding group – typically a group of Staff+ engineers. This group is responsible for guiding proposals towards resolution. They may also be the group that makes decisions, but not always; their main responsibility is ensuring that proposals are considered and decided upon in a clear and timely manner. I’ll call this group an “Architecture Board”, probably the most common name I’ve seen orgs use for this kind of group. I don’t always love the “architecture” term, sometimes it implies a level of organizational abstraction I find counterproductive, but that’s a different blog post. “Architecture Board” is good enough for this one.

3. The Board and the proposal author identify the correct list of stakeholders. I tend to like to use a RACI matrix here, but that’s a relatively unimportant detail. The key is that this group of stakeholders include enough people with enough organizational power to really make and implement the decision, while also still being minimal enough to avoid a “too many cooks” situation.

4. Apply The One Weird Trick: the stakeholders agree on how the decision will be made. My favorite version of this is that the stakeholders appoint a single decider: the one person who will listen to all points of view, try to synthesize something as close to a consensus view if possible, but ultimately make a clear decision. I’ve found it’s pretty easy to get a group of stakeholders to agree on a person they can trust to make a decision – much easier than making the decision as a group directly. But this could also be something like “Architecture Board has a vote”, a defined consensus process, “the CTO always decides”, and so on.

   Critically: however this decision gets made, it needs to be set up to have “teeth”. This means that between the stakeholders, “decider”, and/or the Architecture Board, there needs to be enough organizational power to actually move the decision forward. So for example, technical proposals almost always require implementation time, so this group of decision-makers needs to have the organizational power to direct engineering time! What this means is going to differ across different organizations. It might mean including engineering management or project/product management; it might mean that a Director/VP needs to be the “decider”; it might mean that the Architecture Board has enough clout to direct engineering resources themselves.

   This process only works if the decision-makers have the power to follow up and see that the work gets done.

5. A feedback and discussion period. All identified stakeholders need to be consulted here, and their feedback taken into account. You can include a mechanism for input from the broader organization if you feel you need it, but that feedback should be discounted the further the person is from the impact of the decision.

   My preferred technique is to have the discussion in the open and in writing (e.g. a GitHub pull request, Slack channel, Notion doc, etc.), invite anyone in the organization to follow along, but require that feedback get routed through one of the identified stakeholders. That way there’s a mechanism for feedback from people who aren’t key stakeholders, but there’s a little friction and filtering to keep it from becoming a free-for-all. I find this strikes a good balance: it allows for some transparency and openness around decisions, but avoids stalling the process.

   Critically, this discussion period should be time-boxed. I suggest no more than two weeks, but choose a time window that makes the most sense for your organization. It’s of course OK for stakeholders to agree on a longer window at times, but open-ended interminable discussion doesn’t work.

6. The decision is made based on the previous agreement. So the decider decides, the board votes, consensus blocks are resolved, whatever.

7. Make it so: the work begins.

I know this is more of a sketch than a fully-defined process, but my hope is that if you need a better decision-making process there’s enough of a skeleton here for you to fill in the details you need for your org.

Another great-sounding model: Navigators

But if it doesn’t, here’s an alternative: as I was writing this piece, Will Larsen published a piece about a decision-making framework he uses: Navigators. It shares a couple of things in common with the Dogwood model, but also differs in some key areas – in particular, it does away with a single Architecture Team, for reasons Will explains and that I mostly agree with. I haven’t used this model, but I respect Will highly, and imagine that if it’s working well for him it probably will for you, too.

I’ll close with this: there are few things more morale-destroying than organizational indecisiveness. Yes, it’s important to make good decisions, but I think we often over-value correctness and under-value speed. Most decisions aren’t actually all that consequential; most mistakes can be recovered from. It’s better to build a process that can reach good-enough decisions quickly than one that reaches for perfect decisions but gets bogged down.

So however you accomplish it, if you want to be successful, find out a way for your organization to make decisions quickly and confidently.