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?"

33 of 551 comments (clear)

  1. Don't be a douche by Gothmolly · · Score: 5, Informative

    These are creative people, and will resist things like status reports and hard work schedules.

    --
    I want to delete my account but Slashdot doesn't allow it.
    1. Re:Don't be a douche by sheph · · Score: 5, Insightful

      No that's not flamebait, in fact, it's excellent advice. You can't run a department of advanced programmers the same way that you run a Burger King. Well, you can but you won't have any advanced programmers left if you do. Professionals typically don't enjoy working for someone that doesn't give them the respect that they've earned. Unreasonable timelines designed to drive results for the company will cause your employees to cut corners and deliver an inferior product. When this happens your good employees will no longer feel good about the job they are doing and go find a new one. Good products take time and money. If you want it fast, and cheap it ain't gonna be worth $h!t. Good employees want to work for good companies. It's a simple equation really.

      Status reports are a bunch of non-sense. Requiring your employees to file status reports tells me three things. 1) You don't know enough about what they are doing to manage them, 2) how long it should take, and 3) you don't trust them to work as professionals to deliver a quality product. That last part causes resentment, and if you really want good people to work for you then you treat them like good people until they give you a reason to treat them differently. If you don't care about the people that are working for you then just skip the preliminaries and go straight to managing a project full of Indian developers.

      --
      I don't believe in karma, I just call it like I see it.
    2. Re:Don't be a douche by gerrytucker · · Score: 5, Insightful

      As someone who has been a development team lead (responsible for schedules, explaining budget variances, providing cost estimates etc. to upper management) and a strong developer I would agree with some of what you are saying. However, the one item that I do have a problem with is the written status reports. I know it seems lame to the folks that really are great developers but you also have to contend with people who "think" they are really good developers. If you are having problems with individuals like that, HR and upper management cannot act on just a leads observations. They need documented evidence that either the person is or is not doing their job. Chances are, if the person really is not as good as they think and you need to get them off your team, their status reports will reflect how simple tasks are taking them extremely too long. And the best thing is, it's in their own words! The other benefit is that with the really great developers turning in status reports you have good objective evidence to show to HR types to say, "Look everyone else on the team performs exceptionally well. How can you not agree that this individual is an issue?" Just my 2 cents. Luckily I'm out of the team lead business for now and am having fun just being a dev and designer again :)

    3. Re:Don't be a douche by PitaBred · · Score: 5, Insightful

      I agree on most counts. When you're an ideal manager, your job is to shield your employees from the bullshit from above as much as possible, so they can get their work done as well as possible. That may sometimes require a status report or meeting or something so that you can report to the muckity mucks upstream on what's going on. But it shouldn't be a replacement for involvement with your employees. If you don't know what they're working on and roughly where they are in the task or what problems they're facing, you're doing it wrong.

    4. Re:Don't be a douche by mdvolm · · Score: 5, Insightful

      Of course your employees should do what is expected of them, they're being paid to do so. And you're right about the ego!

      The point, though, is that requiring silly things of your good people is a sure way to see them leave for something better.

      Do you think the quality of your company will not suffer if the highest quality employees leave?

      Then treat them with the respect they require, and they will return the favor.

      Formal status reports, by the way, definitely fall into the "silly" category, as do daily status meetings. If you want to know what someone is doing, then visit them and ask. You'll find that they're probably eager to tell you all about what they're doing.

      So while you had a nice rant there, I wouldn't want to work for you under those circumstances.

  2. Seasoned Programmers? by ColdWetDog · · Score: 5, Funny

    11 herbs and spices?

    Salt / Pepper / Oregeno?

    TFA doesn't really help.

    --
    Faster! Faster! Faster would be better!
    1. Re:Seasoned Programmers? by Anonymous Coward · · Score: 5, Funny

      The question was "How do I manage seasoned programmers", not "How do I season managed programmers"!

    2. Re:Seasoned Programmers? by Anonymous Coward · · Score: 5, Informative

      http://www.hp.com/retiree/history/founders/packard/11rules.html

    3. Re:Seasoned Programmers? by geniusj · · Score: 5, Funny

      lipstick!

    4. Re:Seasoned Programmers? by tomhudson · · Score: 5, Insightful

      Whatever the case, just remember that you're there to serve programmers...

      Actually, this is closer to the truth for MANY jobs than most managers would want to admit.

      In many jobs, the line employee has a better idea of what's going on, and the low-level nitty-gritty details of how to best achieve what has to be done, than the manager. Management of programmers should be about saying "these are the requirements', and NOT adding "and this is how you're going to achieve them". Rather, "These are the requirements; what do you need to make it happen, and how do you propose attacking it?"

      After all, as the article says

      Perhaps I should mention I am in my early 30s while the majority of the team constitute an older, wiser generation.

      ... also ... if you find resistance to the stated goal, maybe it's because they've "been there, done that" and your great idea isn't so hot after all.

      Too many people think "management" meand "dictate" instead of "collaborate".

  3. Specs by Coneasfast · · 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.

    --
    Marge, get me your address book, 4 beers, and my conversation hat.
    1. Re:Specs by Fulcrum+of+Evil · · Score: 5, Insightful

      Or admit that the requirements are somewhat in flux and take an iterative approach. There's nothing wrong with building a small chunk of the app all the way through, then expanding it. Depending on the specific app, of course.

      --
      "We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
    2. Re:Specs by the_banjomatic · · Score: 5, Insightful

      Or no specs at all. The last thing I want as an engineer is someone to come to me with their own solution they want me to implement.

      Good software engineers enjoy solving tough problems. So present them with the problems you are trying to solve and let them come up with their own solutions

    3. Re:Specs by Hognoxious · · Score: 5, Funny

      A proper functional spec does describe the problem.

      Or so I'm told, I've never actually seen one.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  4. Really, there's only one thing... by girlintraining · · 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.

    --
    #fuckbeta #iamslashdot #dicemustdie
  5. Beer by retech · · Score: 5, Insightful

    Beer, wine, whiskey and good food.

    Seriously, they're people. You make it sound like you're some exotic zoo keeper and you need to know what to do when they present their glowing red ass.

    Why don't you think: "How would I like to be treated?" With respect, open communication, acknowledgment of work done, incentive for above and beyond... and learn who they are.

    The fact that you cared enough to ask is a big step.

    1. Re:Beer by Dmala · · Score: 5, Funny

      You make it sound like you're some exotic zoo keeper and you need to know what to do when they present their glowing red ass.

      You know actually, I'd love to know what the correct response is when a programmer does this. I generally just run away.

  6. Flip every 5 minutes by Anonymous Coward · · Score: 5, Funny

    You don't want to touch them too often or they get tough and dried out.

    Oh wait, that's hamburgers. Nevermind.

  7. Listen, listen, listen by greg_barton · · 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.

  8. Re:Key Point # 1 by Hal_Porter · · Score: 5, Funny

    Yeah, watch some documentaries about pack animals or life in prison. That should give you some ideas for ways to communicate that you are the Alpha Male.

    --
    echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
  9. As a seasoned programmer I can easily answer this by thewils · · Score: 5, Insightful

    You don't have to. You are redundant.

    --
    Once I was a four stone apology. Now I am two separate gorillas.
  10. Re:Key Point # 1 by Ethanol-fueled · · Score: 5, Funny

    No, just the opposite.

    The manager should come off as being "cool" and sympathetic to the programmers. The managers should let the programmers know that, since he is familiar with programming, he has a genuine interest(and is also paying attention to ensure that the programmers are doing their job right) into what exactly is going on as opposed to just walking around with a clipboard pretending to do work and pontificating about deadlines.

    Interact with the programmers and ask them questions so that you appear to care and humor them by letting them be the master, you the learner, and that will quickly dispel any "We're seasoned pros, why should we listen to that pipsqueak?"-type attitudes. Stress that you are "one of the boys" and poke fun at yourself with PHB jokes while demonstrating that you're obviously not a PHB.

  11. Re:Key Point # 1 by Anonymous Coward · · Score: 5, Funny

    You have a good point. However, you still should get modded +1 douche for using the word "irregardless".

  12. Re:Key Point # 1 by gEvil+(beta) · · Score: 5, Funny

    Yeah, watch some documentaries about pack animals or life in prison. That should give you some ideas for ways to communicate that you are the Alpha Male.

    Absolutely! Piss in the corner of their cubicles or offices. Hit on their wives/girlfriends when they come around. Make their property yours. Let those guys know who's boss!

    --
    This guy's the limit!
  13. Oh for crying out loud by Weaselmancer · · Score: 5, Insightful

    Don't tell him that. He'll actually believe it.

    Here's what you should actually do: Manage.

    Be honest with your team. Tell them what you need and when you need it. Take advice from them on the best way to arrange that. If they're experienced (read that as set in their ways) forcing some oddball paradigm on them will send you permanently to PHB land. They'll never listen to you after that. You'll be regarded as an obstacle rather than a help.

    You're herding cats - never forget that. Let them do what they want in the way they want to do it and all should be well. Just make sure they know what your expectations are.

    And if you want something Lumbergh-like from them, say so. Then do the unusual thing and say why you want it. Don't just demand status reports from them. Ask for them, tell them you need these reports "because of pressure you're getting from your supervisor about this certain customer, and if we make schedule with this project they will potentially select us for the next project, and that means more revenue for the company."

    Talk to them as equals. Explain your concerns to them. NEVER talk down to them or enforce some odd idea that the manager caste is above the programmer caste. You are all equals on a team, sink or swim together.

    Do these things, ignore the buzzwords and manager-hype, be their fellow employee and the details will solve themselves. If these guys decide they like you your job will become a thousand times easier. You will always have loyal allies, rather than disgruntled drones.

    And best of luck. Don't just be a manager - be a good one.

    --
    Weaselmancer
    rediculous.
  14. Been there, done that by corporate+zombie · · Score: 5, Insightful

    Went back to the tech side.

    But the management stint wasn't wasted. It did make me realize there is a "bigger picture" that is always mentioned. I'd say the most important thing is to get this across. Tell them there will be decisions made by you, sometimes that you have control over and sometimes not, that won't make a lot of sense at your group's level. If they're your decisions you have some hope of explaining them. If they are decisions made up the chain then give as much information as you have and point out that it made sense to someone at some point and since y'all are all getting a paycheck from the same company then those are the marching orders.

    Other than that just work to get your team the things they need. It's their work that will make you look good (or bad) so your job is to make sure they have the tools and time they need to do their jobs. If you give them that then they need to actually do their jobs and you will want to keep them accountable for that. Nothing says bad manager more than someone who ignores the slacker while everyone else is pulling their weight.

        $0.02,
        -CZ

  15. Very Simple by LibertineR · · Score: 5, Interesting
    As their manager, they will expect and respect ONE thing above all else.

    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.

  16. Re:Key Point # 1 by Xoltri · · Score: 5, Funny

    Also, dry humping them is a sure fire way to express your dominance over them.

    --
    -Xoltri
  17. Re:Key Point # 1 by Bobby+Mahoney · · Score: 5, Funny

    [mutates and goes into chaotic rage upon reading the word "irregardless"]

    --
    !#&*
  18. Re:Key Point # 1 by BLQWME · · Score: 5, Insightful

    The key to managing people is the same as anything else in life. Treat them with respect and dignity. Remember, "do unto others".

    --
    "Nobody shoots anybody in the face unless you're a hit man or a video gamer"- Jack Thompson
  19. Re:Key Point # 1 by naoursla · · Score: 5, Insightful

    I think you just described Micheal from "The Office."

  20. Be a friend first. Informal meetings, free food. by Khopesh · · 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 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, wiki, source control, project management, social networking). 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 practice and consider migrating the team to a scrum 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.

    --
    Use my userscript to add story images to Slashdot. There's no going back.