Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Do I Manage Seasoned Programmers?

kdawson posted more than 5 years ago | from the just-don't-say-mmm-kay dept.

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

cancel ×

551 comments

Sorry! There are no comments related to the filter you selected.

Don't be a douche (5, Informative)

Gothmolly (148874) | more than 5 years ago | (#26095811)

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

Seasoned Programmers? (5, Funny)

ColdWetDog (752185) | more than 5 years ago | (#26095825)

11 herbs and spices?

Salt / Pepper / Oregeno?

TFA doesn't really help.

Re:Seasoned Programmers? (5, Funny)

Anonymous Coward | more than 5 years ago | (#26096235)

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

Re:Seasoned Programmers? (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#26096309)

[citation needed]

Key Point # 1 (2, Funny)

Anonymous Coward | more than 5 years ago | (#26095829)

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.

Re:Key Point # 1 (5, Funny)

Hal_Porter (817932) | more than 5 years ago | (#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.

Re:Key Point # 1 (5, Funny)

gEvil (beta) (945888) | more than 5 years ago | (#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 (5, Funny)

Xoltri (1052470) | more than 5 years ago | (#26096299)

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

Re:Key Point # 1 (5, Funny)

Ethanol-fueled (1125189) | more than 5 years ago | (#26096045)

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 (5, Funny)

Anonymous Coward | more than 5 years ago | (#26096053)

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

Re:Don't be a douche (5, Insightful)

sheph (955019) | more than 5 years ago | (#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.

Um, duh (4, Funny)

IceCreamGuy (904648) | more than 5 years ago | (#26095813)

Microsoft Project!

Specs (5, Informative)

Coneasfast (690509) | more than 5 years ago | (#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 (5, Insightful)

Fulcrum of Evil (560260) | more than 5 years ago | (#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 (5, Insightful)

the_banjomatic (1061614) | more than 5 years ago | (#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 (5, Funny)

Hognoxious (631665) | more than 5 years ago | (#26096247)

A proper functional spec does describe the problem.

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

Re:Specs (1)

thegnu (557446) | more than 5 years ago | (#26096323)

Good advice, but if that's the case, I would put together specs, then have a meeting about them.

I mean, being organized is not that hard, and if people's feelings get hurt because one or two of their ideas are shitty, they are definitely NOT wiser. Older, maybe.

Re:Specs (2, Informative)

Hassman (320786) | more than 5 years ago | (#26096335)

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.

Really, there's only one thing... (5, Informative)

girlintraining (1395911) | more than 5 years ago | (#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.

It's good for the programmers, too. (2, Insightful)

khasim (1285) | more than 5 years ago | (#26096121)

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]
or
http://www.stevemcconnell.com/rdmistak.htm [stevemcconnell.com]

Re:Really, there's only one thing... (1)

Red Flayer (890720) | more than 5 years ago | (#26096283)

I recommend Kerzner's books on project management (Wiley & Sons), they have been very useful to me.

Since your question relates specifically to managing the team, I suggest Turner's "People in Project Management" (Gower)... while useful, you will find this most useful if you already have a foundation in project management.

Sorry (0, Flamebait)

binarylarry (1338699) | more than 5 years ago | (#26095869)

You ARE Bill Lumbergh. You aren't going to fool most of these guys into believing otherwise. Your best bet is to stay the fuck out of the way and order things when things need to be ordered.

Remember, you are basically a glorified secretary. You don't actually DO anything. So don't forget that and get them coffee when they ask for it.

Re:Sorry (1, Insightful)

Anonymous Coward | more than 5 years ago | (#26095945)

I'm assuming you're either physically or mentally in your 20s and don't understand anything about business. Hopefully, you will mature as you gain in years.

Re:Sorry (-1, Flamebait)

binarylarry (1338699) | more than 5 years ago | (#26096179)

Wow, posting as an anonymous coward.

You sound like someone with real backbone! You must be in management.

Re:Sorry (1, Informative)

Anonymous Coward | more than 5 years ago | (#26096063)

Your comment proves that you are merely another of the "slashtards" your sig mentions.

Re:Sorry (0)

Anonymous Coward | more than 5 years ago | (#26096143)

"(Score:2, Flamebait)"
 
'nuff said.

$$$$$$$$ money money money!!! (0)

Anonymous Coward | more than 5 years ago | (#26095879)

Mo money mo money mo money!

Just in case I know you in person.

Seasoned programmers... (1, Insightful)

gluefish (899099) | more than 5 years ago | (#26095895)

Read up on Agile. As a programmer I have felt the most empowered, gotten the most enjoyment, and positive feedback, by working in an Agile scrum team.

Re:Seasoned programmers... (0)

Anonymous Coward | more than 5 years ago | (#26095989)

Dont do this. Agile is fucking retarded.

Oh for crying out loud (5, Insightful)

Weaselmancer (533834) | more than 5 years ago | (#26096129)

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.

Re:Seasoned programmers... (4, Insightful)

Rinisari (521266) | more than 5 years ago | (#26096171)

Read Hackers and Painters [amazon.com] and Mythical Man Month [amazon.com] , especially the latter.

Know this: checking in on your developers via a bug tracking system is probably advisable instead of constantly walking in and saying, "What's happening." Note period instead of a question mark.

Fire them and offshore all your work (-1, Troll)

gelfling (6534) | more than 5 years ago | (#26095899)

A C+ level of skill and competence is all we should expect from anyone. And no one in a position of leadership cares as long as you get the crap out the door more or less on time and reasonably close to budget. Beyond that, it really doesn't matter. So lose them all and send the work to Russia or India or China or Brazil.

Re:Fire them and offshore all your work (0)

Anonymous Coward | more than 5 years ago | (#26096049)

A C+ level of skill and competence is all we should expect from anyone. And no one in a position of leadership cares as long as you get the crap out the door more or less on time and reasonably close to budget. Beyond that, it really doesn't matter. So lose them all and send the work to Russia or India or China or Brazil.

I sincerely hope you are joking. Many outsourcing projects that I have seen have ended up behind schedule and over budget. To add insult to injury, when you decide to bring the code back into the organization, the code is often nearly unmaintainable.

Re:Fire them and offshore all your work (1)

nedburns (1238162) | more than 5 years ago | (#26096291)

Amen to that! Comments and object names in Indian/Russian aren't doing me any good.

Re:Fire them and offshore all your work (0)

Anonymous Coward | more than 5 years ago | (#26096267)

ffs you just caused me to embarass myself by breaking out in sudden uncontrolled laughter, sometimes slashdot is annoying

Beer (5, Insightful)

retech (1228598) | more than 5 years ago | (#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 (1, Insightful)

Anonymous Coward | more than 5 years ago | (#26096069)

I had a manager who spent our teambuilding exercise fund on a trip to a bar and we spent it on pizza and beer. We were the only group in electronics division to ever get anything done on time (we got everything done on time) and were easily the closest knot group.

Re:Beer (2, Insightful)

Weegee_101 (837734) | more than 5 years ago | (#26096081)

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.

Extremely true. Stop looking at them as subordinates and start looking at them as team mates on the same team and morale will improve. If someone slips though, make sure that they understand that you still are in charge, and you've got the last say in any business matter.

Well, as a seasoned programmer ... (1)

morgan_greywolf (835522) | more than 5 years ago | (#26096177)

As a seasoned programmer...I'd have to say I agree with the beer part. And someone mentioned pizza. Pizza is good. And I prefer single-malt Scotch.

Re:Beer (5, Funny)

Dmala (752610) | more than 5 years ago | (#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.

Re:Beer (1)

morgan_greywolf (835522) | more than 5 years ago | (#26096295)

You wouldn't understand. It's a programmer thing. Go write a few hundred thousand lines of C, Python or Java and then you'll know.

Go with a standard approach (1)

Skyshadow (508) | more than 5 years ago | (#26095921)

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 Trenches" by Henrik Kniberg, which helped me with implementation of ideas I knew in concept.

Once you've got a grounding, you can move on from there and make tweaks.

Managing seasoned coders (1)

gormanw (1321203) | more than 5 years ago | (#26095929)

Were I you, the first thing is to observe your team to identify their personalities, leaders, and quirks. Secondly, clearly set out expectations and how you measure success. Thirdly, communicate regularly. Remind them of your requirements and ask them to tell you how you are doing as manager. Finally, don't tell them how to do their job. They are adults. Managers not only set the tone and lead, but they also support and protect their employees. Ask them where you can run interference or otherwise make doing their jobs just a little bit easier. Honest communication and feedback makes this happen.

Flip every 5 minutes (5, Funny)

Anonymous Coward | more than 5 years ago | (#26095931)

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

Oh wait, that's hamburgers. Nevermind.

joelonsoftware? (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26095935)

If you want advice on being gay, ask joel. If you want advice on software or management, ignore that cocksucker.

Get out of their way! (4, Insightful)

www.sorehands.com (142825) | more than 5 years ago | (#26095937)

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

Re:Get out of their way! (1)

smallshot (1202439) | more than 5 years ago | (#26096113)

Exactly. This should include not making promises to your customers without consulting the team, and not consulting the team and then disregarding their time and effort estimates just because the customer wants it now. When you try to motivate your team with impossible deadlines, it tends to have the opposite effect. Hopefully you learned this from Dilbert, if nowhere else.

Re:Get out of their way! (3, Interesting)

Skyshadow (508) | more than 5 years ago | (#26096123)

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.

Hammocks (0)

Anonymous Coward | more than 5 years ago | (#26095941)

n/t

Everything you need to know is on the simpsons (4, Funny)

genner (694963) | more than 5 years ago | (#26095943)

All you need to do is walk in and say:

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

If they get tired buy them hammocks.
It helps if your wearing a Tom Landrey hat.

Re:Everything you need to know is on the simpsons (1)

outcast36 (696132) | more than 5 years ago | (#26096251)

where can I get some hammocks?

Listen, listen, listen (5, Interesting)

greg_barton (5551) | more than 5 years ago | (#26095951)

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.

I'll go one better: OUTSOURCE THEIR ARSES (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26096213)

Seriously. Quit pandering to the pinnacles of uber geek primadonnism and threaten to outsource their pathetic skins. Enough already.

Difficult (4, Insightful)

dedazo (737510) | more than 5 years ago | (#26095959)

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.

As a seasoned programmer I can easily answer this (5, Insightful)

thewils (463314) | more than 5 years ago | (#26095969)

You don't have to. You are redundant.

Re:As a seasoned programmer I can easily answer th (2, Insightful)

frank_adrian314159 (469671) | more than 5 years ago | (#26096223)

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 term so you can see if people are achieving short term goals, re-assigning resources in case issues come up, renegotiating with superiors about more resources and scope reduction when you fall behind, etc. Very little of your time should be spent telling them what to do. You should tell them the goals and then let them decide how they're going to get meet them. Of course, if they tell you that they need hookers and blow first, you might ask them how that's going to help their productivity (for the hookers, at least).

One thing (1)

ipb (569735) | more than 5 years ago | (#26095975)

Listen!

Cattle prods, Electroshock therapy, and drugs (2, Interesting)

mveloso (325617) | more than 5 years ago | (#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.

Ask for their input ... and actually listen to it. (3, Interesting)

Richard Steiner (1585) | more than 5 years ago | (#26095981)

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

Golden Rule of Management (2, Insightful)

rlp (11898) | more than 5 years ago | (#26095995)

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

Re:Golden Rule of Management (1)

geek2k5 (882748) | more than 5 years ago | (#26096127)

I definitely second this one.

Try your best to support your team and help them do the best job possible. That includes protecting them from upper management demands that are less than wise.

You know both the business and the technical sides and there is a chance that your programmers may know something about both sides too. Listen to them and they will listen to you.

Re:Golden Rule of Management (2, Insightful)

Skyshadow (508) | more than 5 years ago | (#26096167)

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.

show them the business case. (2, Insightful)

timmarhy (659436) | more than 5 years ago | (#26096003)

99% of the comments you'll get will be technical. This shows /. er's lack of undrstanding about the business world, and your programmers are likely to suffer the same blindness. I would say in general let these guys work unhindered and give them all the support you can, but in the event there is something drastic you need to change about the product explain the business case to them. When you can show that X > Y means $$$ most people will understand right away. This works both ways, in the event you get given directives that won't work on a technical level.

Pay more. (1)

fut87 (1430405) | more than 5 years ago | (#26096009)

Pay more.

A few things (3, Insightful)

david_thornley (598059) | more than 5 years ago | (#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.

Ask them (3, Interesting)

FortKnox (169099) | more than 5 years ago | (#26096035)

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

gEvil (beta) (945888) | more than 5 years ago | (#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.

Make Them think They are in Charge (1)

shareme (897587) | more than 5 years ago | (#26096071)

Make them think they are in charge.. In your communication should be always listening always speaking out loud exploration of their ideas point out the good points and etc of those ideas. Assume that their experience in project management has more depth than yours and treat it as a learning experience from the greatest teachers in al the world of project management. Think of them as Marines, they are there to save your ass if you are willing to listen

put your team before..... (1)

shawnbutts (449657) | more than 5 years ago | (#26096083)

... your "customers" and your team will never fail you.

First - Stay out of their way (1)

gnosi (893875) | more than 5 years ago | (#26096087)

The first and best thing you can do is to stay out of their way.

The second thing to do is to find out what is preventing them from getting their development done and to eliminate or reduce the interference.

Since they are seasoned they will have an understanding for the need of management updates they should be asked for these updates no more than once a week.

The one thing that you should be making decisions on is the business needs of the application. For this you should understand and communicated the business needs.

Show the team that you are interested in the crafting of their solution to the business need.

Avoid being a PHB at all costs.

Avoid being a PHB at all costs.

--

Task Management (1)

Mr. Sketch (111112) | more than 5 years ago | (#26096097)

Manage by tasks, not by reports and work schedules.

When you're planning a new release, make a list of desired features, priorities, and assign them to the person you think is best for the job based on their abilities. Then send the lists around to the developers and ask them to fill in a guess for how long each of their items should take. You can use that to setup a timeline for a rough guess of how long the new release should take.

For bug fixes, each developer should just have a list of bugs and you can maintain the list and elevate priorities or contact them to say bug #XXXX needs to be fixed now.

Your basic goal should just be to ensure everyone has a list of items to work on and generally let them decide how/when/etc to work on each task, and you can guide or steer them towards different tasks as necessary.

Status meetings should be kept to a max of once a week, just to keep the team on the same page about what everyone else is doing, maybe bring up issues to discuss etc. Your goal is actually to manage the least while giving them some freedom and flexibility to work on tasks they want to, and if something comes up, then (and only then) interrupt that flow to get a high-priority task done. Your job will amount to keeping track of what everyone is working on, verifying that what they were working on got done, and assigning/prioritizing new tasks/bugs as they come in.

Don't check up on them too much, since you'll be seeing them at the weekly meeting. After all, you should be cc'd on all bugs that they resolve anyways and since they're seasoned, should keep you in the loop as they complete other tasks and start new tasks.

Simple really (2, Interesting)

Locke2005 (849178) | more than 5 years ago | (#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 ... (3, Funny)

Chyeld (713439) | more than 5 years ago | (#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.

Just don't micromanage (1)

Toreo asesino (951231) | more than 5 years ago | (#26096119)

There's nothing worse than "ex-programmer managers" that get into details they really don't need to.

Set/agree key project milestones with the team and leave them to it. Maintain clear tracking of these and pressure them only when they're slipping on these into the buffer time you would've naturally planned for anyway (even if not publicly planned for).

Second to micromanaging, there's nothing worse than managers agreeing to project deadlines without consulting the geeks first.

Also, geeks appreciate a manager that stands up for them when the goalposts have been artificially moved from higher up.

Get it right and you'll have a highly motivated team that will go above & beyond for you when you need them most; get it wrong and your project will fly like a lead balloon.

How do I.... (1)

eyecorporations (1401035) | more than 5 years ago | (#26096133)

shot web?

It's a lot like herding cats (1)

twmcneil (942300) | more than 5 years ago | (#26096141)

Like a herd of cats, these "seasoned programmers" are already motivated to go somewhere all on their own and they will without any prodding on your part. Your job is to make certain that the desired direction forward is clear, understood and changes as little as possible. After that, remove all obstacles in their path and it should be smooth sailing.

Re:It's a lot like herding cats (2, Interesting)

vil3nr0b (930195) | more than 5 years ago | (#26096315)

HSPLTA - Hire Smart People Leave Them Alone...simple yet never achieved by anyone I've ever worked for.

teach them the business (0)

Anonymous Coward | more than 5 years ago | (#26096147)

teach them the business so it eliminates your job. businesses dont need to pay a separate salary for your position when the programmers should be learning the business and understanding it.

Been there, done that (5, Insightful)

corporate zombie (218482) | more than 5 years ago | (#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.

    $0.02,
    -CZ

Management tools (1)

crmartin (98227) | more than 5 years ago | (#26096157)

A whip and a chair.

Software Engineering Methodologies.... (1)

God of Lemmings (455435) | more than 5 years ago | (#26096161)

If it already hasn't been done, the first thing I would do is to see what software engineering methodologies they are all familiar with, and figure out what you're going to use. Anything will usually be better than nothing at all. Then agree on some common method of documentation, and a minimal style guideline. Maybe set some policy for when and how often something must be committed to CVS (or your favorite storage method)

confidence (2, Insightful)

br00tus (528477) | more than 5 years ago | (#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 (5, Interesting)

LibertineR (591918) | more than 5 years ago | (#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.

Always hire from within.. (0)

Anonymous Coward | more than 5 years ago | (#26096215)

IMO, the most successful Java development managers could step-in and perform the role of anyone on the team. Why this isn't a requirement of a software development manager is beyond me.

Take my advice now. Save you and your team a lot of trouble. Put someone in the role who could step in and write every line of code in the product if needed. Anything else represents lost opportunity.

Sincerely,

John

glower at them in the hallway (3, Funny)

circletimessquare (444983) | more than 5 years ago | (#26096229)

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

Tell them the deadline and expected end result. (1)

Technomancer (51963) | more than 5 years ago | (#26096233)

And don't tell them how to do it.
Obviously, the deadline you tell them has to be before real deadline/product delivery, allocate at least 20% of extra time. Programming projects never end on time.
If there is multiple seasoned programmers working on it, pick one to be a leader that has final say in architectural matters and interface specs, otherwise they will never agree.

Incentives the ultimate in managerial arsenal (0)

Anonymous Coward | more than 5 years ago | (#26096237)

Incentives can motivate even the most uncooperative work force.
I have several years of experince being unproductive, unreachable, and uncooperative.
I also have had my moments where I have been a shinning example of slavery to the man.
The key things I have learned are:

Incentives can be positive or negative like:

Positive: offering early completion bonuses for milestones or projects completed without bugs.

Negative: offering to let me keep my job if I complete it early or without bugs.

Incentives can be meaningless if:

I spend more time looking for a new job or posting meaningless posts on slashdot.

I think the company I work for is run by a bunch of monkeys in a suit who I could do a better job if I just had the opportunity.

Respect, you don't respect my idea's or suggestions. I immediately question every decision you will ever make.

You already made your first mistake by caring about how you do your job.

Show no mercy and fire someone at random to reassert your authority and make everyone else cover for that persons workload.

Walking Disaster (0)

Anonymous Coward | more than 5 years ago | (#26096265)

* Respect their experience
* Ask questions and _listen_ to the answers
* Be their advocate, not their overseer
* Don't tell them how to be productive, ask them what they need to be more productive

These are rules that apply to anyone managing any group. Developers are people too. If they're made to feel relevant and respected, they will offer you respect back.

Why (0)

Anonymous Coward | more than 5 years ago | (#26096269)

Why is a 30-year old "business guy" managing a small team of "seasoned" Java programmers? What is the business element of this job which makes it more important to have you managing this team than a technical person. At 30, you can't have that much business experience, either. Are you related to someone important in this company?

Understand what your job is ... (1)

gstoddart (321705) | more than 5 years ago | (#26096297)

If you've coded, then you're half way there, since you actually understand what the job entails.

Understand what the project is, and understand that you need to be the middle layer between the upper management and the people doing the work so stuff doesn't get out of hand and things don't get promised that can't be made to happen. Handle the scheduling and planning with some degree of skill, and push back if upper management is falling victim to scope creep or is trying to turn the project into a death march.

Too often I've seen some n00b of a PM who really doesn't understand the technical/resourcing issues at hand. After telling them that what they're asking for is ridiculous, out of scope, or downright not achievable I've been overruled so that they could appear to be saying yes to management or the customer. Eventually after that person was canned, I found myself saying "that was never going to be possible" and when I was asked why, I told them in no uncertain terms, and explained the previous person had completely ignored all of the technical advice to the contrary. That got met with completely incredulous stares.

You'll need to be able to rely on your own judgement to know if they're sand bagging or being serious when they tell you a feature can't be done at all or in the timeline you need to do it. The worst thing I've seen is when Marketing gets handed over the reins over a technical product, and then proceeds to make promises from their backside and simply not listen to the technical staff when they object. Unfortunately, some of those people can't be made to understand that the only reasonable response to some requests can only be "no damned way", so they turn the situation into one that's untenable.

We're developers, we're not THAT hard to understand. But, we don't want to deal with too much of the scheduling stuff or fight the bureaucracy, and we don't want to be on the receiving end of some idiot who thinks that can promise a flying car. Treat us with respect, listen to us, bring your own ideas but don't be too focused or limited by them unless this is your subject expertise, and don't turn the situation into a Dilbert cartoon of management by ineptness and intimidation.

If you make it easier to do our jobs without needing to beat down unreasonable demands, and actually do things which help us to move forward in the software cycle, we'll respect you and treat you like one of the team. If you don't, well, we might go all BOFH on you and that stash of animal porn we planted on your laptop will be discovered. ;-)

Cheers

Be specific. (1)

Ironica (124657) | more than 5 years ago | (#26096301)

Lots of folks have said good things already. I'll tell you what I find works for me in getting what I want out of programmers (including the one I'm married to ;-): be specific.

When you have the project spec in hand, sit down with the development team, and have them all go over it. Then get ALL their questions, and get answers. Some may be things that are up to the discretion of the team, and some may be things that need to be answered from other quarters... but all those "Step 3. ??????????" parts need to be identified and filled in before any code gets written.

If they have input such as "Why are we doing this? This is stupid. It'd make more sense to do it THIS way, because..." take notes, give an answer if you have one, and otherwise, bring that to wherever the spec came from and present the case, but in business speak. "We can achieve better security and efficiency by altering the spec such that..." or whatever.

If something is intentionally left up to the developers' discretion, make THAT explicit.

When feedback comes in about beta versions, make sure that is very specific, too. "The second screen doesn't work" is not useful feedback. "When I click on the button marked XXXX after inputing "flibbertygibbet" in Y field, I get Z response and am expecting W" is useful feedback. Create feedback/bug report forms that require certain information if the folks responsible for testing aren't able to do this properly on their own.

If you have a really good spec that all the devs have weighed in on and you've got buy-in, you can mostly coast downhill from there. If problems arise, you've got a document to refer to, and if they bring up problems with it at THAT point, you can ask why they didn't bring this up to begin with. (Though you should also continually solicit feedback, so that as someone's getting into the code and realizes that it's not going to work that way, they tell you right away rather than just burying it until you ask.)

Easy (1)

BlackCobra43 (596714) | more than 5 years ago | (#26096307)

That's easy. Red staplers. Preferably of the Swingline brand.

Less documentation (0)

Anonymous Coward | more than 5 years ago | (#26096313)

More coding, less documentation. Keep it easy for the developers to focus on coding rather than have to write bunch of documents.

Three must-read books (1)

bfwebster (90513) | more than 5 years ago | (#26096327)

First, read Gerry Weinberg's classic work, "Becoming a Technical Leader" [amazon.com] . It's particularly apt for you, since you've transitioned from being a developer to being a manager.

Second, read "Peopleware: Productive Projects and Teams" [amazon.com] by Tom DeMarco and Timothy Lister. Still the single best work on shaping and managing software teams.

Finally, work your way through "Journey of the Software Professional: The Sociology of Software Development" [amazon.com] by Luke Hohman. This book deserves to be far better known (and read) than it is. It's a denser book than the first two, but will cover virtually every issue that you'll run into as a software project manager. ..bruce..

Re:Three must-read books (1)

dkleinsc (563838) | more than 5 years ago | (#26096353)

Wow, you missed at least one of the biggies:
Fred Brooks' "The Mythical Man-Month"

don't let the inmates run the asylum... (3, Insightful)

Foolicious (895952) | more than 5 years ago | (#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...).

Lead by Example, amongst others... (3, Insightful)

sco_robinso (749990) | more than 5 years ago | (#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.

Engineer Management (4, Insightful)

E. Edward Grey (815075) | more than 5 years ago | (#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.

ideas (1)

alxkit (941262) | more than 5 years ago | (#26096351)

don't play catch-up on sundays, and you'll be good. and for the love of god, don't EVER use a phrase like `that would be great, mmmkay` .

Performance Equation (1)

karstdiver (541054) | more than 5 years ago | (#26096367)

Everyone's performance is determined by the equation P=f(M,S,E) where: P= performance M= motivation S= skill (right skills to do the job) E= environment (right tools to do the job. Performance is a function of a person's Motivation, Skill level, and Environment. A leader's role is to make sure the S's and the E's are satisfied (more training; better tools) and to properly motivate. For each person the M is different but there are common goals. A good leader can identify, create, and nurture those M's such that P is maximized. There are many ways to create M's: 1) performance based pay/bonus 2) competition with peers or self 3) fear 4) freedom 5) challenges 6) "whitewashing the fence" 7) others?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>