How I ship projects as a leader

Sean Goedecke’s How I ship projects at big tech companies went up on Saturday and I’ve sent it to three people since. His central claim is that shipping is a social act: a project has shipped when the important people at your company believe it has shipped. Code in production that nobody important thinks of as launched hasn’t shipped. And projects don’t ship on their own once the tickets are closed. Somebody has to make it happen, usually one person who understands the whole thing end to end.

Most of my career has been at startups, so I read it wondering how much would transfer to a company of about a hundred and twenty people. More than I expected.

The “one person” part transfers completely. Every project I’ve seen stall here stalled because it had three owners, which is to say none. The ones that shipped had a person who could tell you, on any given day, what was left, what was risky and who was blocking what. At our size that person is usually a senior engineer, not a manager, and my job is mostly to make sure there is one, that everyone knows who it is, and that they have the time. That last part is the one I’ve got wrong most often, by giving the owner of a big project a full load of other work as well.

The “important people” part is different for us, and I think simpler. There’s no VP three levels up whose opinion decides whether a launch happened. Our important people are customers, and before them, our support team, because they’re the ones who’ll be explaining the thing on Monday morning. So for anything customer-facing, “shipped” in my book means support has used it, on a real account, behind a flag, and has stopped asking questions about it. If support is confused, it hasn’t shipped, whatever the deploy log says.

He also says to deploy early, and to be the least scared of scary changes, because you’re the person with the most context. I agree with the first and have mixed feelings about the second. The first is just shipping in slices, which I’ve been preaching since 2013 and still have to preach. The second is right for the owner and dangerous as general advice, because at a startup a lot of people think they have the most context and some of them are wrong. I’ve been one of them.

The one thing I’d add, because it’s what I actually do between the kickoff and the launch, is a question. Every week, in the project’s channel, I ask: if we had to ship this on Friday, what would we cut? Nobody hears it as a threat any more. It forces the list of what’s left into the open, sorted by what matters, and about one time in three somebody answers “honestly, nothing, we could ship it now”, and we do.