Doing a Job – The Management Philosophy of Adm. Hyman G. Rickover(govleaders.org)
govleaders.org
Doing a Job – The Management Philosophy of Adm. Hyman G. Rickover
https://govleaders.org/rickover.htm
48 comments
This is a country of nothing but transients. A company I worked for converted every dev it politically could to 1099s it turned even admins to 1099s. I did a stint at AMD and it did everything it could to turn seasoned people to seasoned people to orange badges. No one has ownership of their lives or their work.
Dept of labor probably has something to say about that.
I am not against business education. A knowledge of accounting, finance, business law, and the like can be of value in a business environment. What I do believe is harmful is the impression often created by those who teach management that one will be able to manage any job by applying certain management techniques together with some simple academic rules of how to manage people and situations.
©1982 H.G. Rickover
A detailed video about how Adm. Rickover maneuvered through bureaucracy to bring into existence America's smallest nuclear submarine: https://youtu.be/2XoPPXQYGXU?t=73
Sounds like reverse-management to me: a clueless manager who makes you do his job, while he focuses on the details of your day to day work.
https://www.fiveeasypieces.xyz/p/five-easy-piecesthe-reverse...
https://www.fiveeasypieces.xyz/p/five-easy-piecesthe-reverse...
This type of philosophy is good but not scalable or efficient.
Scalability and efficiency requires well defined specialized roles. Additionally the more specialized and "stupid" each compartmentalized role is... the more efficient and scalable the organization becomes. Heavy Specialization is in fact the root reason for the complexity of civilization in the modern world. Therefore, if the objective is growth and efficiency, management of every organization must seek to organize the hierarchy in a way where each role becomes small and extremely well defined.
See McDonald or similar for the huge scalability and efficiency that is brought on by the opposite philosophy of Rickover.
Rickovers' philosophy optimizes for flexibility and creativity at the huge cost of basically zero scalability. This type of philosophy is good for labs and R&D work.
In terms of software I currently work at a company that affords this level of flexibility, freedom and ownership. Software Engineers at my company "own" their product and are given full autonomy. But they have to deal with all the politics from other stakeholders and generally spend less time doing actual software.
A software engineer allowed to deep dive on a stream of tickets/tasks while being defended from non-software related issues by a manager is by far more efficient than one given the responsibility of "ownership."
Literally software engineers at my company are expected to push products to production and cat herd all the required people to make it a reality.
What in your mind is a better setup? One where a manager does the cat-herding and the software engineer is given the very small task of just coding? Or One where the software engineer has ownership and responsibility of the entire product and has to manage it all the way to production?
Scalability and efficiency requires well defined specialized roles. Additionally the more specialized and "stupid" each compartmentalized role is... the more efficient and scalable the organization becomes. Heavy Specialization is in fact the root reason for the complexity of civilization in the modern world. Therefore, if the objective is growth and efficiency, management of every organization must seek to organize the hierarchy in a way where each role becomes small and extremely well defined.
See McDonald or similar for the huge scalability and efficiency that is brought on by the opposite philosophy of Rickover.
Rickovers' philosophy optimizes for flexibility and creativity at the huge cost of basically zero scalability. This type of philosophy is good for labs and R&D work.
In terms of software I currently work at a company that affords this level of flexibility, freedom and ownership. Software Engineers at my company "own" their product and are given full autonomy. But they have to deal with all the politics from other stakeholders and generally spend less time doing actual software.
A software engineer allowed to deep dive on a stream of tickets/tasks while being defended from non-software related issues by a manager is by far more efficient than one given the responsibility of "ownership."
Literally software engineers at my company are expected to push products to production and cat herd all the required people to make it a reality.
What in your mind is a better setup? One where a manager does the cat-herding and the software engineer is given the very small task of just coding? Or One where the software engineer has ownership and responsibility of the entire product and has to manage it all the way to production?
Admiral Rickover managed nuclear submarines and aircraft carriers. Moreover, he was responsible for introducing these incredibly complex and dangerous technologies to the Navy.
Claiming that his approach was “not scalable” and that yours is “flexible” sounds naive and conceited to me.
Claiming that his approach was “not scalable” and that yours is “flexible” sounds naive and conceited to me.
>Claiming that his approach was “not scalable” and that yours is “flexible” sounds naive and conceited to me.
Insulting people for a differing opinion that is introduced neutrally is not a conductive way to communicate... it is way of communication that is both against the rules on this site and one that Admiral Rickover himself will condemn.
One thing that is for sure is that insults, rude behavior is not scalable or acceptable in any organization.
>Claiming that his approach was “not scalable” and that yours is “flexible” sounds naive and conceited to me.
Why don't you read what I wrote again. I said Rickovers' approach was "flexible" while my approach was "scalable." Another thing I should mention that I'm sure Admiral Rickover will agree with me on is that insulting people based off of a cursory reading and complete misinterpretation of a post is not productive for any organization. It's very careless
> Admiral Rickover managed nuclear submarines and aircraft carriers. Moreover, he was responsible for introducing these incredibly complex and dangerous technologies to the Navy.
It's debatable how efficient and productive these technologies are. The Defense industry is famous for inefficiencies and incompetence. While the feat you describe is impressive there is nuance that needs to be examined here. Objectivity is warranted. Learn to be able see things not in terms of black and white but in sets of pros and cons which is likely the reality here.
Insulting people for a differing opinion that is introduced neutrally is not a conductive way to communicate... it is way of communication that is both against the rules on this site and one that Admiral Rickover himself will condemn.
One thing that is for sure is that insults, rude behavior is not scalable or acceptable in any organization.
>Claiming that his approach was “not scalable” and that yours is “flexible” sounds naive and conceited to me.
Why don't you read what I wrote again. I said Rickovers' approach was "flexible" while my approach was "scalable." Another thing I should mention that I'm sure Admiral Rickover will agree with me on is that insulting people based off of a cursory reading and complete misinterpretation of a post is not productive for any organization. It's very careless
> Admiral Rickover managed nuclear submarines and aircraft carriers. Moreover, he was responsible for introducing these incredibly complex and dangerous technologies to the Navy.
It's debatable how efficient and productive these technologies are. The Defense industry is famous for inefficiencies and incompetence. While the feat you describe is impressive there is nuance that needs to be examined here. Objectivity is warranted. Learn to be able see things not in terms of black and white but in sets of pros and cons which is likely the reality here.
> I'm sure Admiral Rickover will agree with me on ...
FYI, Admiral Rickover (born 1900) died in 1986.
FYI, Admiral Rickover (born 1900) died in 1986.
*would've agreed
[deleted]
This is well-stated, except one nuance: software is itself scalable, so small software teams can out perform large software teams if they can keep the requirements under control.
> A software engineer allowed to deep dive on a stream of tickets/tasks while being defended from non-software related issues by a manager is by far more efficient than one given the responsibility of "ownership."
This works if ownership boundaries are clear and unambiguous, however defining these boundaries involves many tradeoffs which may be judged incorrectly or shift over time. If so you may hear management start talking about "breaking down silos" and ICs enter a kafkaesque knightmare as the structure chokes on the communication overflow as no one is able to get the support from colleagues to get their own issues done because they are all assigned ownership of different issues.
Overall I think we need to be careful about naively optimizing for scalability and efficiency without first identifying the goal. Just as you probably wouldn't want Rickover designing enterprise software, you also don't want an OKR-toting MBA to be responsible for designing a nuclear submarine.
> A software engineer allowed to deep dive on a stream of tickets/tasks while being defended from non-software related issues by a manager is by far more efficient than one given the responsibility of "ownership."
This works if ownership boundaries are clear and unambiguous, however defining these boundaries involves many tradeoffs which may be judged incorrectly or shift over time. If so you may hear management start talking about "breaking down silos" and ICs enter a kafkaesque knightmare as the structure chokes on the communication overflow as no one is able to get the support from colleagues to get their own issues done because they are all assigned ownership of different issues.
Overall I think we need to be careful about naively optimizing for scalability and efficiency without first identifying the goal. Just as you probably wouldn't want Rickover designing enterprise software, you also don't want an OKR-toting MBA to be responsible for designing a nuclear submarine.
You're thinking along the lines of the dimension of distribution. Yes in terms of distribution, software scales because it can be copied.
However there are many other dimensions of scalability to consider. Examine the complexity of the software system itself where thousands of people have to work on it. Eventually there will be no choice but to go this route due to rising complexity of the software. You need specialists with narrow assignments because those narrow assignments are already so complex that it takes a team to comprehend it. Engineers on these projects have to give up ownership of certain things and trust that others can handle it if they ever want to get any work done.
I stated it above as a tradeoff. Efficiency and scalability vs. flexibility. I completely agree with you on being careful about optimizing for scalability but eventually a bigger org HAS to make this tradeoff because they have no choice.
If a few bespoke nuclear submarines don't necessitate the trade off that's fine, but putting a new ever complexifying smart phone in the hands of the ENTIRE population year after year requires immense sacrifices to flexibility in the name of scalability.
However there are many other dimensions of scalability to consider. Examine the complexity of the software system itself where thousands of people have to work on it. Eventually there will be no choice but to go this route due to rising complexity of the software. You need specialists with narrow assignments because those narrow assignments are already so complex that it takes a team to comprehend it. Engineers on these projects have to give up ownership of certain things and trust that others can handle it if they ever want to get any work done.
I stated it above as a tradeoff. Efficiency and scalability vs. flexibility. I completely agree with you on being careful about optimizing for scalability but eventually a bigger org HAS to make this tradeoff because they have no choice.
If a few bespoke nuclear submarines don't necessitate the trade off that's fine, but putting a new ever complexifying smart phone in the hands of the ENTIRE population year after year requires immense sacrifices to flexibility in the name of scalability.
Yes I understand all this, hence my comment about enterprise software.
My key point is that people fetishize scalability, IMHO because of individual incentives towards wealth and power. However in practice making something scalable often means making it horrible. "Leaders" who get paid by scope and headcount are incentivized to build big frankenstein projects that are fundamentally disjointed. This makes it very hard to fix problems that come up once the practitioners dig in, because the structure imposed from above already precludes a solution.
This isn't universal, certainly there are problems where it can be broken down cleanly by specialization, but it really depends on the interfaces and communication bandwidth/abstraction leakiness between the working groups.
My key point is that people fetishize scalability, IMHO because of individual incentives towards wealth and power. However in practice making something scalable often means making it horrible. "Leaders" who get paid by scope and headcount are incentivized to build big frankenstein projects that are fundamentally disjointed. This makes it very hard to fix problems that come up once the practitioners dig in, because the structure imposed from above already precludes a solution.
This isn't universal, certainly there are problems where it can be broken down cleanly by specialization, but it really depends on the interfaces and communication bandwidth/abstraction leakiness between the working groups.
Agreed. I'm not fetishizing scalability. I am saying that it is an inevitability.
If you can avoid it great, but if you continue growing. You must face it.
If you can avoid it great, but if you continue growing. You must face it.
A dedicated ticket-churner might be the most efficient way to churn tickets. But why are you so sure that the ticket stream amounts to the best long-term future for the software and its customers?
An owner can see around corners. Identify patterns in customer requests and make platform-level changes to get ahead of the customer needs not yet fully articulated. If he does it right, they never will be. He has his thumb on the pulse of production. Knows, cares, and investigates when something merely seems a little weird, before it becomes a bug report or an outage. Sees the real need behind the “requirement” and negotiates a different way to satisfy the business that doesn’t tie the architecture up in knots.
Without the understanding of the codebase that comes from having written or worked on large parts of it, one cannot hope to do this well.
I get to be an owner at my current company and it is one of the reasons I’m very hesitant to ever leave.
An owner can see around corners. Identify patterns in customer requests and make platform-level changes to get ahead of the customer needs not yet fully articulated. If he does it right, they never will be. He has his thumb on the pulse of production. Knows, cares, and investigates when something merely seems a little weird, before it becomes a bug report or an outage. Sees the real need behind the “requirement” and negotiates a different way to satisfy the business that doesn’t tie the architecture up in knots.
Without the understanding of the codebase that comes from having written or worked on large parts of it, one cannot hope to do this well.
I get to be an owner at my current company and it is one of the reasons I’m very hesitant to ever leave.
> A dedicated ticket-churner might be the most efficient way to churn tickets. But why are you so sure that the ticket stream amounts to the best long-term future for the software and its customers?
Because a ticket churner worried about ownership of the entire product has his mind divided between the tickets and the product. A human spending all his effort on one task does a better job on that task than if he divided his effort on multiple tasks.
>An owner can see around corners. Identify patterns in customer requests and make platform-level changes to get ahead of the customer needs not yet fully articulated. If he does it right, they never will be. He has his thumb on the pulse of production. Knows, cares, and investigates when something merely seems a little weird, before it becomes a bug report or an outage. Sees the real need behind the “requirement” and negotiates a different way to satisfy the business that doesn’t tie the architecture up in knots.
Then there should be a dedicated person for this type of role. This dedicated person is called, the product manager. The product manager working closely with the software engineer is from a processing standpoint better than the software engineer owning the entire product. The software engineer no longer needs to context switch and you have two parallel brains working together.
However their is an inefficiency that exists in the communication between the product manager and the software developer. The software developer knows more about the code than the product manager and the product manager knows more about the interface between the product and the customer. Cross communication and lack of understanding between the engineer and the product manager is the source of many complaints.
If the software developer was the owner of the entire product than this communication efficiency is eliminated at the cost of the software developer having to have to divide his effort between multiple domains.
At a certain scale autonomy and complete ownership becomes impossible due to the complexity of the product. At this stage the company must embrace scalability at the cost of flexibility and ownership.
Because a ticket churner worried about ownership of the entire product has his mind divided between the tickets and the product. A human spending all his effort on one task does a better job on that task than if he divided his effort on multiple tasks.
>An owner can see around corners. Identify patterns in customer requests and make platform-level changes to get ahead of the customer needs not yet fully articulated. If he does it right, they never will be. He has his thumb on the pulse of production. Knows, cares, and investigates when something merely seems a little weird, before it becomes a bug report or an outage. Sees the real need behind the “requirement” and negotiates a different way to satisfy the business that doesn’t tie the architecture up in knots.
Then there should be a dedicated person for this type of role. This dedicated person is called, the product manager. The product manager working closely with the software engineer is from a processing standpoint better than the software engineer owning the entire product. The software engineer no longer needs to context switch and you have two parallel brains working together.
However their is an inefficiency that exists in the communication between the product manager and the software developer. The software developer knows more about the code than the product manager and the product manager knows more about the interface between the product and the customer. Cross communication and lack of understanding between the engineer and the product manager is the source of many complaints.
If the software developer was the owner of the entire product than this communication efficiency is eliminated at the cost of the software developer having to have to divide his effort between multiple domains.
At a certain scale autonomy and complete ownership becomes impossible due to the complexity of the product. At this stage the company must embrace scalability at the cost of flexibility and ownership.
I understand the desire, but there's a reason "product ownership" has become a trend. Similar to what's mentioned in the article, development and deployment and working with customers aren't independent. I would rather "own" my software than attempt to work on a stream of "isolated" tickets. And I think the real task of delivering value to stakeholders is more efficient without over-specialization.
Consider the fact that when complexity of the system rises to a point where no human can comprehend it, the project must lean more and more on specialization rather than a bunch of jack of all trades ownership type organization.
Ideally, personally and professionally we prefer autonomy but there hits a point where logistically it becomes fundamentally impossible due to complexity. Society itself must segment itself into specialists due to immense complexities it has to deal with. Eventually organizations within these societies must do the same as they grow bigger and begin to assimilate and represent a bigger portion of the society itself.
Ideally, personally and professionally we prefer autonomy but there hits a point where logistically it becomes fundamentally impossible due to complexity. Society itself must segment itself into specialists due to immense complexities it has to deal with. Eventually organizations within these societies must do the same as they grow bigger and begin to assimilate and represent a bigger portion of the society itself.
I found a lot of this very relatable, but from the sound of it, Adm. Rickover built organizations which are structured around him, rather than creating "more Rickovers" which provide some delegation. This kind of organization is not for everyone, definitely not for people who'd like to grow in their capability and responsibility. I think it have worked better during Rickover's times than today, as people's expectations of their careers have shifted. This also applies to keeping people in the same role indefinitely, which simply won't fly in many companies and societies today.
Managing 40 direct reports, each probably (given the scale the US military industrial complex operates) representing an operation of tens to hundreds more is not just difficult from a time management perspective; you're going to need to context switch between so many disciplines and activities that your head would spin.
Finally, your "bus factor" with a central manager like that would be through the roof.
Still the parts about ownership, accountability and details are all very true.
Managing 40 direct reports, each probably (given the scale the US military industrial complex operates) representing an operation of tens to hundreds more is not just difficult from a time management perspective; you're going to need to context switch between so many disciplines and activities that your head would spin.
Finally, your "bus factor" with a central manager like that would be through the roof.
Still the parts about ownership, accountability and details are all very true.
> from the sound of it, Adm. Rickover built organizations which are structured around him, rather than creating "more Rickovers" which provide some delegation.
One might reasonably conclude otherwise, judging by the nuclear Navy's track record — not only on Rickover's watch, but also since his (forced) retirement in 1982.
One might reasonably conclude otherwise, judging by the nuclear Navy's track record — not only on Rickover's watch, but also since his (forced) retirement in 1982.
Aged 82
I really liked this article, many things that still ring true, yet are not adopted. I worked in a few organizations where no one was responsible, so no one wanted it to succeed. The resulting product was a mediocre example at best. Nothing to put on your resume.
For people not familiar with Rickover, videos of his interviews like [0] are useful for understanding his personality.
[0] https://vimeo.com/56270169
[0] https://vimeo.com/56270169
He sounds like an asshole. But, he also sounds like an extremely effective leader. His conviction and directness weren't for making friends. He wanted to do and finish hard things.
FTA: "In my work, I probably spend about ninety-nine percent of my time on what others may call petty details. Most managers would rather focus on lofty policy matters. But when the details are ignored, the project fails. No infusion of policy or lofty ideals can then correct the situation."
I couldn't agree more. Also, this is not micromanagement, quote the opposite IMHO. For a manager, especially those from larger orgs, this approach is just hard so. Larger orgs tend to be very political, and thus policy heavy.
You can navigate that environment without tons of policy, but it requires investing in clear values and a solid culture. That's much harder than adding a new policy at the end of every incident.
The very best managers I ever had were those that managed to play the politics, were good in whatever they managed, provided clear goals and had an eye for details. Obviously, those are few and far between. I remember two, maybe three in my life so far.
Yup, there are managers so good, I'd go to war with them if asked at 3AM. Others I wouldn't trust with getting groceries.
I remember a quote attributed to the KOG* about certain high-ranking civilian managers: "There but for the grace of God goes God."
* KOG = Kindly Old Gentleman
* KOG = Kindly Old Gentleman
Tangentially relevant, from The Atlantic: "Say Goodbye to Your Manager | The pandemic has exposed a fundamental weakness in the system."
https://www.theatlantic.com/ideas/archive/2021/09/manager-wo...
https://www.theatlantic.com/ideas/archive/2021/09/manager-wo...
> Complex jobs cannot be accomplished effectively with transients. Therefore, 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.
My fave.
My favorite Rickover story may be an urban legend.
It is said that, when salespeople showed up at his second-floor office with sample kit, he'd grab the sample, walk over to his window, and drop it.
He would then say "If it still works, we'll talk."
My fave.
My favorite Rickover story may be an urban legend.
It is said that, when salespeople showed up at his second-floor office with sample kit, he'd grab the sample, walk over to his window, and drop it.
He would then say "If it still works, we'll talk."
That quote applies to CEOs and executives more than any other employee. A company that is sold and run by a hired gun CEO will run poorly.
Software is the antithesis of that philosophy. The word I hear most from developers when evaluating an approach: easy. Not simple, but easy. Then comes all the memorized patterns, a laundry list of tools, thousands of dependencies, and their favorite pet framework they cannot live without. You take any of that bullshit away the immediate response is some form of crying or hostility.
Most things in software are never that challenging, but then that is a matter of perspective. Everything is challenging the moment an adult comes in and cuts off the nonsense.
Most things in software are never that challenging, but then that is a matter of perspective. Everything is challenging the moment an adult comes in and cuts off the nonsense.
I ran a shop, that, when we were finally disbanded, after 27 years, the person with the least tenure had a decade.
Our work was far from easy. It was developing cross-platform image processing pipelines in C++. Lots of whacky stuff, like leveraging hardware threading, cache optimization, etc.
Each engineer had strengths in various areas, and we were able to work together to develop some stuff that worked nicely (it wasn't always packaged especially well, by the application implementation team, but our stuff was great).
We were a US shop that fed into a Japanese organization, and the Japanese wouldn't even acknowledge my engineers, until they had been there at least a year.
I'm not really a fan of "Programming by Dependency." I understand that it can allow relatively unskilled and inexperienced programmers to create some pretty ambitious works, but I feel the cost in quality, performance, resource usage, licensing, and future maintainability are too high, in many cases.
Our work was far from easy. It was developing cross-platform image processing pipelines in C++. Lots of whacky stuff, like leveraging hardware threading, cache optimization, etc.
Each engineer had strengths in various areas, and we were able to work together to develop some stuff that worked nicely (it wasn't always packaged especially well, by the application implementation team, but our stuff was great).
We were a US shop that fed into a Japanese organization, and the Japanese wouldn't even acknowledge my engineers, until they had been there at least a year.
I'm not really a fan of "Programming by Dependency." I understand that it can allow relatively unskilled and inexperienced programmers to create some pretty ambitious works, but I feel the cost in quality, performance, resource usage, licensing, and future maintainability are too high, in many cases.
Software is the antithesis of that philosophy? Or did you mean Silicon Valley Hypergrowth and Billionaire-worship Culture is the antithesis of that philosophy?
Because it strikes me that software can be many things, it's primary attribute of course being malleability.
Because it strikes me that software can be many things, it's primary attribute of course being malleability.
I feel they were being sarcastic.
Where does this policy of rotating people out of jobs come from? I saw what Rickover was describing at GE and the poor outcomes that result. Everyone had adapted to having new managers every two years...your new manager is always another "lifer." It created a thick layer of pessimism that was hidden from the managers that rotate in. Employees learned to just do what they are told and sit there with their hands folded if no one gives them "direction." They are resolved to the idea of managing a manager that does not know what is going on and never will. All the managers think they are hot shit.
In the military, there is a practical justification for this constant rotation: it prevents officers from establishing fiefdoms that can undermine the unconditional adherence to orders from above.
Of course, this idea is firmly rooted in the operational demands of military organizations, which is not really the same kind of work as, say, developing new weapons systems.
Of course, this idea is firmly rooted in the operational demands of military organizations, which is not really the same kind of work as, say, developing new weapons systems.
I assume it’s also because the military assumes that during wartime, some officers will be killed, thus the organization needs redundant people who know multiple roles and can rotate in as needed. That’s obviously less of a concern in corporations.
In competent militaries that problem is solved by training people beyond what their role requires and promoting from below. If you want results, especially in a crisis, you just can't parachute strangers in from outside who have never seen the problem field.
...redundant people who know multiple roles...
Seems like this would be far worse in corporations? Isn't the median tenure in the tech industry around 3 years?
> Good ideas are not adopted automatically. They must be driven into practice with courageous impatience.
I really like that phrase: courageous impatience.
I really like that phrase: courageous impatience.
> Complex jobs cannot be accomplished effectively with transients. Therefore, 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.
I wonder what he would say about today’s corporate environment.
I wonder what he would say about today’s corporate environment.
Rickover had an interesting discussion on the size of the team. He suggests that the optimal size depends on how much time each member needs to discuss details with their superior. Larger size occurs when most people are highly independent and only need short meetings with the boss. I always thought the size of the team was only a function of the preferences of the boss. His passage adds nuance to this topic.
Excerpt: "He was certainly thrifty, but my father could also be extremely generous with his money as well as with his time. He donated all the profits from his books and the honorariums from his many speaking engagements to a Jewish orphanage in Chicago. When one of his staff died during surgery, he made sure his widow had enough money to tide her and her family over and went to great lengths to find her a good job with the civil service."
http://www.rickover.com/