The most emotionally gripping anecdote for me, in short form: they got really cocky and promised the moon (a new operating system that would be a programmer's dream); then scopes crept, and deadlines slipped; as they tried to understand better why they were totally sucking, they realized that nobody had solved the actually-hard problem that they needed to and everyone just assumed it would be OK; even after significant optimization work they were two orders of magnitude slower than their competition. Clients had waited for years for this thing, bought hardware for it, and now they were being told "look, we're cancelling this project, we just can't do this well enough."
Hoare expresses his then-disbelief that he wasn't fired for the massive failure, especially given his then-belief that MIT was going to succeed doing its variant of the same thing (Multics -- insert notes of irony). Then,
> At last, there breezed into my office the most senior manager of all, a general manager of our parent company, Andrew St. Johnston. I was surprised that he had even heard of me. "You know what wen wrong?" he shouted -- he always shouted -- "You let your programmers do things which you yourself do not understand." I stared in astonishment. He was obviously out of touch with present day realities. How could one person ever understand the whole of a modern software product like the Elliott 503 Mark II software system?
> I realized later that he was absolutely right, he had diagnosed the cause of the problem, and he had planted the seed of its later solution.
After a grueling meeting of "what the @#$% just went wrong and how the @#$% do we fix it?" he describes the reorganization, and it's remarkably anticipatory of something like Agile. He establishes small teams who visit clients directly and figure out what they need; he discards clients' huge-project requests in favor of incremental improvements; those teams then have to convince him personally that this feature is important/useful and not too hard to implement; finally they work on the feature.
It's very much describing a management style which provides some sort of quality-control and pushback, but does not micromanage or mistrust. And it's got a sort of fractal structure: Hoare is only able to succeed because his own supervisors did not destroy him for his failure but trusted him to learn; his system is to act as a filter for the requests hitting his programmers, but he still trusts them to write awesome software if they have a strong sense of direction.