moving fast and breaking things

Let’s start with the classic Facebook quote, Move fast and break things. Facebook’s used that for years: it’s a philosophy of trying out new ideas quickly so you can see if they survive in the marketplace. If they do, refine them; if they don’t, throw it away without blowing a lot of time on development.

Breaking existing functionality is acceptable… it’s a sign that you’re pushing the boundaries. Product comes first.

Facebook was known for this motto, but in early 2014 they changed it to Move fast with stablity, among other variations on the theme. They caught a lot of flak from the tech industry for this: something something “they’re running away from their true hacker roots” something something. I think that’s horseshit. Companies need to change and evolve. The challenges Facebook’s facing today aren’t the same challenges they’re facing ten years ago. A company that’s not changing is probably as innovative as tepid bathwater.

Around the time I started thinking about this talk, my friend sent me an IM:

Do you know why kittens and puppies are so cute?

It’s so we don’t fucking eat them.

Maybe it was the wine I was drinking or the mass quantity of Cheetos® Puffs™ I was consuming, but what she said both amused me and made me think about designing unintended effects inside of a company. A bit of an oxymoron, perhaps, but I think the best way to get things done in a company isn’t to bash it over your employee’s heads every few hours, but to instead build an environment that helps foster those effects. Kittens don’t wear signs on them that explicitly exclaim “DON’T EAT ME PLS”, but perhaps their cuteness help lead us towards being kitten-carnivorous-averse. Likewise, telling your employees “DON’T BREAK SHIT” might not be the only approach to take.

I work at GitHub, so I’m not privvy to what the culture is like at Facebook, but I can take a pretty obvious guess as of the external manifestations of their new motto: it means they break fewer APIs on their platform. But the motto is certainly more inward-facing rather than external-facing. What type of culture does that make for? Can we still move quickly? Are there parts of the product we can still break? Are there things we absolutely can’t break? Can we build product in a safer manner?

This talk explores those questions. Specifically I break my talk into three parts: code, internal process in your development team and company, and the talk, discussion, and communication surrounding your process.