Trace the system in your head
One of the best engineering managers I've ever worked with was at Cloudflare.
Let's call him Tom, because his real name is Thomas Hill.
What did Tom do in his free time when he first arrived at Cloudflare? Read version control.
Especially the joints where his team's code integrated with that of other teams.
What was the result of his lucubration?
Tom knew everyone's systems better than they did and could facilitate and cut through the bullshit in meetings due to his deeper technical knowledge.
When he found himself in a contentious debate, or in a situation where another EM was trying to foist something onto his team that didn't really belong to us, Tom had the upper hand because he'd already done all the research.
I remember being somewhat in awe of this ability of Tom's. Someone from the security team might wander into our sector wanting to know more about how API keys were generated and managed.
Tom recited it from memory even though he was not expected to be shipping code himself.
There are a couple of caveats to this approach:
- You need to work at a large enough organization to have multiple teams but central version control
- You need to care enough to be good at what you do. This won't work if you're trying to phone it in
The longer I do this job, the more I notice the most effective developers and technical leaders doing the same thing. They have an impressive map of their company's territory in their heads.
They can point you to where you need to go - even if they haven't committed to the repositories they're referring to.
Trace the whole system in your head. Even the parts that don't belong to your team!