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.
During one of my gigs as a product manager, an executive in our company was overjoyed to have a US Defense Department client. He was eager to land a reference customer, but he fundamentally misunderstood how easy it would be to get a military organization to join the ranks of success stories. He wrongly assumed, in this very hierarchical organization, successful adoption of our collaboration tool was the simple process of (1) the general in charge ordering people to use it, followed by (2) people under his command dutifully using it. The military doesn't work that way, in large part because, when faced with a bad order that might kill them, military professionals learn how to wriggle out of these diktats. (Which is why there's a fine line between initiative and insubordination.)
Even if our executive's assumptions about how the military operated were correct, that formula might spell doom for the project. What happens when the general in charge moves on to another post? No assignment is forever, and the next officer in charge might have a far lower opinion of our product. The crisis might happen earlier, if the current general got impatient with the progress of the project. Fearful of these potential outcomes, this executive bet the entire project on maintaining good relations with the general and his immediate subordinates, including the irascible project lead, whose view of technology adoption was summarized in his comment during a meeting with us: "Users are stupid, so they don't know what they want."
Another excellent post from Scott Sehlhorst, this time pointing out that, even without product managers, product management still happens. Scott’s post is a response to Jason Calcanis, the founder of Mahalo, who wrote the following:
In under 30 days, we completely overhauled our product-development process, removing everything between the developer and iterating on the product. We eliminated positions and process. We made it clear the developers were to make the decisions even if those decisions resulted in a developer being 50 percent slower because they were busy *thinking* about the product (as opposed to just transcribing features from the product manager wireframes).
If Calcanis is arguing that his company doesn’t need product managers, because they just are in the way, Scott makes the obvious counterargument:
When I was still writing software and leading teams that were writing software, I would occasionally point out that all software is designed – even if someone sits down and just starts typing code. There is, at the minimum, implicit design happening in the mind of the programmer. It might not be “good” design, but there is always design. There is always a method to the madness, just not always a considered method. The same is true of product management...Eliminating product managers does not eliminate product management.
[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.