I think calling Google processes "mistakes" is a little strong. For example, I recall at one point at Google where they were trying to improve latency on the products, so you weren't allowed to launch a new feature if it hurt latency.
I could imagine somebody who just made an awesome feature that made an application 5% slower complain about how stupid that policy is. However, they don't realize that however awesome their feature is, speed of applications is a hidden cost that everybody bears, and sometimes the priority for a company may differ with a specific developers vision. Google wants their products to be fast, wants them to be available, and wants them to be secure. I'm not saying that everything they do is great and their processes and checklists are optimal, but when they have processes designed to do a certain thing, it isn't fair to say their processes are a mistake because they don't do something else.
Very much agreed. When an organization becomes large it needs to make tough choices. In an organization built around product-centric teams, it may be easier to release products more quickly and the average employee may perceive a smoother course from concept to execution, but the organization will quickly discover that horizontal changes become extremely difficult. The frustrated product developer who can't get products out is replaced by the frustrated operations guy who can't patch unsecure systems fast enough. Which one is worse? For Google, I would say the latter. While it always seems like a tragedy to hear about "great" products getting killed, pre-birth, in the corporate mill, I much prefer my stable, high uptime, browser-performant Google to a Google that releases way more product than it already does.
Not to mention that most products (like most startups) fail. As a product-centric company, do you break teams apart after a product fails? If a product succeeds, do you take that successful team and move it to the other product? That may work if you're lucky enough to have a team with the proper skills balance (not to mention passion) to move across different products. What about career goals? People in a particular field tend to want to work with the best people in that field--a huge draw of working at Google is working with the best people in Field X. In a functional organization, the functions (almost) never go away--so the teams are stable.
Of course, being on the outside I can't speak for the problems that are mentioned, such as in-fighting, lack of executive discipline ("You will not launch your product because I don't like your hair style, FUUUUUUUUU!"), etc., but those problems are bad regardless of organization type.
to me presence of in-fighting is a manifestation that whatever executive is responsible for both parties and the issue at hands is just not able or avoiding doing his/her job - taking decisions. Usually it is a combination of the inability and being afraid to take the decision and responsibility for it. "Fish starts to rot from the head" as they say in my old country.
I could imagine somebody who just made an awesome feature that made an application 5% slower complain about how stupid that policy is. However, they don't realize that however awesome their feature is, speed of applications is a hidden cost that everybody bears, and sometimes the priority for a company may differ with a specific developers vision. Google wants their products to be fast, wants them to be available, and wants them to be secure. I'm not saying that everything they do is great and their processes and checklists are optimal, but when they have processes designed to do a certain thing, it isn't fair to say their processes are a mistake because they don't do something else.