
Too Many Leaders Spoil the Group - bootload
https://www.psychologytoday.com/blog/ulterior-motives/201602/too-many-leaders-spoil-the-group
======
fnbr
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.

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

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

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

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

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

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

------
chrisseldo
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/](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."

~~~
Terribledactyl
> "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.

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

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

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

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

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

~~~
developer2
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. :'(

~~~
ktRolster

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

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

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

[http://blog.codinghorror.com/content/images/uploads/2004/02/...](http://blog.codinghorror.com/content/images/uploads/2004/02/6a0120a85dcdae970b0120a85dd9b1970b-pi.png)

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

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

~~~
ktRolster
What's the point of the comic?

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

------
0xADADA
Too Many Cooks Spoil the Broth.

