Err Toward Deciding

I've spent a fair amount of time trying to work out why some teams move quickly and others, with comparable people and comparable resources, don't. The answer I keep landing on is unsatisfying, because it isn't about talent or process. Slow teams are usually not deliberating. They're waiting — for a decision that has no owner, for a meeting that keeps getting rescheduled, for someone senior to say the thing everyone already suspects.

Count the calendar days a piece of work actually spends being worked on versus waiting to be unblocked. In most organizations I've seen, the ratio is embarrassing. And almost none of that waiting shows up in a retro, because waiting doesn't feel like a mistake. It feels like diligence.

So the thing I try to build is a team where the default, under uncertainty, is to decide and move — and where that default is safe because the team has enough context to decide well. Those two halves are not separable. Telling a team to move fast without giving them the context to aim is how you get fast motion in an arbitrary direction, and then you get to blame them for it.

The vision has to be aspirational enough to be worth wanting

Most product visions I've inherited fail in the same way: they're a description of a slightly better version of the current product, written to be defensible. Nobody argues with them and nobody is moved by them.

A vision's job is to name a future state a good engineer would want to be part of building. That means it has to be genuinely ambitious — far enough out that we plainly can't do it today — and concrete enough that you can picture a person's day inside it. Not "become the leading platform for X." Something more like: an administrator opens their console and the environment has already diagnosed itself, proposed the fix, and is waiting on a yes. You can disagree with that. You can tell whether a given quarter moved toward it. That's the bar.

The test I use is whether the vision does work in a room where I'm absent. If a team can hold a design argument, invoke the vision, and have it actually resolve something, the vision is real. If it only appears on slides at kickoff, it's a slogan and it's doing nothing.

The strategy has to be tactical enough to disqualify things

This is where I diverge most from how strategy usually gets written. A strategy that only says what you're going to do is not a strategy; it's an ambition list. The load-bearing part is the part that rules things out.

Practically, I want a strategy to answer: which sequence, and why this order. Which customers we're deliberately not serving well yet. What we've decided not to build even though it's a reasonable idea. And what would have to be true for us to change our minds.

That last one matters more than it looks. Strategies with no stated falsification condition don't get revised, they get quietly abandoned, and everyone loses faith in the next one. Writing down "we believe partners will build on this framework rather than around it — if we have no design partners actually building in six months, that belief was wrong" gives the team a legitimate way to escalate a strategic problem without it being a fight.

A concrete version: when I picked up an AI platform with no strategy in place, the sequencing decision was to make a deliberately small bet first — a natural-language query builder inside a workflow people already used daily — specifically because shipping something real would expose which shared capabilities were actually missing. It did. Two structural gaps became obvious once there was working software: every team was about to rebuild agent plumbing from scratch, and every team was about to invent its own definition of quality. Those became the next two platform layers, and the sequencing argument was now evidence rather than opinion. The strategy was tactical enough that a team could look at a proposal and say "that's not the sequence" without needing me in the room.

Then get out of the way, loudly

With a vision worth wanting and a strategy that disqualifies, delegation stops being a leap of faith. What's left is being explicit about it, because ambiguity about decision rights is the single biggest source of the waiting I described above.

A few things I've found actually move the needle.

Name the reversibility. The distinction between decisions that are easy to undo and decisions that aren't — two-way and one-way doors, in Amazon's framing — is the most useful tool I have for calibrating speed. Most product decisions are reversible and get treated as though they aren't. So I say it out loud: this is a two-way door, decide it today, we'll know in three weeks. And equally: this one is a one-way door, slow down, bring me in. Teams don't over-deliberate because they're timid. They over-deliberate because nobody told them which kind of door they were standing in front of.

Make the bias explicit and mean it. "Err on the side of deciding" is easy to say and only becomes real the first time someone decides wrong. What I owe the team at that moment is to publicly own the decision as one I'd rather have than a two-week delay, and then talk about the substance separately from the speed. If a leader says "move fast" and then does forensics on the first bad call, the team correctly learns that the real policy was caution.

Treat escalation as a service, not a failure. Ideally a team escalates because a decision genuinely crosses their boundary — a one-way door, a resource trade they don't control, a strategy question. If escalation costs them status, they stop doing it and start guessing on exactly the decisions where guessing is expensive. I try to respond to escalations fast and without commentary about why it got escalated.

Write the decision down. Not a document, a paragraph: what we decided, what we believed when we decided it, what would change it. This is the cheapest thing on this list and it's what lets a decision get revisited in three months without relitigating everyone's memory. It also makes changing your mind a normal event rather than an admission.

Where this breaks

Speed is not free and I don't want to write as though it is. A few honest failure modes.

A bias toward deciding degrades into a bias toward acting if you don't distinguish between decisions that are cheap to reverse and decisions that merely look cheap. Database schemas, public API shapes, pricing signals sent to a market, anything a customer starts depending on — these get filed as two-way doors and are not. Getting the door classification right is most of the skill.

It also fails when the team is thin on judgment. Empowered speed assumes people who can tell a two-way door from a one-way door on their own. A new team, or one without a designer, or one that's never owned an outcome, will need me to be more directive than I'd like — and the right move is to say so plainly, along with what would change it, rather than to grant autonomy as a gift and watch it go badly.

And the whole model is fragile to one thing: a leader who says "you decide" and then overturns decisions. You get exactly one of those before the team goes back to waiting for you, and no amount of restating the principle will undo it. Which is a reasonable summary of the culture argument generally. Vision and strategy are what you write. Culture is what the team concludes from watching what you do when a decision you didn't make turns out badly.