I think the move from managing engineers to managing managers is a bigger change than the move into management in the first place. The first move changes what you do. The second changes what you can see.
You stop seeing the work
A manager of engineers has direct access to the work: the pull request, the standup, the board. When something goes wrong, you often know before anyone tells you.
A manager of managers does not. Every signal arrives through another person's judgment: their summary, their sense of the week, what they chose to escalate. You are a step removed from the code and the people who write it, and that distance is permanent.
The instinct is to close the distance, to stay in the technical reviews and keep a hand on the work. I think that is usually a mistake, not because the information is bad but because the time comes out of the thing you are now responsible for, which is the managers themselves. The distance is not a problem to solve. It is the shape of the job.
Your output is other people's decisions
The decisions that matter to a team, who works on what, what gets reviewed how, when something ships, are now made by someone else, in meetings you are not in. Your contribution is whatever shaped their judgment before they walked in.
I have come to think of that as the real output of the role. So the time goes into what shapes judgment: being clear about what matters, explaining why, and talking through the hard calls afterward so the next one is easier. A few decisions I still need to be part of, usually about people. The rest belong with the manager closest to the work.
Different is not wrong
Every manager runs their team a little differently from how you would. At first every difference looks like something to correct. I think most of them are not. A team that is run differently from how I would run it, and is healthy and delivering, is a team that is run well. The question is not whether I would have done it that way. It is whether the results and the people are fine.
The exceptions are the things that have to be the same across teams: how people are treated, the standards the organization agreed to, and commitments to other teams. Those are not styles.
The feedback loop gets long
When you manage engineers, a change to how the team plans shows up next sprint. One level up, a change to how you support a manager might take a quarter to show in their team. You can no longer rely on tripping over problems. You have to decide on purpose what you will look at, and how often, because nothing will come to you until it is already big. For me that means a few regular questions for every manager, and a few things I check even when nothing seems wrong.
What success looks like now
As a manager of engineers, a good week was one where I did things. As a manager of managers, a good week is often one where I did little that anyone could see and the teams did a great deal. I think the measure of the role is what happens without you: the difficult situation handled without escalation, the decision made the way you would have made it by someone who did not need to ask. That can take a while to feel like work. The days with nothing visible to show for them are often the ones that mattered most.
Where this stops being true
On a small team, a manager of managers often still reviews code and makes many of the calls, and that is fine. The distance arrives gradually as the number of teams grows, and I think the mistake is to resist it when it does. None of this means stepping away from the technology, either. Staying close enough to ask good questions is the job. Staying close enough to make the decisions is the thing to give up.
Photo source: https://photos.robertstowe.com/cumberland-island