Your Company Is Not Facebook

Earlier today, FrameThink posted an entry about how Facebook ships code. There were quite a lot of “juicy” bits to the story – quite a few of which were rather quickly pointed out as incorrect or misleading (the author of the original post does not work at Facebook). The post as a whole, however, was mostly framing the concept of developer-driven culture. In developer-driven culture, the main driving force in the company is the software engineers. The people who write the code are the people who choose what code is going to be written, who decide what the code should do, and who figure out if the code actually works. According to FrameThink, Facebook takes this to an extreme, with designers and architects being an “optional” part of the process, as opposed to something inherently built into it.

Obviously, this kind of process has been at least moderately successful for Facebook. It’d be hard to get to the web’s #1 position with a completely broken development model. On the other hand, how much of Facebook’s success is due to simply brute forcing the problem of design? For instance, take this aspect: “arguments about whether or not a feature idea is worth doing or not generally get resolved by just spending a week implementing it and then testing it on a sample of users, e.g., 1% of Nevada users.” Sure, web applications make it much easier to rapidly iterate on possible development ideas and designs (we do this plenty where I work, too). But there’s still the factor of developer time to take into account.

Facebook can get away with letting engineers work on whatever random feature idea comes to mind for a week because they have something like 500 engineers working on a single website, so occasionally having a couple of developers diverted from the flow doesn’t make a significant impact. When your engineering team is on the lower end of the double-digit range, however, having an engineer or two decide that they’re going to spend the week implementing something they’re not sure if it will work can put a significant dent progress on more major aspects of a site.

Facebook can also get away with redesigning the entire layout of the website multiple times in a year – because even if it takes 50 people to rework major site layouts, that’s only 10% of their engineering team. It doesn’t impede progress in other major areas. Even with the ability to redesign an entire layout scheme multiple times a year, that doesn’t mean it’s a good thing to have to use it – ask any Facebook user and there’s a pretty good chance they’ll gripe about at least one of the most recent Facebook UI changes. The big thing here is that software engineers are not users. Heck, user interface designers are not users – but unlike software engineers, UI designers spend a lot of their time figuring out what the people who are the users need. Software engineers spend a lot of their time writing code. Facebook’s approach to a lot of their UI design is effectively a brute-force approach – throw things at the wall and see what sticks. When you have 500 people throwing things at the wall, you can get a lot of stuff that sticks pretty quickly – but you also wind up with a ton of stuff that didn’t stick on the floor.

So before you rush out to convince everyone at your workplace that Facebook is the model to emulate, consider the fact that your workplace is probably not Facebook:

  • What works for Facebook may not work for everyone. The key is to find the proper balance between developer-driven culture and managed structure – the balance that gives your developers freedom to experiment, while at the same time providing the coherence and external input that is beneficial for a stable development process.
  • Product managers are not obsolete – it’s just a matter of being intelligent about how your product managers fit into the process, what role they play, and who they are. The concept of a non-technically-competent product manager, on the other hand, is obsolete – your product managers do need to have at least some idea of what’s going on with the technical side of things to be able to keep up (and help developers, rather than hinder them) in a modern environment.
  • Just because release cycles are down to weeks or days or even hours, as opposed to the month-long release cycles for more traditional companies, does not mean that everything should be thrown out the window for a faster release cycle: faster is good, but not always better.

About this entry