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