Nurturing programmers
April 4, 2005 8:21 AM Subscribe
How should we nurture programmers so that they can manage projects? (I think this is more general than programmers - I'd appreciate help from anyone who has been involved in moving people from technical to more managerial positions).
We've just lost an excellent programmer and I am trying to work out what we could have done to keep him. It's finally dawned on me that he probably has gone through a similar experience to me in my last job - I too am a programmer (a good one, I believe), was asked to lead a project, and, while strong on the technical side, hated both dealing with the powers that be and being responsible for the work of others.
I left to a new job; he's doing the same. Yet it's not always possible to bring in outside technical management skills, and our own management is already stretched thin (and perhaps not so good on the technical side).
Some of our work (thankfully) is either heavy on the maths or so small scale that one person can be responsible for both design and implementation. In those cases people like this are happy left to do their own thing, and produce results. But increasingly we are moving towards more ambitious projects with a hierarchical structure. Hence the pressure to change people.
How have others handled this? Is there some kind of pair approach where two people work closely together, one on the technical and one of the more people/power-oriented parts of managing the project? Should we provide some kind of training for programers in management? Or is the idea simply stupid - programmers are not managers and shouldn't be made (or even helped) to be so?
We've just lost an excellent programmer and I am trying to work out what we could have done to keep him. It's finally dawned on me that he probably has gone through a similar experience to me in my last job - I too am a programmer (a good one, I believe), was asked to lead a project, and, while strong on the technical side, hated both dealing with the powers that be and being responsible for the work of others.
I left to a new job; he's doing the same. Yet it's not always possible to bring in outside technical management skills, and our own management is already stretched thin (and perhaps not so good on the technical side).
Some of our work (thankfully) is either heavy on the maths or so small scale that one person can be responsible for both design and implementation. In those cases people like this are happy left to do their own thing, and produce results. But increasingly we are moving towards more ambitious projects with a hierarchical structure. Hence the pressure to change people.
How have others handled this? Is there some kind of pair approach where two people work closely together, one on the technical and one of the more people/power-oriented parts of managing the project? Should we provide some kind of training for programers in management? Or is the idea simply stupid - programmers are not managers and shouldn't be made (or even helped) to be so?
The first thing I'd say is that programming/design/technical skills are very, very different from project management skills. This is perhaps widely understood but not widely acted upon. When I was in my twenties the standard career path for a programmer was to move through analyst/programmer, systems analyst, business analyst (possibly: this stage was often skipped), project management...and beyond. For some of us it worked, for a whole lot, it didn't.
I have so often observed that there is a particular breed of highly-capable technical person who is just all wrongfor management. Equally, I have known many people start as programmers and become perfectly decent managers.
My current company has tried to develop two alternative (but equal - they say) career paths: one to satisfy the "traditional" curve towards management and one to allow someone to remain in a predominantly technical role but with greater responsibilities for larger and larger projects. This may include that notoriously vague role "team leader", but even that's not considered essential for recognition and visible seniority.
The key point is recognising that a highly skilled, highly productive, highly effective, highly responsible programmer/techie is every bit as valuable as a good manager (some might argue even moreso!). Once that recognition is truly accepted, and (here's the controversial bit) pay scales adjusted accordingly, things become much fairer and more manageable, and diehard techie satisfaction increases.
However, I have to finish with a does of reality: I can't honestly say my company's experiment has worked out too well; largely because the old attitude that seniority and skill = management dies very, very hard.
Good luck with whatever you decide to try. And if it works, write a best-selling business guide about it!
posted by Decani at 8:45 AM on April 4, 2005
I have so often observed that there is a particular breed of highly-capable technical person who is just all wrongfor management. Equally, I have known many people start as programmers and become perfectly decent managers.
My current company has tried to develop two alternative (but equal - they say) career paths: one to satisfy the "traditional" curve towards management and one to allow someone to remain in a predominantly technical role but with greater responsibilities for larger and larger projects. This may include that notoriously vague role "team leader", but even that's not considered essential for recognition and visible seniority.
The key point is recognising that a highly skilled, highly productive, highly effective, highly responsible programmer/techie is every bit as valuable as a good manager (some might argue even moreso!). Once that recognition is truly accepted, and (here's the controversial bit) pay scales adjusted accordingly, things become much fairer and more manageable, and diehard techie satisfaction increases.
However, I have to finish with a does of reality: I can't honestly say my company's experiment has worked out too well; largely because the old attitude that seniority and skill = management dies very, very hard.
Good luck with whatever you decide to try. And if it works, write a best-selling business guide about it!
posted by Decani at 8:45 AM on April 4, 2005
You must read, and have all your developers read How to be a Programmer (HTML , PDF). It's less than 60 pages but contains plenty of insight on how to do your job, do it good, and foster growth as a developer.
The sections on judgement, team skills, communication compromising and serving your team may all be relevant to what you're asking, or at least serve as an inspiration.
posted by furtive at 8:47 AM on April 4, 2005
The sections on judgement, team skills, communication compromising and serving your team may all be relevant to what you're asking, or at least serve as an inspiration.
posted by furtive at 8:47 AM on April 4, 2005
Response by poster: i agree with these being very different skills. trouble is, there are times when we need someone to manage stuff. how, if you like, do we make the best of such a bad situation?
posted by andrew cooke at 8:51 AM on April 4, 2005
posted by andrew cooke at 8:51 AM on April 4, 2005
Dammit, it occurs to me I didn't really answer the question, "How should we nurture programmers so that they can manage projects?"
Keeping it short, I do think the "by stages" method is as good as any. Give them team leadership responsibilities. Start with a small project or sub-project. Give them lots of help understanding what leading a team is about, what the important facets of it are. Team leadership - whilst a vague notion, as I said earlier - provides an opportunity for a good manager to introduce someone to basic management techniques at a level and speed which suits that person. But it must include help and guidance: all too often we see someone made a team leader for the first time and left to struggle through it unaided - often providing a marvellous scapegoat for a lazy or incompetent PM, sadly....
posted by Decani at 8:52 AM on April 4, 2005
Keeping it short, I do think the "by stages" method is as good as any. Give them team leadership responsibilities. Start with a small project or sub-project. Give them lots of help understanding what leading a team is about, what the important facets of it are. Team leadership - whilst a vague notion, as I said earlier - provides an opportunity for a good manager to introduce someone to basic management techniques at a level and speed which suits that person. But it must include help and guidance: all too often we see someone made a team leader for the first time and left to struggle through it unaided - often providing a marvellous scapegoat for a lazy or incompetent PM, sadly....
posted by Decani at 8:52 AM on April 4, 2005
I know that a lot of programmers are happiest programming and come close to actually resenting being forced to spend time managing others. But unfortunately in many companies, career advancement necessarily involves moving into management. Management considers this a step up from programming. They never consider that if you have a highly productive coder without management aspirations, it is counterproductive to move him (or her) into management. He (or she) will likely be unhappy, not to mention a lousy manager. In fact, you reward good programmers by giving them 1) more money and other perks, 2) recognition (e.g. make them "Member of Technical Staff Level 2") and most importantly, 3) more challenging programming tasks. #3 is what most companies forget. Programmers want to be challenged!
I would suggest looking at lightweight development methodologies such as XP (but not only XP), understanding why they have adherents, and trying to incorporate some of this methodology in your process. If you need to increase your programming staff, do it by creating small teams (no more than e.g. 4-5 people) each with its own sphere of responsibility relative to the product, e.g. one or two features. Allow the small teams to manage themselves and have one person in each team (e.g. the senior member or perhaps the one with the best people or management skills) responsible for architecture and integrating with the other teams' work. Mix it up from project to project and as Capn suggests, try different team leaders occasionally (but avoid those without the interest in doing so). Make one or two people with the knack or the interest responsible for the bigger architectural chunks (they should also be responsible for some of the coding, though not as much as others -- it is important that they have their fingers in the code, so that they know the implications of their design decisions, and that their design skills are respected by the other coders) and have at most another person or two responsible for monitoring the progress of the teams and making sure they're on track.
posted by kindall at 9:02 AM on April 4, 2005
I would suggest looking at lightweight development methodologies such as XP (but not only XP), understanding why they have adherents, and trying to incorporate some of this methodology in your process. If you need to increase your programming staff, do it by creating small teams (no more than e.g. 4-5 people) each with its own sphere of responsibility relative to the product, e.g. one or two features. Allow the small teams to manage themselves and have one person in each team (e.g. the senior member or perhaps the one with the best people or management skills) responsible for architecture and integrating with the other teams' work. Mix it up from project to project and as Capn suggests, try different team leaders occasionally (but avoid those without the interest in doing so). Make one or two people with the knack or the interest responsible for the bigger architectural chunks (they should also be responsible for some of the coding, though not as much as others -- it is important that they have their fingers in the code, so that they know the implications of their design decisions, and that their design skills are respected by the other coders) and have at most another person or two responsible for monitoring the progress of the teams and making sure they're on track.
posted by kindall at 9:02 AM on April 4, 2005
Depends on the size of your IT department, but you might consider hiring a project manager/business analyst who can deal with (my observed) banes of the programmer's existence: the entropy barrier of people-work, requirements/signoffs/documentation, and scope creep.
If your programmers are used to a DIY ethic, it can be ingrained so heavily that they view project management as an unproductive annoyance. That's your problem to solve.
There are a lot of good PM/BAs out there, and the right one is often worshipped if said specialist can get in the techie mud as well as ameliorate the above-mentioned occupational hazards.
If your firm is large enough to have to comply with section 404 of the Sarbanes-Oxley Act, or is a G10 country-based-bank and you have to deal with Basel II, you must change your programming culture. But don't do it by flanging on 'project management' to existing responsibilities. Start small. Select two of your leading programmers, ask if they can delegate 20% of their work so you can send them to a good project management boot camp. Maybe even commit to incent them at year-end with a one-time extra bonus if they successfully integrate project management into their work (be specific with them as to goals and deliverables, and above all, be realistic and make the goals/deliverables achievable and beatable).
This is a winnable challenge - the industry is trending to value coders less, and your programmers probably know it. The way to ehnance their contribution, and their overall 'marketability' is to build and imbue project management and business analysis skills steadliy over time.
But division of labor may trump all in the name of happiness and tranquiility, so getting a project manamer/business analyst might be speedier.
posted by nj_subgenius at 9:09 AM on April 4, 2005
If your programmers are used to a DIY ethic, it can be ingrained so heavily that they view project management as an unproductive annoyance. That's your problem to solve.
There are a lot of good PM/BAs out there, and the right one is often worshipped if said specialist can get in the techie mud as well as ameliorate the above-mentioned occupational hazards.
If your firm is large enough to have to comply with section 404 of the Sarbanes-Oxley Act, or is a G10 country-based-bank and you have to deal with Basel II, you must change your programming culture. But don't do it by flanging on 'project management' to existing responsibilities. Start small. Select two of your leading programmers, ask if they can delegate 20% of their work so you can send them to a good project management boot camp. Maybe even commit to incent them at year-end with a one-time extra bonus if they successfully integrate project management into their work (be specific with them as to goals and deliverables, and above all, be realistic and make the goals/deliverables achievable and beatable).
This is a winnable challenge - the industry is trending to value coders less, and your programmers probably know it. The way to ehnance their contribution, and their overall 'marketability' is to build and imbue project management and business analysis skills steadliy over time.
But division of labor may trump all in the name of happiness and tranquiility, so getting a project manamer/business analyst might be speedier.
posted by nj_subgenius at 9:09 AM on April 4, 2005
manamer=manager. sorry.
posted by nj_subgenius at 9:09 AM on April 4, 2005
posted by nj_subgenius at 9:09 AM on April 4, 2005
I am a developer who has done some ad-hoc project management from time to time on small projects, and here are some books I have come up with in my research. I have not read any of the books but they all looked like promising resources for me to puruse if I needed to progress further in that direction. The Accidental Project Manager, Herding Cats, Leading a Software Development Team.
posted by matildaben at 9:56 AM on April 4, 2005
posted by matildaben at 9:56 AM on April 4, 2005
Going to chime in here, I'm a programmer, been moving up the ranks from programmer to lead to development manager.
Just some thoughts not just from my growth, but how I've identified people who are capable of moving up.
You need to be able to identify people who are capable of managing other people. How to do this?
So what's left is manager #2, and a lot of good programmers can become good development managers. A development manager parses out tasks, understands the architecture of the system, communicates effectively with both the team and client.
So how to get there once you've identified solid, capable, bright people. Two halves here
Jsut some thoughts.
posted by patrickje at 11:13 AM on April 4, 2005
Just some thoughts not just from my growth, but how I've identified people who are capable of moving up.
You need to be able to identify people who are capable of managing other people. How to do this?
- Give people more and more freedom managing their work, at some threshold, you will find people who are capable of managing themselves and their work output given little supervision. If a person can't manage him/herself, there is no way he/she is going to be an effective lead/manager.
- Once you've identified capable people, give them small leads, let them lead one or two other programmers, but track their progress with the people they're leading. Some people don't like managing, a lot of people lack the interpersonal skills or desire to do that kind of work.
- OK, now you've found someone who is capable and interested. There are several types of managers. I'm going to condense here.
- Program/Project Managers In charge of managing client requirements, making sure deadlines are met, keeping an eye on the budget, but not too involved in the coding or system design.
- Development/Technical Managers In charge of managing a team of programmers, often does the system architecture, can vary, but usually codes 50-95% of the time.
So what's left is manager #2, and a lot of good programmers can become good development managers. A development manager parses out tasks, understands the architecture of the system, communicates effectively with both the team and client.
So how to get there once you've identified solid, capable, bright people. Two halves here
- Managing People There are a lot of good books out there on how to effectively manage people, the one I like is How to Win Friends And Influence People, an old chestnut, but basically says be nice, listen to people. Tells how to critize, how to suggest ideas.
- Documentation Oh the bane of my existence! Here is where a software development framework comes in handy, because it often comes with 'suggested' documentation. I personally use Microsoft Solution Framework with lots of padding from Steve McConnell books (Rapid Development, Code Complete, Software Project Survival Guide). There are other methodologies (SDLC, XP, Agile Programming, and a lot of others).
Jsut some thoughts.
posted by patrickje at 11:13 AM on April 4, 2005
Response by poster: thanks for all the info. i'm going to chew it all over for a week or so (while on holiday). i'm not in a management position (and another reason for asking is to prepare myself in case i'm ever pushed to become so again), but the group is so small/informal that if i can find anything useful to say, someone is likely to listen. the flip side of that is that i may end up saying things that are obvious/trivial to those whose job it is to care. hence the need to think things over.
posted by andrew cooke at 11:34 AM on April 4, 2005
posted by andrew cooke at 11:34 AM on April 4, 2005
I'm not a programmer, but I think you're right in that this question applies to other fields. I thought I hated management and left a job because of a bad experience like you describe. Luckily, at my next job they did it right and I'm comfortable leading a project now (still not my favorite thing, but I think I'm pretty good at it).
What worked: mentoring/coaching your new manager through the first project or two (one experienced go-to person who checks in regularly and can offer solutions to management issues), carefully defining the project first and keeping the focus narrow, giving the new manager power over the project and the ability to say "no" to last minute requests from upper management. The first point is probably easiest to make happen, I benefited a lot from being able to lean on someone who'd been through it all before. The second one is of course on the wishlist for every project, but I think the clarity of the goal is more important in a first project than the size of the project. Lastly, nothing leads to burnout faster than responsibility without power. The hardest part of learning to manage for me was managing my bosses. I had been trained to follow orders and fulfill requests no matter what, and I had to undo a lot of that previous training in order to accomplish the larger goal of completing the initial project.
posted by cali at 12:02 PM on April 4, 2005
What worked: mentoring/coaching your new manager through the first project or two (one experienced go-to person who checks in regularly and can offer solutions to management issues), carefully defining the project first and keeping the focus narrow, giving the new manager power over the project and the ability to say "no" to last minute requests from upper management. The first point is probably easiest to make happen, I benefited a lot from being able to lean on someone who'd been through it all before. The second one is of course on the wishlist for every project, but I think the clarity of the goal is more important in a first project than the size of the project. Lastly, nothing leads to burnout faster than responsibility without power. The hardest part of learning to manage for me was managing my bosses. I had been trained to follow orders and fulfill requests no matter what, and I had to undo a lot of that previous training in order to accomplish the larger goal of completing the initial project.
posted by cali at 12:02 PM on April 4, 2005
The three best project managers I know -- of programming projects -- have never written a line of code in their lives. A notable portion of the worst PMs in my workplace are former coders. I would strongly question the assumption that project management should be on a programmer's career track. This isn't to say that technical people are incapable of project management, but they are radically different skill sets. One does not "nurture" programmers into PMs if they aren't already management material.
If you are still determined to do this thing, despite a probable high rate of failure, I suggest starting with project sizing and scheduling skills. Teach these to senior level implementation leads, who are likely to be your best possible PM candidates. With some rudimentary scheduling skills under their belt, give them small-team projects -- activities that do not require assignment of a large group -- and co-manage with the new PM. Take a mentoring role rather than one of command and control hierarchy, because a brand new PM is going to need lots of help learning how to get things done, and in some cases, the activities that need to be done!
posted by majick at 2:37 PM on April 4, 2005
If you are still determined to do this thing, despite a probable high rate of failure, I suggest starting with project sizing and scheduling skills. Teach these to senior level implementation leads, who are likely to be your best possible PM candidates. With some rudimentary scheduling skills under their belt, give them small-team projects -- activities that do not require assignment of a large group -- and co-manage with the new PM. Take a mentoring role rather than one of command and control hierarchy, because a brand new PM is going to need lots of help learning how to get things done, and in some cases, the activities that need to be done!
posted by majick at 2:37 PM on April 4, 2005
I'm a programmer who became a manager. I was thrown into it without much training but I did a decent job. Part of that was due to my desire to be a manager along with my organizational skills and part of it was due to the team members themselves. I agree with majick, you can't make someone a manager if they don't want to or lack the basics.
I've known a lot of programmers who had absolutely no desire to be managers. Many of them were the most skilled and productive members of their teams. Forcing them to be managers would have been a mistake. On the other hand, offering management skills training to those who wanted the skills (I would have been one of them) allows them to essentially self-select. You will have to eventually separate out those who simply have ambition and lack skill, but the results should be worth it.
And don't forget the techies. A lot of companies I've worked for lacked a significant career path for those who didn't want to be a manager. Some of them became managers simply to keep getting raises.
posted by tommasz at 3:18 PM on April 4, 2005
I've known a lot of programmers who had absolutely no desire to be managers. Many of them were the most skilled and productive members of their teams. Forcing them to be managers would have been a mistake. On the other hand, offering management skills training to those who wanted the skills (I would have been one of them) allows them to essentially self-select. You will have to eventually separate out those who simply have ambition and lack skill, but the results should be worth it.
And don't forget the techies. A lot of companies I've worked for lacked a significant career path for those who didn't want to be a manager. Some of them became managers simply to keep getting raises.
posted by tommasz at 3:18 PM on April 4, 2005
I would strongly question the assumption that project management should be on a programmer's career track.
Seconded.
If you really want to give it a try though, start the prospective manager off with a project that has (a) a short timeframe, (b) a small team to manage, and (c) is not mission-critical. The programmer-turned-manager needs to be allowed to fail, something that a programmer is usually not comfortable with.
posted by SPrintF at 8:01 PM on April 4, 2005
Seconded.
If you really want to give it a try though, start the prospective manager off with a project that has (a) a short timeframe, (b) a small team to manage, and (c) is not mission-critical. The programmer-turned-manager needs to be allowed to fail, something that a programmer is usually not comfortable with.
posted by SPrintF at 8:01 PM on April 4, 2005
As someone who's helped a lot of coders, designers, IAs, etc. move into management roles, I would say the most important broader point--by far--is to be very, very open about the new skills you're asking people to demonstrate. Establish clear expectations of what they're expected to do differently as managers, talk with them regularly about what they're doing and how they're doing it, and then evaluate them honestly and often on how well they're doing it.
As far as the "growing means becoming a manager", I've always tried to establish a model where people can follow one of two basic routes--they can either become a "subject matter expert", or they can become a manager. Some people are just not cut out to be managers, but that doesn't eliminate the fact that if you're going to grow professionally, you need to expand your responsibilities. In an organization that's over a certain size, there's definitely room for some people to focus on things like R&D, and standards, and methodology, and just being a general black-belt-problem-solver.
You have to be honest with folks, though, that you really can't have half your team expect to become subject matter experts. The reason that most companies assume that growing means "becoming a manager" is that a good manager justifies their own position and the positions of several others. If your organization is going to grow at all, at least half your team has to be expected to evolve into managers over time, or you're just going to stagnate. If you need to grow aggressively, at least 75% of your team needs to expect to manage more as they grow.
Having a fixed-size team may seem appealing, but you're also talking about a fixed _income_ team, too--if people are going to want raises every year, the whole team has to be doing something bigger/better to make that possible.
posted by LairBob at 10:08 PM on April 4, 2005
As far as the "growing means becoming a manager", I've always tried to establish a model where people can follow one of two basic routes--they can either become a "subject matter expert", or they can become a manager. Some people are just not cut out to be managers, but that doesn't eliminate the fact that if you're going to grow professionally, you need to expand your responsibilities. In an organization that's over a certain size, there's definitely room for some people to focus on things like R&D, and standards, and methodology, and just being a general black-belt-problem-solver.
You have to be honest with folks, though, that you really can't have half your team expect to become subject matter experts. The reason that most companies assume that growing means "becoming a manager" is that a good manager justifies their own position and the positions of several others. If your organization is going to grow at all, at least half your team has to be expected to evolve into managers over time, or you're just going to stagnate. If you need to grow aggressively, at least 75% of your team needs to expect to manage more as they grow.
Having a fixed-size team may seem appealing, but you're also talking about a fixed _income_ team, too--if people are going to want raises every year, the whole team has to be doing something bigger/better to make that possible.
posted by LairBob at 10:08 PM on April 4, 2005
This thread is closed to new comments.
There are people who are excellent managers and ok programmers, and people who are ok managers and excellent programmers and a few very very rare people who are excellent at both.
If you have the time and the power, you need to start small. (Once again, I have no actual practical experience here, I'm just tell you how I, a programmer, would like to be treated in this situation). Make teams of three people to do a small project. Put one person nominally in charge. Rotate this over different projects, let everyone try to be a leader. This way you might find the people that have an aptitude for it.
posted by Capn at 8:44 AM on April 4, 2005