How Do I Manage Seasoned Programmers?
This recent post on Slashdot caught my eye. My advice:
Take genuine and deep interest in what they do. Celebrate their successes and get involved in their problems. Most programmers do what they do because they enjoy the work. They want somebody to appreciate their work, and they want somebody to understand the difficulties.
Understand what excites them and brag on this work. Be clear about obligations, deadlines and expectations, then ask what you can do to help. Take requests for help seriously. Your role (as a manager) is to be of service to them, not the other way around.
Spend time with them one-on-one to find true problems and understand the good things. Also spend time with them in a group (short daily meetings are a requirement), and look for recurring themes that could be problems that need your attention. Also look for issues of interpersonal dynamics within the group. When you see the "elephants head in the corner" bring it up point-blank. Preferably to the entire group. Facilitate the use of the group's skills to solve the problem.
Look for a member with leadership skills (who may or may not be the best technically). Delegate to them. The amount of delegation depends on if you'd like a backup, go-to guy who can solve unexpected problems when your gone, or if you'd like to train your replacement.
Take genuine and deep interest in what they do. Celebrate their successes and get involved in their problems. Most programmers do what they do because they enjoy the work. They want somebody to appreciate their work, and they want somebody to understand the difficulties.
Understand what excites them and brag on this work. Be clear about obligations, deadlines and expectations, then ask what you can do to help. Take requests for help seriously. Your role (as a manager) is to be of service to them, not the other way around.
Spend time with them one-on-one to find true problems and understand the good things. Also spend time with them in a group (short daily meetings are a requirement), and look for recurring themes that could be problems that need your attention. Also look for issues of interpersonal dynamics within the group. When you see the "elephants head in the corner" bring it up point-blank. Preferably to the entire group. Facilitate the use of the group's skills to solve the problem.
Look for a member with leadership skills (who may or may not be the best technically). Delegate to them. The amount of delegation depends on if you'd like a backup, go-to guy who can solve unexpected problems when your gone, or if you'd like to train your replacement.
posted by Steve at 6:43 AM
2 Comments:
Excellent, Steve! I agree 100% and, from my experience, would add one more item. Hopefully its not quite off-topic. In addition to bragging about team members' achievements in the short weekly team meeting, I bragged about their accomplishments to my directors.
When budget time comes around, its easier to justify the salaries of the senior programmers when leadership knows their support of the teams' success throughout the year. While compensation is not always a factor for our senior programmers, acknowledgement from leadership in terms of kudos and unquestioned salaries/salary increases is a huge thing, I have found.
I think I spent as much time managing up in this regard as I did managing my team.
If a development manager follows the principles you list, Steve, I believe she/he increases the chances of their team's success exponentially.
Well said, Steve. Agreed, Chris. I'll note the importance of accountability and the use of criticism with your group and individual team members.
Everyone f's-up now and again. Mistakes/issues comes in many forms: software bugs, device misconfigurations, passive aggressive behavior, unnecessary sarcasm, etc. Mishaps need to acknowledged and folks need to be held liable for the mishap for the sake of the individual and morale of the team. As Steve said, preferably issues will be address in front of the entire team. Mishaps should be addressed in a non-negative way; presented as opportunities for improvement.
No one's perfect. Being negatively critical invariably causes resentment. Focus on the fix. Work as a group to reform or create new processes that avoid recurrences of the same issue (a pre-release peer review for software bugs, face-to-face, facilitated conversations between yourself and team members who are rubbing each other wrong). Everyone on the team needs to know they'll be held accountable for their code/actions both individually and collectively. If they aren't, morale and productivity will quickly head south.
Post a Comment
<< Home