Rapid decision making for startups

As an Engineering Manager, my favorite compliment is when someone comments on how much we've built with such a small team.

It’s usually followed by "How do you do it?"

Well, we're pretty efficient at Threads. Our platform helps makers on the team quickly align on decisions, and then protects their time to stay in flow.

In this thread, I'll cover how we make decisions quickly as a startup.

What makes a decision "good"?

We make dozens of decisions every day across product, design, and engineering.

With hindsight, some decisions turn out "good" and some turn out "bad."

The good decisions were usually the ones that included the most research and insights.

The bad are usually the ones you had to revisit, because your team found issues, blockers, and edge cases later.

To make a good decision, you need to include more people in the decision.

With more people you get more historical context, data points, and perspectives. You uncover cross-functional issues faster. And no one feels surprised by the decision or blocks you later.

Why does it take so long to make a good decision?

The more people you include, the longer the decision takes.

• With more people, you have to coordinate calendars. The first free time slot might be days from now.
• You’re not sure who has relevant context or blockers, so you over-invite people.
• During the meeting, 80% of people don’t contribute; they just listen. You want to hear from everyone, so you schedule a follow up.

So how do you include more people and still move quickly?

1. Start as far left on the graph as possible
2. Find the minimum number of people who need to be included in the decision
3. Use their time as efficiently as possible

Here’s how we do it at Threads

1/ One person writes a problem statement and a very rough proposal. We call it a 33% thread, since the idea is very incomplete at this point.

I might write 3-5 of these threads a week. Some have 1-2 blocks. Some are structured proposals.

2/ They then publish the thread to the team. They’ll @mention people who they know have relevant context or interests.

3/ Over the course of the next day, anyone who would care about the problem and proposal get to read the thread. If they have feedback, ideas, or blockers, they'll comment on the thread.

Basically, people self-select themselves as relevant. As the decision driver, you don’t have to guess who you need to include. You don’t need a meeting with everyone. You don’t need to coordinate calendars.

4/ Now that you know everyone who has some stake in the decision, you iterate with them until you address the biggest concerns:

• We typically do this part over synchronous communication like a voice chat or video call. You can hash out the nuance of ideas and objections quickly this way.
• Since the group is much smaller and more focused now, synchronous communication works well here.

Finally, we share the discussion, notes, and finalized proposal in a thread. Again, everyone has access to all the information now.

Why is this fast?

It’s fast because at each step:

• you minimize the number of people involved
• you communicate with them efficiently, using sync or async where appropriate

The process works well for us, as a startup. Overall, it takes less time than waiting for everyone's calendars to free up.

We also save time, because we uncover the cross-functional blockers and issues extremely early in the process.

Often, people don't have substantial feedback. The crucial part is that you gave them the opportunity to leave feedback. You never revisit a decision because someone didn't get a chance to chime in.