[lucozade]

In my experience of running groups upto around 100 people, very few people are effective at directly managing more than about 10 others (preferably <7-8). I tend to struggle at more than about 6.

As such, for a team in the 20ish size I would definitely have 2-3 leads looking after the day to day support of the developers' needs. I've found that this is really in everybody's interest: yours as it gives you more time to concentrate on over-arching issues, the developers get more support and team leaders get experience making decisions.

Something I found early on was that it's often tricky to get the balance right between micro-managing and being hands off. The balance can differ with the abilities of you and the leads as well as the dynamics of the team. Obviously this is hierarchy but I'd argue it's not unnecessary if the lack of hierarchy isn't working effectively.

I've also found that the skills I've built up designing software apply reasonably well to organisations and processes. They often are susceptible to fragility, coupling etc in similar ways and can, to some extent, be designed out.

One other nice thing about running larger teams is that you can mitigate some of your own inadequacies. For me, I'm good at simplifying and solving problems. I'm truly dreadful at keeping on top of detail and pretty bad at day to day organisation. So I've found that having a "chief of staff" type person in my group works really well for me. YMMV of course.

[dver23]

I'm scoutmaster for my son's troop and this is one of the foundations for the BSA Patrol Method.(It's also talked about in lots of other leadership trainings) Once you move out of 6-8 in a group things break down quickly.

You also hinted at servant leadership. As a leader my goal to make sure the folks in the group have what they need to get the job done.

There are still management details, plans, schedules, budgets and what not. But, that's a separate thing from leadership.