Slashdot Log In
How Do I Manage Seasoned Programmers?
Posted by
kdawson
on Fri Dec 12, 2008 04:07 PM
from the just-don't-say-mmm-kay dept.
from the just-don't-say-mmm-kay dept.
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?"
Related Stories
Submission: How do I Manage Seasoned Programmers? by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Don't be a douche (Score:5, Informative)
These are creative people, and will resist things like status reports and hard work schedules.
Seasoned Programmers? (Score:5, Funny)
Salt / Pepper / Oregeno?
TFA doesn't really help.
Parent
Re:Seasoned Programmers? (Score:5, Funny)
Parent
Re:Seasoned Programmers? (Score:5, Funny)
Parent
Re:Seasoned Programmers? (Score:5, Insightful)
Actually, this is closer to the truth for MANY jobs than most managers would want to admit.
In many jobs, the line employee has a better idea of what's going on, and the low-level nitty-gritty details of how to best achieve what has to be done, than the manager. Management of programmers should be about saying "these are the requirements', and NOT adding "and this is how you're going to achieve them". Rather, "These are the requirements; what do you need to make it happen, and how do you propose attacking it?"
After all, as the article says
Too many people think "management" meand "dictate" instead of "collaborate".
Parent
Re:Seasoned Programmers? (Score:5, Informative)
http://www.hp.com/retiree/history/founders/packard/11rules.html
Parent
Re:Seasoned Programmers? (Score:5, Funny)
lipstick!
Parent
Re:Don't be a douche (Score:5, Insightful)
No that's not flamebait, in fact, it's excellent advice. You can't run a department of advanced programmers the same way that you run a Burger King. Well, you can but you won't have any advanced programmers left if you do. Professionals typically don't enjoy working for someone that doesn't give them the respect that they've earned. Unreasonable timelines designed to drive results for the company will cause your employees to cut corners and deliver an inferior product. When this happens your good employees will no longer feel good about the job they are doing and go find a new one. Good products take time and money. If you want it fast, and cheap it ain't gonna be worth $h!t. Good employees want to work for good companies. It's a simple equation really.
Status reports are a bunch of non-sense. Requiring your employees to file status reports tells me three things. 1) You don't know enough about what they are doing to manage them, 2) how long it should take, and 3) you don't trust them to work as professionals to deliver a quality product. That last part causes resentment, and if you really want good people to work for you then you treat them like good people until they give you a reason to treat them differently. If you don't care about the people that are working for you then just skip the preliminaries and go straight to managing a project full of Indian developers.
Parent
Re:Don't be a douche (Score:5, Insightful)
Parent
Re:Don't be a douche (Score:5, Insightful)
Of course your employees should do what is expected of them, they're being paid to do so. And you're right about the ego!
The point, though, is that requiring silly things of your good people is a sure way to see them leave for something better.
Do you think the quality of your company will not suffer if the highest quality employees leave?
Then treat them with the respect they require, and they will return the favor.
Formal status reports, by the way, definitely fall into the "silly" category, as do daily status meetings. If you want to know what someone is doing, then visit them and ask. You'll find that they're probably eager to tell you all about what they're doing.
So while you had a nice rant there, I wouldn't want to work for you under those circumstances.
Parent
Re:Don't be a douche (Score:5, Insightful)
There are so many wrongs in this paragraph, it hurts.
First off, written status reports are not a part of "acting like a normal human being" or even of "being a normal employee". It's a sign of a dysfunct corporate culture where people don't talk to each other and where middle management is not even trusted with rating their own teams.
The normal process for dealing with a problem-employee would be to talk about it. You know, stuff like: "Hey bob, what's up with your performance recently". And to closely monitor problem areas in order to find ways for improvment. Know what, it seems like that would be your actual job if you weren't all busy passing written self-assessments back and forth.
Secondly, working with half-assed programmers is always more expensive than working with uber-programmers (aka "rockstars"). But by the way you describe your environment I strongly doubt that you'd be able to convince a rockstar to work for you anyways. I even doubt that you have ever only interviewed a rockstar that deserves this label.
A strong indicator for a great programmer is that he indeed doesn't need to listen to you much. Not because he doesn't want to, but rather because he already understands your pesky little business problems and requirements better than you do. A great programmers explains your problems to you, not the other way round. In an environment where rockstars are involved you merely exist to serve the programmers needs, you are effectively their secretary. You schedule meetings, acquire resources for them, interface with other parts of the company and generally make sure that nothing gets in their way of getting the job done. "Written reports" are an anachronism in such a setting. Hence my conclusion that you have never worked with a rockstar and not the slightest idea how they tick.
Parent
Re:Don't be a douche (Score:5, Insightful)
Your point is cogent. I do not advocate the elimination of all management, just the elimination of inexpert management of professional projects.
To take the lawyer example, the senior partner reviews the associate's draft. He's looking at the work, not a status report. For fighter pilots and traders, it just gets easier: the results are plain and status flows from them naturally.
A good IT project runs the same way: the manager is a domain expert, and can evaluate the product as it is being created. If she can't do this, or relies on self-assessment of her reports, the product is going to suck.
Parent
Re:Don't be a douche (Score:5, Insightful)
I agree on most counts. When you're an ideal manager, your job is to shield your employees from the bullshit from above as much as possible, so they can get their work done as well as possible. That may sometimes require a status report or meeting or something so that you can report to the muckity mucks upstream on what's going on. But it shouldn't be a replacement for involvement with your employees. If you don't know what they're working on and roughly where they are in the task or what problems they're facing, you're doing it wrong.
Parent
Re:Key Point # 1 (Score:5, Funny)
Yeah, watch some documentaries about pack animals or life in prison. That should give you some ideas for ways to communicate that you are the Alpha Male.
Parent
Re:Key Point # 1 (Score:5, Funny)
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!
Parent
Re:Key Point # 1 (Score:5, Funny)
Parent
Re:Key Point # 1 (Score:5, Funny)
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.
Parent
Re:Key Point # 1 (Score:5, Insightful)
Parent
Re:Key Point # 1 (Score:5, Funny)
I'm pretty sure they throw you in jail for doing unto others what I would have them do unto me without their permission.
Parent
Re:Key Point # 1 (Score:5, Insightful)
I think you just described Micheal from "The Office."
Parent
Re:Key Point # 1 (Score:5, Informative)
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.
Parent
Re:Key Point # 1 (Score:5, Funny)
You have a good point. However, you still should get modded +1 douche for using the word "irregardless".
Parent
Re:Key Point # 1 (Score:5, Funny)
Parent
Re:Key Point # 1 (Score:5, Interesting)
Like anyone's going to listen to someone who thinks irregardless is a word, regardless of the merit of what they said
Parent
Um, duh (Score:5, Funny)
Specs (Score:5, Informative)
As a programmer, the thing I hate the most is having to redo code over again due to poor specs or bad design docs. Make sure they are organized and have the correct specifications.
Re:Specs (Score:5, Insightful)
Parent
Re:Specs (Score:5, Insightful)
Or no specs at all. The last thing I want as an engineer is someone to come to me with their own solution they want me to implement.
Good software engineers enjoy solving tough problems. So present them with the problems you are trying to solve and let them come up with their own solutions
Parent
Re:Specs (Score:5, Funny)
A proper functional spec does describe the problem.
Or so I'm told, I've never actually seen one.
Parent
Really, there's only one thing... (Score:5, Informative)
The big problem I see in people who are tech managers is a lack of understanding of project management. They're fine with people, if not missing some subtlety here and there, and it sounds like you've got a team that has few personnel problems. So focus on building your project management talents, which is about deadlines, coming up with objective measurements for progress, and setting realistic goals. Your team should be able to tell you where the trouble spots will be in the development cycle, how fast they expect to overcome each obstacle, and help you plot a roadmap, but only if you ask the right questions.
Or you could make things easy on yourself... (Score:5, Interesting)
...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.
Parent
Re:Or you could make things easy on yourself... (Score:5, Insightful)
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).
Parent
Re:Or you could make things easy on yourself... (Score:5, Funny)
"Agile is not a silver bullet, and its gurus never claimed it to be"
Gurus never claim that their way is a silver bullet, they just claim it will bring down a werewolf or vampire with a single shot.
Parent
Beer (Score:5, Insightful)
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)
You know actually, I'd love to know what the correct response is when a programmer does this. I generally just run away.
Parent
Be a friend first. Informal meetings, free food. (Score:5, Informative)
Assuming you're all in the same office...
One-on-one meetings in a comfortable and somewhat informal manner. Make it regular (twice a week or so?) and find some way to give them advanced notice indirectly, like doing it at the same time every week or passing by their office/cubes a few minutes before jumping in to ask for the informal report. If you startle them, leave and come back in a few minutes (really!). Their desks should be oriented in a manner that makes it hard to sneak up on them; if that's not the case, buy a mirror [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.
Parent
Flip every 5 minutes (Score:5, Funny)
You don't want to touch them too often or they get tough and dried out.
Oh wait, that's hamburgers. Nevermind.
Get out of their way! (Score:4, Insightful)
Focus on getting them what they need, staying out of their way, and keeping the management shit out of their way.
Everything you need to know is on the simpsons (Score:5, Funny)
"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.
Listen, listen, listen (Score:5, Interesting)
Listen.
Be open to criticism and be willing to change course in response to it.
Make sure when you do talk technical, you know what you're talking about. Feel free to ask questions if you don't know, and be able to absorb and express abck what you've learned.
If you need to make a decision based on "fluffy business stuff" that goes against the right theing to do on a technical issue, explain it thouroughly and be able to back it up. Geeks thrive on more information, not less.
Give the geeks freedom to graze.
Difficult (Score:4, Insightful)
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 (Score:5, Insightful)
You don't have to. You are redundant.
Ask for their input ... and actually listen to it. (Score:4, Interesting)
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! ;-)
Been there, done that (Score:5, Insightful)
Went back to the tech side.
But the management stint wasn't wasted. It did make me realize there is a "bigger picture" that is always mentioned. I'd say the most important thing is to get this across. Tell them there will be decisions made by you, sometimes that you have control over and sometimes not, that won't make a lot of sense at your group's level. If they're your decisions you have some hope of explaining them. If they are decisions made up the chain then give as much information as you have and point out that it made sense to someone at some point and since y'all are all getting a paycheck from the same company then those are the marching orders.
Other than that just work to get your team the things they need. It's their work that will make you look good (or bad) so your job is to make sure they have the tools and time they need to do their jobs. If you give them that then they need to actually do their jobs and you will want to keep them accountable for that. Nothing says bad manager more than someone who ignores the slacker while everyone else is pulling their weight.
$0.02,
-CZ
Very Simple (Score:5, Interesting)
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.
Unless your project is 100% exciting to everyone (Score:5, Insightful)
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.
Oh for crying out loud (Score:5, Insightful)
Don't tell him that. He'll actually believe it.
Here's what you should actually do: Manage.
Be honest with your team. Tell them what you need and when you need it. Take advice from them on the best way to arrange that. If they're experienced (read that as set in their ways) forcing some oddball paradigm on them will send you permanently to PHB land. They'll never listen to you after that. You'll be regarded as an obstacle rather than a help.
You're herding cats - never forget that. Let them do what they want in the way they want to do it and all should be well. Just make sure they know what your expectations are.
And if you want something Lumbergh-like from them, say so. Then do the unusual thing and say why you want it. Don't just demand status reports from them. Ask for them, tell them you need these reports "because of pressure you're getting from your supervisor about this certain customer, and if we make schedule with this project they will potentially select us for the next project, and that means more revenue for the company."
Talk to them as equals. Explain your concerns to them. NEVER talk down to them or enforce some odd idea that the manager caste is above the programmer caste. You are all equals on a team, sink or swim together.
Do these things, ignore the buzzwords and manager-hype, be their fellow employee and the details will solve themselves. If these guys decide they like you your job will become a thousand times easier. You will always have loyal allies, rather than disgruntled drones.
And best of luck. Don't just be a manager - be a good one.
Parent
Re:Oh for crying out loud (Score:5, Funny)
Up a waterfall, with a rolled up tissue.
Parent
Re:Seasoned programmers... (Score:5, Insightful)
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.
Parent
programming != managing (Score:5, Insightful)
Your first post was possibly funny. Now you've proven you're either a troll or a bitter, jaded individual who was probably passed over for good reason.
It was actually a *mistake* that the only advancement path for most exceptional skilled workers was to become a manager that didn't use their exceptional skills. Project management has always been a specialized skillset. For some unknown reason, it was assumed that people who learned how to build things could also supervise other builders. I call shenanigans.
The military figured this out years ago. Commissioned officers make plans, non-coms implement the plan, and specialists do the work. Each butterbar junior officer goes through a fairly rigorous training course to give them the concepts and then they get to actually learn the job once they get assigned to their unit where their captain and sargeant finish up the training.
When the engineering company I used to work at introduced a "technical expert" path as well as a "project management" path I was overjoyed. Finally, the best do-ers could keep do-ing without being forced into managing. Plus, theoretically, the project managers would *finally* know how to manage.
None of that happened, unfortunately, so I jumped ship. Last I heard they were closing offices. The place I work at now does have various technical grades that provide a pretty wide salary band and it's doing fine.
Parent