Shipping Velocity

"I communicate to my leaders that my expectation is they bring in the clock speed one click faster. If you think something needs to be done this year, it needs to be done this half."

"We take the design and we cut, cut, cut until we can really say that it's going to be useless if we cut anymore. We get that out and people come in."

"And I think the recipe for all this is constantly small teams have a single-threaded focus, give them the resources they need to execute big lofty goals, very tight timelines, and then shield them from the chaos that is the rest of the organization."

"So we have a rotational program on production engineering, for example, where engineers are protecting the core team from escalations, from bugs, from issues. We have product operators that are protecting the PM from the chaos that is documentation and escalations and release management and enablement customer requests."

"I think there's kind of a universal truth that you want small teams with clear missions. Right? If there's 300 people trying to work on one thing, the just sheer communication challenges, Dunbar's number, all of those things come into play and it's really, really hard to act quickly."

"We would pick a owner for something really urgent at the nightly leadership call. Then that owner would be expected to have all hands on deck for however long that problem is every single day and then report the updates on the daily call."

"What it really looks like is you have some rough time budget for how long you think something's going to take. By the time 10% of it has passed, after week one, you have something that works that tests some kind of key hypothesis internally."

"I just really want to jump to the punchline, "Why can't we do this now?" I always felt like part of my role here is to just set the pace and the resting heartbeat."

"We want to implement good technical practices like automated testing, good architectural practices so that when you move fast, you are also more stable, right. We want to be thinking about improving the developer experience so that when we are faster, we are also saving time."

"And some folks, myself included at certain points, swung way too far on the outcomes train and forgot that output is an indicator of that. So if you have a team that's doing all of the ideation and figuring out how to make decisions quickly and getting the right documentation and setting up the right product briefs and design briefs and experiment briefs, all the things that we know go into to successful product development, that's great, but if you're also not shipping a lot of things to market quickly enough, then it just doesn't matter that much."

"In my opinion, your tempo framework is more important than your org design. And so if you've ever had a team that seems really, really smart, but they're always planning or they don't really ship a lot, or you've had trouble where everyone kind of gets it at the leadership level, but then the team below them and below them seems to be kind of going in a different direction, you probably don't have enough alignment and you don't have enough alignment on what good looks like in terms of tempo."

"We're going to go the other way around and we're going to say, what is the maximum amount of time we're willing to go before we actually finish something? How do we come up with a idea that's going to work in the amount of time that the business is interested in spending?"