For the last six and a half years, I’ve worked in a “speed wins” culture of quick iterations, speed of execution, done is better than perfect. A culture that believes that the faster you go, the more you can iterate, the closer you can curve-fit to the user’s needs. Of course, it doesn’t always work out that way. Sometimes, you break things. Sometimes you break important things, and the company loses money. Sometimes – not often, but sometimes – you break things so badly that servers go down and the site is put at risk. And so we’ve worked hard to create a process and infrastructure which prevent or mitigate the vast majority of problems, and provide an escape hatch in the worst case scenario.
We have several staging environments, each of which runs a different set of automated/load tests. When we release new code, we release to a limited number of servers, watch for new errors and system instability, and only roll out to the full site when we’re convinced things are reasonably safe. We release twice daily, so there are always opportunities to fix emergent issues. And if all else fails, we can fail over to a secondary data center.
Any company with an effective process will be thinking about these kinds of tradeoffs. For us, the natural antagonism lies between moving quickly, stability, and technical debt. We emphasize speed, but still need to balance the needs of stability and long-term code maintainability. You can easily imagine a company that went in the opposite direction, with a “slower is faster” culture that focused on stability, maintainability and long-term development speed – at the price of fewer iterations, slower product cycle, etc. Or a company that focused on design and polish over schedule and cost. And so on.
Each of these is a choice, and each has its place – you wouldn’t want Boeing to “move fast and break things,” for instance, and Apple wouldn’t be Apple without their design focus. The danger comes when there’s an unwillingness to identify, admit to, and mitigate the tradeoffs in culture and process. Moving quickly only works if you understand the dangers and prepare for the inevitable breakages.
Even as an individual contributor, it’s important to sit down and think through these tradeoffs. It’s not enough to take a mantra at face value – as our CEO likes to remind us, “speed wins” doesn’t mean it’s ok to ship crappy code as long as you do it quickly. Everyone wants to have it both ways, and it’s precisely your ability to work according to the cultural norm, while managing the downside risk, that will determine your success in any organization.