I think a lot of organisations (and people) fall into the trap of thinking of an engineering manager as a more senior tech lead, when in fact they are very different jobs with very different modes of working.
As soon as you start taking on managerial work, your development productivity starts to fall rapidly. I've never found a happy medium, nor have I seen others achieve it. People who try to do both quickly settle on ~80% of one and ~20% of the other. Which is fine if you acknowledge that you can only do ~20% of the other, and that the shape of it is likely to look very different to when you were spending 100% of your time on it.
As others have mentioned, if you are an engineering manager and you still want to dedicate some of your working time to development, you have to take yourself out of the critical path. Nobody wants to hold up a release because you were working on an important part of it and you've been constantly interrupted all week with managerial work and meetings.
Instead, pick things that are either tiny or decoupled from the release process. Things like refactoring, non-critical bug fixes, documentation, tests, spikes. These are the kinds of things that won't fall apart if your development productivity is unpredictable and the kinds of things that are easy to put down and pick up again. As an engineering manager, you're interrupt-driven which is incredibly disruptive for focus. If you do write code, then it has to be the code that works within those constraints, or you'll end up being a blocker for the rest of the team and your managerial work will suffer as well.
As soon as you start taking on managerial work, your development productivity starts to fall rapidly. I've never found a happy medium, nor have I seen others achieve it. People who try to do both quickly settle on ~80% of one and ~20% of the other. Which is fine if you acknowledge that you can only do ~20% of the other, and that the shape of it is likely to look very different to when you were spending 100% of your time on it.
As others have mentioned, if you are an engineering manager and you still want to dedicate some of your working time to development, you have to take yourself out of the critical path. Nobody wants to hold up a release because you were working on an important part of it and you've been constantly interrupted all week with managerial work and meetings.
Instead, pick things that are either tiny or decoupled from the release process. Things like refactoring, non-critical bug fixes, documentation, tests, spikes. These are the kinds of things that won't fall apart if your development productivity is unpredictable and the kinds of things that are easy to put down and pick up again. As an engineering manager, you're interrupt-driven which is incredibly disruptive for focus. If you do write code, then it has to be the code that works within those constraints, or you'll end up being a blocker for the rest of the team and your managerial work will suffer as well.