Operating Principles for Decision-Making

Why decision-making matters

Last year during a retrospective, one of the engineering teams I lead acknowledged that making decisions felt like a slow and often inconclusive process.

Going deeper, we found out that making relatively small decisions within the team had been the most taxing: many people were continuously involved in plenty of conversations, with little gain at a high cost.

This situation led to:

• constant context switch at the expense of focus
• “democratic” decision-making with little-to-no accountability
• inability to take action on an increasingly bigger backlog of problems

Enter “Operating Principles”

In the attempt of changing this situation moving forward, I suggested adopting some operating principles to avoid “analysis paralysis” and encourage more effective decision-making.

As Ray Dalio puts it in his homonymous book:

Principles are fundamental truths that serve as the foundations for behavior that gets you what you want out of life.

In other words, principles allow us to have a guideline for the desired behavior and remove friction from executing on the team’s vision.

Defining the behavior we want to see is the key here, because it forces us into action instead of leaving us stuck (over) thinking.

Personally, I am a big fan of principles and in this article I will share with you what we landed on for our team (a little redacted after some learnings on the way).

Before we jump onto the principles themselves, though, a small note of caution: for these principles to work at their fullest, it is my view that any team has to display a high level of trust. In my experience, when trust is in place, principles and common sense have consistently been a better tool than strict rules. Nevertheless, you milage might vary, so make sure you identify the right moment for introducing principles in your team’s work.

Ok, let’s get started!

#1: Make “2-way door” decisions

As described by Amazon’s CEO Jeff Bezos in a letter to shareholders, “2-way door” decisions are easily reversible, so they can be made quickly and are safer to execute.

2-way door decisions allow us to take calculated risks, so we can:

• Size the value of an idea before committing to a substantial effort
• Take smaller steps we can more easily measure, and possibly adjust our aim as new insights are available
• Learn faster than we otherwise could
• Most importantly, correct the course of action when we reckon we made a mistake without paying the full price for it (or avoiding the endless push forward caused by sunk cost fallacy)

So here’s our first principle:

We strive to make decisions that are reversible (2-way door).

How do you make a 2-door decision? Before committing to something, ask yourself:

• “What are the actual steps I should take to revert the effects of this decision?”
• “If need be, how difficult would it be to go back to the previous state?”
• “How big of a cost (financially or otherwise) am I willing to accept before I admit this was a mistake and go back to square one?”

Keep in mind, a handful of decisions will necessarily be the “1-way door” type: some changes are difficult, time-consuming, or simply costly to undo. When it’s the case, it’s critical to make the decision as explicit as possible, and highlight the consequences we’d face (as well as their order of magnitude) if something was to go wrong.

Risk is usually the main factor in determining the type of decision we are looking at. As a rule of thumb, the bigger the potential consequences of a decision, the more likely the decision-making process will take a longer time and involve more people (and that’s generally ok).

On the flip side: when risk is low, we should act incrementally and fast. Take ownership and make a move. Over time, the return on invest on biasing towards action outshines the cost of making a mistake.

Regardless of their type, great decisions are well documented and timely communicated with relevant stakeholders within and outside the team.

#2: Be an owner

As engineers, in pretty much every scenario, we want to:

• Deeply understand the problem we are solving for our customers and why it matters (i.e. impact)
• Define what success looks like, and how we are going to measure it
• Build a solution that solves that problem, such that is both well-designed and scalable
• Ship it quickly (within reason), possibly in small iterations with a tight feedback loop
• Follow up on its success as per the measurable definition settled earlier on (e.g. is it working? is it generating the expected value? do we notice any side effects?)

While a lot of the initial work of understanding our customers’ needs is often driven or carried out by someone with a different function (e.g. product manager/owner, ops, account manager, etc), engineers are not exempted from getting a thorough understanding of the matter and participating in the conversation that defines the solution we will build.

On top of that, it is our responsibility to push towards the finish line any work we decide to take on as a team. This mindset ultimately translates into being accountable and taking pride in what we do.

This is then our next principle:

We act as owners and, as such, we provide value to both our customers and stakeholders with great care.

#3: Ask for forgiveness, not for permission

Sometimes, it can be scary to pursue an idea that challenges the status quo or simply goes in an unconventional direction. At the humongous scale many companies operate nowadays, even logical actions can take a toll on us when it comes to owning the outcome of what we do (that is, in case something goes wrong).

While intuitively understandable, this kind of fear stands in the way of getting stuff done and achieving significant results. We don’t want to be reckless in the way we execute, though we need the ability to take steps forward confidently when the opportunity arises.

Leaving aside the genuine fear of making mistakes, often people are also doubting whether the wrong move will reflect poorly on their relationship with their lead/manager and impact negatively their growth and career. This is especially true in bigger companies, where there is a more hierarchical reporting structure. As a manager in a healthy company, I can promise you I have little-to-no interest in making a call when I’m not the best person in the room to do so.

As a team we trust each other and we believe everyone is moved by the best possible intentions. Therefore our next principle is:

We do and push for what we think is best, while keeping each other accountable.

In that light, here’s some examples of the behavior we do not want to see:

• Decisions getting postponed because we think only a couple of rather senior/tenured teammates can sign off a given initiative or approve a piece of code
• Lack of a clear owner (i.e. final decision maker) for a certain initiative or action item
• Waiting for feedback or input indefinitely (e.g. because people are “busy”)
• Holding back when it comes to suggesting new ideas
• Not executing a scary procedure because we never did it before

In contrast, these are examples of the behavior we do want to see:

• We provide feedback timely and thoroughly when asked to review a document or some code; if we genuinely can’t, we communicate that we won’t be able to help (also timely)
• When a decision needs to be made or an action needs to be taken, we ask the group for clarity on who will be the owner (and consider volunteer ourselves)
• We remind each other of important commitments and we over-communicate to align on progress and expectations
• We speak our mind openly and share our train of thoughts often — at the appropriate time (e.g. the standup is not a retrospective, the retrospective is not a planning session, etc)
• We ask someone with more experience to teach us how to execute that non-trivial procedure and then we do it often (until we are confident in doing it by ourselves)

#4: Embrace async-first communication

This is a less straight-forward point, so hear me our.

Our ability to concentrate and deliver high-value outcomes is largely affected by interruptions and distractions. In the multi-track, distributed, and chaotic world we live in, it’s fundamental to reduce context switching to a minimum and preserve focus. While we don’t want to disappear from our team’s radar for days going down the rabbit hole of a given problem, we need headspace to concentrate and be productive.

One way to make sure we protect our focus is to increase the signal-to-noise ratio, and we can do that in a few ways:

• Put less on our plate
• Block time to do deep work
• Limit the need for synchronous communication

The last one is especially important: when days are fragmented by meetings and discussions, our ability to find the time and concentration for high-quality, deep work is compromised; let alone be in the headspace to make a sound decision.

So here comes another principle:

We prefer “asynchronous first” communication and protect the focus we need to perform deep work.

Here’s what each of us can do:

• Before implementing any significant change (e.g. an API interface or existing data flows, a new feature, etc), document the idea in a brief collaborative artifact, like a Google doc; circulate it early on, starting with the few key people who can give you the most impactful feedback
• Be explicit about when a decision needs to be made by and share it alongside your document, so people can provide feedback in a reasonable time frame
• Protect the time to perform deep work (e.g. block 2–3 hour blocks in our calendar); make clear when you are going to be available next for code review or synchronous conversation
• Block time regularly to provide feedback to others in an asynchronous manner (e.g. code reviews, feedback to a collaborative document)
• Push back on meetings without a clear agenda or a decision maker
• Avoid attending meetings for the sake of participating: receiving an invite doesn’t automatically mean that you have to accept. You can ask yourself questions like: what is my role in the conversation? Can I actively contribute to it? If not, can I learn something fundamentally useful for me or my team? Will my point of view be represented by someone else who is already attending?

Asynchronous communication is great, though it comes with a few things to watch out for:

• Too many one-off, disconnect documents that require review time but add little value
• Investing time in long write-ups before a quick checkpoint with the team on the need for the document to begin with (e.g. it might already exists, the scope or the “why” is unclear, etc)
• Moving all communication to be asynchronous, losing the human connection among teammates or the effectiveness of a meaningful conversation when a decision is on the critical path

#5: We can improve only what we measure

Oftentimes we intuitively know that a given approach or action is the right one. Nearly as often, we are way off in our ability to forecast, estimate, or predict the outcomes we feel so sure about.

In a world of poorly aimed intuition and gut feelings, we believe that:

Data can give us the confidence to make the right decisions.

There is a thin line between data-driven and data-informed, and we want to always err on the side of the latter. With that said, it’s nearly always possible to come up with at least one metric that embodies the change we want to see. In other words: if our hypothesis is correct, something in the data will change significantly and prove us right (or not change at all, and prove us somewhat wrong).

While statistical significance is a complicated matter, we can simplify our approach by saying that we want any experiment (or initiative) to relate to a KPI (Key Performance Indicator) of some sorts. For that KPI, we want to know:

• The baseline number we start at
• The number representing the goal we are aiming to achieve
• The indicators that we should pause or stop a given initiative (i.e. a so-called “break-glass” metric to limit any negative side effect of our change to real users)

An example could be: “Our web service is handling 2.5k GET operations per second. We believe that we can improve its rate by 20% (i.e. 3k GET ops/sec) by rolling out change X. Our break-glass metric will be the service SLA dropping below three nines on a 24-hour basis”.

The exercise alone of figuring out what could move the needle (and which needle) helps clarify our intentions, and forces us to provide some evidence that we are putting our effort towards high impact actions.

Speaking of avoiding time wasted on the wrong problem, it is critical to have short feedback loops. When the path ahead is not clear, perform first a time-boxed exploratory task (or “spike”) with the only goal of learning what you don’t know. Please note that a spike is not an MVP: any MVP is beyond the exploration phase and not a good path to pursue when we are not sure of the benefits & risks of our actions.

Conclusions

Thanks for reading it all!

Recapping our operating principles for decision-making:

1. We strive to make decisions that are reversible (2-way door)
2. We act as owners and, as such, we provide value to our customers and stakeholders with great care.
3. We do and push for what we think is best, while keeping each other accountable.
4. We prefer “asynchronous first” communication and protect focus we need to perform deep work.
5. We believe that data can give us the confidence to make the right decisions.

Most of these principles and related examples best fit an engineer team’s work. Nonetheless, I believe each principle at its core can be used in many other work functions and even be abstracted to other aspects of life.

Lastly, while none of these principles are particularly novel, they frame the behavior we want to see and have helped my team approach decision-making with more clarity, focus, and confidence.

I hope you enjoyed this article and you are inspired to step back and think in terms of principles whenever you or your team are facing the next problem :)