Welcome to Gaia! :: View User's Journal | Gaia Journals

 
 

View User's Journal

Some Ideas
Some things I have written.
A Bit on "Doing a Job"
Today, I came upon a speech delivered by Hyman Rickover. He was an admiral in the US Navy and lead the development of the first nuclear submarine. In this speech, he talked about his management philosophy. I gotta say, it really resonated with me, especially on my current project. Here, I'll take out excepts and comment on them.

I found the speech here: https://govleaders.org/rickover.htm
If that link is dead now, try searching "Doing a Job" by Adm. Hyman G. Rickover. It was a speech he delivered at Columbia University in 1982.

Quote:
Human experience shows that people, not organizations or management systems, get things done. For this reason, subordinates must be given authority and responsibility early in their careers. In this way they develop quickly and can help the manager do his work. The manager, of course, remains ultimately responsible and must accept the blame if subordinates make mistakes.

I have already adapted the "accept blame of subordinates" in my leadership style, but I often have a hard time delegating authority/responsibility. It's something I acknowledge that I'm not great at doing, and I've been inching towards doing it more. I think it's usually a matter of trust, I can often assign things to NM, because I know he can get the job done, but with the outside contractors, I don't feel like they're at that level.

Another lead on my team works with outside contractors, and he easily delegates entire features, but I would have a very hard time doing that.

Quote:
As subordinates develop, work should be constantly added so that no one can finish his job. This serves as a prod and a challenge. It brings out their capabilities and frees the manager to assume added responsibilities. As members of the organization become capable of assuming new and more difficult duties, they develop pride in doing the job well. This attitude soon permeates the entire organization.

I think he's somewhat wrong here. You see, people have an upper limit on their capabilities. If you keep pushing people to do more and more, then eventually they hit their limit and all it does it put an undue amount of stress on them.

That being said, sometimes you need to hit the limit to find out where the limit is. Take children for example, you need to push them outside their comfort zone so they can grow. I think he's speaking with this perspective in mind.

I don't know where the decision point for "push people" and "let them be" is. So, I usually decide the latter. I think that's probably the wrong decision, I should probably push people more. But I'm too worried about stressing them out.

Quote:
One must permit his people the freedom to seek added work and greater responsibility. In my organization, there are no formal job descriptions or organizational charts. Responsibilities are defined in a general way, so that people are not circumscribed. All are permitted to do as they think best and to go to anyone and anywhere for help. Each person then is limited only by his own ability.

Another point I don't entirely agree with. In software, anyway.

There are two lens' I can view this from: "full stack vs specialized" or "job descriptions don't matter".

So, a full stack engineer is a jack of all trades, they can do anything both front and backend. A specialized engineer finds a place to focus and develops expert knowledge in that area.

Viewing what he says with that lens, he's basically saying "everyone should be a full stack engineer", which is silly. Not everyone is suited to "learning every technology", and if a person isn't suited to it, they really just become bad at everything.

Putting the other lens on...A lack of job descriptions means people don't really have guidance in what they should be doing. This works out fine if people are self-directing, but I've met quite a few people who aren't. Some people need clearly defined roles and responsibilities.

Those things being said, I would be comfortable in the environment he describes. It really depends on the person.

Quote:
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.

The Defense Department does not recognize the need for continuity in important jobs. It rotates officer every few years both at headquarters and in the field. The same applies to their civilian superiors.

This system virtually ensures inexperience and nonaccountability. By the time an officer has begun to learn a job, it is time for him to rotate. Under this system, incumbents can blame their problems on predecessors. They are assigned to another job before the results of their work become evident. Subordinates cannot be expected to remain committed to a job and perform effectively when they are continuously adapting to a new job or to a new boss.

When doing a job—any job—one must feel that he owns it, and act as though he will remain in the job forever. He must look after his work just as conscientiously, as though it were his own business and his own money. If he feels he is only a temporary custodian, or that the job is just a stepping stone to a higher position, his actions will not take into account the long-term interests of the organization. His lack of commitment to the present job will be perceived by those who work for him, and they, likewise, will tend not to care. Too many spend their entire working lives looking for their next job. When one feels he owns his present job and acts that way, he need have no concern about his next job.

I appreciate this observation. It's one of the clear downsides of high turnover, of which there are many. I wouldn't describe my current project as having high turnover, but it's an example of the negative impact those "2 year CEOs" have.

Quote:
In accepting responsibility for a job, a person must get directly involved. Every manager has a personal responsibility not only to find problems but to correct them. This responsibility comes before all other obligations, before personal ambition or comfort.

I was just talking about this to AS this week! My vague way of expressing it was "it feels like nobody cares", which he understood implicitly. There are leadership people on my project who are not interested in making quality. They are OK with substandard work. And they frustrate the hell out of me.

Quote:
A major flaw in our system of government, and even in industry, is the latitude allowed to do less than is necessary. Too often officials are willing to accept and adapt to situations they know to be wrong. The tendency is to downplay problems instead of actively trying to correct them. Recognizing this, many subordinates give up, contain their views within themselves, and wait for others to take action. When this happens, the manager is deprived of the experience and ideas of subordinates who generally are more knowledgeable than he in their particular areas.

Reminds me of RH, who quit a couple months ago because he got burnt out. He told me one of the big reasons was that he never had enough time to complete the work on his plate. So, he did things poorly and took shortcuts, depressing him to no end.

He said that he kept his issues to himself (reflecting that this was a mistake) because he thought it didn't matter and no one could do anything about it. This was a consequence of his direct lead being OK with the situation where their team had too much to do and not enough time to do it. I talked to his lead about the scheduling hell, and he said "well, if we miss the dates, they just push out all the work anyway, so it doesn't really matter". He was painfully oblivious to the affect it was having on his subordinate.

Quote:
A manager must instill in his people an attitude of personal responsibility for seeing a job properly accomplished. Unfortunately, this seems to be declining, particularly in large organizations where responsibility is broadly distributed. To complaints of a job poorly done, one often hears the excuse, “I am not responsible.” I believe that is literally correct. The man who takes such a stand in fact is not responsible; he is irresponsible. While he may not be legally liable, or the work may not have been specifically assigned to him, no one involved in a job can divest himself of responsibility for its successful completion.

Ah, this is a hard one for me. "no one involved in a job can divest himself of responsibility for its successful completion" <- I feel this responsibility, I really do, but the problem is not enough people on my team do.

I can only do so much on my own. I fix things outside my domain because they bother me. I do it all the time. But there are always more broken things. And some of the things I want to fix will take days and have other knock-on effects that I don't have time to handle.

Quote:
When I came to Washington before World War II to head the electrical section of the Bureau of Ships, I found that one man was in charge of design, another of production, a third handled maintenance, while a fourth dealt with fiscal matters. The entire bureau operated that way. It didn’t make sense to me. Design problems showed up in production, production errors showed up in maintenance, and financial matters reached into all areas. I changed the system. I made one man responsible for his entire area of equipment—for design, production, maintenance, and contracting. If anything went wrong, I knew exactly at whom to point. I run my present organization on the same principle.

This is an interesting one. At my job, areas of the codebase are cut up in this way, like client, web services, core gameplay. So, it's a bit like he's advocating for everyone to be full stack, like I mentioned earlier.

You could maybe apply features this way? Like "you're the lead engineer for this feature, do what it takes to get it done". But of course I would expect that person to have to communicate with other departments, like design, art, and production.

When I am king, I will seriously consider assigning specific people to be "feature leads".

Quote:
A good manager must have unshakeable determination and tenacity. Deciding what needs to be done is easy, getting it done is more difficult. Good ideas are not adopted automatically. They must be driven into practice with courageous impatience. Once implemented they can be easily overturned or subverted through apathy or lack of follow-up, so a continuous effort is required. Too often, important problems are recognized but no one is willing to sustain the effort needed to solve them.

This one really hits home. What happens sometimes is people get together in a meeting, they agree to a solution, and then no one follows up. I have attributed this to "no one is assigned to follow through". So, if it's no one's responsibility, then it doesn't happen.

I think in Rickover's ideal, everyone would be interested in following through.

Quote:
The man in charge must concern himself with details. If he does not consider them important, neither will his subordinates. Yet “the devil is in the details.” It is hard and monotonous to pay attention to seemingly minor matters. 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.

There is a fine line between this and micromanagement. And I don't know where it is. I am certainly the type to care about details, I am constantly making tiny adjustments to code reviews that come my way. But I often have to do that through a small bit of guilt, thinking "why can't I be OK with the way they originally wrote it?" It's something I'm working on.

I'm inclined to say that it's a mistake for a manager to be so focused on details.

Quote:
One must create the ability in his staff to generate clear, forceful arguments for opposing viewpoints as well as for their own. Open discussions and disagreements must be encouraged, so that all sides of an issue will be fully explored. Further, important issues should be presented in writing. Nothing so sharpens the thought process as writing down one’s arguments. Weaknesses overlooked in oral discussion become painfully obvious on the written page.

This one might apply more to large scale operations, like building submarines, then it does to my <5 person meeting discussing how to implement a feature. But in principle, I agree with it. A well thought out argument will win over off-the-cuff discussions. That being said, we can't only communicate over email all the time. Some things are better done in person.

Quote:
It is a human inclination to hope things will work out, despite evidence or doubt to the contrary. A successful manager must resist this temptation. This is particularly hard if one has invested much time and energy on a project and thus has come to feel possessive about it. Although it is not easy to admit what a person once thought correct now appears to be wrong, one must discipline himself to face the facts objectively and make the necessary changes—regardless of the consequences to himself. The man in charge must personally set the example in this respect. He must be able, in effect, to “kill his own child” if necessary and must require his subordinates to do likewise.

A true one, but a hard one for me to actually do. I have no problem acknowledging to myself "hey, you screwed up here". It's when I have to actually go and tell someone else that I screwed that that I hesitate. I think it's because in my brain, I put too much weight on what other people think of me. I want to be the flawless engineer, if not in reality, then in other people's eyes. But I acknowledge this is stupid.

If you'll let me sound pretentious for a second, I'm reminded of a quote from Dune. "The mind commands the body and is instantly obeyed. The mind commands itself and meets resistance." This one is attributed to Saint Augustine.

Quote:
No management system can substitute for hard work. A manager who does not work hard or devote extra effort cannot expect his people to do so. He must set the example. The manager may not be the smartest or the most knowledgeable person, but if he dedicates himself to the job and devotes the required effort, his people will follow his lead.

A careful line to tread here. In software, the manager who works late or on weekends and communicating to his subordinates "I'm comfortable doing this, so should you".

Occasionally, I'll do extra work on the weekends, but I'm always careful to keep that to myself. I don't want anyone to feel undue pressure for the things I do electively.

---

And that's everything I have to say. I find this speech to be inspiring, finding me at a time when I was most ready to hear it. The speech is not without criticism, "be a filter not a sponge" and all that. But it will be a big influence on me going forward, that's for sure.





 
 
Manage Your Items
Other Stuff
Get GCash
Offers
Get Items
More Items
Where Everyone Hangs Out
Other Community Areas
Virtual Spaces
Fun Stuff
Gaia's Games
Mini-Games
Play with GCash
Play with Platinum