How Do I Manage Seasoned Programmers? 551
An anonymous reader writes "I have a technology background and worked as a programmer for a few years before slipping over to the dark side. I am now on the business side and have been given responsibility for a small team of Java programmers. While the technology aspect of what my team works on doesn't scare me, I need ideas to make sure the team stays motivated while reporting to me, a business-oriented guy. Perhaps I should mention I am in my early 30s while the majority of the team constitute an older, wiser generation. What advice should I follow to avoid turning into yet another Bill Lumbergh?"
Don't be a douche (Score:5, Informative)
These are creative people, and will resist things like status reports and hard work schedules.
Specs (Score:5, Informative)
As a programmer, the thing I hate the most is having to redo code over again due to poor specs or bad design docs. Make sure they are organized and have the correct specifications.
Really, there's only one thing... (Score:5, Informative)
The big problem I see in people who are tech managers is a lack of understanding of project management. They're fine with people, if not missing some subtlety here and there, and it sounds like you've got a team that has few personnel problems. So focus on building your project management talents, which is about deadlines, coming up with objective measurements for progress, and setting realistic goals. Your team should be able to tell you where the trouble spots will be in the development cycle, how fast they expect to overcome each obstacle, and help you plot a roadmap, but only if you ask the right questions.
Re:Sorry (Score:1, Informative)
Re:Specs (Score:3, Informative)
Noooo... No specs means no one knows what is built or why. 6 months later when something changes, there is no baseline!
That said specs != a detailed plan on what to build, how and with what technologies / architectures. Specs = exact requirements as to what the business wants. You as the engineer get to figure out the how part.
Help them be productive (Score:3, Informative)
What you're responsible for is what they produce, not the people. If your team is composed of professionals, they will be self-motivated already. So focus on helping them produce. This means looking for what's hampering them and working to minimize/eliminate it, and looking for what could make them more productive and working to provide that. If you don't know -- ask. Talk to them, as a group or one-on-one, and find out what their "pain points" are or what they want to see done.
Never forget they are people, not "human resources", and treating them with respect and consideration will earn you major props.
Thomas
Give them space to do their jobs (Score:3, Informative)
I've just spent 2 years managing programmers who although not older, were generally much smarter than me, so I speak from relevant experience.
First of all you have one huge advantage; Software developers want to do great work. Coders are generally passionate and proud about what they do.
Your job is to make sure they have the environment they need to do that.
Programmers tend to be task-focussed people. Their faults are typically that they don't communicate unless asked, and they forget deadlines unless they are constantly made aware of them. Obviously I'm generalising here, but the balance of your team will probably tend this way.
So what you need to give them is clearly defined tasks, regular meetings where they talk to you and each other, and no excuse for not being aware of their targets/deadlines.
Most people, and geeks more than most, don't like to be ordered around and will be more invested in decisions they made themselves. Therefore when you make decisions about the development process, do it in a meeting. Say something like, "We need a more structured process for development." (Programmers will generally agree, they like order and structure, that's why they're programmers.) "We could use [insert favoured methodology here], what does the team think?"
If they have no stronger opinions, people will generally choose the one choice given to them and consider it to be their own idea from then on. If they /have/ got stronger opinions, they might well be worth listening to.
So in short;
Define the team methodology in as democratic manner as you can.
Get them to sign up to the methodology and make it theirs.
From then on enforce discipline with reference to the methodology. Your authority then proceeds from the team itself, as well as your position.
A couple of other piece of advice; be a hard-ass about defining requirements with your clients (internal or external) and even more so about changing them. Learn everything you can about software estimation. Most projects that fall over at the end make their mistakes at the beginning.
Re:Key Point # 1 (Score:2, Informative)
Be a friend first. Informal meetings, free food. (Score:5, Informative)
Assuming you're all in the same office...
One-on-one meetings in a comfortable and somewhat informal manner. Make it regular (twice a week or so?) and find some way to give them advanced notice indirectly, like doing it at the same time every week or passing by their office/cubes a few minutes before jumping in to ask for the informal report. If you startle them, leave and come back in a few minutes (really!). Their desks should be oriented in a manner that makes it hard to sneak up on them; if that's not the case, buy a mirror [google.com] for their monitor.
Group meetings at a less often interval (weekly or every other week) where everybody talks about what they're doing, and you reveal the long-term strategies, etc. Doing this over a free lunch or end-of-day beers (5:30p is "beer thirty" on "frosty friday" or "thirsty thursday," etc.) is always a winner. You already know most of the answers, so this is actually all for their benefit; this is when you report to them and they report to each other. This helps emphasize the philosophy that when co-workers are all friends, more work gets done with less apparent effort.
Never criticize them for something you also fail at. Instead, announce that you're looking to improve that aspect in yourself and they'll get the message.
You read Slashdot, so you're probably very IT-savvy ... older software engineers are a bit removed from that, so be careful about introducing new services (e.g. software services for bug tracking [mantisbt.org], wiki [wikipedia.org], source control [opensolaris.org], project management [project.net], social networking [facebook.com]). When you do such introductions, make sure they are walked through, and the installation process is trivialized (all the above examples are web-based to eliminate client-side installation).
Finally, pick up a book on agile development [wikipedia.org] practice and consider migrating the team to a scrum [wikipedia.org] cycle. Even if you decide it's not the right idea (or if you're already doing it), it will give you some management insight.
Re:Key Point # 1 (Score:5, Informative)
I will add to this as I have "been there, done that." As a manager of a group of programmers it's your job to be the bridge between them and their ideas, thoughts, feelings about the project they are working on and the company they work for, and the management that you report to, get budget from, sets goals and, ultimately, pays your paycheck. As the middle man in this scenario you have to take the arrows from both sides and figure out how to keep the team together and motivated, as well as meet you budget and deliver a product on time. These are not easy things to do with youngsters that don't know any better, but even harder to do with more mature, "seasoned" programmers.
What you need to understand is that as a new manager your role is to learn. The company hopes you learn from the mature programmers how best to get a project out the door. The programmers hope you learn how to balance your humanity with the needs of the company so their world doesn't get turned upside-down. My suggestion: Be as hands-on as possible with the project. This means that the unit you are in charge of becomes flat from an organizational perspective; only communication in and out of the group to and from upper management is filtered through you, and being the team leader when key decisions need to be made, differentiate you from the rest of the team. I have found that my teams respect me and my skills (both inside and outside the team's competency) better and I get to build a more human rapport with those on the team. You'll be surprised at how the mocking behavior will turn into good natured ribbing that you would expect in a tightly knit team. It won't completely eliminate malicious behavior because there's always someone in every group that will disagree with something you do, but it sure does let folks know you're not an armchair quarterback blindly following directives from upstairs. You will probably hone your programming chops in the process.
Bottom line, create an environment of mutual respect and allow the social interactions to progress at their own rate. Keep the team focused and motivated by being in the thick of things with them. Remember, it's your team and if you don't take ownership/stewardship/responsibility for them then why should they or management care what happens? They won't, because you won't be a manager for long.
Re:Seasoned Programmers? (Score:5, Informative)
http://www.hp.com/retiree/history/founders/packard/11rules.html