Slashdot Mirror
How Do I Manage Seasoned Programmers?
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.
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.
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.
...and use Agile. Here is the best book in the world: Agile estimation and planning
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.
Like anyone's going to listen to someone who thinks irregardless is a word, regardless of the merit of what they said
My other sig is extremely clever...