
Doing a Job (1982) - henning
https://govleaders.org/rickover.htm
======
sjy
This article is great. I particularly liked this part:

> Some management experts advocate strict limits to the number of people
> reporting to a common superior—generally five to seven. But if one has
> capable people who require but a few moments of his time during the day,
> there is no reason to set such arbitrary constraints. Some forty key people
> report frequently and directly to me. This enables me to keep up with what
> is going on and makes it possible for them to get fast action.

It’s interesting to know that at least one successful manager of a large
organisation found that limit of 5 or so direct reports to be unnecessary. The
article was written in 1982. I would have thought the increased use of
technology in the workplace would make it easier to manage many people these
days – but the trend seems to be the reverse.

~~~
Aloha
It just depends on the nature of the reporting - if you need intensive
reporting from your directs, then yes, less is more - if your people work in
relative isolation then more is more.

~~~
lonelappde
Right, it's silly to compare the line manager of 40 assembly line workers
doing the same task, vs a leader of a SEAL team.

~~~
Aloha
You can have one manager managing 20 engineers doing project work too, because
often there is a project manager attached managing the specific issues with
the project.

------
HammockWarrior
> 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.

I hear this kind of talk from managers at my workplace as well. Extreme
ownership seems like the management technique du jour. I am quite sceptical of
it. I'll treat the work as my own business when it _is_ my own business and
when I have a significant stake in the outcome. Otherwise, I am just a guy you
pay to do a job, not a business partner and definitely not a loyal slave.

------
jammygit
> All work should be checked through an independent and impartial review. In
> engineering and manufacturing, industry spends large sums on quality
> control.

I feel that the code reviews I’ve been a part of were not as effective as they
could have been. I think there is social awkwardness at criticizing design or
conceptual aspects, and a multitasking aspect that means the reviewer is in a
hurry and mostly checks conformity to the style guide. Very little checking
out of branches and manual testing happened, so we had more regressions than
expected.

Is this the norm? What practices have you seen that lead to better results?

~~~
journalctl
I think code reviews on teams without architects are awkward. Someone
naturally might step up to take on that role, but if there’s no clear decision
maker for hard technical choices, then it’s just a bunch of awkward, passive
suggestions. And with no clear leadership, it’s hard to resolve disputes.
People need to be empowered to do their jobs, but I’ve noticed that on a lot
of dev teams that empowerment isn’t explicit. So you end up with the strongest
personality being the one that makes important technical decisions or
architecture decisions, regardless of whether or not they’re qualified.
Personally, I’m not a fan of this approach.

------
jammygit
> When important decisions are not documented, one becomes dependent on
> individual memory, which is quickly lost as people leave or move to other
> jobs. In my work, it is important to be able to go back a number of years to
> determine the facts that were considered in arriving at a decision. This
> makes it easier to resolve new problems by putting them into proper
> perspective. It also minimizes the risk of repeating past mistakes. Moreover
> if important communications and actions are not documented clearly, one can
> never be sure they were understood or even executed.

In my limited experience, I have not seen this done effectively in a software
project. What does this actually look like when done properly? Ie, how do you
store the data and keep it from becoming busy work?

~~~
anon9001
Git is an immutable history of all work ever done on code.

Take a look here:
[https://github.com/torvalds/linux/commits/master](https://github.com/torvalds/linux/commits/master)

And here: [https://lkml.org/](https://lkml.org/)

Wikipedia does a pretty good job of maintaining document and discussion
history as well.

In both projects, you can pull on any random thread and trace it all the way
back to its origin. And if the team (and maintainer) is doing a great job of
capturing the thought process behind a decision in commit messages (as Linus
does so well), then you're in really great shape.

------
dang
One small past thread:
[https://news.ycombinator.com/item?id=18153566](https://news.ycombinator.com/item?id=18153566)

