Move Fast – Facebok's Approach to Engineering

Books · Business · Source

Summary

This purported to be a summary of how Facebook’s engineering culture works, but was entirely too complementary to Facebook and did not (at all) address Facebook current innovation problem

Had some very useful insights though — particularly about Facebook in the 2008-2013 period. My main takeaways were:

• Facebook’s biggest early mistake was focusing too much on html5 instead of native (because they started in a pre iPhone world). But they managed to pivot quickly
• The company’s general approach was to start hacky and iterate quickly from there. But you couldn’t improve html5 with just iteration
• Web engineers wanted to move quickly. But mobile engineers needed more time. So the pace of development significantly slowed
• Innovators dilemma. Don’t sacrifice the future. If something is small but growing fast, pay close attention to it. Example: all desktop users were future mobile users in 2011/12. So it made sense to focus on mobile even though desktop was the majority of users at the point
• Google+ was a real threat. But cultures were different. Google+ engineers were working normal hours, Facebook was working 7 days/week and treating Google+ as an existential threat
• Experimentation is inportant — “we don’t make services to make more money, we make money to build and experiment with more services”
• Facebook had a bootcamp process for new hires. Employee gets familiar with the tooling, code review, and stack and actually has to fix bugs in the first six weeks they are hired across multiple teams

Highlights

• Facebook’s biggest early mistake was focusing too much on html5 instead of native (because they started in a pre iPhone world). But they managed to pivot quickly
• Facebook saw many more mobile logins by 2010. But their mobile experience wasn’t very good even as smartphone adoption was growing
• The first attempt at mobile was html5. They thought having a single codebase instead of maintaining 2 different (objective c and Java) applications was a good idea. But html5 sites were much slower than native and also couldn’t integrate well with hardware features
• General approach was start hacky and iterate quickly from there. But you couldn’t improve html5 with just iteration
• Web engineers wanted to move quickly. But mobile engineers needed more time. So the pace of development significantly slowed
• Innovators dilemma. Don’t sacrifice the future. If something is small but growing fast, pay close attention to it. Example: all desktop users were future mobile users in 2011/12
• Google+ was a real threat. But cultures were different. Google+ engineers were working normal hours, Facebook was working 7 days/week and treating Google+ as an existential threat
• Experimentation — “we don’t make services to make more money, we make money to build and experiment with more services”
• When you’re building a product that works, you’ll attract a lot of competitors. So you need to keep iterating and building+deploying fast to stay ahead. Make sure your stack, processes, and culture are streamlined for this
• Build a prototype, ship, get some data, iterate, and ship again as infinitum
• Bootcamp process for new hires. Employee gets familiar with the tooling, code review, and stack and actually has to fix bugs in the first six weeks they are hired across multiple teams