Default Go

15 Apr 2017

Perhaps even more so than for other startups, our choices are 1) go fast or 2) go out of business.

As we grow, that gets harder.

I've been adopting a couple of new strategies to help with this.

One is well-known, most recently described by Jeff Bezos: make decisions with about 70% of the information you'd like to have. Reverse them quickly if you're wrong.

The other is something I call Default Go. I normally introduce it with "Unless someone stops me... <what I intend to do> <when I intend to do it>". This is a way of cueing the rest of the team that I'd value their feedback but that I won't wait long for it.

It's only a default. Anyone can stop me, turning the default-go into a larger discussion around what we're doing and when we should do it. But if no one does, I have all the permission I need and I'm moving.

I've seen a lot of companies - in fact, even this one - using Default Wait. A project or task stalls until it's had everyone's buy-in - after all, that's only fair, plus it's likely to produce better decisions (and it diffuses blame for bad ones). But good people are always busy, priorities vary, communications aren't 100%, and this shifts the project's delivery date (or sometimes its start date!) to somewhere between "next week" and "never".

After some experimentation, I've been persuaded to use a minimum 24-hour window for larger actions. That is still quite aggressive; someone who's very busy or off ill can miss any chance to comment. I think that, at least for us, once the window is more than a few days wide, the damage from waiting exceeds the possible benefits from more input.

For small actions - for example, getting a second set of eyes to read a mailout before sending it to 10000 people - I've used a window as small as ten minutes. That looks something like posting the mailer to slack with "I'm sending this when I've finished making a cuppa".

Like everything else, this is experimental, but it seems to work. Unless anyone stops me, I'm doing this.