Hi! I am a longtime developer with a passion to empower other developers to be their best. I focus on cloud development and everything related to data access from .NET and .NET Core.
Yes, it's possible. Not ideal, but possible. I spent 10 years in consulting both managing and delivering code. There is no "one-size-fits-all" answer. For example, if I'm on a single project as technical lead it is possible to divide my time between managing, removing roadblocks, enabling other team members and contributing to the bottom line by building features and completing stories. On the other hand, if I'm on a dozen projects then I probably won't be very effective as a contributor and could end up negatively impacting things.
There is also the question of timeline. In many projects I led, I would start out in a very hands on role and help provide initial guidance and architecture. Then I'd transition to having less of a hands on role and shift responsibility more to the team.
My personal philosophy is that there is a nuanced line between a person responsible for the team (interviewing, feedback, support, etc.) and a person responsible for the project (staffing, delivering, removing roadblocks, clarifying expectations, etc.). Sometimes those roles overlap, but while team management doesn't require hands-on, managing the project does. It is tough to help resolve conflicts if you're not knowledgeable about the code base or in the trenches with the team to understand what they are facing.
It also depends on a certain extent what your personal desires are vs. the flexibility of the role. I never wanted to be ivory tower management, and always wanted to have some stake in the game just because I love both coding and managing and never felt they had to be mutually exclusive. If I wanted to stop coding I could have easily changed the makeup of the team to ensure there was no need for me to be part of the critical path for delivery.
There is a great metaphor for building a pyramid with massive blocks. Imagine them attached to ropes so that a team can pull them up a ramp to put them in place. I always focused on roles that let me grab the rope and lead by pulling it up the ramp with my team alongside me, and purposefully avoided roles that would have forced me to sit on the block, point up the ramp and expect my team to do all of the pulling.
That's a great bit of input Jeremy, thanks so much for that. It's good to know that it can work and the feedback I'm getting is that it seems to be a 'in the right situation' scenario -- which seems to describe life really doesn't it!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yes, it's possible. Not ideal, but possible. I spent 10 years in consulting both managing and delivering code. There is no "one-size-fits-all" answer. For example, if I'm on a single project as technical lead it is possible to divide my time between managing, removing roadblocks, enabling other team members and contributing to the bottom line by building features and completing stories. On the other hand, if I'm on a dozen projects then I probably won't be very effective as a contributor and could end up negatively impacting things.
There is also the question of timeline. In many projects I led, I would start out in a very hands on role and help provide initial guidance and architecture. Then I'd transition to having less of a hands on role and shift responsibility more to the team.
My personal philosophy is that there is a nuanced line between a person responsible for the team (interviewing, feedback, support, etc.) and a person responsible for the project (staffing, delivering, removing roadblocks, clarifying expectations, etc.). Sometimes those roles overlap, but while team management doesn't require hands-on, managing the project does. It is tough to help resolve conflicts if you're not knowledgeable about the code base or in the trenches with the team to understand what they are facing.
It also depends on a certain extent what your personal desires are vs. the flexibility of the role. I never wanted to be ivory tower management, and always wanted to have some stake in the game just because I love both coding and managing and never felt they had to be mutually exclusive. If I wanted to stop coding I could have easily changed the makeup of the team to ensure there was no need for me to be part of the critical path for delivery.
There is a great metaphor for building a pyramid with massive blocks. Imagine them attached to ropes so that a team can pull them up a ramp to put them in place. I always focused on roles that let me grab the rope and lead by pulling it up the ramp with my team alongside me, and purposefully avoided roles that would have forced me to sit on the block, point up the ramp and expect my team to do all of the pulling.
That's a great bit of input Jeremy, thanks so much for that. It's good to know that it can work and the feedback I'm getting is that it seems to be a 'in the right situation' scenario -- which seems to describe life really doesn't it!