I've been an engineering manager myself for the last 10 years and one thing I have also found is that I still like doing hands on stuff. You have to manage your own motivation, not just that of your team(s), regardless of what the "ideal way" to spend your time looks like in your environment.
Sure as a manager you have to plan, communicate, go to meetings, handle conflicts, prioritize tasks and so on. When all is said and done, keeping a slice of time doing what originally got you in the engineering business in the first place, might be just the thing that keeps you going.
That's a really great point. I like to reserve my Friday afternoons for side projects or learning. This gives me something fun to look forward to and keeps me in touch with engineering.
I think the challenge to lead people and remain technical, while being less hands on, is what contributes to so many engineering managers feeling imposter syndrome. It's a really tough mental switch to stop being hands on all the time and just accept that you have value beyond being hands on keyboard.
I have been an individual contributor at large corporations for more than 10 years. Every time I have had a colleague promoted to manager, they always planned to stay technical and keep coding. Every one of them, without fail, stopped coding because they were too busy.
Thinking back to my managers who left for other roles, only one quit to work in higher management, the rest all went back to working as developers.
I worked at giant, globally distributed companies (15-25k employees), so I imagine that my experience is not typical.
I've been promoted into management for over one year now, and I've barely programmed on the job. I find it hard to keep up with the details on the application, but I still make an effort to with news, and do some programming for fun on my on.
I think it's important for manager to still be able to make small contributions to the application. The manager isn't going to own a big new feature that takes several sprints to complete, but he can still debug or solve some bugs, or make smaller changes. He should also have an overview of the code's structure, and know about the technologies used to build the project.