Caroline Clark

Shipping fast

Last week, Airbnb announced that their biggest change in a decade was adding categories. I was confused, curious, and baffled when I read this news. Of course, I’m sure that it was a tremendous amount of work in a way that I can’t even begin to fathom across their millions of listings.

But Airbnb’s announcement brought to the surface two questions that I’ve been wondering about for a while:

  1. Why does shipping speed vary across companies?
  2. Why does keeping at a fast pace get harder for larger companies?

I’m mostly addressing 1. in this essay because that’s what I’ve experienced more, and 2. is sort of obvious (more people = more complexity). At Arcade, we try to ship fast.

There are a lot of references to the mythical man-month problem, which is an observed rule about how adding people-power to a project that is already late makes it later. As a solution, Brooks suggests doing the “Bermuda effect” (removing most people on a project to increase velocity) and prototyping as soon as concepts form.

In many ways, startups are mini Bermudas. Shipping fast is the universal mantra of startups. It is how we win against incumbents. Yet, if we scan the startup universe around us, we can see degrees of variance in shipping fast.

A quick tell is the changelog cadence. Are they updating frequently? Another tell is how fast the startup fixes bugs. If a customer reports a bug is it fixed within the hour? The day? The week? The month? Or....never?

Finally, the most obvious tell is using the product frequently and noticing if it feels lighter (faster load times, fewer steps to get some actions done) or heavier over time. There are a few tools that I’ve grown to enjoy using more and more as time goes on, and a few that I can tell have barely changed.

In this post, I share a little bit more about why shipping fast is so important to us, and a few things that we do startup-wise that I hope we retain as we grow. I also welcome feedback as well about this post and if we can do additional things as well.

There are a few things that we do to ensure speed:

Culture of ownership

We try to have tight feedback loops between engineers and customers. We do not have anyone who “owns the product” because everyone (especially builders and engineers) should feel accountable for what we ship and learn directly from the customer about what is adding value. Here are tangible ways about how we promote this culture of ownership:

Ownership translates to speed because it means: “if you see something wrong, you can fix it.” We don’t require any review or process other than a pull request (PR) for code quality.

Ownership also translates to speed because generally speaking, urgency increases when builders see the pain directly in front of them. Once there are degrees of pain between the customer and the builder, there’s not as much incentive to make it great.

The right people

I’ve quickly discovered that this culture is not something that everyone enjoys being part of. The reality of this culture means that there’s a lot of ambiguity and some people only like coding, and not talking to customers. That’s okay! But probably not a fit for Arcade at this stage. We aspire to keep this culture as long as we can — for example, Stripe didn’t hire their first product manager until 100 people in.

So we try to recruit people who are excited by this culture, and screen for it in the interview process.

Minimal process and meetings

Overall, process and meetings = slower speed. Some process is necessary to ensure that we don’t break things all the time. Our process at Arcade right now is:

As time goes on and we grow, I want us to move towards fewer meetings. Because we talk to customers so frequently and the market changes a lot, we kept sync meetings to chat about what we’re learning.

A lot of people think it’s nuts that we want to progress towards fewer meetings. Usually the opposite happens when companies grow. But it’s possible — a friend who leads product, engineering, and design at a high growth 500-person company has one meeting a day. They very deliberately keep it that way through rigorous documentation and tooling for decision making.

I’m paranoid about slowing shipping speed as we grow. In the long run, I hope we end up like Stripe, which clearly has done a great job despite their size.

Thanks to Rich Manalang, Phillippe Siclait, and Barry McCardel for feedback on this post.