There are blog posts that you can write without doing any prior work (he says, looking meaningfully at himself in the mirror), and then there are blog posts that require real work. This very interesting post about how the Facebook development organization operates is in the latter category. Instead of pointlessly summarizing the author's findings, compiled from sources who know Facebook from the inside, I'll add a few reactions:
If, as reported, the development team comprises about a quarter of the company's employees (and operations another quarter), that's an unusually high ratio for any tech vendor, whether or not it's in the software-as-a-service (SaaS) business. At salesforce.com, R&D comprises 15% of the company, which is high for the tech industry. Facebook's 25% R&D is staggeringly high.
Even though Facebook regularly confuses the heck out of the people with changes to security features, the company does pilot features before shipping them.
Facebook developers bear a lot of responsibility for their own code, across many dimensions of quality (design, testing, justification, etc.).
The ops team has a more gradual approach to deploying new code than it might appear.
[For earlier posts in this series, click here and here.]
Imagine that you're dining at a new Italian restaurant that just opened in your neighborhood. You've heard that the chef is well known and widely respected, so you're expecting a great first experience.
You sit down, and the waiter hands you a menu. Actually, it's not a menu, but a listing of all the top-quality ingredients in the restaurant's refrigerator. Some ingredients suggest the kind of recipes that the chef might prepare: For example, the veal shank might be destined to become Osso Bucco. Since you're not an expert in Italian cuisine, it's hard to guess what kind of recipe might require some of the other ingredients (rabbit, goat, boar, etc.).
The waiter is no help. He'll dutifully return to the kitchen with the ingredients you tell him the chef should prepare, but he won't tell you if that combination will transform into a delicious meal or an indigestible lump.
In this scenario, chances are slim that you'll get the sort of dining experience you expected. If you were hoping for an experience you've never had before, the kind that a world-class chef could provide, the odds are even worse.
Sadly, this is exactly the way in which technology companies have pitched their products. Rather than explaining the experience you should have, they leave it up to you to figure out what experience might be possible, given the ingredients (features and functions) available in the product. This approach has two pernicious consequences:
Politics is a word that we use so loosely that it risks losing meaning altogether. When we talk about office politics, as some recent posts by product management bloggers, we're usually expressing scorn for odious behaviors that stand in the way of some rational course of action. Every organization is susceptible to politics, in this negative sense, including every development team. Better to assume it, or even take advantage of it when possible, than to pretend that some magic tool or methodology will do away with politics.
Can't Live With Politics. Can't Live Without Politics
In their blogs, both Jim Holland and Jennifer Doctor recounted a session about politics at a recent Product Camp in Seattle. The topic struck a nerve, as evidenced by the outpouring of complaints from the audience. We've all heard them, whether we're product managers or not: Empire builders put themselves ahead of the interests of the group; real decisions happen in a back channel, instead of in the open; teams decide in haste, and repent at leisure . . . It sounds as if this session was as therapeutic for the audience as it was informative.