techies and management

[cellio]

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.

Comments

[http://users.livejournal.com/merle_/]

I both agree and disagree with parts of both the original entry and yours.. which has made commenting difficult.

It seems clear the OP is one of the "old school" programmers who has been around for decades. Back in the 80s, you only went into programming because you absolutely loved it. That isn't the case these days. The rise of the internet and dot coms (which are still around, of course) has taught the world that "mere programmers" can be lucky and become millionaires in charge of their own companies overnight.. or, at least, if they get in on the ground floor, become managers.

Which is what a lot of people graduating with CS degrees over the last five years have been doing. Much as the high school kid takes a job flipping burgers not as a final career path, but as a means to an end (car, money, resume, whatever), college graduates are taking CS degrees to get in on the ground floor -- in order to become managers. I've seen so many programmers who are just hopping jobs after college, waiting for the company that will assist them with tuition for their MBA. And then they jump into management as soon as possible. It's just a savvy shortcut in the system. Most such programmers are just okay, and don't really do anything with computers on their off-time.

So I agree with the assessment as it applies to people who really crave coding. What she(?) is seeing is the new generation of people, who really aren't in it for the coding.

As to moving into management.. like you, I've been a tech lead. But unlike you, I do not want a formal management role, for two reasons. One is the dysfunctional company I work at: entrenched managers; reorgs twice a year; constant political infighting, backstabbing, and (honestly!) active sabotage of projects. The other is that, as you mention, the peon-vs-leader chasm is a bad thing if you want a bright and adaptive team. I cannot reconcile treating everyone as a peer if I have direct hire-or-fire control or have to decide on their raises. That's just how I'm wired.

What I did to gain my role at my current company (tech lead, product architect, what you will, but without the HR management side) would probably not work at many other companies. I started by talking openly with the other peons, asking questions as if they were the experts, dropping everything to help them if they had questions. Pretty soon I had an underground network, and my product (mostly ignored by management) lept up from being a cast off to being the flagship product. Management tried to take it over, but (a) being so schizoid they could not focus, and (b) after a year it became clear they knew nothing about the product, while the peons did.

So I am now the de facto product manager. People higher and lower ask me technical or design questions, ask for advice, and the like. It works because upper management does not see me as a threat (I "enable" them in some way), and everyone else is accustomed to working with me. I much prefer being the power behind the throne to sitting on it.

As I said, though, this technique would likely fail in most rational companies. But I would still prefer to be the technical lead giving advice to management to being a manager. And, as you note, if you are a very seasoned developer who apparently has no management skills, it is very hard to find a new job. I'm sitting in that boat right now: "what, just mild management skills after 17 years, and you still want to code?"