How do you make decisions on a distributed team?

[I'm already publishing a post that violates the 300-word limit. Eh, it was late and I was on a roll.]

For every decision I make, I spend 5x that time enabling people on my teams to make great decisions. Which in turn means I think a lot about how we go about making those decisions.

Our team at Appsembler has been distributed for at least as long as I've been there (over 6.5 years). At some point, we were one of a few companies operating in this mode, so reference material on "how to" was scarce. Nowadays, far more companies operate remotely in part or in whole, so this might seem like old hat. But I thought I'd recap what we've learned about making decisions.

(N.B. These aren't exclusive to distributed teams.)

Record the decision

Starting here because it's the biggest win. Write down the decision in a "decision doc". Use the DACI Framework. Include background info and several options with rationale. Let some discussion happen in the doc, and record the result even if you decide elsewhere (e.g. a meeting).

Writing it down forces you to make the case clearly and helps crystalize your rationale. It shows that you're thinking through alternatives and risks, and gives others a chance to participate in and learn from the process.

Especially in a distributed team, you can't make nor communicate all the decisions in synchronous meetings. A well-structured decision document addresses this gap.

Bonus points for starting a new doc to record an already-made decision, so you have a clear record of the decision you can link to and find later.

(If you're using Confluence, they have a fantastic decision template —— hack it to your needs.)

Consider the introverts

Extroverts (c'est moi) are significantly more likely to end up in management or leadership positions. They're also likely to call for a live meeting to present new information, hash it out, and make a decision. Sometimes this is OK. More often, it's a mistake.

Some folks on your team do better reading information and processing it outside the pressure of a group meeting. They may prefer to write a response. Give them the space and time to do this, and ensure that their "voice" is heard in equal measure to those who dominate the mic in a meeting. Resist the urge to call on them in the meeting, putting them on the spot as a way to "listen" to them. You'll get much better results if you let them read and respond asynchronously.

In my experience, some of the best decision-shaping ideas come from those who blanch at the thought of jumping into the fray of a meeting.

Take time zones into account, but set a clear due date

If you can make a decision quickly while the folks involved are all online, go for it. But more often in a distributed team, you're working across time zones. Working async in a decision doc lets folks contribute when they're online, and when they're at their max energy.

However, if you own the decision, you need to set a very clear due date and enforce it. Make sure everyone involved weighs in, make the decision on time, and then communicate it. Cat herding isn't fun, but it's required to push through an async decision.

Make it very clear who owns the decision

Someone needs to own the decision. I almost didn't include this point, but I'm surprised how often managers overlook it. Particularly in an organization that tends toward collaboration, consensus can feel like the default mode. Without a clear owner, either decisions languish or they default to the highest ranking person involved (see the bonus reminder for why this is a mistake).

If you own a decision, it means you're making the call. You're responsible for gathering input from the involved folks. You're making the decision and communicating it clearly. And you're ensuring it's all documented.

Bonus reminder for execs and managers: Push the decisions as close to the work as possible

Ideally, the folks closest to the work are making the most decisions. Individual contributors, team leads, and managers have plentiful, fresh information and (if you've hired and trained well) sound judgement. They should bear the lion's share of the decision making.

The farther you are from the work (e.g. execs), the more impactful, complex, and risky the decisions you're making are, but you're making far fewer of them. In order to make these critical decisions well, you need to delegate the rest.

Search your feelings

I can sense you resisting. This feels like a Big Company approach. Writing it down takes so much time. You're small, you're nimble. You just make decisions on the fly and move. If the outcome of a decision matters to them, people will find it out.

That's fine for small decisions with low or localized impact. But decisions that have broad, longer-term impact need to be written down. They need some discipline.

Give this approach a try, and stick with it. You'll find it becomes second nature and boosts the quality and speed of your decision making.

Other reads on decision-making: