As someone who has been a code-writing 'engineering manager' for 10+ years, much of this rings true, aside from the insinuation that I haven't been doing this a

As someone who has been a code-writing 'engineering manager' for 10+ years, much of this rings true, aside from the insinuation that I haven't been doing this all along anyway and that it's related to business cost savings. Yes, there is the added component of having to 'work' and 'lead' that can and does cause split-brain syndrome and stresses above what it's like to simply be doing the work, but that's how the role has always been for me and I don't see any reason I'd want it to change. Does this make me more or less effective? I certainly cannot answer that question but I do agree that much of what is laid out in the post about how to tackle the disparate work that comes with the role as it exists for me. 1. Delegate as much as possible. - This provides opportunities for your team - It provides space to do more strategic thinking - Remember that while the team may not operate at your level of expertise, they need opportunities to grow into that level and this is the best way for them to do it, even if it means more back-end leadership/management work on your end. 2. Block off time to do strategic work and leadership tasks - This is HUGELY important - If you're not finding enough time, delegate more (see #1) 3. Don't, at all, assume that leaders (you) are just doing leadership work - Keeping on top of the technology and architecture will likely pay dividends to you and the team - Work hard to try and work at the 100K foot, 10K foot, and 0K foot levels. This will help you be able to better help and understand the work of those working for you.