Most obviously, why do executives need to be the proxy to customers? Why can’t development teams simply talk to real customers? This isn’t just an abstract idea in agile, it grew out of actual Japanese product development practices practiced at large organizations: Toyota, Canon, and others, and documented in “The New, New Product Development Game” HBR review article that was so influential to early agile.
The point that in large organizations, most of the work is coordination, again demands the question, why? It’s been understood since at least World War I by some military planners (with organizations far larger than Google) that coordinating dependencies was far more complex than reducing or minimizing them. Goldratt wrote about it when designing a project management system for Theory of Contraints (indeed, you could argue this is a fundamental learning of ToC). And one of my favorite software conference talks of all time is Mary Poppendeck’s excellent “Tyranny of the Plan,” where she notes that as computer systems have been used in planning, we seem to have become more confident but no more competent in coordinating, rather than focusing on flow, in large-scale projects.
Finally, on the importance of software created at large organizations, I agree, something that will have millions of users on day one has a greater responsibility, but that doesn’t mean that loads of bureaucracy and checking are the pathway to quality software. First of all, does anyone believe that highly scrutinized and bureaucratic functions are general high quality services? The often provide access to even the most extreme edge cases, but they do so by reducing the quality of service to everyone else. Anyone who’s ever filled out their own tax forms in the United States knows that it covers every base of possibly income, but 80% of people really only need to be concerned with 2-3 common forms, and 99% could simply be asked about 10 forms or so. Instead we have to answer questions for “directors of foreign corporations who also happen to be Us citizens,” instead of just requiring those people to fill out an additional form. And, of course, to (probably badly mis-)quote Deming, “you can’t check quality into a product.”
I would turn it around in the author: yes, the software practices operate this way in large orgs because large orgs are structured differently—but why do large orgs need to be structured that way? Is it inherent when absentee owners with low domain context (shareholders) pass ownership over to a manager? Is it because hierarchies insulate good but not great managers from genuine value creation as long as they play politics well? Is it because these are first order ways to understand complexity, and again, low-context absentee owners aren’t going to do the work to understand the more complex dynamics at play?