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?"
Seasoned programmers... (Score:1, Insightful)
Re:Specs (Score:5, Insightful)
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
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.
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.
Re:Sorry (Score:1, Insightful)
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.
Golden Rule of Management (Score:3, Insightful)
Be the type of manager that YOU would want to work for.
show them the business case. (Score:2, Insightful)
A few things (Score:4, Insightful)
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:Beer (Score:1, Insightful)
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 (Score:2, 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.
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.
It's good for the programmers, too. (Score:3, Insightful)
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]
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.
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
Re:Golden Rule of Management (Score:3, Insightful)
I'm not sure that's a prescription for on-time product delivery or a successful career, however.
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.
confidence (Score:3, Insightful)
Re:As a seasoned programmer I can easily answer th (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 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).
don't let the inmates run the asylum... (Score:4, Insightful)
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... (Score:4, Insightful)
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 (Score:4, Insightful)
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.
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.
Re:A few things (Score:4, Insightful)
Re:Key Point # 1 (Score:2, Insightful)
Shouldn't that be modded funny?
Be a shit-umbrella (Score:4, Insightful)
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.
Re:Seasoned programmers... (Score:2, Insightful)
But did you actually produce anything?
Re:A few things (Score:3, Insightful)
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 for not keeping up my end of the bargain with them. And even though everyone that works in the office understands how that sort of situation happens, in stressful times, it just serves to create animosity between the different project leaders when one of them "steals" my time from the other. It also makes it nearly impossible for people to create accurate schedules because they have no idea what else will suddenly fall on their desk, or when their help will get randomly pulled away.
The second thing, which in a way causes a lot of the first, is that my boss has a lot of difficulty with setting priorities. As a big boss, he's got dozens of projects under his supervision to at least some degree, and so he tends to wander from crisis to crisis as they arise across all the work in the office. And so whatever the current crisis is, that's what his priority is for that day (or sometimes hour). It's a huge drag on office efficiency, and projects that should take three weeks to get out the door end up taking 6 weeks of work, stretched out over 8 months of on and off progress.
Overall, I'd say one of the most important things is to help your workers stay focused. Lay out the priorities, give them a clear path. I don't mind so much if the endzone is far away and there's a bunch of obstacles in the path, as long as I can see the goalposts.
Re:Sorry (Score:2, Insightful)
Shucks, did the cold reality of my words damage your world view?
It used to be that to be "in charge," it was because you had the experience in the field and knew the business/process better than anyone else. That's why you were in charge. Not because you kissed the right ass and took specific "management" classes in school.
If so, I am eternally sorry.
After all, I don't want my wittle csartanis bear getting his feelings hurt on Slashdot.
*makes kissy face*
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.
Re:Key Point # 1 (Score:5, Insightful)
Re:Key Point # 1 (Score:5, Insightful)
I think you just described Micheal from "The Office."
Re:Don't be a douche (Score:5, Insightful)
Re:Oh for crying out loud (Score:3, Insightful)
Thanks. =)
It's my opinion that a good manager understands their actual job function. Which can be summed up in one word - HELP.
It is their job to help. Two parts to that.
First part: Help the company get what it needs out of engineering. If sales promises a customer something, it is the managers job to help the sales staff get what it needs out of engineering. If manufacturing needs that new rom by Friday, it is the manager's job to help them get it from engineering.
Second part: Help engineering meet those requirements. Do they want to be an Agile shop? Set it up. Do they not want it? Don't force it on them. Do they need new equipment? Move heaven and earth to try to get it.
Sometimes these will conflict. Engineering might want a 4000 dollar logic analyzer. Accounting will say it's not in the budget. The solution? Tell engineering what the budget is, and let them choose. "We are allocated 1500 a quarter for engineering supplies. If we skip the planned PC upgrades you can have that probe in the third quarter of next year. I'll leave it up to you guys to decide which is more important."
If you can phrase the problems the company has in such a way as to make them personal, engineers will see them as their problems and not the company's problems. They'll become personal problems and they'll begin to solve them.
Really, it all just boils down to being honest, open, communicative and not elitist. The best managers have these traits, and the worst ones lack them entirely.
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.
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.
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).
Loop them in. (Score:3, Insightful)
Don't leave your developers out of your design discussions and brainstorming.
Re:Key Point # 1 (Score:1, Insightful)
I don't think dry humping would get you too far in prison.
Depends on how far of a gurney ride it is from the yard to the morgue.
Re:programming != managing (Score:3, Insightful)
Sorry Jamie, not the case here.
You make a false assumption with your title. Programmers aren't necessarily managers, but to manage a programming project, the manager HAS to be a programmer and a manager. This is a common mistake many people make, it's a popular meme that "with the right management skills, you can manage anything." But it's simply not the case. Look at Big 3 as a great example. They've been run by accountants/manager types for years and look where they've gotten.
Look at any company that got rid of the product guys and replaced them with management guys. It almost guarantees poor products, leading to decline sales and bankruptcy.
Ever heard of Apple? Look what happened when a pure manager took over there.... they tanked until Steve Jobs took over. Or hey, what about Microsoft? Oh right, since Steve Ballmer took over, Microsoft's marketshare has eroded to less than 90%.
I could go on, but I think you've realized your mistake already.
The worlds need geeks. Not management tools.
What I saw as good (Score:3, Insightful)
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.
Ask not (Score:1, Insightful)
Ask not what they can do for you, ask what you can do for them.
Don't kiss up and kick down. Or vice versa.
Everyone needs to move in the same general direction. The direction needs to be informed from above and from below. Figure out where you're going and communicate your destination clearly.
Be ethical.
Don't play favorites.
Respect expertise, but don't tolerate rank insubordination.
It's not your job to be everyone's best buddy. Don't be an asshole either.
Protect your workers from needless distractions (e.g. meetings) so that they have the dedicated time they need to focus.
Be a good example.
Try to align your worker's goals with the company's goals. Help them reach their goals, and they'll help you reach yours.
If possible, keep people with very similar skills on different teams, so that they don't step on each other's toes. Value diversity over homogeneity.
Bring a hooker to the office every other Thursday. (Just checking to see if you're asleep.)
Try talking to them. (Score:4, Insightful)
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.
Re:Don't be a douche (Score:1, Insightful)
You need to decide what type of manager you want to be. This may also be dictated to a certain degree by what sort of company you work for.
The United States military has the Army, and the Special Forces.
In the Army, specific orders are given from the top down, and dare not be questioned. "Clean your assault rifles in the next five minutes, or face the consequences!". There is no room for enlisted men and women to question a superior officer.
Now consider the Special Forces. They work in small, loose knit, autonomous teams. Each member will speak a different language and have a particular skill (munitions, medic, translator, etc). A team will be sent in under the radar and have to think for themselves and adapt to conditions on the ground.
A team of programmers is a lot more like the Special Forces than it is like the Army. Which sort of company do you work for? I've worked for both sorts of companies (as a programmer, not in the military), and I can tell you where I'd rather be. I want to be treated like a professional, not an 18 year old kid operating a deep fryer.
Fortunately, I'm at a Special Forces type of company now :)
Re:As a seasoned programmer I can easily answer th (Score:3, Insightful)
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 not have the aptitude, remit or time to deal with all this, or (more often than not) they simply aren't interested.
And that is fine: that's where the team lead or project manager comes in. If some manager is being an arse about requirements or timelines, make sure he talks to you instead of your team. And also make sure that you know how to handle that manager. Can you convince him he's wrong, can you find someone who can, or can you discuss this with the project's steering committee or sponsor? Many, many incorrect decisions and false assumptions will be made. As a techie with a bit of business experience, you stand a fair chance of spotting these. And as a project lead, it is your job to steer the ship away from disaster and back on course. That's where your added value lies.
In my opinion the Parent's statement quoted above is only half right. If you have a team of seasoned and competent programmers, your challenges will indeed not arise from your team, but from the business side. Which means you are anything but redundant.
You don't herd cats - you just put them.... (Score:2, Insightful)
Re:Don't be a douche (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 overkill. If you have a dev team of 8 or more developers, walking around to figure out where everyone is at is tedious and inefficient for all concerned.
That said, if the status report takes more than 10 minutes a week to prepare, something is probably broken.
Re:Don't be a douche (Score:2, Insightful)
However, the one item that I do have a problem with is the written status reports.
Shit tasks like this should be the responsibility of the manager, so she can earn her advanced salary. Passing a status report onto an employee is lazy, shirks responsibility, and takes them away from work that will deliver that product on time. Don't pass off your responsibilities onto your employees.
Easy (Score:3, Insightful)
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.
Re:Don't be a douche (Score:4, Insightful)
If they can't be bothered to fill in a basic status report, you really don't want them anyway. I don't give a damn HOW good they think they are, if they can't do what they are told to do, they're next to worthless.
This bullshit about how you let good/great programmers get by with whatever they want is just that, bullshit. They aren't any different than any other employee, they can either function as a normal person or not, if not, you are probably better of firing the 'uber programmer' and hiring a half-assed programmer that will actually act like a normal human being. Its far more important for a company to have a reliable individual than it is to half a great programmer who doesn't listen or does whatever THEY want rather than what you need from them.
There is a LOT more to being a 'great programmer' than the code you write, and all those people who think they are so great they don't have to do any of the management related portions of the job really aren't that great. ESPECIALLY the ego.
Remember, big ego != (actually good || worth keeping around || worth paying || worth having to deal with)
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.
Re:Don't be a douche (Score:2, Insightful)
Periodic status reports are a tool to manage low-level white-collar workers, not skilled professionals.
Do you really think lawyers, doctors, talent agents, sitcom writers, fighter pilots, traders, salespeople etc, fill out status reports?
We don't, and we just say "fuck you, I'm doing my job, fire me if you're not happy with the way I'm doing it. Oh, if you have anything constructive to offer, please say it, otherwise, go away. Company policy? Great, have an admin write the status report or enter the hours worked or whatever - that's what we pay them for. Actually, what the fuck is your value-add in this deal? You explain what management want to us, and then explain what we did to management? You are a cost-center, do you earn enough a year to make it worthwhile for me to get you fired? Get the fuck out of my desk space and don't come back until you have something useful to contribute."
It's quite simple really. In other news, Bank of America to lay off 30K "workers." Fuck em, maybe they can use their mad management skillz at Burger King.
Re:Don't be a douche (Score:3, Insightful)
'In addition, my experience is that is many cases people who think they can bullshit their way through a report and look good are often detected doing that'
Then again, nobody would know if you're wrong eh?
Sort of like the police always catching the bad guys in crime when they are lucky to catch one in a thousand.
More suggested reading material (Score:3, Insightful)
I'll also recommend Peopleware [amazon.com] and follow the advice in the "Oh for crying out loud" post that this reply is under. I was going to post essentially the same advice.
I once managed a software development group that had several Ph.Ds, some people with Masters degrees (I have an M.Sc. in Math) and most of the rest with B.Sc.s in computer science. We were developing software for a radar project and most of the Ph.Ds had degrees that were applicable in fields like high energy physics and atmospheric physics, etc. They all came to the same conclusion that they couldn't do what I did which was serve as the communications channel between my group and upper management. All I had to do was make sure thet they knew that I knew that they had the answers. They even had to help me with the questions some times.
The key was that I didn't have a problem with this situation. It would have been a problem if I had pretended to know or had ignored the fact that they knew more about the subject than me. Instead, we became a team that solved the problem (almost on time and very close to within budget on a cost plus contract).
The people working for you (hopefully) want to solve the problems you bring to them. Work with them to understand the problem and keep the part that they are trying to solve within the realm of technology. Do your best to keep company politics from disrupting them. Likewise, learn to spot when someone is trying to have your team create a technical fix to what is essentially a political problem. That's usually a recipe for disaster. The better you are able to keep your team focused on technical issues, the happier, more successful and more productive they will be.
One last thing to remember. You mentioned that your team is older than you. Keep in mind that most if not all of them made a conscious decision NOT to go into management at some point in their career. They don't want to deal with management/company politics stuff. That's your job and they will be happy to let you do it so long as they can keep coding.
Cheers,
Dave
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.
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.
Re:Key Point # 1 (Score:2, Insightful)
Ah, were I only 10 years younger with this strong mentality now! Had I known these things then I would be in a much better place. Alas, I have no son to pass this knowledge to, so I post it to Slashdot. You guys are so lucky. 8-)
Re:Key Point # 1 (Score:4, Insightful)
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.
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".