
The abundance of slowness - muratmutlu
https://blog.marvelapp.com/the-abundance-of-slowness/
======
DelaneyM
I found overwork to be an issue when I began managing large (20+ engineer)
teams.

Unlike clients, it's not easy to set boundaries with employees. If something
is preventing their forward progress, or a decision needs to be made, my not
being there to intercede has a material impact on the company.

I don't want to ask people to not leverage flextime. I don't want to create
unnecessary hierarchy. I don't want to over-plan or enforce a less agile
methodology. So I'm chained to slack and email.

Less is written about large engineering team management, so it's not clear
what options exist. The solution might be to better delineate interfaces and
obligations between components and subdivide teams to match, in an inverse
application of Conway's law [1], but those abstractions are inevitably leaky
and we have thin tolerances.

It's enough that I'm reconsidering doing a tour at Google/Amazon/etc as a way
to pick up best practices from my peers at their director levels.

1:
[http://www.design.caltech.edu/erik/Misc/Conway.html](http://www.design.caltech.edu/erik/Misc/Conway.html)

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

