Too Many Leaders Spoil the Group | Hacker News Reader

Too Many Leaders Spoil the Group

psychologytoday.com

36 pointsbootload29 comments

The problem that I see is that people are heavily rewarded by being leaders, and so sell themselves as leaders even when the group incentive isn't there. I encountered this extensively in university, when seemingly every student was trying to be the president of their student group, or trying to found their own group of questionable value.

I see the same issue in the work world- executives are so heavily compensated that there's a strong incentive to become an executive, which requires one to act as a leader. However, that's often not what's best for the group.

Totally agree with that. The only way to get better pay for most people is to be a "leader" no matter you are suited for it or not.

Especially in the US there seems to be this emphasis on leadership. There is not much respect for people who are doing a good job.

I would say it is slowly changing with the Maker over Manager culture. Companies are valuing more makers and less managers.

Maybe they say that. The pay is still with managers.

Sure, why not. The word "leadership" doesn't really mean anything anymore. I have met very few good leaders in my day.

It definitely seems like most people leading companies are not any good at it. The best managers I've had haves simply gotten out of the way and defended us blindly. That's the best I've seen.

I'd love it if we adopted a culture of service, rather than "leadership". How can you be a good servant to others? It'll probably take you far, or it might not, but it has the virtue of being the least bullshit thing to do.

> I have met very few good leaders in my day.

This is true of anyone at any position. Most people are not good at what they do. In fact I'd say in any position in any company 70% are bad/less-than-good, 20-25% are just OK and 5-10% are actually great. It's just a fact of life, and almost unfair to pigeon hold 'leadership' in these types of articles when it really applies to everyone.

Unfortunately all the money is in leadership. Servants get paid as little as possible.

So many times.

If we take the (cough) hackers and painters analogy to weird places, software is painting.

Where when if you have everybody being creative, the vision can get watered down and not as good as it could be.

Companies are the same thing, when different people have conflicting goals, and want to express their creativity, it breeds conflict.

Some conflicts and checks and balances are good, but I believe the most creativity happens when groups are small, vision is unified, and everybody's more or less on the same page.

Working with sharp people is great, but often there are multiple equivalent choices. Arguing over A and B, or compromising to do a little of both, is often way worse than going all in on A or B and then moving on to the next task.

Wait.. am I reading the abstract of this study wrong or just misunderstanding what the author of the article is trying to say:

[Abstract http://psycnet.apa.org/journals/psp/110/2/261/]

"However, high power individuals were more effective when working on tasks that required less coordination: they were more creative (Studies 1B and 4) and persisted longer on a difficult task than other groups"

Then in the article:

"The control groups and low power groups generated more creative ideas than the groups made up of high-power individuals."

> "However, high power individuals...

I think that's best read as an aside. Low coordination to me reads as not really a group task, or less so.

Take someone used to being "high-power" let them work alone, magic happens. Put a bunch of high-power loners together and your in for a bad time.

A governor being the most "powerful" person in a state can be very effectual, but a group of them together in some sort coordinated task may be a disaster fit for tv.

> It was not that high power made people less creative, though. In a second study, the same power manipulation was used, but then people worked alone to generate a creative idea for a business. In this individual task, the high-power individuals were actually more creative than the low-power individuals.

My takeaway is that development managers shouldn't put a bunch of lead developers together on a project, unless the project is big enough that each leader could own an independent piece. Otherwise, toes get stepped on, folks start bickering, and progress grinds to a halt.

I kind of feel much adoption of "microservices" is not for technological regions but for human ones - to increase separation in architectual and code choices where just dividing work up by component wasn't enough.

I think it is more about two things.

1. Learn to flex across roles

2. Be specific about roles in a project/team/task

Sometimes you need a bunch of strong dudes working together on something. When you do, it is extra important to be specific about roles. Who decides when there is a tie or you are stalled? Who facilitates view points? etc.

If you dont have the flexibility to gracefully and effectively not lead, you are pretty one-dimensional. That doesnt mean the passive aggressive "well it is X's project so I guess he decides" way, rather it means to fully support and believe in the group structure you've set up for this thing, whatever the thing is.

Roles are something you flex into and out of, not something that defines you or is something "you are". If you let a role define you, you will be a lot less effective in getting stuff done.

For a programmer team, I like to look at the ratio:

  people writing code/people not writing code

The smaller the ratio, the less productive the team.

All other things being equal. With the right leadership it's feasible that adding a manager to a team of two programmers could increase overall productivity (rather than decrease it 33%).

Maybe, but you'll do better with 3 programmers, assuming they can manage themselves reasonably well.

Yes, I suppose adding 1 programmer to a team of 2 would be the same as adding a manager who increases each programmer's productivity by 50%.

Likewise for a team of 10 programmers, you can either add another programmer or a manager who increases existing productivity by 10%.

If you know a manager who can increase two programmer's productivity by 50%, I'd like to hear how he does it.

It seems unlikely (assuming the programmers aren't doing something stupid, like spending all their time on Facebook).

Tell me about it. Our team has 3 frontend developers and 5 backend developers. We also have 3 product owners, a scrum master, a heavily involved scrum master's manager, team manager, team manager's manager, team manager's manager's manager, then the CTO and higher.

Ignoring CTO and higher who aren't directly involved in day-to-day operations, we have 8 management level positions managing 8 developers. Every sprint is a clusterfuck of confusion wherein those 8 managers can't agree on what should be worked on. It's absolutely stunning that 8 people cannot organize work for another 8 people.

When I hear "scrum master who isn't also programming" a red warning flag goes up.

My favorite way is to take turns being scrum master, cycling through and switching on each sprint. That way everyone gets experience and understands better how the company operates.

I'm not opposed to a dedicated scrum master, but the issue I have is that I have yet to meet one who ever defends the developers' right to have the agile/scrum process respected. Really, they just wind up being another manager that happens to spend a lot of time in Jira. I've butt heads a lot with scrum people who bend over and say "yes" to every single (unreasonable) demand thrown at them from the business side. :'(

  > I'm not opposed to a dedicated scrum master

ok, here's something I've been wondering. Assuming your team is in the 8-12 programmer range (which is typical for an agile team), what does the scrum master do with all his time? How is there enough for him to do to fill up a full time job?

I would hope much of their time would be spent really organizing and understanding the scope of each project/task. In my experience, most tasks still get dropped into a sprint without anyone really understanding the full scope. I can easily see 40 hour weeks being spent making sure that everyone is signing off on well-defined tasks. Anything to help reduce the surprise factor is a win in my book.

Here is the stereotypical example of how too many non-programmers ruin the group:

http://blog.codinghorror.com/content/images/uploads/2004/02/...

Funny but true. If you have three people making decisions for one programmer, things are going to go bad.

I'm pretty sure that's not the point of this comic...

What's the point of the comic?

I think the problem is that it divides your focus, which is bad for success. If an entire group can focus on one goal, they will be much more successful.

Too Many Cooks Spoil the Broth.

Reply on news.ycombinator.com