Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

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?"
This discussion has been archived. No new comments can be posted.

How Do I Manage Seasoned Programmers?

Comments Filter:
  • Don't be a douche (Score:5, Informative)

    by Gothmolly ( 148874 ) on Friday December 12, 2008 @05:08PM (#26095811)

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

    • by ColdWetDog ( 752185 ) on Friday December 12, 2008 @05:10PM (#26095825) Homepage
      11 herbs and spices?

      Salt / Pepper / Oregeno?

      TFA doesn't really help.
    • by Anonymous Coward
      They must understand that you are the boss. They must answer to you, irregardless of what fancy degrees and experience they have. Without order, only chaotic code will result.
      • by Hal_Porter ( 817932 ) on Friday December 12, 2008 @05:17PM (#26095955)

        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.

        • by gEvil (beta) ( 945888 ) on Friday December 12, 2008 @05:26PM (#26096111)
          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!
        • Re:Key Point # 1 (Score:4, Insightful)

          by try_anything ( 880404 ) on Saturday December 13, 2008 @06:02AM (#26101425)

          There's an alternative theory of human social structure, in which men naturally organize themselves into a hunting band with one leader over a group of more-or-less-equals. The leader maintains his position because the other guys like him and trust that they will be successful under his leadership. The leader usually isn't even be the roughest, toughest guy. The biggest sin in this kind of group is overvaluing yourself relative to your contribution to the group: arrogance and selfishness are punished.

          That's quite different from wolf pack model where there's a heirarchy from the strongest at the top to the weakest at the bottom. The only sin in a wolf pack is weakness: weakness is punished ruthlessly.

          In a wolf pack model, the manager would have to be the best coder, the strongest personality, or the toughest hombre. But in real life the manager is usually a poor (or washed up) coder who is allowed to play a "superior" role because the people under him believe the group will be successful under his leadership. Managers who believe they are better than their underlings face constant undermining and insubordination.

      • by Ethanol-fueled ( 1125189 ) * on Friday December 12, 2008 @05:22PM (#26096045) Homepage Journal
        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.
        • Re:Key Point # 1 (Score:5, Insightful)

          by BLQWME ( 791611 ) on Friday December 12, 2008 @06:01PM (#26096691)
          The key to managing people is the same as anything else in life. Treat them with respect and dignity. Remember, "do unto others".
        • Re:Key Point # 1 (Score:5, Insightful)

          by naoursla ( 99850 ) on Friday December 12, 2008 @06:07PM (#26096767) Homepage Journal

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

        • Re:Key Point # 1 (Score:5, Informative)

          by multimediavt ( 965608 ) on Friday December 12, 2008 @06:45PM (#26097205)

          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: (Score:3, Interesting)

            by abinkow ( 1430547 )
            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 int
      • by Anonymous Coward on Friday December 12, 2008 @05:23PM (#26096053)

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

      • by Bobby Mahoney ( 1005759 ) on Friday December 12, 2008 @05:41PM (#26096371)
        [mutates and goes into chaotic rage upon reading the word "irregardless"]
      • Re:Key Point # 1 (Score:5, Interesting)

        by Microsift ( 223381 ) on Friday December 12, 2008 @06:42PM (#26097171)

        Like anyone's going to listen to someone who thinks irregardless is a word, regardless of the merit of what they said

    • by sheph ( 955019 ) on Friday December 12, 2008 @05:40PM (#26096345)

      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.

      • by gerrytucker ( 981939 ) on Friday December 12, 2008 @06:09PM (#26096807)
        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 :)
      • by PitaBred ( 632671 ) <slashdot@@@pitabred...dyndns...org> on Friday December 12, 2008 @06:15PM (#26096869) Homepage

        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.

      • Re: (Score:3, Insightful)

        Status reports are a bunch of non-sense.

        An efficient statusing process is necessary. You can do it with meetings, you can do it by talking to people, or you can do it with email/spreadsheets. If you have people write a concise summary of where they are on a weekly basis, they can do it when it's convenient for them. The alternative is the manager interrupting them and taking more of their developer's time than it would to update the current task list with .

        If you have a team of three, yeah, this may be

      • Re:Don't be a douche (Score:4, Interesting)

        by MindStalker ( 22827 ) <mindstalkerNO@SPAMgmail.com> on Friday December 12, 2008 @11:51PM (#26099815) Journal

        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: (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 resist

    • Re: (Score:3, Funny)

      by Missing_dc ( 1074809 )

      How Do I Manage Seasoned Programmers?

      My favorite solution is to set them on fire and launch them out a window.

      the trebuchet (http://www.trebuchet.com/)on the roof gains you extra points.

      Launch the most vocal two and the rest fall in line quite quickly.
      (funny how that works)

  • Um, duh (Score:5, Funny)

    by IceCreamGuy ( 904648 ) on Friday December 12, 2008 @05:09PM (#26095813) Homepage
    Microsoft Project!
    • Re: (Score:3, Funny)

      by Cow Jones ( 615566 )

      Two words: business hammocks.

      There's four places:
      There's the Hammock Hut, that's on third.
      There's Hammocks-R-Us, that's on third too.
      You got Put-Your-Butt-There - that's on third.
      Swing Low, Sweet Chariot...
      Matter of fact, they're all in the same complex; it's the hammock complex on third.

      Oh, the hammock district.

      That's right.

  • Specs (Score:5, Informative)

    by Coneasfast ( 690509 ) on Friday December 12, 2008 @05:12PM (#26095845)

    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.

    • Re:Specs (Score:5, Insightful)

      by Fulcrum of Evil ( 560260 ) on Friday December 12, 2008 @05:14PM (#26095909)
      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.
    • Re:Specs (Score:5, Insightful)

      by the_banjomatic ( 1061614 ) * on Friday December 12, 2008 @05:15PM (#26095913)

      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

      • Re:Specs (Score:5, Funny)

        by Hognoxious ( 631665 ) on Friday December 12, 2008 @05:34PM (#26096247) Homepage Journal

        A proper functional spec does describe the problem.

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

      • Re: (Score:3, Informative)

        by Hassman ( 320786 )

        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.

    • Re: (Score:3, Interesting)

      by frosty_tsm ( 933163 )

      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.

  • by girlintraining ( 1395911 ) on Friday December 12, 2008 @05:12PM (#26095861)

    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.

    • Project management is not only for the managers. Grab some basic books on the subject (hopefully based around software development) and have the coders read them.

      If nothing else, it gives everyone a shared vocabulary for the situations and approaches that they'll face.

      If nothing else, read a website on it.
      http://www.stevemcconnell.com/rdenum.htm [stevemcconnell.com]
      http://www.stevemcconnell.com/rdmistak.htm [stevemcconnell.com]

    • by Brain-Fu ( 1274756 ) on Friday December 12, 2008 @05:49PM (#26096511) Homepage Journal

      ...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.

      • by shutdown -p now ( 807394 ) on Friday December 12, 2008 @06:17PM (#26096901) Journal

        Or you could make things easy on yourself and use Agile.

        I'd be careful before giving such blanket advice. Agile is not a silver bullet, and its gurus never claimed it to be. There are many projects and environments in which it doesn't work at all, or doesn't work as well as other alternatives. It can also be pretty messy when not done correctly. Most of all, it cannot be pushed onto the unwilling team - it requires full cooperation to be successful; if programmers on the team don't "feel agile", adopting the outer layers won't help you at all, and is likely to hurt you.

        I've actually seen Agile pushed in a company by upper management with programmers and managers not properly familiar with it, not used to it, and not liking it. The results were pretty bad, in my estimation (that experiment is still ongoing, just without me).

  • Beer (Score:5, Insightful)

    by retech ( 1228598 ) on Friday December 12, 2008 @05:15PM (#26095917)
    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.
    • Re:Beer (Score:5, Funny)

      by Dmala ( 752610 ) on Friday December 12, 2008 @05:32PM (#26096203)
      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.
    • by Khopesh ( 112447 ) on Friday December 12, 2008 @06:14PM (#26096859) Homepage Journal

      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: (Score:3, Funny)

        by Fred_A ( 10934 )

        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.

        Wait, is this still about the glowing red ass thing ?

  • Go with a standard working approach, at least until you get your legs under you.

    A lot of very smart people have put a lot of time in figuring out good methods of managing development, so there's no need to come in and re-invent the wheel.

    I recommend finding an Agile training class someplace and learning how to manage a team using Scrum development -- it's a dandy way to go about things, developers tend to like it and it'll keep your business-side guys happy. I'd also pick up and read "Scrum from the Tre

  • by Anonymous Coward on Friday December 12, 2008 @05:16PM (#26095931)

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

    Oh wait, that's hamburgers. Nevermind.

  • by www.sorehands.com ( 142825 ) on Friday December 12, 2008 @05:16PM (#26095937) Homepage

    Focus on getting them what they need, staying out of their way, and keeping the management shit out of their way.

    • by Skyshadow ( 508 ) * on Friday December 12, 2008 @05:27PM (#26096123) Homepage
      That's a great model for delivering late and over-budget.

      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.

      • by Chirs ( 87576 ) on Friday December 12, 2008 @05:50PM (#26096535)

        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.

  • by genner ( 694963 ) on Friday December 12, 2008 @05:17PM (#26095943)
    All you need to do is walk in and say:

    "Are you working?"
    "Can you work harder?"

    If they get tired buy them hammocks.
    It helps if your wearing a Tom Landrey hat.
  • by greg_barton ( 5551 ) <greg_barton@nOsPAM.yahoo.com> on Friday December 12, 2008 @05:17PM (#26095951) Homepage Journal


    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.

  • Difficult (Score:4, Insightful)

    by dedazo ( 737510 ) on Friday December 12, 2008 @05:18PM (#26095959) Journal

    See, the key here is whether or not these developers are good developers. Experienced and responsible.

    If they are, the best advice I'd give you is to stay the hell out of their way. They will deliver. The best developers need a set of requirements, a deadline, a good working environment and caffeinated drinks. Not much more.

    But on the other hand, if they're not, then you need to stay on top of them. But how are you going to figure out if they are, given that you're a business guy? That's a difficult situation.

    If you do know that at least one of them is the kind of person that can lead, work through him/her to make sure you can identify any potential problems.

    There's nothing better than a good developer who can design, code, document and communicate, and does not need constant supervision. On the other hand, there's nothing worse than one that pretends to do those things and turns out to be a disaster for the project.

  • by thewils ( 463314 ) on Friday December 12, 2008 @05:19PM (#26095969) Journal

    You don't have to. You are redundant.

    • Re: (Score:3, Insightful)

      You don't have to. You are redundant.

      There is a lot of truth in this.

      Assuming that you have a good team (not one where they trapped all of the old malcontents together so they'd be easy to herd), they'll know what to do. In general, your job is going to be making sure that the goals for your project are clear, that you have enough resources to do the job that is scoped, negotiating about limiting the scope when you don't have the resources, making sure that you have a detailed enough plan for the short te

    • Re: (Score:3, Insightful)

      You don't have to. You are redundant.

      I've found that seasoned programmers, even so-called "agile" ones, often miss the big picture when it comes to changing business needs, shifting priorities, budget cuts, politics, etc. Some programmers exhibit the same attitude as Dante Hicks in "Clerks": "You know, this job would be great if it wasn't for the fucking customers". Others listen to the customer too much, when it should be clear that the customer doesn't really know (yet) what he wants. Programmers may

  • by mveloso ( 325617 ) on Friday December 12, 2008 @05:19PM (#26095979)

    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.

  • 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! ;-)

  • by rlp ( 11898 ) on Friday December 12, 2008 @05:20PM (#26095995)

    Be the type of manager that YOU would want to work for.

    • Re: (Score:3, Insightful)

      by Skyshadow ( 508 ) *
      The type of manager I want to work for gives me ridiculous annual raises, lets me expense pretty much anything without a receipt and lets me take days off whenever the weather's nice.

      I'm not sure that's a prescription for on-time product delivery or a successful career, however.

  • A few things (Score:4, Insightful)

    by david_thornley ( 598059 ) on Friday December 12, 2008 @05:21PM (#26096031)

    First, remember that they know more about what they're doing than you do. Listen to them. If they say a schedule is unrealistic, it is almost certainly unrealistic, and you need to take whatever business action is appropriate. They know better than you how to do things. Tell them what to do, not how to do it. Tell them the business reasons for doing things. They might have better ideas than you.

    Second, be honest with them. Don't be afraid to tell them things they might not want to hear, but if they catch you in substantive lies your effectiveness will nose-dive. Explain yourself.

    Third, set them up to succeed. Try to figure out what obstacles they're likely to run into, and try to remove them.

    Fourth, keep up to date on their progress. Don't let them go dark on you. Don't make them afraid to admit failure or schedule overruns, or you'll be blindsided sometime.

    These won't necessarily help you with problem employees, but most of your employees are probably interested in doing a good job.

    • Re:A few things (Score:4, Insightful)

      by arthurpaliden ( 939626 ) on Friday December 12, 2008 @05:44PM (#26096415)
      Five: Be sure to keep your superiors away form them. All interaction must be through you.
    • Re: (Score:3, Insightful)

      by cowscows ( 103644 )

      There's two things that my boss does that really upsets me more than anything else. The first one is that he will often promise my time to other people,be it clients/coworkers/consultants/whoever, without first checking with me to see if that time is actually available. Not only does that saddle me with significantly more work than I want to deal with, but it creates a situation where this new task takes up time that I had personally committed to helping someone else, and so I get stuck having to apologize

  • Ask them (Score:4, Interesting)

    by FortKnox ( 169099 ) * on Friday December 12, 2008 @05:22PM (#26096035) Homepage Journal
    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...
  • easy answer (Score:4, Funny)

    by gEvil (beta) ( 945888 ) on Friday December 12, 2008 @05:22PM (#26096039)
    The answer is simple--be their best friend. And let them know repeatedly that you want to be their best friend. There's no way they won't accept you. Trust me on this one.
  • Simple really (Score:3, Interesting)

    by Locke2005 ( 849178 ) on Friday December 12, 2008 @05:26PM (#26096101)
    How do you handle programmers? The same way you handle kindergarteners. Really, if you've ever had kids, you already have all the skills you need to manage engineers. Set clear expectations and priorities. Make sure they play nice with each other. Give them a shiny new toy when they've been good. As a manager, you filter all the information coming from above. Good managers filter out the pressure and bullshit and only on passes on information that gives the programmers a good idea of what their goals and priorities should be. Bad managers just pass on the shitting on they get from their managers along to their underlings, sometimes even amplifying it.
  • Hmmm ... (Score:4, Funny)

    by Chyeld ( 713439 ) <chyeld@NOsPAm.gmail.com> on Friday December 12, 2008 @05:26PM (#26096115)

    First thing you need to do is establish yourself as the alpha geek. Walk into the room and fire the first one to make eye contact. Then expound for two hours on how crappy Java is and how all you really need is a copy of Ruby on Rails and a Red Bull to be able to cover everything they do.

    The next day, show up with a box of Dilbert comics and pass them out, demand each team member identify five 'wrong thoughts' express by Dilbert and his coworkers and indicate how they actually should have acted in regards to their PHB. Emphasize that the PHB a highly paid executive and deserves their attention and respect. Dilbert's job is to make his bosses' ideas successful, not to mock him.

    The next day, first the second person who makes eye contact with you. Encourage your team to ridicule them as they make the walk of shame from your office to the exit.

    The day after that, ask them to participate in a team building session where everyone is armed with a nerf weapon and is allowed to act out their aggression. Bring your own baseball bat.

    The day after that mention that you expect the team to put in manditory overtime. You forgot to mention to them that they have a milestone deadline coming up tomorrow and you are still working with marketing to finialize the specs.

    On the day after that, enjoy the peace and quiet you've earned yourself. You'll need it as you now no longer have a team to worry about.

  • by corporate zombie ( 218482 ) on Friday December 12, 2008 @05:28PM (#26096151)

    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.


  • confidence (Score:3, Insightful)

    by br00tus ( 528477 ) on Friday December 12, 2008 @05:32PM (#26096205)
    There's only one quality I generally rate managers by, and you could call it confidence, ability, cool-headedness or whatever. It all tends to boil down to the same thing. A manager who is incompetent, an example of the Peter Principle, afraid he is going to lose his job if it's discovered he is unqualified is someone who says yes to his boss and other business units all of the time, and makes ridiculous demands on those under him. If things go wrong he panics and flips out. A confident, able boss knows his stuff, can deal firmly with his manager or other business units when need be, doesn't flip out when something goes wrong and so on.
  • Very Simple (Score:5, Interesting)

    by LibertineR ( 591918 ) on Friday December 12, 2008 @05:32PM (#26096207)
    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.

    • Re: (Score:3, Interesting)

      by tsstahl ( 812393 )
      I've mod points, but parent is already at 5.

      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
  • focus on a pointless statement in an offhand conversation, and keep repeating it over and over, getting louder all the time, the whole week, with a huge grin on your face, like its a hilarious joke

    ask them to come in your office and sit down, ask them to close the door in a very soft whisper, and then stand up, displaying an obvious erection in your pants

    in the company restroom, stand next to them while they are urinating, even if there are ten open urinals, and make sure to pee a little on their shoes, making emotionless blank eye contact while doing so

    sit silently in a meeting for the longest time, with a slightly pained expression, then excuse yourself, and, outside of the room but within earshot/ plain view, starting crying loudly and hysterically like a wounded child

    in no time you will be deriving the respect and affection you deserve

  • by Foolicious ( 895952 ) on Friday December 12, 2008 @05:39PM (#26096329)

    You need to let the programmers do what they do best...while remembering programmers' tendencies to do things like pick resume-padding technologies instead of the right technologies and freaking out over small changes instead of rolling with the punches. Easier said than done, but it's the truth.

    Also, whatever you do, do NOT, as some people have erroneously suggested, "be the manager that you would want to work for" because there's a good chance you don't share the same values as some of your programmers. The best rule for managers is to treat others like they want you to treat them.

    For example, I'm not particularly driven by money. Don't get me wrong, I wouldn't work for free and I like financial security, but when I line up priorities, thingslike freedom of time and thought are a lot more important to me than if a bonus is paid at 150% or something like that. My favorite managers have understood this, even if they don't understand how I'm wired, and they tend to leave me alone and not over-manage, unless absolutely necessary. And I've worked quite hard for them.

    So as much as you can (while maintaining consistency and keeping expectations well-known), adapt to each individual instead of implementing some across-the-board strategy. One guy may be driven by money. Another may be going through a divorce and always one the edge.

    Programmers are people and there's plenty of good and bad that comes with that. Some of them are just going to be jerks. And some aren't. Some will even be tremendous people. There's nothing you can do about this, but don't let yourself get pushed around or too worked up about it.

    Finally, always set clear expectations and never ever raise your voice or roll your eyes (neither of those work...).

  • by sco_robinso ( 749990 ) on Friday December 12, 2008 @05:39PM (#26096337)
    These I learned in the military... Probably one of, if not the biggest things to do - Lead by Example. There's no better way to shred your credibility and reputation for barking at someone for coming in a bit late, if you come in late all the time.

    Secondly, always check up on your people. It's amazingly simple to do, but it's almost a bygone in the modern corporate world. No matter how busy your month, take a good 5 or 10 minutes with each member of your team as ask them how everything's going, what some of there frustrations are, what are some things they may need. It's amazing how good a roadmap you get when you just sit an listen.

    Communicate - both ways. Encourge input from your team, but dont be afraid to send some the other way. If someone's doing something you like, or not doing something, say so. Probably my biggest personal pet peeve is non-confrontational managers who basically shotgun-blast you with their little annoyances once a year at your performance review. Your team doesn't necessarily have to know where your at every second of every day, but it's always good to provide some high-level status updates. Take a few minutes out of your schedule to update the team.

    Recognize good performance, but don't be overly cheesy about it. Taking a minute to walk into an office and say 'I really appreciate the effort you put in last week to meet the deadline, Jim' will often mean a lot. It means even more in person, rather than email.

    I could go on, but really a lot of it is pretty straight forward. You people should want to work hard for you and want to impress you, and good leadership shows when they do. Treat you team members as professionals with respect and how you would like to be treated.
  • by E. Edward Grey ( 815075 ) on Friday December 12, 2008 @05:40PM (#26096341)

    My area of expertise is not in programming, but rather in engineering - similar, but different too - so take this with a grain of salt.

    As a manager of technically proficient people, you have only a few major tasks in front of you: first, be sure to marginalize or fire uncooperative or difficult people (the "no-assholes rule"). You can live with lower levels of expertise, but you cannot live with drama. To paraphrase Roger Zelazny, the graveyards are full of people who thought they couldn't be replaced.

    Second, it's important to know that, aside from keeping the team asshole-free, you are not "in charge" here. They know what they are doing and they can track it better than you can. Employees of technical expertise actually need facilitators to assist them more than they need managers to direct their efforts. So be available to your team to take up the things they cannot afford to spend time doing - communicate with other departments, run interference with project managers, make sure that they get the help they need.

    In my particular field, a manager should be prepared to provide more assistance than control. I don't think programming would be that different.

  • by Tomster ( 5075 ) on Friday December 12, 2008 @05:46PM (#26096469) Homepage Journal

    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.


  • Be a shit-umbrella (Score:4, Insightful)

    by thockin ( 514323 ) on Friday December 12, 2008 @05:50PM (#26096545)

    The most inspiring thing a manager ever said to me, and a line which I always try to use when appropriate: That's my problem, let me handle that. Clear the landmines for them and let them run.

  • by nut ( 19435 ) on Friday December 12, 2008 @05:51PM (#26096563) Homepage

    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.

  • by melted ( 227442 ) on Friday December 12, 2008 @05:56PM (#26096625) Homepage

    Unless your project is 100% exciting to everyone on the team, the answer is, you won't be able to manage it without adding some junior programmers. A dude with 10 years of experience and multiple death marches under his belt will simply find hard to get excited about the mundane. That's not what he's there for. He's there to take on the big challenges, design stuff that works and implement it in a way that he's not embarrased by it five years from now.

    The corollary is either/or:
    1. Most of your project must be "exciting" to developers on the team. Very few projects qualify. In this case you can spread the shitty bits around so that people are less annoyed by them.
    2. You have to have a significant contingent of junior employees who will do the shitty bits that don't matter (but don't forget to throw them a bone and let them do something interesting as well).

    Most importantly, show appreciation for the work people do, whether they're senior or junior. I've been in the industry for well over a decade, and you won't believe how much easier it is to motivate people if you just say thanks to each of them personally every now and then, and maybe slip in a perk here and there. For reasons I don't understand, a lot of managers focus a lot more on cracking the whip. Big mistake, if you want people to stick around and actually produce something decent.

  • Loop them in. (Score:3, Insightful)

    by Dogun ( 7502 ) on Friday December 12, 2008 @06:20PM (#26096945) Homepage

    Don't leave your developers out of your design discussions and brainstorming.

  • What I saw as good (Score:3, Insightful)

    by Alioth ( 221270 ) <no@spam> on Friday December 12, 2008 @06:24PM (#26097001) Journal

    On my last project for an extremely large customer (with an equally huge project), the good line managers were our (the developers) advocates, they took the bullshit so we didn't have to, and determined the "big picture". They didn't manage who was doing which particular piece of code - that was down to the developers to organize themselves. Managing the development team was less about managing the people in it (the developers could organize themselves) but being an advocate for the team, and making sure that the people who knew how to do the stuff were fully involved in decisions affecting them. Developers were not merely involved but critical to things such as sizing parts of the project, so that unrealistic schedules were not set. The line manager's job was in this case often to tell upper management "this is why it's going to take this long" in terms they could understand, and persuade upper management not to cause a disaster by compressing schedules or adding more work.

    It resulted in a productive development team which did not have to do unpaid overtime, and delivered a quality product to the customer - earning a very large sum of money for the company.

  • by zullnero ( 833754 ) on Friday December 12, 2008 @06:45PM (#26097211) Homepage
    Seriously, it sounds obvious, but it's a start. Figure out what their interests are, where their passions are in regards to their work, and determine if this is a person that you can put in charge of a piece of your project, or if this is someone who is only working for a paycheck. I've had my best results (and I picked this up from working in successful teams like this) by giving those who had stronger interests a degree of responsibility over a particular section of code, and had the "paycheck" guys work on all the other tasks that needed to get done.

    This approach works fine for both Agile and Waterfall, if you really "get" both methodologies. When you're working with seasoned developers, you're probably working with guys and ladies who've developed strong interests in particular niches by this point in their careers. If you can find a section of your project that jibes with those interests, you'll probably get fantastic results out of those folks. People who tell you that it's better to stay super generalized and constantly switch tasks without respecting those interests don't understand that if you're not passionate about something in your job, you'll most likely start looking for another job.

    And hey, if you have some seasoned guys who don't care either way, and just like that paycheck, those guys come in handy, too. They're like handymen, you can assign all the other tasks to them and they'll probably do them well enough. Saves you some time from trying to find contractors to do the work.
  • Easy (Score:3, Insightful)

    by pvera ( 250260 ) <pedro.vera@gmail.com> on Friday December 12, 2008 @08:53PM (#26098649) Homepage Journal

    I totally feel your pain, I served a tour as a lead programmer, then technical manager, then director, then back to lead. Here's some of the things that I learned that weren't the most obvious to my fellow managers in other departments:

    1. Protect them. Put a programmer in a position in which he reports to just ONE boss and he'll follow you into hell. If the manager does his job, his programmers can actually spend the time programming instead of getting sucked into a reporting system where they have 8 bosses.

    2. Don't waste their time. Corporate is always adding stupid crap that all it ends up doing is slowing down the personnel that are actually producing. Try to cut down on redundant and/or useless reports, non-project/deliverable meetings, etc. Your goal here is to have your people spend as much time as possible billing to a project instead of burning overhead.

    3. Detach yourself a little bit. You are not their friend, you are their boss. You don't have to be an ass about it, but you can't hang out with them unless you take out the whole team for food, drinks, whatever. If you want to hang out with people in the same company, find other managers.

    4. You can rule with an iron hand, but try not to humiliate people in public. If one of your guys screws up, pull him aside and deal with it in private. Just because you have to adjust the employee doesn't mean you have to add humiliation to the mix. I know too many managers that simply can't understand how crucial this is.

    5. Don't obsess over the minutiae that is out of your control. The whole idea of having these senior guys is to have them do the heavy lifting for you, while you steer them in a general direction. Don't bother catching up to whatever technology they are dealing with. You do need to understand its capabilities and its limitations, but you don't need to know how to type the damn code yourself. Again, I know plenty of managers that refuse to let go and end up as horrible micromanagers.

    The best way to handle senior people is to tell them what you expect them to deliver, with broad guidance, plus whatever constraints are in place and out of your control. Let them do the work, try not to stand on their way and protect them from people that won't hesitate to make them waste their time.

"The pyramid is opening!" "Which one?" "The one with the ever-widening hole in it!" -- The Firesign Theatre