Mark Zuckerberg's lines, and what they meant for building a company
Nearly everything Zuckerberg has said about building comes back to one preference: a working thing beats a discussion about one.
A month ago, at Facebook’s developer conference on the last day of April, Mark Zuckerberg announced that the company’s engineering motto had changed. For years it had been “Move fast and break things.” The new version, he said with some amusement, was to move fast with stable infrastructure, and it came with a promise to outside developers that the core programming interfaces would stay stable for two years. A saying that had defined the company for most of a decade was retired in public, which makes this a good moment to look at what Zuckerberg’s lines have argued all along.
The old motto was meant for Facebook’s engineers, and it has its own page here. Its logic was that a company afraid of mistakes slows down, and that a small company loses more by moving slowly than by occasionally shipping a bug. That logic weakens as a company grows. Once thousands of outside developers build on a platform, every break lands on someone else’s product, and the time spent repairing breakage starts to exceed the time the speed saved. The 2014 revision is Zuckerberg conceding that the trade had flipped.
The second recurring idea is a preference for showing over telling. In May 2010, with Facebook under heavy criticism over privacy settings, he answered a question from the blogger Robert Scoble by email with a line that sums up his instinct: “I’d like to show an improved product rather than just talk about things we might do.” Within days the company released simpler privacy controls. The instinct is sound for a builder. Promises cost nothing and a shipped change can be judged.
The same episode also shows the limit. Several of Facebook’s worst weeks came from shipping first and explaining afterward. News Feed appeared without warning in 2006 and set off a wave of user protest before extra privacy controls were added. Beacon, which in 2007 broadcast users’ purchases on other sites to their friends, ended with a public apology. On questions of trust, a product change delivered without explanation can read as one more decision made without the people it affects.
The third idea came in writing in February 2012, in the letter Zuckerberg attached to Facebook’s registration statement for its public offering. He called the company’s culture the Hacker Way: release small improvements quickly, learn from each one, and build a prototype rather than argue for days about whether an idea will work. The letter reports a mantra heard around the offices, “Code wins arguments.” Regular hackathons produced features that later shipped to everyone, and new engineers, including managers, went through a training program on the codebase before starting their jobs.
There is an earlier and gentler strand too. Speaking to an audience of would-be founders in 2009, he said that before Facebook he had mostly built things he liked, with no grand design, a view developed on the page about not needing a master plan. All of these lines share a bias toward a working object over a plan or a promise.
That bias explains much of Facebook’s speed in its first ten years, and the retired motto shows its price. Arguments settled by code favor what can be prototyped in a night over what needs months of careful thought, and moving fast works best when the damage from a mistake stays inside the company. For a small startup, Zuckerberg’s lines are still close to the right default. For a company whose product has become other people’s infrastructure, his own revision this spring is the better guide.