Managers should get good at RTS games. A lot of the same principles apply - * production vs process - you can spend resources on improving process(usually to

Managers should get good at RTS games. A lot of the same principles apply - * production vs process - you can spend resources on improving process(usually tooling) to improve production but this isn't always an easy knob to tune and can have diminishing returns. "Automate all the things" is how I know you don't know what you're talking about. * DOTs - damage over time can be brutal, question every meeting and email that hits your team. Similarly- Engineers need large blocks of time to find flow and be effective(aka void rays). That 15 minute 2pm weekly check-in may seem trivial but you're pretty much nuking an afternoon's worth of productivity. * macro vs micro - you generally need to spend time on both. Even Sr. engineers can benefit from occasional guidance because you should know more than them(see below). (knowledge != intelligence) * bottlenecks/'stage III' production - you can have too many resources on something. * Some resources are much better at certain tasks than others. * situational awareness - know the executive roadmap, your roadmap, your internal customer's roadmaps, know 'the theory of how engineers are working in your org' and the reality. Know every project in your code repository. Know about most other possibly relevant open source technologies. Mostly this is just a lot of listening and reading. Be Omniscient * 'strats/build-orders' - similar to the above, know how the industry/competitors solve the same problems your org has (but don't necessarily seek to copy them) That said, treating people like RTS units is also a good way be disliked and ultimately be ineffective so you have to do the whole empathetic human thing.