techies and management
gregbo linked to an article about
why
it's hard to keep senior developers doing development. The
author asserts that no self-respecting developer started his career
thinking "I want to be a manager!", but the natural progression is
toward technical leadership, management, or both. This progression
is captured, somewhat cynically, as the
Peter Principle.
The author of the blog article calls on developers to resist the urge. Remember that you love coding, he says. But I think there are good reasons to want to move in this direction, reasons that probably don't become apparent until you've been out there a while, and which I'm seeing now that I'm in that position.
I think I was a pretty darn good individual contributor when that was the main thing I did professionally. Because I work with a cool group of people in a business sector that already tends toward this kind of flexibility, I was generally able to get a hearing with the leaders -- product managers, tech leads, executives, et al -- because I'd proven that I had some clues. That means it was possible to have influence beyond my own little box. That's important to me. If I'm going to spend 40+ hours a week on something, I want to have some ability to make it matter. If I don't care, I disengage, and that's no good for job satisfaction or employer satisfaction. I need to believe that I'm making good stuff and meeting professional quality standards. Nearly a year ago, when the possibility of my current project first arose, I told our CEO-equivalent that if we're going to do this right I want to be deeply involved, and if we're not going to do it right I want nothing to do with it. He made me tech lead.
I've been a tech lead before, but this is my largest and most complex project so far, with potential to get much bigger, and it's been pretty nifty. I'm providing a lot of the technical vision, conducting design and code reviews, mentoring newer people, learning to be agile and adaptive (new requirements, discovering bodies in the code base, bugs, etc), and, in many ways, setting the agenda. I'm not the arbiter of requirements nor long-term strategy (and I don't have customer contact), but I have opinions there and a chance to get them heard seriously. Because I've been at the company a while, I'm seeing seeds I planted (as tech lead of a much smaller effort) years ago finally starting to take root -- this project is a logical follow-on, and in the intervening time I've gained some credibility. I think I can push out some good stuff beyond the confines of my own projects, and this role gives me better traction to do that.
I make sure I keep some individual-contributor work for myself, because I don't want my skills to rot and because I want to produce something beyond carbon dioxide and meeting notes. I also hold by the philosophy that, as much as possible, I shouldn't ask people on my team to do stuff I'm not willing to do myself. I might not be able to do it due to time constraints or (lack of) specialization, but I should strive to be able to, as much as practical. First off, it avoids that peons-versus-leaders chasm where the scut work falls to the so-called peons (today I started doing a particularly ugly merge, for instance). There shouldn't be peons; I want the people on my team to feel they have more power than that. Second, it improves overall adaptability if someone gets sick or hit by a bus or lured away by Google.
I'm also a manager (in the HR sense); I currently have three direct reports, two of whom I got this year. I used to worry that I would be bad at this, but so far that's working out ok. Part of that is excellent people. But I also find that I enjoy the mentor role. (And it's a small-enough group that management qua management doesn't consume a lot of time, except during performance-review season.)
All of this gives me a chance to increase my impact. I think I'm good at what I do and that I have a decent clue about what's good for our business unit on a strategic level, so this seems like a win to me. But it's not without risk; most significantly, I think, it can be hard to go back to the old role. I like this now, and I like where I think it leads for the next few years; beyond that is pretty hard to imagine.
Granted, I was never the type of senior developer the article is targetted at, but there are enough similarities with the sometimes-twisted path my career has taken to resonate anyway.
The author of the blog article calls on developers to resist the urge. Remember that you love coding, he says. But I think there are good reasons to want to move in this direction, reasons that probably don't become apparent until you've been out there a while, and which I'm seeing now that I'm in that position.
I think I was a pretty darn good individual contributor when that was the main thing I did professionally. Because I work with a cool group of people in a business sector that already tends toward this kind of flexibility, I was generally able to get a hearing with the leaders -- product managers, tech leads, executives, et al -- because I'd proven that I had some clues. That means it was possible to have influence beyond my own little box. That's important to me. If I'm going to spend 40+ hours a week on something, I want to have some ability to make it matter. If I don't care, I disengage, and that's no good for job satisfaction or employer satisfaction. I need to believe that I'm making good stuff and meeting professional quality standards. Nearly a year ago, when the possibility of my current project first arose, I told our CEO-equivalent that if we're going to do this right I want to be deeply involved, and if we're not going to do it right I want nothing to do with it. He made me tech lead.
I've been a tech lead before, but this is my largest and most complex project so far, with potential to get much bigger, and it's been pretty nifty. I'm providing a lot of the technical vision, conducting design and code reviews, mentoring newer people, learning to be agile and adaptive (new requirements, discovering bodies in the code base, bugs, etc), and, in many ways, setting the agenda. I'm not the arbiter of requirements nor long-term strategy (and I don't have customer contact), but I have opinions there and a chance to get them heard seriously. Because I've been at the company a while, I'm seeing seeds I planted (as tech lead of a much smaller effort) years ago finally starting to take root -- this project is a logical follow-on, and in the intervening time I've gained some credibility. I think I can push out some good stuff beyond the confines of my own projects, and this role gives me better traction to do that.
I make sure I keep some individual-contributor work for myself, because I don't want my skills to rot and because I want to produce something beyond carbon dioxide and meeting notes. I also hold by the philosophy that, as much as possible, I shouldn't ask people on my team to do stuff I'm not willing to do myself. I might not be able to do it due to time constraints or (lack of) specialization, but I should strive to be able to, as much as practical. First off, it avoids that peons-versus-leaders chasm where the scut work falls to the so-called peons (today I started doing a particularly ugly merge, for instance). There shouldn't be peons; I want the people on my team to feel they have more power than that. Second, it improves overall adaptability if someone gets sick or hit by a bus or lured away by Google.
I'm also a manager (in the HR sense); I currently have three direct reports, two of whom I got this year. I used to worry that I would be bad at this, but so far that's working out ok. Part of that is excellent people. But I also find that I enjoy the mentor role. (And it's a small-enough group that management qua management doesn't consume a lot of time, except during performance-review season.)
All of this gives me a chance to increase my impact. I think I'm good at what I do and that I have a decent clue about what's good for our business unit on a strategic level, so this seems like a win to me. But it's not without risk; most significantly, I think, it can be hard to go back to the old role. I like this now, and I like where I think it leads for the next few years; beyond that is pretty hard to imagine.
Granted, I was never the type of senior developer the article is targetted at, but there are enough similarities with the sometimes-twisted path my career has taken to resonate anyway.