Some of these ideals don’t translate well to smaller scale. A 5 person team doesn’t have to work out much except the work. How do you get 1000 people to agree on a plan, an IDE, a language, and to row in the same direction? Not magic. Study and practice.

In my career, I've seen shocking, astounding, career, organization, and company threatening examples of nearly everything he mentions, and to me his reactions are terrific and make a lot of sense.

But, likely as you mentioned, need lots of real world examples from which he has extracted general, "abstract" lessons.

He has terrific stuff. He is an excellent observer and, then, analyst of what the heck he saw.

I put the text in my collection of management essays and regard it as by a wide margin the best management advice I've found for my startup: Currently I'm a sole, solo founder, so far have done it all, including all the important work and a lot of grunt work, but if my startup is successful then I'll have to hire and manage, all of it. Sure, eventually I'll get a COO and delegate a lot to them, but, still I'll have to know what's going on. And there will have to be more software development; I'll have to manage that either directly or through, say, a CTO or CIO, and that essay is the best advice I've seen so far.

Other good advice is in Brooks, The Mythical Man-Month. Brooks is deeper in technical issues; the OP is better in the human and management issues which, IMHO, is where the real problems really are.

Oh, by the way, I still believe that nearly all the best ideas in software management I've heard about are old (although I do have along list of questions where the old stuff doesn't give good answers and where I haven't seen good answers either old or new). So, e.g., I have essentially no faith in "agile" or "object-oriented". And I believe that (A) code without good documentation is essentially worthless, (B) the documentation is more work than the code, and (C) between the code and the documentation, if I had to save just one, it would be the documentation. So, in particular, for the work, the most important part of it is writing documentation; writing the code is the lesser part. And (D) my view of writing code is that it's simple: Start with a good description of (i) the programming language to be used and (ii) good descriptions of the functions, classes, APIs, etc. to be used, and between these two by far the more difficult is (ii). [No, right, usually it's not automatically simple, not at all; instead, in the end it should look and be simple, and that can take a lot of hard work.] Then from the documentation get the really crucial stuff -- what the heck the code is to do. It is the documentation that makes clear the issues of threading, locking, roll back, exceptional condition handling from small scale to large, the UI/UX, etc. Those issues are to be clear in appropriate parts of the documentation and not to be worked out only during the coding. So, e.g., try to get most of the coding down to (a) allocate storage, (b) the usual control structures if-then-else, do-while, select-when, (c) call-return, (d) clear architecture on exceptional condition handling, logging, etc., and (e) the functions, classes, APIs, etc.

From what I learned from before the OP, although the OP has it better but maybe not as explicit, here are two lessons:

First Lesson.

"Why should I"? If you see a person in an organization and some work they might do, ideas they might have, etc. you have to ask the question, how will that person answer the question "Why should I". What's important here for a manager is not how YOU would answer this question but how you would anticipate that subordinate, other person, would answer the question. To be cynical, just because some area A is in the person's area of work, for some work X, will they actually do X and do it well? First way to know is, how would that person answer "Why should I do X"? To be cynical and likely often realistic, without a good answer, the person may simply neglect to do X.

E.g., there is the old Ross Perot joke: Most organizations, when they see a snake, form a committee on snakes. In a good organization, when someone sees a snake, they kill it. Well, then, the answer to "Why should I kill the snake" is that Perot had a good organization.

Second Lesson.

There is a field, with courses, in public administration, business schools, and parts of sociology called organizational behavior. There one of the better ideas is goal subordination. Well, the OP is awash in cases of goal subordination. The idea of goal subordination, and common for middle managers, is to "subordinate" the "goals" of the organization to the "goals" of that middle manager. So, the manager does what he believes is good for his career even if it is bad for the organization. So, an exercise is to read the OP essay and list and explain the places where the author is suggesting goal subordination.

There's much more to say, but, trust me, the OP is talking about stuff that is darned real.

For me, I want my startup to work. A big, huge advantage of being founder and 100% owner is that I don't have to explain stuff to some BoD that, as in the OP, has no chance of understanding reality. So, I'd constantly have to create "company theater" for the BoD, and that would be so wasteful it could kill my company.

My point here generalizes and is generalized in the OP: The crucial details of a serious real problem and its best solution are typically too difficult for communicating up a management chain or even just from a CEO to a BoD. The OP is correct. So, as sole founder and 100% owner, I don't have to try to communicate to a BoD that has no hope of understanding or waste effort on company theater. Instead, I just concentrate on making my company successful. If I am successful, then the main evidence visible externally will be just the financial, brand, etc. success, a lot of which the news media will likely heavily distort; the real reason the company was successful will be known just to me and maybe a COO or CTO if I get really good ones.