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.
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! ;-)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Best manager I ever worked under asked me my pain points, and what I wanted to do in the job and how I wanted to grow. He then proceeded to help me in those three areas.
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...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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.
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
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.
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.
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...
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.
This was a great comment. I would also add a couple of other things: 1) Unfortunately, as a manager you are also responsible to those outside the team as the representative of the team. This means that you really DO need the status reports, so you can honestly tell those outside the team what is going on. This is as important for the team members as for those outside; the team members WANT and NEED you to be that representative, so they can be creative, constructive, and complete their work without interference. One of my old bosses (the CIO of the company, at that time), had a great slogan: "Perception is reality". If those outside the team perceive that you have a handle on things (even if you don't), they will leave the team alone to get things done. Similarly, if the team perceives that you are shielding them from the outside pressure (even if you aren't succeeding), they will be willing to put up with a little "management intrusion" into their creative processes. 2) Sometimes, it's good to disguise things. For example, several years ago I took over a team from another project manager. This project manager had a half-hour meeting every morning, where each member of the team (15-25 people) stated what they had done yesterday, the hours spent on each task, what they planned to do today, and how many hours they had available. My upper management insisted that these meetings continue. Needless to say, they did not go over big with the team. So, I changed the meeting to a problem-solving session; someone would throw a problem on the table, and the whole team would present solutions. I facilitated, using my technical knowledge to bring the right skillsets to bear, come up with a potential solution, and assign the details of testing that solution to team members (even if they weren't the original programmer). As this problem solving went on, I gathered enough information to determine who was on and off schedule, which allowed me to manage the schedule and the budget. Quality went WAY up.