Common guidance given to most aspiring engineering leaders is to delegate details and focus on the big picture. While generally sound advice (as your scope grows, the number of hours available in a day remains constant), it comes with an important pitfall: you’re risking becoming an ignorant and potentially harmful manager.

Engineering leaders grow through the ranks, typically within the same org so their understanding of how systems work serves them well when making high-impact decisions around prioritization, team structure, and generally strategic planning.

Over time the relevance of their past experience decays as underlying systems evolve. They no longer understand what’s slow or cumbersome in the development cycle and they don’t have a good intuition of the technical consequences of product decisions. For example, they might reorganize teams along some abstract notions of domains or user journeys without understanding that the code organization or production setup doesn’t allow for that yet, so teams end up even less productive than before as they step on each other’s toes.

This is especially true as leaders move to new companies: now they have no past experience or relationships to lean into and they will soon be asked to start making high-impact decisions without grounding in deep technical understanding. Eager to prove their impact, they frequently get ideas of doing major rewrites or migrations based on past experiences without fully understanding if those lessons are applicable at the new place.

It’s admittedly hard to disambiguate when people push back on your idea for good reasons (e.g. you don’t understand all aspects sufficiently) or bad reasons (e.g. people generally dislike change). I frequently got both.

It’s therefore critical for engineering leaders to know relevant architectural details of the systems they’re responsible for. When joining a new place, your first priority should be to understand the system well. And as engineers, we typically learn best by doing: make simple changes, understand the development toolchain, learn the architecture.

And this isn’t just a task for the first month on the job: make sure your understanding stays relevant. You’re in a high-leverage position, so costs of wrong decisions are high. Make sure you fully understand what you’re proposing. It’s easy to think you do (“how hard could it be?”), make sure you solicit opposing views to see if you do have all the answers. I certainly didn’t.