There's a gear-change that happens when you go from leading a team to leading teams of teams. It's not gradual. One day you're in the code reviews, the next you're in a room deciding whether to reorg.
Most writing about engineering leadership skips this transition entirely.
What Changes Structurally
You're no longer the closest person to the work. You might not even understand the technical details of every project your org is running — and that's correct. Your job shifted. You're not the expert anymore. You're the person who makes sure the experts have what they need.
The information flow changes too. You used to get signal from the code and the standups. Now you get signal from your leads, and the quality of that signal depends on how much they trust you with bad news.
What Changes Psychologically
Letting go of being the technical authority is harder than it sounds. You built your career on being the person who could solve the hard problems. Now your job is to hire and develop people who solve the hard problems, and to stay out of their way.
The mistake most new engineering leaders make: staying in the weeds. They keep reviewing PRs, attending architecture meetings, weighing in on implementation details. It feels productive, but it undermines their leads and prevents them from doing the work that only they can do.
What Your Actual Job Becomes
Context-setting. Your teams can't make good autonomous decisions without understanding the broader picture — business priorities, cross-team dependencies, organizational constraints. That context has to flow through you, clearly and consistently.
Unblocking. The problems that reach you should be the ones that nobody else can solve — cross-team conflicts, resource allocation, priority calls. If your day is full of decisions your leads could make, you've either hired the wrong leads or you haven't given them enough trust.
Culture. You set the standard for how the org communicates, debates, and ships. This happens whether you're intentional about it or not.
Driving back to established objectives. Holding your teams accountable that their work is advancing the roadmap. Not micromanaging the how, but staying firm on the why and the what.