You can be proficient in both, maybe you are good at one, it’s very hard to be excellent at both – but the whole point is that you cannot fill both roles at the same time. It’s not going to work.
One requires focused effort and attention, the other constantly going out and reacting, protecting your team, growing it. You are the façade that makes your developers’ life easy.
What happens when you’re put in a position when you have to do both development and project management? If you’re wicked smart or know from the start, you refuse the job. You know it’s bound to fail – no need to waste your time. If you’re not so smart or you succeeded in either or both positions in the past, you accept the challenge and, when you realize how pointless it is, you quit.
You’re bound to find yourself sooner than later in a situation when the capacity of your team is below the expected output. That’s when the problems start.
If your “team” is new, that often happen because you don’t actually have a team in the first place: you have a a group of people. They are just an imperfect approximation what a team should be: people who fit very well together, knows each other strengths and weaknesses and how to compensate each others.
Your team needs to deliver more. You need to grow the technical talent in your developers or build more automation in your tasks. If you do the first, you’re thinking as a manager. If you do the latter, you’re thinking as a developer. Pick one and deliver. If you can do both, you’re doing a great job.
What happens when you can’t grow technical talent or you can’t build more automation fast enough? The worst thing you can do is to think that you can compensate by taking over more development tasks. That’s your basic instinct if you have a history as a developer, fight it! If you go down that route, you’ll do a big disservice to your team mates – they are the first to feel your lack of focus on management and they are not becoming better developers – and you fail your company – you’re trying to cope with contingent issues, but you’re not improving the team’s output on the long run.
You may even go that route in good faith. You may even have explained to your own managers that you boost your team output temporarily working overtime, since you’re working at 60% of your potential, or 8 hours per day, and you could put in 10/12 for a few weeks. DON’T DO THAT! They will only hear “60%” and consider you a slacker and chances are they haven’t read Slack.
The fact is, as a technical lead compensating by doing more development work is the wrong decision. You’re failing to apply the very lesson explained in that book: if something unexpected goes work, if something that you relied upon fails in unexpected ways, you have no more capacity to fix it.
What would someone with the instinct of a manager do? They would refuse to take over more tasks than his team can deliver, asking for the proper resources or the proper time to build up capacity. Maybe you did, but then you let your developer instincts take over. That’s a really bad idea.
