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?"
Listen, listen, listen (Score:5, Interesting)
Listen.
Be open to criticism and be willing to change course in response to it.
Make sure when you do talk technical, you know what you're talking about. Feel free to ask questions if you don't know, and be able to absorb and express abck what you've learned.
If you need to make a decision based on "fluffy business stuff" that goes against the right theing to do on a technical issue, explain it thouroughly and be able to back it up. Geeks thrive on more information, not less.
Give the geeks freedom to graze.
Cattle prods, Electroshock therapy, and drugs (Score:3, Interesting)
What does responsibility mean? Can you fire them and increase their salaries? If so, then they should be relatively motivated to at least meet your expectations.
What can you do to make it easier? Don't be a bozo. That means (1) take the political heat for your team, and (2) try and insulate them from changes in specs. Or, (3) make sure they know what they're building/supposed to do.
Think of them as normal employees, not programmers. Sure they may be smart, but they're still people. Possibly weird, potentially infantile, probably high maintenance, and hopefully productive people, but they're still people. So treat them like everyone else.
Oh, and be sure to treat them like experts. They like that.
Ask for their input ... and actually listen to it. (Score:4, Interesting)
Seriously. People will tend to respond a lot better to you if they feel that they have legitimate input into the process, and many of those folks might be able to provide ideas and experience that you can benefit directly from.
Of course, I'm speaking as a 46-year-old programmer who's been doing software design/development for 20 years, so my bias is from the other side. Then again, most of the folks I tend to deal with are at my experience level or higher so in many cases *I* tend to be the youngster with the radical ideas. But I've learned to defer to my elders in many cases even tho I disagree. Sometimes they actually turn out to be right! ;-)
Ask them (Score:4, Interesting)
That's it. Pretty simple, eh?
If they are seasoned, keep out of their way, help them when they are frustrated, and make sure they are doing stuff they enjoy and keep them happy. They find a new technology they want to use? You make sure they get the opportunity to use it. They want a managerial job? You make sure they get the classes/seminars/education/opportunities they need. Your job is simply to remove obstacles that get in there way...
Simple really (Score:3, Interesting)
Re:Get out of their way! (Score:4, Interesting)
Developers are like creative people the world over -- you've got to keep them on track, and that means managing them properly. Again, I recommend the Scrum model.
Very Simple (Score:5, Interesting)
Bullshit stops at YOUR door. Whether coming down from your management, or headed up from one of your primadonna coders.
Your job is to provide the environment that best lets your people do what they do best. You are insulation, you are the sponge, you are the glue. All superfluous shit must be sandwiched and eaten by you.
Don't try to be technical, admit what you don't know and ask for explanations. Realize that coders consider their code as a mother does her children. If you criticize, you better be right, or you will be hated forever. If the baby is truly ugly, KNIFE it, don't adapt to crap.
NEVER turn down a legitimate request for tools considered necessary for their jobs. NEVER. Find the money, find the stomach to fight your management for the funds, and YOU make the arguments on your people's behalf.
This is how you get coders on your side. (that and free food and drink.)
You have to be the cog in the wheel.
Re:It's a lot like herding cats (Score:2, Interesting)
Re:Specs (Score:3, Interesting)
Kind of related to this is decision making. Don't put a decision off to make sure we know 100% the best possible solution. Usually a good-enough solution will work until more is known about the problem (especially if it contributes to the later solutions).
I've seen near a year lost on a project because management couldn't make the decision everyone knew they would.
Or you could make things easy on yourself... (Score:5, Interesting)
...and use Agile. Here is the best book in the world: Agile estimation and planning [amazon.com]
To micro-manage them is to underutilize them (and to frustrate them). Your job is to understand the business problems and communicate them as business problems, and let the team figure out the technical solutions...they should give you some alternatives, and let you pick the right ones. After that, your job is to ensure that nothing obstructs their development, and to take action whenever they tell you that they are blocked.
If you must be hard on deadlines, then you must be soft on requirements. Or vice versa. Being hard on both will always guarantee failure to deliver, and talent walking out the door. Usually being hard on deadlines is the choice of the day.....so being soft on requirements must be done, but *intelligently.* Some requirements are core to the usefulness of the app. Some are gold-plating. Move the gold-plating to the bottom of the priority heap. Each iteration will then represent the maximum possible business value that can be developed within the allotted time.
You also spend a lot less time trying to stick stuff end-to-end in making a project plan and having to spend more time changing it all around after things don't go as planned halfway through the project. Micro-managers tend to hate agile, despite the fact that it is a much more realistic addressing of the realities of software development than traditional, waterfall, winds up being.
Re:Get out of their way! (Score:4, Interesting)
I disagree, to a certain extent.
My job is to give estimates, draw up designs/estimates, handle bugs/features as requested, and ensure that my boss is up to date on how things are tracking to the plan.
In return, he acts as an interface with upper management, runs interference to make sure I'm not bothered by less important issues, makes sure I get appropriate lab/tester resources, handles priority calls between competing issues, and all the other stuff that I'd rather not have to deal with.
It's a symbiotic relationship.
Re:Very Simple (Score:3, Interesting)
Most advice so far concentrates on the obvious.
I will stay with the darker side that nobody likes to talk about.
Do not subordinate your will. You may be younger, but you have the authority. They owe you their duty, it us up to you to earn their loyalty. Let's say that again: it is up to you to earn their loyalty. Seasoned professionals respect strength and competence. We can smell incompetence and fear like a jackal. If you show strength, your team will actually help you achieve competence.
You are overtly asking for tactical advice, I believe you are actually seeking insight into the world and culture of your team. Don't just observe, become part of it and mold it as is your duty as manager.
Finally, avoid the mistake I have seen way too many young managers make: do not put them in your shoes. They have life experience you can only read about; you need to live in their shoes. Eventually you will find that we all wear the same shoes. Hmm, ok, that took the metaphor too far, but hey, I can't stay all dark and gloomy in this post.
Re:Key Point # 1 (Score:5, Interesting)
Like anyone's going to listen to someone who thinks irregardless is a word, regardless of the merit of what they said
Re:Don't be a douche (Score:3, Interesting)
will resist things like status reports and hard work schedules.
I disagree. I don't mind status reports and hard work. In fact, I immensely prefer a rational status reporting approach to an hour(s) long meeting of listening to everyone recite where -they- are with the project. JoelOnSoftware has some good thoughts on how to do this crisply. I would much rather take 10 minutes to summarize my status in a weekly email, and in fact have tried to force this discipline into my current team, against the resistance of my boss.
I think what experienced folks resent is stupidity and make-work. Working hard because you've got a challenging project is one thing. Being asked to work over the weekend because someone promised a demo on monday without checking with the team whether this was feasible is another.
To take care of experienced folks:
1) treat them as equals with different roles than yours. This means asking their opinion on approaches to be taken, acting on those opinions when they make sense, and offering rational responses when you disagree.
2) work with to communicate objectives in terms of -what- needs to be done, rather than telling them -how- to do it. The odds are good that they know how to do it.
3) shield them from the company bureaucracy as much as you can, while making sure you don't patronize them.
4) as much as you can, let them participate in the determination of the objectives and approaches for what your team is doing.
5) manage the meeting load, and run efficient meetings.
I don't think I'm any different as an employee at 50 than I was at 25, except I recognize idiocy and incompetence more quickly now. Your team will be the same. Geezer coders are still coders. We're just likely better at it.
Bologna. (Score:3, Interesting)
And you treat your kids like they're your friends rather than your kids?
A poor metaphor. You and your children are not equals. Not in any way. Not legally, not in terms of experience, nada. They need stern guidance. Most grown-ups (meaning both engineers and managers) do not. If they do, they need fired, not managed.
That being said, I do my best to be a friend to my son. 99% of the time a kind word works as well (or better) than punishment. I won't hold back though if punishment is called for though. I'm not soft. Just thoughtful.
Your statement about status reports would come across as BSing to me.
If you're incapable of responding to adult conversation and honest communication, that's your problem not mine.
Status reports help engineers focus their minds and keep their attention on track of what they need or have agreed to do.
Maybe if you have ADD it does. I know what my tasks are without having to explain them to someone every other day.
For the managers they help reassure them that they've understood that the engineers understand the requirements and direction
Only if the engineers you've hired are morons who have to have things explained to them over and over and over. If that is the case, go to careerbuilder and hire yourself a new batch of engineers. What you've got there aren't engineers, they're idiots.
They still have to talk to each other between reports though.
If you have motivated adult workers, this is certainly enough. Reports gathered from engineers who don't respect you won't add up to jack. I know this for a fact.
I once had a job where - for reasons too complicated to get into - the head of engineering had me working on a secret project. It was something we were working on, his boss said to stop it, but he told me to keep going on it. That meant I had to falsify status reports every week.
Yes, I was paid to lie. And from that experience, I learned two things.
1) You can lie your ass off on status reports. Either nobody reads them, or nobody understands them. My boss eventually admitted it was the first case. Too much work to babysit everyone. It's a psychological trick to make you work harder because you think you're being watched. Odds are, you aren't.
2) Because nobody is getting anything of value from them, they are generally useless.
I'm sure there are exceptions to this, and there may be a manager out there who actually reads his team's status reports. Probably as rare as hen's teeth, and I've never met one, but it's not impossible.
Re:Don't be a douche (Score:4, Interesting)
Anonymous status reports.. WTF.
Was reading the other day about a development house that has the programmers fill out time sheets and status reports but that these reports are specifically not used by managers and can not be used for punishment. They are used to generate cost and time estimates, what works, what doesn't etc etc. The group that handles these reports are independent and not the managers. They know that the second reports can be used for punishment or rewards most of the data will become fake and totally usable for statistical purposes.
Re:Key Point # 1 (Score:3, Interesting)