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.
> My not being there to intercede has a material impact on the company
Whether we are talking about romantic relationships or client relationships, Setting boundaries inherently requires that you be able to say, "You don't like this. This hurts you. I'm going to enforce it anyway."
Once you say that, it frees you in the same way that immutable data types free you. Putting constraints on your own time means that "I should really figure out a different way to manage my team" becomes "It is my goal to manage my team in a way that accounts for me only being personally available for 8.5 hours". That makes a whole bunch of decisions clearer because you aren't in this ambiguous state of "well...maybe I can handle it all myself." It leads you to take the plunge and trust some of your direct reports with leadership/mentorship responsibility. It leads you to decide to make investments (which have real cost!) in your internal developer experience, testing, and documentation so that your junior engineers are more effective.
> I don't want to create unnecessary hierarchy
If you are feeling unable to respond to your reports, then is the hierarchy actually unnecessary? Within your 20+ team, how many other team leads or team mentors do you have? If you are the only one, than I guarantee you that you are not, will not, and can not succeed providing enough mentorship to junior engineers.
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.
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.
> 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.
yes, this is exactly right, and is why i have decided that fighting this kind of thing is a pointless exercise in futility, because someone, somewhere, always wants you to work more, or juggle more tasks during the time you are working. it's just how the business world works. it's actually what you expect out of a 'good' employee.
i am still young, which is why i'm in the process of selling ownership in my business and "being the change i want to see in the world" in my next venture, i.e. do something that doesn't involve a team, and therefore probably with a limited financial upside.
You being there might contribute to other side effects on your company's culture - you're setting the tone that it's ok or valuable to spend a long time at work (whether physically or virtually,) and more impressionable employees might do the "cannot leave before the boss leaves" routine. And even if you verbally stress the work-life balance, it becomes one of those "do as I say, not as I do" things.
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