It’s something you tell yourself when you agree to go from developer to manager. You convince yourself that this new role is something you can do for a percentage of your time and you will fit in the same amount of development as you did before. You’ll work a bit harder, you’ll get up a bit earlier, you’ll do the odd bit at home. You won’t.
For the first few weeks you think, “I’ll just get over this initial settling in period then I’ll get down to some code”. You might get a bit done here and there but you’ll keep getting interrupted. The big feature for the big product that you were going to get done easily by the deadline is suddenly looking scarily incomplete. You start to scramble for any bit of quiet time to get it done, sleep becomes a distant memory.
Sooner or later the phone will be off the hook, Outlook will be closed down, the office door barricaded the light off and you’ll power through the remainder of the feature. You’ll be elated, you knew you could manage the team and get work done. You emerge from your programming cocoon triumphant, but something’s wrong, Jimmy, the junior developer, has been sat fiddling with his pet CMS project for three days because there was no one to tell him what to do next. Sven, your über-programmer, has taken it upon himself to rewrite your business logic in IronPython because the hardware he needed to develop his new feature against hasn’t been ordered yet.
Your team has become less productive as a direct result of your productivity. It’s hard to take but you need to realise that one of your major responsibilities is to remove obstacles from the path of your team not to churn out code. There will be much less work going out the door with your name on it and you need to adjust to that. Your success is now based on what the team produces.
You will go through denial, I’m pretty sure every developer turned manager does. You need to deal with this and get on with the task at hand. That’s not to say stop coding, you really don’t want to be that manager that is so distanced from the code base that they can’t make good decisions about it but you are going to have to strike a balance. Coding marathons are going to be a rarity but owning a small feature in each release is a good way to keep in touch without burdening yourself with something that will overtake your other responsibilities.
There’s no magic ratio for this, factors like the state of the development process you have inherited, the level of pragmatism of your team and the complexity of projects that are going on are going to cause you to adjust this ratio. Set it at something achievable though, if anything start on the low side, there’s going to be plenty of stuff to do.