I found overwork to be an issue when I began managing large (20+ engineer) teams.<p>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.<p>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.<p>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.<p>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.<p>1: <a href="http://www.design.caltech.edu/erik/Misc/Conway.html" rel="nofollow">http://www.design.caltech.edu/erik/Misc/Conway.html</a>