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:
- Why does shipping speed vary across companies?
- 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
- People
- Process (or lack thereof)
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:
- When someone joins Arcade, they join all customer calls for the first few weeks.
- Our Intercom channel is open inside Slack in a global setting. Anyone can join and hop in for a conversation when a customer reports a bug — the only rule is that we have to close what we started.
- If a customer emails someone about an issue or have feedback, we route it to the engineer who built it and forward it to Productboard which is accessible to everyone.
- When someone is about to ship something, they must watch a few customers use their tool.
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:
- Monday morning Rich and I have a chat about our priorities for the week. This is connected to the overall goals that we want to hit product and growth-wise. We then map this out how the team’s work is structured.
- After that meeting, we have a team sprint planning session to discuss what we want to get done for the week. People are encouraged to propose their own “cards” which are task specific pieces of work connected to larger projects.
- We have a daily standup T, W, Th, and Fri. We experimented with async but we found that things got lost in translation. We may continue to experiment with it.
- Friday retro to discuss the past week.
- Dev-wise, we do PRs which are reviewed by the team. Sometimes we pair program if there’s a particularly complex piece, but that is ad hoc.
- We do a hackathon (aptly called Turbo) once a quarter. A surprisingly high amount of things that we do in the hackathon make it into the product. For example, after our last Turbo we shipped new settings and a new capture experience a few days later.
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.