Doing a Job (1982) | Hacker News Reader

Doing a Job (1982)

govleaders.org

56 pointshenning14 comments

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.

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.

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.

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.

The rule seems invented to create more manager jobs.

And then all those managers need to report some activity to their superiors, which is how we get micromanagement, arbitrary changes in the project, meetings, evaluations, forms to fill, etc.

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

> 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?

I worked in a place where QA was cyclical - there would be too many errors, so they would add another layer of checks. Then someone would think, well, people are being too careless because they think the next layer will catch what they miss, so let's remove a step.

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.

That's because your code shop is not doing engineering.

> 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?

Don't document too much.

For what you do document, have a central repository with a clear organization.

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

Take a look here: https://github.com/torvalds/linux/commits/master

And here: 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.

One small past thread: https://news.ycombinator.com/item?id=18153566

Reply on news.ycombinator.com