The first time I managed a manager
Managing engineers is about the work. Managing managers is about the people they manage, seen through a layer you do not get to remove. The habits that did not transfer, and the ones I had to build.
When I first had a manager reporting to me, I did what had always worked. I asked about the projects. I read the pull requests. I dropped into the team channel and answered questions. I was helpful, I was engaged, and within two months I had made his job impossible, because his team had figured out that the real decisions came from me.
He told me, carefully, that he could not build authority with a team that could route around him. He was right. The habits that had made me a decent manager of engineers were actively harmful one level up.
The work is no longer yours
Managing engineers, the unit of work is the project. You can see it, review it, and course correct it. Managing managers, the unit of work is the team, and you see it through the manager's account of it. That layer is not a bug. It is the job. The manager has to own the team's outcomes fully, and every time I reached through to fix something directly, I took a piece of that ownership back.
So I stopped reading pull requests on his team. I stopped answering in his channel. When an engineer on his team came to me with a question, I sent them back to him, every time, even when I knew the answer and it would have taken thirty seconds.
What I ask instead
The 1:1 with a manager is about different things. Not the projects, but the people. Who on your team is at risk and why. Who is ready for more. What decision are you avoiding. What do you need from me that you are not getting.
And one question that I found more useful than any other: what are you worried about that you have not told your team yet? The answer is usually the thing we should spend the hour on.
Skip levels are not surveillance
I hold a 1:1 with each engineer on my managers' teams every quarter. The first time I did this, my manager was nervous, and he was right to be, because done badly it undermines him.
So the rules are explicit and I share them with him. I do not take work requests or make decisions in a skip level. I ask how things are going, what is working, what they would change, and whether they are getting what they need from their manager. If something comes up that he needs to know, I tell him, unless it is about him, in which case I tell him that too, but framed as feedback rather than as a report from a spy.
Skip levels are how I know whether the account I am getting matches the team's experience. Most of the time it does. When it does not, that is the most important thing I learn all quarter.
Coaching the manager, not the team
The mistake I keep making, still, is solving his problem instead of helping him solve it. He brings a performance issue on his team. My instinct says: here is what to do. What is actually useful is: what have you tried, what do you think is going on, what would you do if I were not here.
He grows when he makes the call. He stalls when I make it for him. And the calls he makes will sometimes be different from mine, and I have to let most of those stand, which is the hardest habit of the whole transition.
What I hold him to
Ownership is not the same as being left alone. The things I hold a manager to are clear and I say them early: his people know where they stand, his team's commitments are met or renegotiated before they slip, his engineers would describe him as fair, and he brings me problems before they become surprises.
If any of those slips, that is the conversation, and it is direct. The layer between me and his team means that a manager who is failing can hide it for a long time, and the cost lands on people who did not choose him.
The rollout, one level removed
Rolling out an AI first way of working through managers rather than directly was slower at the start and faster at the end. Slower because I could not just run the office hours myself. Faster because each manager owned adoption on their team, and the ones who took it seriously got there ahead of anything I could have driven centrally. The teams whose managers were daily users crossed 80% adoption. The one whose manager treated it as a program to be delegated stalled at 40%, and that number was the most useful piece of feedback I had for him all year.