the challenge of not making a decision

the worst decision you can make is not making one.

I've seen indecision slow teams down more than bad architecture or tech debt ever did. it rarely looks like a problem. it looks like "let's think about it a bit more", "we need more data" or "let's revisit next week".

#what "pending" costs

say the team has to pick between two API designs, and the answer is "let's get more input". here's what usually happens next:

• engineers build around the uncertainty and add abstractions just in case
• half the team assumes one design, the other half assumes the other
• the PR sits open while everyone forgets why it exists
• three weeks later the same meeting happens, with less context than the first one

the expensive part was never the choice. it was the limbo.

#speed is a small team's edge

big companies have more people and more money. what they don't have is speed: every call goes through approvals and committees.

a small team can ship in a day what takes them a quarter, but only if someone decides to ship.

I once watched a team spend weeks on Postgres vs MySQL. the feature that mattered would have run on either.

#tempo

one fast decision is easy. making them every week, across the whole team, for years, is the hard part.

Steve Blank calls this tempo: making quick decisions consistently over a long time, across the whole company, and not only at the top.

#most decisions can be undone

Jeff Bezos splits decisions into two types. type 1 can't be undone: you walk through the door and it locks behind you. type 2 can: you walk back out.

most teams treat every decision like type 1, but most technical ones are type 2:

• React or Vue? you can migrate.
• REST or GraphQL? you can version the API.
• microservices or a monolith? you can split or merge later.

undoing a type 2 decision almost always costs less than not making it. Bezos ties slow decisions to day 2 companies, the ones on their way to irrelevance.

#decide at 70%

in his 2016 letter to shareholders, Bezos says most decisions should be made with around 70% of the information you wish you had. wait for 90% and you're probably late: the context changed, or someone else shipped.

the other 30% you learn by shipping, not by analyzing.

#limbo hurts morale too

engineers want to build. when a decision hangs for weeks, people stop proposing bold ideas. why bother, if it ends up in a committee anyway?

the best engineers I've worked with would rather have a clear wrong direction than none. a wrong direction can be corrected. no direction just drifts.

#what deciding well looks like

• set a deadline. "we decide by Friday" beats "let's keep discussing".
• give the call to one person, not a committee.
• when unsure, ship something small and learn from it.
• once it's decided, commit to it, even if you disagreed.
• if it turns out wrong, change it, and nobody gets to say "I told you so".

#standing still is a choice

waiting feels safe because our brains see more risk in acting than in not acting. that's status quo bias. but at a startup, waiting is a decision too: you chose not to move while everything around you does.

when you decide, you might be wrong. when you don't, you're definitely standing still, and at a startup that means falling behind.