Rickover's Lessons

It's certainly true the strategic arms processes and nuclear submarine engineering benefited in a long term view.

I just find myself asking if the US army recruiting tag line Be The Best You Can Be was really met, or if Rickover achieved what might be more akin to crystallography "local optimum" where there are better peaks out there, but this one is mine. (To borrow another army concept)

Viewed from Australia the current state of US submarine construction is woeful. We're on the brink of being ripped off having prepaid for access to Virginia class subs soon, and AUKUS subs in future. We expect to be told we cannot have Virginia class subs ever, we cannot have longterm crewing or command ever, but we can host them retained in US HANDS and we can continue to pay for them.

Not that Rickover made that happen, but whatever his lessons are, the US submarine building industry doesn't seem to have learned then, or be able to apply them.

If you've watched Game of Thrones (before it lost the plot), you might be aware of the moment where one of the characters turns around to a petulant, teen tyrant-king and says, "Any man who must say, 'I am the King,' is no true king." I think that statement rings true for McKinsey and the obsession a lot of companies have with "hiring the best."

Admiral Rickover was a true king; i.e., the opposite. He didn't hire the "best." No, he hired people with extraordinary potential and then worked with them to develop their potential.

The theater with the chair and his hiring practises were filters to find people with agency whom he could teach how to be capable and smart. I wonder what the modern equivalent is today.

Side note, almost exactly a year ago (~51 weeks), I edited together a video of him talking about how there aren't any extraordinary people waiting to be hired; https://x.com/1517fund/status/1775253578916974606

That's downright un-American!

I love hearing stories about him. One that I have heard, a couple of times, is that a salesgoblin went into his second-floor office at the Pentagon, with a sample of some electronic equipment.

Rickover is said to have grabbed the device, walked over to his window, and dropped it to the ground beneath. He then said something along the lines of "If it still works, we can talk."

https://www.usni.org/magazines/naval-history/2025/february/c...

If you want to read the full write-up of the story of Rickover and the USS Nautilus, you can find my original substack here: https://charlesyang.substack.com/p/how-hyman-rickover-built-...

I'm also planning on doing some archival research through the Rickover Files at US Naval Academy Archives, so if there are particular topics that are of interest about Rickover's legacy, let me know! Currently planning on prioritizing congressional testimony and unpublished memos or speeches that he gave.

Complex jobs cannot be accomplished effectively with transients. A manager must make the work challenging and rewarding so that his people will remain with the organization for many years. This allows it to benefit fully from their knowledge, experience, and corporate memory.”

~ Hyman Rickover, 1982

> From time to time, I note evidence that NR representatives at field offices, such as a shipyard or laboratory, do not fully understand their primary mission. It is amazing to me how representatives new to these positions uniformly get themselves into the frame of mind, where they conceive of themselves as intermediaries between NR and the contractor. That is, that their job is to judge who is right, NR or the contractor, and then make the decision on their own. In many cases, not even notifying NR. In this way, the NR representative then becomes in effect NR's boss. All NR representatives are of course, encouraged to state their views to me at any time, but it is not their job to assume my responsibility. Another and more serious mistake arises when the NR representative decides what he should or should not report to me. Frequently, he decides not to report things to me because he feels he can handle the matter better himself or he is afraid that by notifying me of the situation, which is his job, I will take ignorant, improper action and upset the applecart. Nearly all NR representatives have had inadequate experience to handle the important and complex tasks they face. I do not expect them to be able to make wise decisions on all matters by themselves. Under some circumstances, it is better to have no NR representative at all because I would not then be lulled into thinking the NR interests are being taken care of. Please bear in mind always that you are the NR representative. That you are to carry out the policies of NR. That you are not to judge NR or to represent the contractor to NR. To achieve the status of a true NR representative requires the acquisition of godlike qualities, but you can try. Signed H.G. Rickover.

[1] https://itrevolution.com/podcast/the-idealcast-episode-10/

I love this quote.

> Free discussion requires an atmosphere unembarrassed by any suggestion of authority or even respect.

This has always been an interesting idea to implement at tech companies. I've not yet been reprimanded for it, but I have definitely gotten raised eyebrows when the CEO or some other higher-up makes a statement, then pauses for replies. It seems like management isn't expecting anyone to do anything other than applaud.

> Responsibility is a unique concept. You may share it with others, but your portion is not diminished. You may delegate it, but it is still with you. If responsibility is rightfully yours, no evasion, or ignorance or passing the blame can shift the burden to someone else. Unless you can point your finger at the man who is responsible when something goes wrong, then you have never had anyone really responsible.

This is my number one source of frustration in tech, specifically in incident management / retrospectives. Companies have fully latched onto blamelessness in such a way that obliterates any responsibility. There is a difference between blaming a person for causing a problem, and holding a person accountable for their actions. The former usually also implies a disinterest in finding and fixing the root cause, instead looking for a scapegoat. That is flawed thinking that will not yield positive results. However, it's also patently absurd to pretend that when Bob has caused 3 of the last SEV0s, Bob isn't at least related to the problem. "We need more guardrails," they'll say, and implement automated checks to prevent the specific issue. I have no problem with guardrails, but what bothers me is when the guardrails become so onerous that it's difficult to do my job, and the bottom line is no one is holding Bob accountable. If you are careless with your work, no amount of guardrails will fix that; the problem is you.

> I am not satisfied with bringing an individual to a qualified level once, and then forgetting about him. Therefore, we continually reinforce theoretical and practical training with a continuing training program. This includes frequent practice in plant evolutions and casualty drills.

As much as any sailor hated drills, you can't deny that they work. I was jolted awake once by the sound of the collision alarm, followed by the announcement of flooding. While it turned out that it wasn't flooding, but merely a "controlled seawater leak," (someone messed up a rig for dive and left a valve open; that's an entirely different discussion), the fact remains that everyone knew where they needed to go, and what they needed to do.

Companies, especially / mostly ops-related departments, should practice scenarios. DR, loss of a K8s cluster, whatever. If you've automated everything, terrific; find something new that you haven't automated, and see if people know how to deal with it. This leads me to my next point: understanding fundamentals.

> I recall once several years ago an Admiral, whose conventionally powered ships were suffering serious engineering problems, asked me for a copy of one specific procedure I used to identify equipment which was not operating properly. He believed that would solve his problem, but it did not. That Admiral did not have the vaguest understanding of the problem or how to solve it, he was merely searching for a simple answer, a check off list, that he hoped would magically solve his problem.

and

> One of the elements needed in solving a complex technical problem is to have the individuals who make the decisions trained in the technology involved. A concept widely accepted in some circles is that all you need is to get a college degree in management and then, regardless of the technical subject, you can apply your management techniques to run any program...

Rickover understood that in order to operate things, you have to understand how they work. To this end, the training pipeline for my job began with basic algebra, in order to assure a baseline level of knowledge, and then proceeded through the structure of an atom, electrons, PN junctions, diodes, transistors, and logic circuits, before finally learning a great deal about the CPU (Motorola 68000 when I was a student; I was part of the curriculum overhaul years later to "modernize" it to the Intel 386) at the logic signal level. All this, to operate with massive layers of abstraction. But critically, that fundamental knowledge is there. We could, if absolutely necessary, troubleshoot a logic board (which are simply specialized computers) down to the component level, and desolder / resolder the new one.

Tech largely operated in this manner for decades by necessity. If you asked how to do something, you were told to RTFM. If you instead said, "I read section x.y.z but don't understand what it means," there was a much better chance of someone offering guidance. The onus was on you to understand enough of your current layer to apply it to the abstraction above. Instead, we now have vibe coding, and people pushing PRs having neither written nor tested any of the code. We have people copy/pasting error messages into Slack and asking what they mean, instead of taking the 10 seconds required to read it. We have people who have successfully memorized Leetcode, but who can't apply any of that knowledge to real-world problems.

Rickover was an asshole, but he had an extremely transparent and level requirement of all his employees: know your job inside and out. If you didn't, he would destroy you.

There _has_ to be a middle ground somewhere that modern companies could strive towards.

His writing style is very good, and he succinctly summarizes the phenomenon where a technology that is substantially complete to the point that it has known issues is looked down upon while a technology that is purely "on paper" (the "paper reactor" as he calls it) is treated as a good alternative, since the paper technology isn't far enough along for the problems to even be known. That's not even a good TL;DR, so you should just read Rickover's essay.

The nose is a bright gold-ish hue against the brown of the rest as the Midshipment rub it for luck on their way to exams.

Which never afforded me much, alas.

I don't know how many people on HN have served and heard of Rickover? But I'm pretty sure most people on HN could not function in a Rickover style management context. It gets things done, but it's not terribly polite about going about getting them done.

To the article's credit, it does touch on this aspect of his management style. But engineers today are from the Millennial or GenZ generations. A lot of that just would not fly. I chuckle thinking about the shock and surprise on the average HN'ers face when one morning they come in and find out they're fired because a hypothetical "Rickover" did a code review last night and found a long existing bug they didn't fix yet.

And keep in mind, this hypothetical "Rickover" would review your code, and that of all your reports, every night. He doesn't like the architecture you chose? You're gone. He finds issues in the code of one of your subordinates? That subordinate is gone and you are too.

It's harsh. I'm not sure today's Americans are ready for that?