[HN Gopher] Doing a Job - The Management Philosophy of Adm. Hyma...
___________________________________________________________________
Doing a Job - The Management Philosophy of Adm. Hyman G. Rickover
Author : wheresvic4
Score : 86 points
Date : 2021-09-18 08:33 UTC (14 hours ago)
(HTM) web link (govleaders.org)
(TXT) w3m dump (govleaders.org)
| datavirtue wrote:
| 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.
| jkhdigital wrote:
| 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.
| SkyMarshal wrote:
| 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.
| stickfigure wrote:
| Seems like this would be far worse in corporations? Isn't
| the median tenure in the tech industry around 3 years?
| HarryHirsch wrote:
| 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.
| SkyMarshal wrote:
| _...redundant people who know multiple roles..._
| ChrisMarshallNY wrote:
| _> 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."
| silexia wrote:
| 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.
| austincheney wrote:
| 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.
| dasil003 wrote:
| _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.
| ChrisMarshallNY wrote:
| I feel they were being sarcastic.
| ChrisMarshallNY wrote:
| 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.
| black_13 wrote:
| 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.
| dboreham wrote:
| Dept of labor probably has something to say about that.
| jgamman wrote:
| 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. (c)1982 H.G. Rickover
| prox wrote:
| 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.
| dctoedt wrote:
| I just found this: Rickover's only son's eulogy for him,
| putatively at Yom Kippur 2008. (Rickover died in 1986.) Sounds
| like the man had a human side and really was kindly -- at least
| toward some.
|
| 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/
| j7ake wrote:
| 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.
| MattGaiser wrote:
| > 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.
| jkhdigital wrote:
| > Good ideas are not adopted automatically. They must be driven
| into practice with courageous impatience.
|
| I really like that phrase: _courageous impatience_.
| mLuby wrote:
| 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
| physicsgraph wrote:
| For people not familiar with Rickover, videos of his interviews
| like [0] are useful for understanding his personality.
|
| [0] https://vimeo.com/56270169
| mabub24 wrote:
| 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.
| dctoedt wrote:
| 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."
| hef19898 wrote:
| 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.
| groby_b wrote:
| 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.
| hef19898 wrote:
| 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.
| dctoedt wrote:
| 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
| dctoedt wrote:
| 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...
| flyinglizard wrote:
| 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.
| dctoedt wrote:
| > _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.
| dboreham wrote:
| Aged 82
| deltasixeight wrote:
| 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?
| dasil003 wrote:
| 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.
| deltasixeight wrote:
| 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.
| dasil003 wrote:
| 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.
| snth wrote:
| 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.
| deltasixeight wrote:
| 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.
| closeparen wrote:
| 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.
| hitekker wrote:
| 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.
| deltasixeight wrote:
| >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.
| [deleted]
| dctoedt wrote:
| > _I 'm sure Admiral Rickover will agree with me on ..._
|
| FYI, Admiral Rickover (born 1900) died in 1986.
| deltasixeight wrote:
| *would've agreed
___________________________________________________________________
(page generated 2021-09-18 23:02 UTC)