Engineering Manager

The hardest part of becoming an Engineering Manager isn't learning something new — it's giving up the thing you're already good at. Google's and Amazon's current EM postings describe a job that looks, on paper, like a natural next step for a strong senior engineer: own a team, set a technical roadmap, review architecture. In practice, it's a different job with a different success metric. You stop being measured by what you personally ship and start being measured by what your team ships, whether they're growing, and whether the org trusts your judgment when things go wrong.

That shift trips up more people than any technical gap. A new EM's first instinct under pressure is often to grab the keyboard — to fix the bug themselves because it's faster than coaching someone else through it. That instinct, run for too long, produces a team that never develops the skills to solve the next version of the same problem, and a manager who's secretly still doing an IC's job with a manager's title and none of the actual leverage. The core skill is delegation that actually develops people, not delegation that's really just deferred rework.

The technical bar hasn't disappeared, though — current EM roles still expect real architecture and code-review judgment, and increasingly, fluency with AI-native engineering workflows well enough to guide a team through them, not just approve budget for tools. The mastery path treats people leadership and technical leadership as equally real skills, culminating in a capstone that requires setting a team charter, a technical roadmap, and the operational systems (priorities, quality, reliability) that make both work together.