Hacker News Reader

Comment by arctangent | Hacker News Reader

I can't agree with you more.

But let me briefly offer an insight about why I think things won't change: management itself exists to perpetuate the things on the left hand side of your equations above.

Traditional managers in established (i.e. large) companies are terrified of letting their staff work from home because they perceive (correctly) that if those staff are still productive then there isn't really any reason for them to be employed in their own role.

The things on the left hand side of your equations are a proxy for success that the manager can use to justify their own usefulness. As soon as you start measuring "real" progress the need for non-productive members of staff disappears entirely and most middle management instantly becomes surplus to requirements.

View on HN

I don't have much experience with managers because I freelance now and I've never worked at a company with more than about 80 or 100 people.

So this is a real question and not snark... Assuming large companies continue to exist, how do you run one without managers?

If your company is 1000 people do have 10 executives and 990 engineers, customer support, etc. and no managers at all? How does everyone communicate? How do the executives delegate?

Do you need some managers? How many per worker is optimal?

It seems like every large corporation in existence has managers. I can't think of any exceptions. So I'm not sure what an alternative would even look like. Perhaps rotating temporary management structured like jury duty?

I'll probably be downvoted because bashing management is a time honored hacker pastime... But I really am curious. Is it possible to do away with management? Is it desirable?

Oh, you definitely need some managers. I'm not suggesting that we should do away with them completely :-)

In the past (i.e. prior to what we sometimes call "the information age") it was a perfectly reasonable thing to have a very tall pyramid shaped hierarchy within a company. This was because the people at the bottom of the hierarchy needed to be told what to do and how - i.e. the manager was the "expert" at some task.

Nowadays people at the bottom of the hierarchy (especially in technology) tend to know exactly how to do their jobs - in fact they know much more than their manager about their own specialty. This has led (in savvy organisations, at least) to much flatter hierarchies.

> Do you need some managers? How many per worker is optimal?

http://en.wikipedia.org/wiki/Span_of_control

"In the hierarchical business organization of some time in the past it was not uncommon to see average spans of 1 to 4 or even less. That is, one manager supervised four employees on average. In the 1980s corporate leaders flattened many organizational structures causing average spans to move closer to 1 to 10. That was made possible primarily by the development of inexpensive information technology. As information technology was developed capable of easing many middle manager tasks – tasks like collecting, manipulating and presenting operational information – upper managers found they could hire fewer middle managers to do more work managing more subordinates for less money."

Do you really think that managers 80 years ago knew more about task X than the people they managed who did task X every day? I think software/info people like to think our situation is different, but I don't suspect it was all that different in the past. What may be different is that today we have the ability to get a lot more information at our disposal about what's going on in a company than people did 100 years ago.

I think technology has allowed people at the bottom of the pyramid to "own" larger pieces of responsibility within a company, thus allowing them to operate much more independently.

In the past this really wasn't the case. An entire discipline called "Scientific Management" sprung up to explain why workers should be treated almost like animals by management:

http://en.wikipedia.org/wiki/Scientific_management#Taylor.27...

I think this knowledge inversion where the "individual contributors" know more (about the job) than the manager is why many managers do not like agile methodologies like Scrum. Developers are "seizing the means of production". ;)

When developers can work directly with product owners and track their progress, the traditional manager loses. I'm not sure how a developer-driven team might handle HR issues though.

I'm not sure how a developer-driven team might handle HR issues though

There is a nuance here that is being missed, there is management and there is administration, management is authority and administration is coordination among contributors to keep the production line running. Many organizations mistake the two for the same roles as such they give to many administrators authority and make them managers. When many organizations could flatten their management hierarchy and create more administrative roles. HR is a good example of a business function that can be done via administration and not authority. The funny part is when you make people administrators they see themselves more like contributors and become less threatened by efficiency.

Thanks for the clarification. Is the administrator role you describe something like a program manager (PM) or scrum master?

Would you say a "tech lead" is a manager? They have (technical) authority of the product, but not necessarily hiring/firing of other people.

I generally consider leads and architects to be administrators same with project managers, if fact in a good deal of organizations that I have been a part of we did not call them project managers, we called them project coordinators or project liaison which better reflects the role.

Not every company has this fear. In fact, some large companies are the most progressive with the ability to work remotely and have a huge investment in infrastructure to support this. On the negative side, the employees become more replaceable in the minds of many execs. This includes project and middle managers, so it's not just on the leaf developers.

Agreed : out of sight = out of mind. It's a -lot- easier to think of remote workers as a pure commodity.

Indeed. Some people believe that there's no real productivity gain from all team members being located in the same place. However, one of the (potential) benefits of being located in the same place (as management) is job security. People grow attachments to others.

Plausible if you accept that problems can be broken into separate pieces. Furthermore, measuring/comparing the productivity is non-trivial/impossible.

You should read some Rands in Repose about the point of the manager job role.

At my previous employer, a high* level manager (3 levels above me - a leaf node developer), considered it his job to just shield his subordinates from demands/bullshit of those above him.

That's definitely a desirable quality, and leads me to believe he'd have other desirable qualities.

* In reality, middle management, but at the level where strategic decisions are made/strongly influenced.

The idea that management exists to perpetuate the things on the left is as cynical and generally wrong as the idea that coders exist to increase complexity and guarantee their own necessity. It is true only of the worst of either group of people. The best work hard to make themselves unnecessary.

>coders exist to increase complexity and guarantee their own necessity

Holds true in more cases than not, at least in my experience in the enterprise. "Writing your own X" when off-the-shelf solution is available is a dominant example of this.

In many companies the same rigid structures that allow them to operate with average and below-population-average employees reward those who can game them andreduce their own output to the lowest levels toleraed by the structure.

I have freed many good programmers from this trap, but not nearly enough and many remain to be saved.

I've seen the very worst managers a lot more frequently than the very worst programmers. While some structures may reward bad programmers, structures far more frequently reward bad managers and very often prvide them with a place to hide their inadequacies very easily.

That's because if a programmer is bad, work doesn't get done, and people notice immediately. But if a manager is bad, the subordinates often manage to get work done despite the manager, and the bad manager is in turn more likely to have a bad manager who doesn't recognize the on-going failure.

Reply on news.ycombinator.com