Look, No Pointy Hair
I have three roles. I code about half time. I'm project manager. And I'm team leader. Of these the hardest, most exciting, and most productive role is team leader. And yet I've only recently acknowledged to myself that managing programmers is what I do.
If asked "What are you?" the reply that comes most naturally is "a programmer". I've spent fifteen years working as a programmer. That's about half my working life. In terms of my attitudes and especially my cognitive style, I was a programmer for the other fifteen years, and always will be. But writing the code is no longer the hardest part of what I do.
Is this just my blind spot, or do we face it as a community? There must be more than one line manager for every ten programmers. But compared to the flood of literature on programming, there's little on managing programmers.
I'm writing this half way through some team training on TDD. Some team members are taking it on board, some are resistent. One thing that is noticeable is that none – apart from me – are accepting a share of responsibility for the outcome that the training has for the team as a whole. This is the highest leverage activity available. In relation to John Bennett's article, the best advice I know is "step up to the plate".
Welcome Back, Donna
Donna, thanks for the great response to Chris's post. It's good to read your posts after your summer off. :-)
Dan
Managers and Team Leads
Hi Chris,
I can relate to what you express in your post, and also to Donna's response. One thing that sticks in my mind since first reading it, though, is that I tend to not think of team leading as "managing." To me in order to be a "manager," one has to be one step removed from the action, so to speak. Shops have forepersons, teams have captains, armies have sargeants, and software shops have team leads. In my own career I've avoiding crossing that line from "lead" to "manager" deliberately, and in my roles as a team lead I've never thought of myself as a member of "management."
This is not to say that I necessarily attach a negative connotation to "management"--though certainly bad managers and bad management do happen. I view it rather as a functional difference, and a useful separation. The lead, sargeant, captain, etc. is close to the team on the ground, the grunts, and looks out for their interests while also fulfilling the aims of management. It is necessary and healthy for there to be an adversarial aspect to the lead-manager relationship, though there is probably a better word than adversarial given that the relationship must be based on mutual respect and a shared desire to fulfill the overall goals of the organization.
Anyway, these are just some thoughts that occurred to me after reading your post.
Dan
BTW, you mentioned the lack of good reading related to "managing programmers." Two books I can recommend are Gerald Weinberg's Becoming a Technical Leader and Jim McCarthy's Dynamics of Software Development
also MAY I ( humbly ) SUGGEST
you check out our podcasts and videos at www.mccarthyshow.com ?
Motivator and Buffer
Hello Chris,
It is refreshing to read about someone who recognizes the issues of being a technical team lead. I spent many hours just buffering team members from un-appreciative project managers that can communicate with the clients and upper management effectively, but can slow progress with a few misplaced comments to programmers.
Just like you, I am and always will be a programmer first. Motivated happy programmers produce more. The stress of deadlines and project deliverables should be isolated as much a possible from individual programmers and with a team lead being a little bit of both he/she can assume that responsibility and communicate to both sides.
I look forward to hearing more from you. Please post any resources you have found on programming team leadership. I agree reference on this topic is sparse.
Behind closed doors
I'm with you brother, and I could tell some stories that are most definitely stranger than fiction about managing programmers. To remain gainfully employed; however, I will have to remain frustratedly mute. That's the one thing that may be hardest. You have staff members doing all kinds of insane (INSANE) things and for the sake of their privacy as well as human decency, you can't discuss it with a soul. You can't say, "Is it just me, or is this INSANE?" And then (if I may be so bold) you face sometimes very overt criticism (such as right here on d.*), claiming that managers are stupid, evil, etc.
We got there (a position managing programmers) because we programmed well and managed projects well. Yet, because we've become managers we've suddenly had a brain dump? People can try to tell you what it's like, but I have to say I never imagined I'd have to deal with some of the things I've been subjected to. You encourage the discouraged, take the blame for failures, but step back modestly and allow the programmers to take credit for the successes (even when they had to be prodded and encouraged). I honestly believe everyone should be given the chance to manage a group of former coworkers because they would be astonished by all that goes on behind closed doors (despite the ridiculously thin walls).
Returning to your blog title "Look, No Pointy Hair," I will say that Mr. Nilges has crept in the back door to our defense by objecting to the stereotype that the Dilbert cartoon propagates (which includes the pointy-haired manager buffoon). Having said that, I still laugh at Dilbert.
Why do we hesitate to say we're managers? It sounds so water-downed, anemic and impotent....like a medical doctor becoming an administrator. An administrator at an HMO might actually make more money, but it doesn't seem to carry the professional credibility of one who saves lives.
Personally, I think managers of software developers are caught between a rock and a hard place and our encouragement and professional pride has to come from deep within, because it's doubtful we'll be acknowledged in this lifetime.