Slashdot Mirror
How Do I Manage Seasoned Programmers?
An anonymous reader writes "I have a technology background and worked as a programmer for a few years before slipping over to the dark side. I am now on the business side and have been given responsibility for a small team of Java programmers. While the technology aspect of what my team works on doesn't scare me, I need ideas to make sure the team stays motivated while reporting to me, a business-oriented guy. Perhaps I should mention I am in my early 30s while the majority of the team constitute an older, wiser generation. What advice should I follow to avoid turning into yet another Bill Lumbergh?"
These are creative people, and will resist things like status reports and hard work schedules.
I want to delete my account but Slashdot doesn't allow it.
Microsoft Project!
11 herbs and spices?
Salt / Pepper / Oregeno?
TFA doesn't really help.
Faster! Faster! Faster would be better!
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.
As a programmer, the thing I hate the most is having to redo code over again due to poor specs or bad design docs. Make sure they are organized and have the correct specifications.
Marge, get me your address book, 4 beers, and my conversation hat.
The big problem I see in people who are tech managers is a lack of understanding of project management. They're fine with people, if not missing some subtlety here and there, and it sounds like you've got a team that has few personnel problems. So focus on building your project management talents, which is about deadlines, coming up with objective measurements for progress, and setting realistic goals. Your team should be able to tell you where the trouble spots will be in the development cycle, how fast they expect to overcome each obstacle, and help you plot a roadmap, but only if you ask the right questions.
#fuckbeta #iamslashdot #dicemustdie
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.
Mod me down, my New Earth Global Warmingist friends!
Mo money mo money mo money!
Just in case I know you in person.
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.
I'd rather have a free bottle in front of me than a prefrontal lobotomy.
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.
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.
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
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.
You don't want to touch them too often or they get tough and dried out.
Oh wait, that's hamburgers. Nevermind.
Focus on getting them what they need, staying out of their way, and keeping the management shit out of their way.
Fight Spammers!
n/t
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.
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.
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.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
You don't have to. You are redundant.
Once I was a four stone apology. Now I am two separate gorillas.
Listen!
What does responsibility mean? Can you fire them and increase their salaries? If so, then they should be relatively motivated to at least meet your expectations.
What can you do to make it easier? Don't be a bozo. That means (1) take the political heat for your team, and (2) try and insulate them from changes in specs. Or, (3) make sure they know what they're building/supposed to do.
Think of them as normal employees, not programmers. Sure they may be smart, but they're still people. Possibly weird, potentially infantile, probably high maintenance, and hopefully productive people, but they're still people. So treat them like everyone else.
Oh, and be sure to treat them like experts. They like that.
Seriously. People will tend to respond a lot better to you if they feel that they have legitimate input into the process, and many of those folks might be able to provide ideas and experience that you can benefit directly from.
Of course, I'm speaking as a 46-year-old programmer who's been doing software design/development for 20 years, so my bias is from the other side. Then again, most of the folks I tend to deal with are at my experience level or higher so in many cases *I* tend to be the youngster with the radical ideas. But I've learned to defer to my elders in many cases even tho I disagree. Sometimes they actually turn out to be right! ;-)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Be the type of manager that YOU would want to work for.
[Insert pithy quote here]
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.
If you mod me down, I will become more powerful than you can imagine....
Pay more.
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.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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.
This guy's the limit!
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.
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
Fred Grott(aka shareme) http://mobilebytes.wordpress.com
... your "customers" and your team will never fail you.
-
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.
--
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.
Things you think are in the Constitution, but are not.
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.
I've abandoned my search for truth; now I'm just looking for some useful delusions.
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.
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.
throw new NoSignatureException();
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
or
http://www.stevemcconnell.com/rdmistak.htm
Don't tell him that. He'll actually believe it.
Here's what you should actually do: Manage.
Be honest with your team. Tell them what you need and when you need it. Take advice from them on the best way to arrange that. If they're experienced (read that as set in their ways) forcing some oddball paradigm on them will send you permanently to PHB land. They'll never listen to you after that. You'll be regarded as an obstacle rather than a help.
You're herding cats - never forget that. Let them do what they want in the way they want to do it and all should be well. Just make sure they know what your expectations are.
And if you want something Lumbergh-like from them, say so. Then do the unusual thing and say why you want it. Don't just demand status reports from them. Ask for them, tell them you need these reports "because of pressure you're getting from your supervisor about this certain customer, and if we make schedule with this project they will potentially select us for the next project, and that means more revenue for the company."
Talk to them as equals. Explain your concerns to them. NEVER talk down to them or enforce some odd idea that the manager caste is above the programmer caste. You are all equals on a team, sink or swim together.
Do these things, ignore the buzzwords and manager-hype, be their fellow employee and the details will solve themselves. If these guys decide they like you your job will become a thousand times easier. You will always have loyal allies, rather than disgruntled drones.
And best of luck. Don't just be a manager - be a good one.
Weaselmancer
rediculous.
shot web?
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.
"The ferrets, they're every where I tell you!"
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.
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
A whip and a chair.
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)
Non sequitur: Your facts are uncoordinated.
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.
My blog
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.
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.
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
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).
That is all.
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
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
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 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.
* 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.
ffs you just caused me to embarass myself by breaking out in sudden uncontrolled laughter, sometimes slashdot is annoying
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?
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
Lost at C:>. Found at C.
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.)
Don't you wish your girlfriend was a geek like me?
That's easy. Red staplers. Preferably of the Swingline brand.
I never spellcheck and I freely admit it. Save your karma for more worthwhile "lol erorrs" replies
More coding, less documentation. Keep it easy for the developers to focus on coding rather than have to write bunch of documents.
First, read Gerry Weinberg's classic work, "Becoming a Technical Leader". 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" 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" 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..
Bruce F. Webster (brucefwebster.com)
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...).
Please don't use "umm" or "err" or "erm".
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.
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.
---don't make me break out my red pen.
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?
leave them alone, and do not get involved with the project unless they:
1) Miss deadlines.
2) Deviate from the requirements.
3) Go over budget.
I would do it this way:
For 90% of my interaction with my group, I build the project nightly from the subversion tree.
We had a development branch, production branch, testing.
I would build the project daily.
The only thing I told my 5 java guys is:
1) If I cannot build the project daily, I am going to bug you.
2) If you do not meet the deadlines I am going to bug you.
3) If you do not meet the requirements I am going to bug you.
4) If you fail my user testing I am going to bug you.
Never had to say much to them, really except for the weekly meetings.
However, this might not work for groups who are composed primarily of people who need or want direction.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
It's the chain I beat you with till you learn who is in Rutting command.
Hey pritty stars....
In the not too distant future, next Sunday A.D.
Seasoned programmers manage YOU. Now gimme those bailout bucks and shut up.
I manage a staff of 12 locally (others overseas) who's collective tenure is in the hundreds of years (no joke). One guy I'm giving his 45-year service award Monday. What I've done to keep them motivated and earn their trust/pseudo-respect: fine common ground through humor, interests, life (e.g., children if you have them) and build from there. I've kept them motivated through various incentives (money, looking the other way on leaving early, some work from home) but I also make rational arguments as to why, for example, I've raised their productivity targets. This has resulted in a 50% YOY productivity increase, and they'll go 30% over that next year at this pace. No one hates me and while they may grumble, they understand why things are the way they are. Anyway, hope that helps.
Are they really older than you? Time can be hard on a Java programmer. Double check.
Be like oil in the machinery rather than molasses. The best teams need the least managerial intervention. And oh yeah NEVER EVER micro manage.
What you're responsible for is what they produce, not the people. If your team is composed of professionals, they will be self-motivated already. So focus on helping them produce. This means looking for what's hampering them and working to minimize/eliminate it, and looking for what could make them more productive and working to provide that. If you don't know -- ask. Talk to them, as a group or one-on-one, and find out what their "pain points" are or what they want to see done.
Never forget they are people, not "human resources", and treating them with respect and consideration will earn you major props.
Thomas
try this: start every interaction by assuming you know nothing and that they're right. they probably _are_ in most cases, but finding out is the problem. taking this stance will give you a better chance of engaging them. you have a little knowledge in their domain, so strive to keep it from being dangerous. sure, you have other knowledge (and constraints and commitments) but everyone is better off with a cooperation rather than hierarchy. hierarchy inevitably breeds resistance, ignorance, conflict, etc.
You probably also have people working for you who are more intelligent than you are - statistically speaking, it's likely. I would expect you have the experience and maturity to deal with that situation, too.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
The short answer is: stay out of their way and let them do what their good at. Be sure they have what they need and go to bat for them when needed. At the same time stick to goals and milestones of the project.
Honestly I think this advice is applicable to most teams and managers. Good luck!
is don't take the piss , don't let them take the piss and talk normally. Only pull being manager when you have to. Treat it as though you are all in it together and you are there to filter the crap out and make sure they are doing what the business needs.
...and use Agile. Here is the best book in the world: Agile estimation and planning
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.
Doing lines off a hooker's ass is the ONLY decent delivery system for blow. I mean, come on.
Please stop stalking me, bro.
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.
I've just spent 2 years managing programmers who although not older, were generally much smarter than me, so I speak from relevant experience.
First of all you have one huge advantage; Software developers want to do great work. Coders are generally passionate and proud about what they do.
Your job is to make sure they have the environment they need to do that.
Programmers tend to be task-focussed people. Their faults are typically that they don't communicate unless asked, and they forget deadlines unless they are constantly made aware of them. Obviously I'm generalising here, but the balance of your team will probably tend this way.
So what you need to give them is clearly defined tasks, regular meetings where they talk to you and each other, and no excuse for not being aware of their targets/deadlines.
Most people, and geeks more than most, don't like to be ordered around and will be more invested in decisions they made themselves. Therefore when you make decisions about the development process, do it in a meeting. Say something like, "We need a more structured process for development." (Programmers will generally agree, they like order and structure, that's why they're programmers.) "We could use [insert favoured methodology here], what does the team think?"
If they have no stronger opinions, people will generally choose the one choice given to them and consider it to be their own idea from then on. If they /have/ got stronger opinions, they might well be worth listening to.
So in short;
Define the team methodology in as democratic manner as you can.
Get them to sign up to the methodology and make it theirs.
From then on enforce discipline with reference to the methodology. Your authority then proceeds from the team itself, as well as your position.
A couple of other piece of advice; be a hard-ass about defining requirements with your clients (internal or external) and even more so about changing them. Learn everything you can about software estimation. Most projects that fall over at the end make their mistakes at the beginning.
Never trust a man in a blue trench coat, Never drive a car when you're dead
While it's not nice, it's certainly true.
Every coin has 2 sides you know.
They work for you, because they are seasoned experts. So ask them, and expect them to know better than you. There's no shame in it. You are the expert in your field. That way you work together instead of against each other.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Not the other way around.
You exist in order to create and maintain an environment in which they can get their work done. The better you can do that job, the happier everyone (them, you, and your customers) will be.
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
Take time and expend the effort frequently to see things from your engineers' point of view, given the information and the incentives and the motivations and the backgrounds they have.
Technical management is a little tricky, especially with experienced, high-caliber resources. You HAVE to understand current technology, and solid design and architecture principles or you'll either get run over or completely alienate them, neither of which is good for business. Luckily, it sounds like you have a good start, possessing a technical background. You don't have to continue to code, but should at least be able to converse. A large part of the value of technical management is to be able to communicate technical constraints and direction to the business AND vice versa. PM is just PM...and is a given.
Other posts have summed it up: be good at your job. The programmers are good at theirs; you should be good at yours. Being good does not mean building up an impenetrable layer of bullshit so you can CYA and point fingers. That's the primary indication of being crappy at what you do, regardless of what it is.
If you don't know, admit it. Ask. Figure it out. RFTM, ask the right questions, take advice seriously, let people do their jobs. If these people are truly good at what they do, your job is simply to be there making sure they're working on the right project and getting them the support they need to get their job done. Be their advocate, not the representative of other groups.
What you need to do isn't hard. You should already know these things at some level. Just do them.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
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.
And remember they are professionals, treat them like that.
Think Deeply.
Surprise tickets to the Star Trek movie when it comes out and the afternoon off to go see it as a group would probably endear most of them to you for life.
As mentioned in another reply...they are not exotic animals or anything. Treat them as you want to be treated and be honest and respectful and they will be respectful of you as their manager.
I'm currently working for someone younger than me for the first time in my life. However, he is a respectful manager and I respect him and enjoy working for him.
I don't even think he minds me posting to /. occassionally...but just in case, here he comes and I'm outahere...
I only manage myself, and I'm on a deadline, so the best thing I can probably do is point you to the blog of a genuinely smart manager, Rands in Repose.
Even though it's not really aimed at me, not being a manager, I still find at least a couple of things to take away from every entry.
More rank and file programmers should read this guy, too. Gives you a real insight into what is involved in the bigger picture. It will make you a better developer.
This is the voice of World Control. I bring you Peace.
Substitute accounting for programming and I'm there. The pure and simple truth it leave them alone and let them do their job. They know it better than you ever will and have solved problems you have never seen. Most employees that have been around a while know what their job is and how to do it. Come up with a reporting system that helps them manage their work and gives you the information you need and then don't manage/report them or the project to death. If you do this you'll do fine. Try and manage them too much and out the door they go.
I need very little from a manger, but those things are needed very much.
Keep upper, and other, management off your team members' backs.
Resources, particularly test resources. Whether, or not, there's a formal QA for your group's output, be sure that they have appropriate, especially correctly scaled, test beds before it goes to QA/production.
Find out what the real desired product is, not the "wish list" of current buzz phrases that is often passed off as a requirements document.
Once in a while, you will need to referee. Software is still much more of a craft than engineering. There may be more than one usable way to solve a problem, and if the team can't reach consensus on its own in a couple of days, then you will have to choose a path to keep things moving.
Schedules: multiply the value by two and raise the units to the next level. "Two hours" is "four days", by the time it is properly done, rather than a "this will bite you in the ass" quick hack.
Keep the long days for a real crisis, not lunatic PHB expectations. If your team is at all competent, you'll get those days when they count. When they happen, provide a late-evening meal on the company's bill.
I am in a same boat as you. Except for the fact I am also a seasoned programmer myself.
Honesty is always the best policy.
Don't try to pretend that you know what they are talking about if you don't. Stop ask questions get informed, it is not a sign of weakness to not know everything. Even seasoned programmers don't know everything and need to learn stuff from other now and then.
Insure you are meeting the Business Requirements. That is you main job. Make sure the programmers are moving into a direction of meeting the business requirements. They are people and sometimes stray from the business requirements and begin focus on more
interesting things such as cross platform development and other good features and good ideas. You really need to balance these side ideas to make sure you are going in the right direction. If your app is planned to run on Windows with say Microsoft SQL Server with no plans of going to Oracle or MySQL in the next year or so. Then make sure they are not focusing on getting the product to work on Oracle just on Microsoft SQL which is the goal. If the business requirements change then we create a new projects for the change in requirements. Yes it will be cheaper in the long run if they Did both Microsoft SQL and Oracle at the same time... However if they never move to Oracle then you have wasted the money to get something that wasn't part of the requirements. Focus on the Business Requirements.
Next is to flexibility for the Non-Business Requirements. Yes, it is a contradiction. But these people usually know what code maintenance they will need to perform in the future. And giving them some breathing room will make things run smoother. Getting the right balance is an art of its own.
Don't micromanage. These guys are Pro's let them do their work.
Don't let them take advantage of you. You are still the Boss if you have a feeling you are going the wrong way. Put a stop to it.
Listen to everyone. Inside and outside meetings. Some people will fight to the bitter end for their idea. Others will be meek on them. Talk about issues in and outside formal meetings and get everyones input. Allow people anonymous contributions be anonymous.
Learn what is easy to program. hard to program, very hard to program and impossible to program. And if there are other solutions viable. And judge the value and time it takes to do each. You may need to change you plan because the value of adding a hard to program feature isn't worth the effort in doing it.
Learn what the guys like to program and dislike to program. Some things people enjoy doing and others they hate. Having a team try to make sure they are all doing things they love as much as possible.
Make sure they know how to do the things they hate. Make sure there is still exposure to the parts they really dislike as they may still need to maintain it in the future.
Give them some diversity. When working on a big project it is easy to get board with it. Try to break it up into small sections.
All them to focus. When there is a big section don't make them feel like the gun is to their head. However let them know that it is a critical component that cant be slacked off.
Allow them some FlexTime. If they like mornings allow them morning or let them work late if they feel like it and come in late. I am a morning person myself and managers sometimes assume that I am lazy because I leave work at 4:30pm although I got to work a 7:00am
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Andy Hunt's Pragmatic Thinking and Learning will give you some insight into different skill levels and how people at those levels go about doing their work.
As a long time programmer I don't want somebody that doesn't have nearly as much development knowledge as me trying to lead me by the hand. Leave me alone and make sure the specs and requirements are good (something severally lacking usually) and I'll make my milestones.
That's what my boss does. Nobody 'manages' me. I am expected to do my job and if somebody in the environment doesn't do it's job according to what is demanded, they get talked to and eventually fired. You are 'managing' 5 programmers? That's more like micromanaging to me and it brings only pointless meetings, cruft and endless delays in projects. What a programmer's manager does (what my boss does) is to keep me from having to deal with stupid people (upper management and HR) keep me from having to distract myself from my job for no good reason (support calls that get escalated etc.) and to keep me supplied with what I need (office supplies, budget and paycheck).
Just start out by making some coding guidelines (function and class namings, documentation, overview etc.) and then let them do their job. If they really are seasoned, they won't need much handholding if any. If you're in charge of a group of fresh programmers, you might have some more stuff to do with them and have a bit more meetings but in general once they get to know one another and get used to a certain regiment, they will 'grow up'.
And yes, programmers play a lot, they have a lot of fun, they're not always working while they actually could work, but we're like artists and you have to accept us the way we are, you don't rush us and do your job managing the managers (set reasonable deadlines and stuff) eventually you'll get a masterpiece. All you need to know is that it's going to be done when it's going to be done and maybe a status update once in a while. Just trust us that we know what we're doing.
Custom electronics and digital signage for your business: www.evcircuits.com
How to manage seasoned programmers? First, become a seasoned manager. Then act naturally.
Don't assume that because they are programmers, they don't understand business or the big picture. If they are truly seasoned then they have probably done a stint in management at one time or another and chose to go back to development. Perhaps the best advice I can give is listen - you might just learn from them. After many years of taking upper management's great new ideas and trying to shoehorn them into the way the business actually works though carefully crafted software, there's a good chance they know more about the business than anyone else.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
Good luck with that. I've had one good manager in the past 20 years.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
As a manager, MANAGE stuff. Don't attempt to DIRECT the project and people.
That means listening to your team, gathering information for them, from them.
You may understand programming, but don't claim to "know" what they know. Wisdom is learned from experience.
You know who Bill Lumbergh is, and obviously have watched "Office Space."
Half the battle is already over.
The price is always right if someone else is paying.
Simply point out the fact that this post has made it to the /. front page. That alone should give you sufficient geek cred that they will respect your judgments and understand that you are trying to to what's best for the project, from both sides (Development AND Business).
"To invent, you need a good imagination and a pile of junk." - Thomas A. Edison
Any technical manager's job is to:
Keep them supplied with work
- make sure the work makes sense
- try to keep it challenging
Keep other people off their backs
- from above AND below
- don't let them be constantly interrupted
Keep them on track
- be available for questions
- meetings no more than twice a week, no less than once a week
- keep all meetings short and concise
Reward hard work
- small things like buying them pizza once a week is nice, even if your programmers all make 6 figures
- push for bonuses and awards for those who do a great job, and not phony certificates - CASH awards
- allow flexible working hours
eom.
Do not call them older. The wiser part is appreciated by them, I'm sure. Still under no circumstances should they be addressed as older. To keep them motivated, provide. Provide coffee, healthy snacks, and rewards for work done well. Make sure that their needs are met, both financially and mentally. Make sure they check slashdot, or other posts as a group. It will be a good team building experience to talk about the news of the day. Remember, that bringing people together is much easier than you think. All you have to do is keep a positive attitude dressed in a smile. Be professional first, but keep kindness in there someplace too.
Assuming you're all in the same office...
One-on-one meetings in a comfortable and somewhat informal manner. Make it regular (twice a week or so?) and find some way to give them advanced notice indirectly, like doing it at the same time every week or passing by their office/cubes a few minutes before jumping in to ask for the informal report. If you startle them, leave and come back in a few minutes (really!). Their desks should be oriented in a manner that makes it hard to sneak up on them; if that's not the case, buy a mirror for their monitor.
Group meetings at a less often interval (weekly or every other week) where everybody talks about what they're doing, and you reveal the long-term strategies, etc. Doing this over a free lunch or end-of-day beers (5:30p is "beer thirty" on "frosty friday" or "thirsty thursday," etc.) is always a winner. You already know most of the answers, so this is actually all for their benefit; this is when you report to them and they report to each other. This helps emphasize the philosophy that when co-workers are all friends, more work gets done with less apparent effort.
Never criticize them for something you also fail at. Instead, announce that you're looking to improve that aspect in yourself and they'll get the message.
You read Slashdot, so you're probably very IT-savvy ... older software engineers are a bit removed from that, so be careful about introducing new services (e.g. software services for bug tracking, wiki, source control, project management, social networking). When you do such introductions, make sure they are walked through, and the installation process is trivialized (all the above examples are web-based to eliminate client-side installation).
Finally, pick up a book on agile development practice and consider migrating the team to a scrum cycle. Even if you decide it's not the right idea (or if you're already doing it), it will give you some management insight.
Use my userscript to add story images to Slashdot. There's no going back.
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.
I've been on slashdot so long I'm starting to get out of touch with the cool stuff if it ain't on slashdot.
and lots of it.
No pants Friday!
What they care about is how good a job you'll do protecting them from all the usual political garbage that has zilch to do with them completing projects, and standing up for them when other groups demand unreasonable changes at the last minute for free.
Just be crystal with them.
-- Tigger warning: This post may contain tiggers! --
1) Don't attempt to babysit them or micro-manage them.
2) Ask them for what they prefer to deal with specifically with in projects and attempt to assign them tasks within those areas first.
3) Have them give you a weekly status report on progress made and status of projects.
4) Let them do what they're good at without interference.
Don't make assumptions about their knowledge of business just because they choose to stick to programming. Experience and time in business is worth every bit as much as management experience, and some people just don't want to manage others period no matter what their level of business understanding is.
Pantek, Inc. - http://www.pantek.com/ - info@pantek.com
+1-877-LINUX-FIX - Expert Open Source Support
http://www.youtube.com/watch?v=TvYqhYEaqMs
http://en.wikipedia.org/wiki/Scrum_(development)
Not any particular hint for seasoned programmers. Just do it well and it will be OK for juniors and seniors.
1. Don't pretend that you understand all technical stuff.
2. Don't question developers estimates. If they say that something takes given amount of time, then it does.
3. Be boss. Your ass is on the line. Developers know that company won't be loyal to them, and they won't be either. Everyone is (should be) covering their own ass.
4. Head count is important, but 4 developer does not equal 4 developers. Firing one guy and employing different one, does not mean that your project is on track.
5. Other than that? Manage, keep track how things are going. Don't be afraid to ask how things are going. Usual stuff.
...they should be reporting to a lead, who is a technical person - the lead should report to you depending upon your position.
In all honesty, you should not be in their hierarchy at all if you're business oriented.
For example, I am the CTO at my current company, where I've been in this position for 4 years. There are technical people in two groups at our company: (1)Development and (2)Services
Development creates products - this is not to be confused with creating 'solutions.' ;)
Services create solutions - this is not to be confused with creating 'products.'
The development team reports to someone who is a direct report to me.
The services team reports to the Director of Services who is a direct report to me for technical matters (what product/tools/technologies for providing a solution) and to the President (I report to the CEO and the Board.)
The services team would remain entirely in engineering were it not for the fact that we're too small to have a separate technical support group and/or sales engineeering staff; ergo, Services handles all of these issues on a 'first tier support' basis.
The organization should differ based upon whether your an ISV (that may/not supply services work) or a services company. In either case, 3 developers shouldn't be directly reporting to someone in a business position.
Loading...
First, don't approach this backwards.
Don't think, "What can I do to/for them?" because that puts you one one side and them on the other. If you are part of the team then they will want to work for you because you are one of them.
Becoming part of the team doesn't mean doing their job. That is their role. Play your own. As a manager you fight for your guys in any discussion with the rest of the organization. And let your team see it. Defend their flexible time, their choice of desk decoration, whatever. Then eat where they eat and generally be around for them.
They will be motivated to work for you if they want you to be a part of their team.
Don't leave your developers out of your design discussions and brainstorming.
I once had a manager, a very good one, who told me his job is to remove any obstacles I may have so that I can do what I do best.
I think that was a great way of summarizing what great managers do day-to-day to help their teams be successful.
In Soviet Russia, I ruled you
Amen.
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.
Oolite: Elite-like game. For Mac, Linux and Windows
The best thing a manager can do is enabled engineers to do their jobs, don't disable them. Don't make technical descions. Descions should be made when dev's disagree, or present the cases for decisions to be made. Also budget should be your main constraint.
Or rather, do not engage in the 'layers of abstraction' model of LISP where each layer is entirely cordoned off from the others, and only information about official, authorized practices is allowed to be shared among different levels, and the different layers are forbidden from seeing the other layers. It's one of the worst programming practices I've ever been shown, and it's death to managing competent people. Your people will perform better if they're aware of other groups as part of their company, part of their group, with whom they share goals and resources.
Far too many managers are taught to segment their group away from others, to protect their turf and 'husband their resources'. The resulting isolation is devastating technologically, and socially, to a programming group creating products or an IT group providing services.
you can start from here:
http://lwn.net/Articles/105375/
First thing I'd do is:
1. Schedule more meetings and make them long, with everyone in attendance, even if what they're working on has nothing to do with the agenda.
2. Count how many lines of code they write, and count things like assignment statements as if they're as valuable as complex decisions.
3. Every time another manager says they didn't deliver what the manager wanted, march in and attack them, and take the other managers side. ... oh, wait, you wanted to be a good manager?
Then do the exact opposite of what I said.
-- Tigger warning: This post may contain tiggers! --
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.)
Do not allow politics (childish posturing by senior management) to force technical decisions on the team. Seasoned programmers don't suffer such nonsense and will leave - I've seen it on several teams.
1. Hire smart people who get things done. Look up in their resume if they finished school and if they have finished many interesting projects. Make them do tests or otherwise ask for certifications.
2. Install subversion.
3. Ask them to use maven 2 and then install Luntbuild on a build machine. Create Development, Staging, QA, Production machines.
4. Use archiva.
5. Use Jira or another tool for task tracking.
6. Set predefined delivery dates called iterations. Short iterations of about 2 weeks will do.
7. Scrub requirements until you know for sure they are really good requirements. Number requirements and then prioritize.
8. Prioritize work. This is management's job.
9. Developers estimate each Jira issue.
10. Create a meaningful release in the first iteration. Continue adding features on later iterations until done.
11. Use automated unit tests.
12. Use automated functional tests.
13. Each abstraction layer is run by a seasoned programmer (team leader). Helper programmers follow the seasoned programmer's instructions.
14. Team leaders do code reviews before check-in.
You seem to be pretty good at that, keep it up. Really what destroys good engineering teams is managers with other interests (such as forwarding their own career). If you put the team ahead of yourself--even stand up for them at the risk of being fired, you'll have a productive team and you'll be the most remembered boss on the unemployment line :)
Seriously, it sounds obvious, but it's a start. Figure out what their interests are, where their passions are in regards to their work, and determine if this is a person that you can put in charge of a piece of your project, or if this is someone who is only working for a paycheck. I've had my best results (and I picked this up from working in successful teams like this) by giving those who had stronger interests a degree of responsibility over a particular section of code, and had the "paycheck" guys work on all the other tasks that needed to get done.
This approach works fine for both Agile and Waterfall, if you really "get" both methodologies. When you're working with seasoned developers, you're probably working with guys and ladies who've developed strong interests in particular niches by this point in their careers. If you can find a section of your project that jibes with those interests, you'll probably get fantastic results out of those folks. People who tell you that it's better to stay super generalized and constantly switch tasks without respecting those interests don't understand that if you're not passionate about something in your job, you'll most likely start looking for another job.
And hey, if you have some seasoned guys who don't care either way, and just like that paycheck, those guys come in handy, too. They're like handymen, you can assign all the other tasks to them and they'll probably do them well enough. Saves you some time from trying to find contractors to do the work.
With an older, more experienced team, I would stay focused on constantly thinking and discussing things in the context of what's good for the team. Never make it about right and wrong, but always frame it in the context of moving forward. When two team members conflict in their technical views, they can either choose to take it personally or not. If you hear them both out and give them both a sense that their views were well considered, then the loser (for lack of a better term) can choose to either respect your decision or not. The only tricky part comes when a team member chooses to start sabotaging your role. This often takes form of saying nasty things about you during lunches you're not invited to, and constant disagreement with anything you say. In that case, you're actually dealing with a very inexperienced developer pretending to be experienced. At that point, you've got to go through the 3-step: warn, document, then fire.
Assigned a guy to handle schedule and budget, so I didn't have to.
Took care of the company politics, so they wouldn't affect me.
Created an environment where I could concentrate on my project.
Paid well.
Didn't require a lot of paperwork.
Didn't wast our time in meetings.
Approved the purchase of necessary tools.
Left the technical details to me.
Required excellence, rewarded success and dealt harshly with those who failed to deliver.
And no...this isn't a fantasy, it really happened.
from Tom DeMarco
First thing to know is that all programmers thing they're pretty good, but reality is 95% are utterly wrong.
Second, if you treat them as if they were commanding you instead of the opposite, you'll get in trouble, they only see code and technology, they don't care about business most of the time.
So first thing is: get real taugh on making them understand what they're building is something that someone is paying for, they expect to get that investment back and this is the reason they get paid. Not because they know how to write keywords in a geeky text editor.
Second: the only people I know who can transform technology into business value are those who are experts in both. So if you consider yourself a "business guy" get another job, you ain't gonna make it too far. For experts to respect you, you're going to need to be an expert too.
Third: on the personal daily job there's only one trick, which sums up the previous points:
- be passionate about what you do
- be the best at what you do
- be an expert
engineers are going to respect such a guy. (unless you're a extreme case of assholeness).
And don't forget to push your team to their limits, sometimes they'll be happy sometimes not. But that's the only way to get the most out of the people.
I understand why you are asking. A couple of things, without the sarcasm. Listen when they raise issues or offer solutions. Be straight with them if you can't go along with with they want, and let them know why. Let them set the direction when you get outside your realm of expertise. Don't hover. Don't set ridiculous deadlines and then constantly ask when things will get done. Don't have constant meetings in which they have no input. Stand up for them when needed.
Find out what works best for each of your engineers and be flexible. Is this person more productive when they work with a team, or when they work alone? Is this person more productive when you handle some of the organization responsibilities and let them focus on coding, or should you let them handle project planning themselves? Does this person like to have a more personal relationship with their manager (ex. happy hour) or would they rather come in, do their work, and go home at the end of the day?
See what works and what doesn't with each person. Chances are you'll be doing very little oversight, because you'll be busy fighting the pressure from the top down, but be ready to act as a decision maker for your team when asked.
http://positivesharing.com/2006/03/how-not-to-lead-geeks/ I sent this to my ex-boss once - I don't think she read it. By the way, there are many websites dedicated to this subject if you do a search for something like "how to manage geeks (programmers, technical people, etc.).
Take a humble approach, Start by seeing what each person works on and remember things worked before you came. Don't start making changes right off the bat. Also remember that you have two options as manager, Option 1 keep those that you manage happy (this goes along with the comment of being the sandwich) Option 2 Keep your Boss happy. Personally if you do Option 2 your boss will eventually be happy because remember those that you manage have the power to let you swim or sink. It is very difficult to do both but if you do write a book and let every one know.
Oh and for the record if you ask some one to come in on Saturday make sure you are there to help them out...and buy them pizza or what ever.
They will point out the comments they left for you here, and everything will be pretty peachy from then on.
You can't. Manage that is.
Managing techies is an oxymoron.
You can lead them, if you're good, you have leadership skills and are lucky.
Try to "manage" them and you'll be well on your way to being yet another PHM.
Read some good books on leadership, and pray you learn something about it before your team writes you off.
Chaeron Corporation
Seasoned programmers are uber geeks. They don't have much of a life so you can easily get on their good side. Make sure they get at least one good meal while at work. Allow them to drink beer on the job. Most geeks don't actually like beer, so you won't have much to worry about. They just want to be able to brag that they can drink at work. Most importantly, geeks have no social life. So once a week or so take them to a nudie bar.
Oh, you said "manage". I thought you said "manipulate". My bad.
-- Will program for bandwidth
I guess I'd be one of those older guys working or you...
Just do one thing: Be sure you KNOW what the software is to do and have some nailed down requirements. Go over these with the end user(s) untill they know what they are getting. The worst thing is "requirements drift".
Then you have the team make a plan. And your job is to make sure the plan is reasonable. By that it has critical reviews and various points. Make sure it has a design review before code starts and planty of time for quality testing. A plan that is "all coding" is doomed to fail. Have them make the plan then your job is to track progess and be the ring leader.
A really good software manager will make the rounds and talk to everyone and thereby prevent or reduce the need for meetings.
On the first day, figure out which one the others follow and then pick a fight. He'll probably be surprised by this behavior and try to back down, but don't let him. Deliberately misconstrue anything he says and then beat him soundly with his own keyboard.
The rest will have no choice but to bow down before you!!!
1. Keep them sheltered. Be a good buffer and facilitator.
2. Keep them informed; even of things you are buffering them from.
3. Give them input into decisions.
4. Allow them to choose/recommend the appropriate tools.
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.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Here's a good start, the Nerd Handbook.
--
*An associate's link! I stand to make hundreds of microcents if you use it!
blarg.
"... team stays motivated while reporting to me ..."
Most of the replies I see so far are really answering the question 'What makes a good manager?'. 'How do I keep experienced people motivated?' is an entirely different question.
When I was young, I didn't need anything from my manager(s) to be motivated. It happened naturally because I wasn't yet jaded or cynical. I hadn't seen one hundred page coding standards, TQM, Six Sigma, or AS9100A, and I hadn't been forced to repeatedly take training on how to avoid stabbing myself with writing utensils. The newness of any challenge was enough to make me excited.
Now that I'm older, what I need most to be motivated is to know that the people who manage my work (and rarely understand what I do) care about the quality of the product we produce. If you actually care about the quality of the software you deliver, then you will do lots of things that others have suggested. Its important, however, that you communicate that you're doing it because you actually care about delivering a quality product.
You'll fight for reasonable schedules and budgets. You'll offer your people ways to grow technically and organizationally. You'll value technical skill and put up with a little bit of personality shenanigans in order to keep good people on your team. You won't let your process slide, but you also won't pretend that a well-written TPS report is your actual product.
The most important thing is that a desire for quality is a motivation that managers can share with the people they manage. A junior programmer (no matter how old) may have a hard time understanding the business drivers that influence what you do, but that programmer does want to have his/her work appreciated. As a manager, you probably don't care that some feature of Java EE 5 makes your code so much more elegant the way that your programmers will, but if you understand that its increasing the quality of your code, you can appreciate it, too.
My advice to you, as a 'seasoned' software engineer, is to actually care about quality and tell your team that you do.
By the way, take some of the advice you're being given with a grain of salt. People with 11-digit slashdot IDs are not 'seasoned'. They're brand new :)
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
As a 36 year old Technical Manager with no direct reports younger than me I can feel your pain. How do I tell people who have been doing their job for 10-15 years how to do their job???
I have always taken the roll of being an advocate for my team pushing upwards and an advocate for upper management pushing downwards. Not always easy. Basically, I make sure my team clearly understands the goals and when needed the who, what, when , where and why's. They need clearly defined goals and dead-lines .. and me off of their @sses while they do it. Weekly/Monthly progress checklists help them keep on track and make it seem like I am not riding their butts.
One thing that helped our team communicate A LOT (I can't stress how much this really helped) is the Myers-Briggs Type Indicator. This little team builder exercise showed us how each other communicates and interacts with the team. My boss is intuition and feeling while my director and I are sensing and thinking. This means what my director tells my boss gets changed from the way she puts it into the way my boss hears it and then I don't get what I need from the info. It sounds kinda odd, but it really helped us as a team to learn why someone seems a little grouchy and the other a little sensitive AND how to work together.
Good luck, I hope any of this helps!
Your job isn't to tell developers how to do their jobs. Your job is to tell them what goal needs to be accomplished or what problem needs to be solved, and then get the hell out of the way. Your contribution is to remove impediments to the work, not direct it. When you direct it, you are an impediment.
I'm surprised that most haven't mentioned what I would consider a couple of the most important points:
1. Don't EVER micromanage.
2. Make priorities clear.
3. Be accessible.
Expanding a bit:
1. Tell them what needs to be done, when it needs to be ready, ask for concerns and suggestions, and make sure that they understood this. And then get out of the way (trust that it will be done by then). You'll need to check ocationally, but not every hour :), you'll need to give them updates if the requirements, dates of priorities change, but other than that: stay away.
2. Explain clearly the relative priorities of different projects, and let them handle it. Don't try to tell them how to manage their time.
3. Make sure they know they that they must update you if something can impact their schedule or requirements and deal with it. Really be open to their suggestions and concerns, and do something about them. Make yourself available so they can come to you when needed, and make sure to let them know they can do so.
One problem you're likely to encounter is that they think their experience is more valuable than it actually is. While it is very valuable, in some areas it just won't apply. And they won't want to listen to you because you're a noob.
So make them talk to each other. In case of disagreement, call a meeting with "your senior advisory team". Make a point of listening to people who disagree with each other. If they're really good, the best solution will emerge naturally.
I'm not a programmer, but here's what I like as a human being in an IT organization.
* Don't lie to your employees
Especially the "everything is OK" when you really mean "everything will be OK after you're let go Friday" or "everything will be OK for ME because I'm cashing out my stock and running".
* Remind them that they are valuable to the team
Point out to each member what they bring. While teams can cover for each other, it's their unique skills/knowledge that got them hired.
* Information
Keep them informed on the product they're developing, how the company is doing, how they're doing, and most importantly, what they can do better.
* Bacon
Once a month my boss cooks our team several pounds of bacon along side other breakfast food. It doesn't make us more productive, but it's a great way to show appreciation.
* Let them work
You don't need to tell them how to do their job. There's a great quote, "people like to be LED, not managed". Tell your team what needs to be done, offer help on how to do it, but they're smarter than you. If they're producing good code, stand back, let them code, and be accessible when they need help.
* Don't harp
If you have an employee who's slacking, writing shitty code, or something else unproductive, bring it to their attention in a calm manner and help them correct it. Harping is for a truly broken employee. Guidance is to help good people stay good. We all screw up, off, and otherwise. We're human. Remind us that we're expected to make mistakes, and we can correct that hich is correctable.
You are a "manager", and you need to understand that you are not a "supervisor", mostly because your staff won't necessarily need supervision.
As a manager, you do not work for the company. You work for your staff. You are only PAID by the company. Your job is to make sure that THEY can do THEIR jobs. You are the liaison between your staff and the company. As such, your responsibility is to discover the needs of your staff and do what is in your power to cater to those needs in an effort to maximize the productivity of your staff.
A programmer with concerns about his pay or his vacation time, etc, is going to be much less productive. As a manager, your job is to manage that problem by finding answers and pursuing solutions to problems that exist outside of the production environment.
Think of yourself more as a "coach" who needs to train a team to be as effective as possible... because that is what you are.
Just like most programmers, you will likely be most effective at your job in ways that are virtually invisible to everyone else; your associates will only be aware of what you do when you don't do very well at it.
Keep that in mind too, and realize that your (in all likelyhood) under-appreciated staff will benefit from being recognized for doing their jobs correctly once in a while.
Just keep in mind: they don't work for you, you work for them. They work for the company. It will keep you in perspective.
Reality is prettier inside my head...
if you're not using a methodology like Agile Scrum, or some such that can manage spec's and produce on going working prototypes that allows everyone to get a sense that something is taking shape, then you'll end up doing something like waterfall. And then that's the end of that. Season programmers have been through all the scope creep scenarios w/o being able to get anything up to prototype state of execution. At least things like Scrum allow you to have 10-20min standup where you get your status reports and developers don't have to remember to email them to you and the end of day/week. Agile is actually rather good at getting individuals motivated and satisfied. Scrum is what is used here at where I'm working. As a seasoned vet myself, all I want is to see code+unit_tests(passing)+releases that show me that we're being productive as a team.
Congratulations on making it to middle management! You have successfully demonstrated your ability to offend the least amount of people and an uncanny inability to say "no".
Now that you have this position, it's time to start forming your own thoughts and opinions again before your underlings figure this out.
As a manager, you should be a leader. You should have opinions and be intelligent. But you should delegate important tasks to people wiser than you. You should respect them, even though they might have edgier personalities than you (you cool cool cat)!
Because the moment they find out that you have no backbone and no power, they're going to write you off as irrelevant. Which you are, but you must keep up their illusion. It's a tough line to walk, over that abyss of hopelessness, isn't it?
Buckle your ROFL belt, we're in for some LOLs.
jPod by douglas coupland would be good for you.
A computer once beat me at chess, but it was no match for me at kick boxing. Emo Philips
I am in exactly the same situation. Going over to the business side is a tough transition.
Becoming a real project manager means you have really document what's happening, and you have to forecast things that are impossible to accurately forecast. Just do your best to make sure everyone is on the same page.
Managing developers means not micro-managing. Coming from a tech background myself, I found it extremely hard not to do this. Step back, and let them do their job. Give them clear rules and structure, and they will thrive in this kind of environment.
If there's a conflict, then you really have to get down to making tough decisions. The hand that feeds you (the client) is the bottom line. If the personnel issues affect the clients directly or indirectly, it's time to start thinking about firing or transitioning someone. If not, then it's time to really get down to the problem and perhaps have more open talks with your employees. More communication can never hurt.
And finally, the biggest golden rule of them all: RESPECT YOUR EMPLOYEES, ALWAYS
Since when do we call Java writers, programmers?
You don't herd cats, you just put them near the mice and they turn into a ruthless and efficient killing machine!
As a first level manager of developers, you are...
[Posting as AC to avoid reversing my mods]
Two words:
quality staplers.
You have 3 choices in programming. 1. Good 2. Cheap 3. Fast Pick 2. Remember that. Wayno
Coming from a seasoned programmer (if 'seasoned' means grays):
* Don't do bullshit 'hi I'm your friend' crap. Like for instance buying them some token gift and saying 'hey look I'm so cool I got you this junk'. Even if it's expensive junk. This just makes you look like a tool and you'll probably never get their respect back. Buying a lunch is ok, only if it's on the company dime.
* Keep if professional. If you're a republican, never talk at lunch or water cooler about how awesome Bush is. If they ask you don't tell them. Nobody trusts you to do an honest review or work or salary, argue up the chain on your behalf, etc if they already know you're a retard.
* Don't try to act more knowledgeable that you are... you'll look like an idiot and a poser. I had a manager that would come in and in a conversation about work go off on a tangent like 'well you know they did that because...' some technical reason that was wrong. Since he's already lost any respect earlier (and he had no influence on my salary) I would correct him every time. But even if the guys don't correct you, trying to better them on tech is a bad move.
* Be rational. A manager I had would say he'd never let anything be done in Python because he doesn't like languages where whitespace is important. I'm not a fan of Python syntax either, but 'fu'. If Python is the right tool then use it.
Listen to the seasoned programmers. Find out about the successful programs they've delivered and what made the effort successful. Trust their judgments on technical matters. If you have to overrule them, make sure you've heard them out first and explain your decision. Even if the decision doesn't go their way they'll feel better about it if they believe they've had input.
Go to bat for them. They're programmers, not persuaders. You're the guy who has to make the cases for their technical decisions and judgments to upper management, and protect them from poor decisions made by upper management.
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
For starters, probably not the best idea to ask developers how to manage other developers. That's somewhat like asking a waiter how to manage a restaurant.
If you're talking about running an efficient software project, I recommend reading "Head First Software Development" and "The Mythical Man Month".
Just because they're seasoned software developers doesn't mean they have a sense of the trade-offs between scope, budget, and time. They also may or may not have much sense of how to prioritize things according to the business goals.
If you follow the process in the Head First book on Software Development, you should be off to a good start. You'll probably want to share the book with your developers to make sure they buy into it as well before implementing it, once you're agreed more or less on the process for the project you should be in good shape.
I think the biggest task you have is to translate between the business side and the technical side. In many poor workplaces, the problem is that the programmers don't understand the business purpose they are supposed to serve, and the business people don't understand the technical limitations and practicalities of the software system. As the manager, your job entails putting business goals in understandable language for the programmers, and explaining to business managers what the programmers are doing.
This can be a surprisingly though job, because the two groups of people often talk very different languages, and sometimes even show mutual contempt. But if you don't do it properly, you will see software design done by business managers, and/or business strategy made by programmers -- neither is a particularly good idea.
Your second major task is to stimulate your team to learn and improve, and to give them the opportunity to do so. Your programmers may be 'seasoned', but I don't know whether that means that they are very experienced or smart, or just that they are very experienced and stuck in mind-numbing routine. Anyway, there is always more to learn and good programmers really like to do so. You should protect your team against being so overloaded that there isn't any time to explore new things, and guide them in the direction of exploring something potentially useful.
I recommend the spork, or for the really stubborn ones, a fork and knife. this approach may also work other employees
Besides all that....
KNOW how a specification should look like, act for your team as the XYZ department was your client:
1. require a specification
2. provide a quote ($$ or man hours)
3. Write a contract (terms and conditions)
4. enforce it these !
when XYZ walks in, and tries to change stuff, point them to the project/ticker system, and ensure your team that the change WILL effect deadlines and not effect THEIR free time/holidays.
OR: they will start to freelance, leave you and enforce these themselves
OR: find a company with a manager who does all that.....
Just go easy on the salt!
Actually, I would draft a lieutenant or two from among the ranks of other programmers. This lieutenant should be well respected and trusted among the group. He should be someone that people should be able to go through or go to in order to appeal an unpopular decision you may make at one point or another. You should be their boss and their leader, not their friend.... the role of the lieutenant should be their friend... and the lieutenant should also be aware of his role in all of this and be smart enough to not ever express this to the group. A lieutenant is important for so many reasons beyond the simple "good-cop-bad-cop" thing... someone needs to be able to manage and keep up with stuff when you are on vacation!!!! Otherwise, you won't HAVE any vacation.
Theoretically, seasoned programmers should also be self-driven and directed and mature enough to make their deadlines or give a practical and level-headed reason why it cannot be done. If you find yourself needing to "motivate" seasoned professionals, you need to start looking for more people who don't need motivating because they are the wrong people for the job.
If you eventually have any openings on your team, hire programmers that are hungry to code and enthusiastic about the opportunity to work for you. You may even consider taking a chance on someone who is not quite as skilled/experienced as other candidates. I recently advanced in my current job to a team of experienced programmers who sometimes seemed to lack motivation/desire. I have definitely benefited from the experience and know-how of the "old guys", while I think they have benefited from my youthful exuberance to work on any piece of code I can get my hands on.
The question "How many are you directly supervising?" is a very important one. If it's more than about four, you may be in trouble. (I'm assuming that the department also has a secretary, and that you are directly supervising the secretary.)
One way to handle this is to structure supervision so that you aren't *directly* supervising too many people. You also need to be able to delegate tasks with a due date. (Here I'm assuming that this isn't just one large project. If it is, see if you can refactor it.)
Get to know your people. This can be difficult, but is important. You need to know who you can trust in which situation, and different people are very different. It's got to be OK for people to say that they don't want to do that part, they'd rather do the other, but they also have to be willing to accept that somebody's got to do the unpleasant stuff, and this time it's your turn.
I think we've pushed this "anyone can grow up to be president" thing too far.
A seasoned good programmer will be easy to manage. They'll do the job and keep you up-to-date on things.
It's the young less experienced guys or the not-so-good programmers I would worry about. These are the types that are supposed to be "creative people" and refuse to be managed...
Or at least an Engineering degree so people can respect you.
Well, having been in the same spot, here is my FWIW contribution.
1. Treat your people like the people first. Some of the most interesting people I've met are complete assholes at work.
2. Know when they work for you, and make sure they know when you work for them.
3. Get them the tools they need to get your job done.
4. It's all your jobs, not yours--it's a team. That's why it's not just you or 1 programmer working.
5. Demand transparency within the team at all times. Obfuscation within the team should be cause for a pink slip.
6. Encourage a culture of admitting how you fucked it up, then helping everyone not do the same thing.
7. Dont say yes or no, say how.
8. Set a simple vision for what your group needs to accomplish, not just individuals. Good tacticians will find a way to provide value when they understand the point.
9. Meetings have a purpose or they're over. Whoever's late, including you, stands the rest of the meeting and at the next appropriate opportunity buys the next round of drinks.
10. And, for gawd's sake, avoid all management advice which is based on an ordered list.
Easy. Tell them you'll be expecting them to work with Ruby on Rails, AJAX, Extreme Programming, Web 2.0, Web 3.0, heck, why not Web 4.0 too (just keep adding numbers as you need). Wait for the blood to drain from their faces. Then suggest whatever you like, they'll do anything else you say at this point.
More seriously, find out the problems they like to solve. If you have any good ones, you won't be able to shut them up after you ask this. You might need to give them time to think it over, though. If none respond, you don't have a strong team, and I have no advice to offer. If you have one or more, see if you can figure out where to place them in whatever grand design you are managing, based on their preferences. Get their input- and they will have input- about the problem you are trying to solve. Break off problems to solve from the main design for the good ones, and break off specific tasks for the weaker ones. If people run with their tasks and go above and beyond, shift more of the problem solving onto them, and reduce the amount of management. If you have any very good ones, they'll eventually manage themselves, you'll just have to give them a stream of problems to solve. If they are not as capable, pay more attention, turn more problems into specific tasks. Get the input of the stronger ones. For the ones that demonstrate their ability to take a problem and solve it, act quickly on their input. Once they see that better work leads to more independence and greater input, they'll have a reason to strive.
There's a fair few more things to cover, especially the knowledge gap from being in a business stream *and* younger, but this'll have to do for now.
Just make sure they have plenty of bandwidth with no filters or logging.
Dude, chill out and let the language evolve. Like it or not, "irregardless" has already made its way into the common vernacular. At this point, trying to put that genie back in the bottle is just a waste of time. Just accept it and move on. Nobody's forcing you to use it yourself, and its definition is unambiguous, so, really, what's the problem?
Knowledge != Intelligence
I assume by "seasoned" programmers, you mean ones that are entrenched at their current company. If so, then you must realize that they are there, because they are making more money then they deserve. They will mostly try to discredit their fellow employees in everything they do. Because, a discredited peer is one that won't be stealing their raise. You will be hearing lots of phrases with "since the beginning" and "experience" in them.
What you must do is to show no favor to one or the other. That way they will continue fight for a competitive advantage for review time. I'd also advise bringing in some extremely young programmer and sing his or her praises. Call the young programmer "hotshot" and "guru". There is nothing more that they will hate than this programmer. You can use this hate to blackmail them into working more. You may be able to even get them to do some overtime.
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.
Pedro
----
The Insomniac Coder
I think by "seasoned" he means stuck in a rut that they know best because they have been doing the same thing for years. Those are the worst kinds of shops to have to manage. Read about SCRUM, that will give you some visibility into who actually knows what and does what.
Strive to make sure that if any one member of your team were to be, goodness forbid, struck by a bus -- that you could fill there job with at least barely enough efficiency to still have a chance.
Then deal with the business side as if that is the expected outcome.
If you lack the empathic capacity or technical smarts for this, quit your job and go back to programming.
-t
Have frequent one-on-ones with the architect (or tech. lead). Be frank.
Defer to the architect on technical matters, in the same way you would expect her to defer to you on matters of scheduling and task assignments.
Conflicts are inevitable. Whatever you do, don't let them fester. As the leader, communication failures are your fault by definition. Remember that humility is a virtue.
I'm neither a programmer or manager.
But you know, most people forget that they work with highly educated people.
And well to be true, they are made lazy by poor management in most companies.
Simply ASK THEM how they would improve their job, their taks group etc.
What would contribute to it?, then make it goals for the whole team.
But dont be to strict in it, let them addapt, let them give control, or at least that feeling.
Be clear about costs whats goes in, and what goes out, of the balance, and their group impact on it.
Ask them for ideas to improve it, make them part of your decisions.
It is not all blablabla management show that decissions are for the group, to make your group better.
So lesson one would be to listen to them, but dont become their psychiater, you're there for the group
But if they keep complaining about things tell them to stop and work it out, as they're old enough to do that.
Your 30 and even you can do that.
Keep always in intresting ear to them, to their work, and then next to their personal live. (work 1st)
Try to find group activities, just fun activities outdoors, go to a movie or so with them once in a while.
This will connect the group, maybe if your good you might be able to inspire them.
Also if some person X is making trouble for the rest, let him now that, tell him about his lack of responsibility and how it negativly impacts proction, that the other people have to work harder because of it.
Also dont push people to much, or they backfire at you; and the end result is negative, threat them as if they where your friends, and maybe they even might become that.
I know you're out there. I can feel you now. I know that you're afraid. You're afraid of us. You're afraid of change.
I've found one of the chief differences between managers and programmers is the way that each group views a problem statement. For example, let's say you asked a typical, profit driven manager to make a calculator, and that in return you would give $100. A profit seeking person would attempt to maximize profit and deliver that would barely meets the requirements. Now if you asked the typical creative programmer to build a calculator in return for $100 the outcome would be different. It is highly likely that the creative person would use the entire $100 to develop a great product, perhaps with features that were not specified. I'm not saying that one approach is better than the other, just different ways of viewing the same problem.
http://www.amazon.com/Feiner-Points-Leadership-People-Perform/dp/0446695750/
http://www.amazon.com/Corps-Business-Management-Principles-Marines/dp/0066619793/
They've earned enough freedom to work in, you've got only to work WITH 'em, to make the results engage the rest of the enterprise the way it needs to, and to arrange the leverage they need.
http://www.amazon.com/Rapid-Development-Taming-Software-Schedules/dp/1556159005/ for excellent learning in the difference between effective management & ineffective.
Also, take a look at http://www.taskjuggler.org/ , and do some learning in some GOOD project management books.
Good luck, Good work, and Good living to ye.
Cheerses,
-Antryg
Look into how scrum works: www.scrumalliance.org
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
http://en.wikipedia.org/wiki/Forming-storming-norming-performing
Now that I'm at it, team phases require different leadership styles. Goleman is a good reference:
http://www.collaborativenetworks.net/jeff/downloads/htm/handout.htm
If at first you don't succeed, skydiving is not for you
Its simple really, I think the two biggest parts are:
1 - Listen to the tech-side of the staff and have them involved in planning. Its too easy to claim you can meet every need of the customer and then throw it on the devs to figure out. If its iffy, a consult is in order. If you promise to deliver something really impossible, or difficult but underestimate (and under-bill) based on your mis-assumptions, its going to breed resentment with the dev staff that has to clean up your mess.
2 - Admit when you are wrong and accept responsibility. My very first project from my very first PM was underspecced because they failed to examine the databases we were unifying to ensure that there was enough info present to link all the records together. This caused us to take much more time since we had to discover and implement our own mapping based on desperate identifiers which, as you can also imagine, was a much less reliable method as well. We ran long, and were unable to deliver to the full accuracy we originally quoted, and it all could have been avoided with a little more care on their part. Combined with the fact that our usual margins were only about 20%, and that they were even lower because this particular contract was from another software solution outfit which couldn't do the job, we actually *lost* money on that gig... Guess who caught the blame from the big-whigs, even though they had admitted their fault to me in private? By the way, my "inability to meet deadlines" was cited when they "released me"... Not that I cared, I was glad to be free, got two weeks severance, and had a job that paid 25% more in 3 weeks time, and which led to the subsequent gig with a further 80% increase in pay the next year.
To the unnamed PM -- Haha! I made more than you last year!
I think that you would be best advised to form relationships with all involved. Your working relationship must be such that you have the courage to do what is required for all parties involved.
I don't know anything about you, your programmers, or your company. I would focus on learning about them, and serving them and your company. Not everyone will ever workout in a situation. If you know them, you'll be able to build trust and reliance. In short, a team. Overuse of authority, or authoritarian means will kill you. A bad understanding of relationships will kill you. It depends much on your company.
If you can find the courage to be a real human and engage them at a human-relational level, then you will have the ability to manage all other pieces of your job function. A weak/broken individual will mange with threats and manipulation or not manage at all. Some people believe it's either "tool" or "user".
Learn to know them all, learn to use thier strengths for the purposes of the team and company, and you'll go far with them.
So you asked how to handle programmers on a forum where programmers hang out. The answer you got is: GAAAH BLAH BLAH BLAH don't bother me BLAH BLAH I'm the best programmer in the universe leave me alone BLAH BLAH what's that? status reports? I'm waaay too good for status reports BLAH BLAH oh, btw, buy me all this stuff because you should BLAH BLAH BLAH I don't wanna hear about anything that doesn't affect me personally all that "business" mumbo-jumbo bores me to death just sign my fat paycheck already
How unsurprising... And one-sided.
Somehow, I get the feeling that the answers would have been different if you had posted your question on a forum where managers hang out (if there is such a thing).
I'm not a manager myself but knowing that it could happen one day and because I like to read what people have to say about my industry and their ideas on how to make it better, I have read a couple books from Joel's and Jeff's reading lists.
So should you.
And you treat your kids like they're your friends rather than your kids?
A poor metaphor. You and your children are not equals. Not in any way. Not legally, not in terms of experience, nada. They need stern guidance. Most grown-ups (meaning both engineers and managers) do not. If they do, they need fired, not managed.
That being said, I do my best to be a friend to my son. 99% of the time a kind word works as well (or better) than punishment. I won't hold back though if punishment is called for though. I'm not soft. Just thoughtful.
Your statement about status reports would come across as BSing to me.
If you're incapable of responding to adult conversation and honest communication, that's your problem not mine.
Status reports help engineers focus their minds and keep their attention on track of what they need or have agreed to do.
Maybe if you have ADD it does. I know what my tasks are without having to explain them to someone every other day.
For the managers they help reassure them that they've understood that the engineers understand the requirements and direction
Only if the engineers you've hired are morons who have to have things explained to them over and over and over. If that is the case, go to careerbuilder and hire yourself a new batch of engineers. What you've got there aren't engineers, they're idiots.
They still have to talk to each other between reports though.
If you have motivated adult workers, this is certainly enough. Reports gathered from engineers who don't respect you won't add up to jack. I know this for a fact.
I once had a job where - for reasons too complicated to get into - the head of engineering had me working on a secret project. It was something we were working on, his boss said to stop it, but he told me to keep going on it. That meant I had to falsify status reports every week.
Yes, I was paid to lie. And from that experience, I learned two things.
1) You can lie your ass off on status reports. Either nobody reads them, or nobody understands them. My boss eventually admitted it was the first case. Too much work to babysit everyone. It's a psychological trick to make you work harder because you think you're being watched. Odds are, you aren't.
2) Because nobody is getting anything of value from them, they are generally useless.
I'm sure there are exceptions to this, and there may be a manager out there who actually reads his team's status reports. Probably as rare as hen's teeth, and I've never met one, but it's not impossible.
Weaselmancer
rediculous.
1.) Listen to the team
2.) No really, Listen to the team
3.) Listen to the team, its surprisingly hard to do well.
4.) Never say "I used to be a developer so..." If you do that you have lost.
5.) Never say "I am the manager so..." again this just shows how weak you are intellectually.
6.) Accept that you are not and never will be accepted by the team.
Let the team self-organize. You should not be deciding who leads, which architecture, etc. Let the team do that because that is their passion. They are just as motivated, if not more, to pick the right person, right technology, right design. If you can't trust the team then you need a new team.
7.) Give clear requirements, clear acceptance criteria.
Good requirements are above and beyong everything else testable. If you can't determine how to test the requirement don't bother you team with it because how do they code something you can't explain how to test?!
Give clear expectations (Ex: We will use version control with features x,y,and z. Now you decide how and which one.)
Giving clear requirements and listening are really the heart of being a good manager. Listening and giving clear direction are also the hardest things to do.
The reason most managers suck is that listening and giving good direction are very very hard to do well and its far easier to just play political games.
8.) Let the team create their own inspection list for requirements acceptance. Example: Testability is a great inspection criteria.
a.) Team creates inspection list of things the requirements must do.
b.) Manager uses checklist to pre-inspect the requirements before giving them back to the team. This greatly reduces churn.
c.) Team inspects the requirements using checklist and provides written reasoning for rejections.
d.) Team updates inspection criteria as needed. Changes must be communicated.
9. Don't be afraid to say "I don't know, what do you think we should do?" And "nobody knows everything" should also be heard.
Do the stuff they don't want to do. And take over the world. These are talented, experienced programmers; the idea is to give them well-defined problems, easy communication, sufficient kit, timetables, and freedom from distraction. This sounds like your job. And like anyone, they appreciate good company. Pun intended. We nerds gotta realise we're not that different to other folk, apart from the facts that we reckon OS choice is a character trait, pizza is a foodgroup, and yes we need to get out more. Of course I wish other folk took these sorts of things so seriously. Go Meme!
science in government
The best managers I ever had were people that excelled in one thing: getting obstacles out of the way of getting work done.
They told marketing people, "No you can't borrow so-and-so for 2 days so she can drive Powerpoint for you.".
They told upper management, "No, we're not changing to the latest buzzword technology just because you read it in a magazine."
They said, "Yes, you can stay at a decent hotel that has more than paper-thin walls when working 14 hour days for an onsite installation."
Mostly they said, "Don't worry about the TPF reports, I'll do those, you get the code through test."
The best managers I've ever had also understood that it's easier to get forgiveness than permission. In general, if we did something risky but worthwhile, they ensured that we had a contingency plan and took the heat from above.
Good tech managers are very hard to find, but I know from experience that you'll walk through a hail of virtual bullets for one if you have one.
Donuts and possibility of more donuts to come.
When ever they start getting out of line start talking about the latest version of .Net
Fortunately java coders are a dime a dozen so you can always kill one and rub their blood on the cubicle walls to make the others fall in line.
You do know you can get all this done cheaper from an Indian company.
Treat your employees with respect, and try to "do what's right" in dealing with them.
Don't worry about the rest.
I highly recommend the book "The FIVE Dysfunctions of a TEAM" by Patrick Lencioni. Having been in your shoes in the past, I found the principles in this book very helpful, and in my opinion, dead on. They reflect many of the comments posted to date, reflecting honesty, respect, etc. Another suggestion, just from my own experiences, I have always tried to manage in a flat management style, as opposed to a hierarchical org. I define the manager position as just another team member, with specific tasks and responsibilities; just as everyone else does. The main principle I have always driven home is that the manager is an employee, just the same as everyone, no more important, and can be talked to 100% honestly by his fellow team members. By and large it has worked well as long as remembered that pledge to my fellow team members. Where it went wrong was the few times I thought too much of myself and did not hold to the pledge to acting as just a team member. And, I regretted it.
This is a great collection of software management thought, very practical stuff with jokes. (just read the ones tagged "tech life" and "management")
http://www.randsinrepose.com/archives.html
Q: What did the comedian say to the crowd?
A: If I knew, this joke would be funny.
Never wear your boss's title when you have to bring bad news. It makes you look like a coward.
Like me.
Posting here.
As a coward.
Long answer is you and your team need to understand that you are administering and not leading or managing the project.
Short answer is learn how to manipulate and use people.
Slashdot = Sarcasm
Cash, check, money order, options, you name it. Give it to them.
If they ask for a raise or a bonus, give it to them. They need it.
If they don't ask for a raise or a bonus, give it to them. They need it but are afraid to ask.
If they actually tell you they don't need or want a bonus or a raise, give it to them anyways. They need it and don't know it.
If you do all that and they are still not happy, then obviously you are still not paying them enough.
Now. What was the name of your company again? I need to apply there...
"The only good windmill is a tilted windmill."
The best technical mgr I had was smarter than me and worked harder than me, and was happy to share his knowledge. He kept upper level mgt away and motivated by example (and some competition). He also knew exactly what was going on and what needed to happen. Strange, but you typically want your mgr to actually understand what he's managing! In reality, combination geek-politicos are very hard to find, unfortunately.
If you haven't studied general management theory, you're most likely working with a warped ideology of what management is about. This is basically the Dilbert style of management, which nobody who has studied and understands modern management theory, would actually do.
For instance, you're looking to motivate while controlling costs.
I suggest you look at developing a strategic planning process which defines the relationship between the employees, the company and their performance.
I suggest you choose the most influential person in the group, who wants to exceed in the business, and define them as the lead/senior developer. Use this person to handle all of the project specific details.
Remember, a manager's (I prefer to say leader) job is to help other people work. This does not imply that you walk them through their job.
This brings me to leadership theory. You need to understand that during change people tend towards uncertainty, it's your job to quell that uncertainty, and help them get independent again. For instance if we're using the situational leadership theory, we're looking to bring someone from an R1 state to an R4 state.
Don't control what they do, unless they abdicate to you, however never do their work for them.
If you want more information on this sort of thing, I suggest you either start studying an MBA in your part time, or get some business journals and start reading. I really like the harvard business review, and specifically you might like the "HBR Answers" it's a bunch of topic and associated articles which give you a good perspective on those topics.
Either way, if you want feel free to email me if you'd like to talk about this more, or reply to this post.
This is my footer. There are many like it, but this one is mine.
Step aside and don't get in their way.... sometimes the best manager is the one that knows when to keep his mouth shut and let his/her team just get on with what they need to do.
1) Keep the clients focused on the business requirements, not their personal whims.
2) Keep the techies focused on the business requirements, not their personal whims.
3) Profit.
How Do I Manage Seasoned Programmers?
The best way to manage programmers is to make sure their coffee cups are always full and that their are plenty of healthy (and free as in beer) snacks lying around in convenient locations. Make sure there are real plants in the office and make sure they are taken care of. Other than that keep out of their way, keep quiet and only speak to them when you are spoken to.
I'll also recommend Peopleware 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
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
Make sure they get to do fun stuff and they'll be happy to do the grunt work.
1 Shut up
2 Listen
3 Learn
4 Do not guide, let them guide you.
5 Find each persons strengths and weakness and pair them in tandem with someone who compliments or gets along with them.
6 Don't be an ass.
7 Solve their bottlenecks and make sure they know you are working for their benefit.
8 Earn your worth.
Many programmers do not wish to be on the business side. So they will respond nicely to someone who seems smart like them but has taken on the burden and is open to their cause.
Meaning it's really not that hard to manage them if they respect you.
The key is them respecting you.
You by default have to respect them because lets face it, they have more knowledge than you so to not respect them makes you look stupid and naive.
Take my advice and you will have a team that doesn't care how many days you take off, is more productive than other teams in the company and if you in turn add flexibility to their schedules and base your rewards only on merit and productivity you will make your team grow even further.
Programmers love programming and hate paperwork. Try to shield them from practical details of the daily office life, and give them as much room as possible to do what they love and what they were hired to do: programming. Also, try to make it interesting. The programming tasks needs to compete with other stuff that wants attention, such as the internet. When a programmer finds his task interesting, he is extremely productive, but when it gets boring, productivity immediately drops. One way to accomplish this is to allow them to divide the tasks between then as they see fit. Also, give them a certain creative control. Make sure they learn about how the product is to be used (most likely, most of them already knows more about the subject than the users...) and allow them to make design decisions and suggest future development. Listen to them.
All this "be their friend" business is nauseating. Keep making outsource to -insert favorite 3rd world country here- jokes should they express an opinion. And watch the office for inspirational speeches.
1. You are in charge of the business. They are in charge of the programs. Stick to this
2. Dont be authoritative whithout a good reason.
If you must, explain why.
3. The problem ist not to motivate, but to avoid to demotivate. This ist very serious!
4. They may have a family and children. This requires a good deal of energy and flexiblility, more than any business type without children can imagine. It pays off in loyality if you consider this.
5. Listen carefully.
6. Dont be over sensitive to a rough tone and dont over emphasize "professionality". These are professionels in their field.
7. If you use their errors as a tool of authority it will used against you as well one day.Management does not immunity to errors.
8. A management position doesnt make you more clever.
9. Listen carefully.
don't ask them to file TPA reports .......
*--- Sometimes a majority only means that all the fools are on the same side. ---*
Dev here. Pay them double. it would work for me.
Firstly, older/mature/seasoned techies are not per-se good at their job. Usually the crappy ones will become formal when threatened. You should divide the wheat from the chaff. Can you do that?
Who is an application programmers that duct-tapes stuff together but give you a "good feeling"? Who can program software libraries to be used by former which requires strong overview, discipline and a huge load of experience?
Can you divide work according to skills? (Admin tasks to the crappy lot. Responsible tasks to the good guys.)
How log will you stay? Can you commit to manage them for a longer period and command respect? If Older/mature/seasoned techies magically sense if you'll soon be gone.
And don't be patronizing. Just don't. Tough call for a youngish manager.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Also, dry humping them is a sure fire way to express your dominance over them.
The Managing Director used to dry-hump the development team at one web shop in England.
I was let off the hook because I was new.
The day you start - meet with everyone individually for 5 minutes. Ask them:
* What do you like to do?
* What do you hate to do? This is so you know, and then try not to give them that if you can help it. Chances are someone else will like what another hates...
* Tell them you have an open cube policy - if they need something, come ask.
* Tell them all meetings will be short. Schedule them for whatever the corporate std is, then have them last about 7 minutes. Require everyone to be on-time. When they sit down, go around the table: Here's the agenda, this is blah blah blah... Anyone got anything for me? If it affects everyone, we'll talk about it here, if not, we'll do it off-line... They will LOVE you for this...
* Tell them you trust them - they're all experienced professionals. They know how to handle their job. You'll give them projects, they'll do them. They'll update you on the status well enough in advance that you can advise your boss. Tell them you're not out to micromanage them.
* Tell them flat out - your job is to make me, and my boss look good. Do that, and you have no problems with me, and where I can cut you slack, I will.
One-on-one meetings in a comfortable and somewhat informal manner. Make it regular (twice a week or so?) and find some way to give them advanced notice indirectly, like doing it at the same time every week or passing by their office/cubes a few minutes before jumping in to ask for the informal report. If you startle them, leave and come back in a few minutes (really!). Their desks should be oriented in a manner that makes it hard to sneak up on them; if that's not the case, buy a mirror for their monitor.
Wait, is this still about the glowing red ass thing ?
May contain traces of nut.
Made from the freshest electrons.
1) Give them tasks and get out of the way.
2) Don't micromanage.
3) Tell them to come to you if there's a problem. If not, go to 1.
4) Pay well, with bonus for tasks or projects completed in time and with quality.
5) Be flexible regarding times and work hours.
6) Try to keep the paperwork out of their way.
7) Always have someone else to do documentation. Same for QA.
8) Be open to feedback.
Scientia est Potentia
Just like any other high educated specialists, challenge them and reward them with more knowledge and responsibility (if they are up to it). I am will play the advocate of the devil, but please note I am a developer also. I think it's very important not to treat them like hero's with power tools, it will be killing for teamwork and spoils the corporate athmosphere. There goes my karma.
The worst thing you could do it treat programmers like prima donna's. If you would take the ego of most programmers as a measure of skill, then there are simply way too many talents in this world. There is also no need to treat them like prima donna's, especially since it is also possible to outsource stuff and get high quality stuff for it.
Most programmers will also tell you that one very good programmer can do a better job than a whole bunch of average programmers. If you have such a programmer, then you have to respect this ability the same as you would respect any other highly talented and highly productive specialist. But it's important to reward this behaviour more with training, courses and responsibility (if they are real teamplayers) than it is important to pay more money. Highgly intelligent programmers like to stay challenged and learn in a fast pace, the more stupid always want to earn more. It's good to show respect to programmers, but don't encourage their ego's too much.
If I had a buck for every ask slashdot that basically requested a tutorial on how to do a high level job, I'd be rich. If you don't have the experience or skill to do a job, don't take it on, or at least don't come to strangers with such broad questions. Get an education, get some training, or get a mentor. The last thing you need is a bunch of strangers of varying skill levels and qualifications giving very polarised opinions and telling you how to do your job when they have no stake it in whether you do well.
These posts express my own personal views, not those of my employer
> 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.
OTOH having to waste free time with the manager is not necessarily a winner with anyone that happens to have a life outside the workplace.
I've had a boss who did the beer and lunch routine; I was thoroughly unhappy with him invading and micro-managing my eating schedule. Dude, I have dinner plans; all I want is a sandwich at my desk, not to fill up with lunch and beer. And we both know you'll sulk for days whenever I decline your invitation.
How about reading the last 5 years of Dilbert and not doing what the pointy haired boss does? AG
Non bene pro toto libertas venditur auro
"lawyers, doctors, talent agents, sitcom writers, fighter pilots, traders, salespeople etc, fill out status reports?"
Yes, actually they do. Lawyers need to document what they do to bill their clients. Doctors need to write down everything they do for patient treatments and for insurance companies. You don't think a military fighter pilot has to fill out paperwork on what they do in flight? You think the military lets just lets guys buzz around in the sky with no explanation? Salespeople have to fill out sales reports. Those are all status reports.
Everybody fills out some sort of paperwork for what they do. It varies, but it inevitably is something that tell their boss (customer, person they report to, some company they do business with) what they did to deserve to be paid. If your boss isn't asking your for a status report, you should do one anyway and send it to him as a reminder of the value you add every day to your company.
You were mistaken. Which is odd, since memory shouldn't be a problem for you
A team of programmers generally needs a lead programmer, someone who is respected for his technical expertise, who is responsible for the system as a whole and who has the authority to make technical decisions.
From the article I gather that you aren't taking the role as technical lead, so someone else needs to. And he reports to you. If all programmers report to you separately, then who is responsible for overall systems design (supposing all programmers are working on the same project)? By default that's going to be you, and you probably don't want that.
Apart from that, the most general piece of advice I can give is to extend the maximum amount of trust you can. And know your people. Think of the management quadrant. There may be employee files and some project documentation on who did what and with what result. Be sure to read that sort of stuff (if available) even before you talk to them and provisionally peg them. Ideally all of your programmers are software engineers (quadrant 4 people) and really don't need managing. Just some muppet who's job it is to interface with the rest of the organization, negotiate tasks and budgets, fight their corner when it comes to pay scales and perks, tell them where they stand with the company in the annual evaluation talks, look out for career opportunities for them, ensure that facilities are up to scratch, and take care of the paperwork (i.e. you). But sometimes you get people from other quadrants (even when they're 50 years of age). It happens, and as boss it's your duty to spot that and to act appropriately. If you fail to be firm when needed, you fail just as badly as when you are needlessly directive.
Of course you also have a role in safeguarding budget and deadlines, so you must have some checks. If those programmers are experienced, they will know that. And they will generally be able to suggest some good way of measuring progress and guarding against calamities. If they do, adopt it.
So my general advice is: treat those people as adults and professionals (unless they prove they can't bear that responsibility), trust them to do their job, but ensure that there are checks.
In addition, *ask* them if e.g. they would like to have lunch with you as a group. Or dinner. Or Pizza. But half an hour isn't much.
You need to understand the difference between Management and Leadership.
In the past three years I have had different bosses and they have demonstrated to me the difference and value of Leadership over Management. Leadership is much harder to master and is pretty much a life long study. But it will also make you far more valuable than as a programmer because you will be able to gather multiple programmers with effectiveness.
Management can be defined is doing things the right way. Leadership can be defined as doing the right thing. Having people do the wrong thing, or in the wrong way, is a sure method to end up isolated with an ineffective workforce.
Most seasoned programmers can self-manage, so just tell them what the objective is and let them work in any way they like, preferably at their homes.
Once your programmers are properly seasoned, the only things you have to manage are temperature and cooking duration.
Make sure that the Java programmers (who sound like they're the same vintage as me -- 20+ years experience) understand that you're *not* the alpha male Java programmer. Instead, they should understand that you're the one going to all of those boring meetings and protecting them from the torrent of management E-Mails. They get to do the fun stuff, and deliver good quality, working, tested Java code.
This is simple. First, realize that they have been doing this for a long time and it is your job to work for them . A good manager works for his/her employees while at the same time moves the group toward the goals of the organization. If you stand up for them and respect them, they will respect you.
snacks, and porn.
photosMy Photostream
Read more Slashdot and take note what the programmers here are saying.
If that is not enough for you to solve the puzzle, you should really ask yourself if management job is the right thing.
Remember the Golden Rule -- never impose on others what you would not choose for yourself.
The first mistake is assuming you have to motivate them. These are creative types. They probably already have all the motivation they need. What you have to do is protect them from the myriad DEmotivational elements of a typical business bureaucracy. That includes arbitrary rules, useless reports, endless meetings, unstable management, constant interruptions, and so on. The list is virtually endless, but just ask your staff and I'm sure they can easily tell you what the most demotivational element is in your office.
After many years of trying to understand how programmers and managers interact, I am reminded of something I learned in the service. Called the Theory of Completed Staff Work, the paper stated that managers delegate work, expect it to be completed, and want to hear I am done, or I need more resources. Real life development is much more complicated than this but most seasoned programmers want in their hearts to do a good job and provide what is needed. Incomplete specifications, creeping functionality, and unreasonable schedules, negotiated schedules where estimated ones would have been more appropriate. are the main hurdles to successful programmer management.
Hopefully, your team is a profit center, and not a cost center. If your team is generating the profit, then the people who make the products are Kings. All stars. You should have the goal of making the finest systems possible -- under your constraints of time and budget.
Expect the developers to keep learning; "We don't have expertise in that," should be replaced with, "we should explore XYZ".
Plan on three versions of any important system: Force them to develop prototypes; demand basic functionality within a month of starting. Then revise and replace that prototype with another, better prototype. Then plan on a final version (The Third System) that discards the stuff you didn't need.
Work to avoid heavy-weight programming. I was once hired at $240/hour to write code for a company that had a large team of developers already. I knew only slightly more about the domain than they did. Their problem: this company had allowed the developers to just examine everything to death. They hired me to help because I could actually deliver within rough deadlines.
I disagree with the concept of hiring junior programmers, unless they're just apprentices. Do you want to hire a junior surgeon to do your operation? Or hire a junior Engineer to build the bridge your wife drives? No: senior people do important work. Junior people learn how, and do less critical, separate projects.
Good, adult programmer/engineers don't need much managing, but you need them to make the product. They do need somebody to help them see the bigger picture -- but any team of two engineers can do that for each other in turn. So you're really there to service them.
Fire the jerks. Develop some standard of productivity -- even if it's lines of code + group source code reviews -- and fire the people who are clearly not fitting in.
Oh, obstacles.
Sorry about that.
What?
I'm one of those seasoned programmers, who has explicitly avoided moving into management. I know where my strengths are and are not.
My approach is that my managers work for me. They take care of all the things that would normally get in my way: schedules, resources, setting priorities, communicating across departments and coordinating with other managers.
The best managers I've had excelled at those things, and made work very pleasurable. They also tend to see their role much as I do, and appreciate the irony of it. :)
I used to produce broadcast media (intentionally vague), and was skilled at most of the tasks I had to hire specialists for, although like you, not always as skilled as they are.
Here is what I learned:
A) give them the whole big picture, not just the bits they need to work on. It's the dfference between a team of architects and a construction crew.
B) your job will be to elminate obstacles. Think of ways to make your programmers life easier. If they hit a roadblock they are liable to assume you can't or won't help. Make it clear you will do what you can; renegotiate specs, budgets; etc..
C) get your hands dirty. When I was on a set and the cameraman spent an hour reading the fing manual, it was my fault because I waited the hour before I wound up showing this "seasoned pro" how his rented gear works.
Make it clear you can tolerate errors and an iterative process, but if they want to be treated like seasoned pros they need to communicate with you when they have problems so you can help solve them instead of wasting time.
First learn java and what the latest technologies are, like Groovy, Ruby, JBoss, Eclipse, Netbeans, or the like. Read some editorials on the stuff and learn the limitations of the language they use day to day. Start to understand then workarounds out there. Lumbergh, if you are ahead of the game on the technology they need, they'll appreciate your input and they'll do what you need from them. One of the biggest mistakes management makes is trying to manage first and understand second. Managing programmers often IS nagg-managing no matter how you look at it. If you run their project plans for them, they can focus on the nitty-gritty. If you can understand their frustration and the logic problems they have, they'll respect you, even if you can't do the coding yourself. If you can't understand the basics of what they do, or if you refuse to learn what they do, it will be much harder. -Tres
That is utterly and completely not true. In fact, in my experience, the best programmers I've met are some of the humblest people I know.
Actually, I'd argue that having a big ego is a sign of a bad programmer. The fact that he or she has a big ego means that he or she is much less likely to ask for help when things go wrong. Instead, they're likely to hide and try to cover things up, which simply hurts the project in the long run.
We all know what to do, but we don't know how to get re-elected once we have done it
Most universities offer a 200-level course in industrial/organizational psychology, and it was, by far, the best thing I could have done for my management career. http://en.wikipedia.org/wiki/Industrial_and_organizational_psychology
First, it doesn't matter what kind of employees you have, they're all unique individuals. Packard's 12-item list is nothing but a sound-bite introduction to the concept of a http://en.wikipedia.org/wiki/Psychological_contract
Don't look at them as a bunch of older employees. Don't look at them as "technical," and yourself as "business." That's pigeonholing, and will do more damage than it will help. You are people, they are people, and winning relationships will come only from striving to understand the relationships.
While I agree that formal status reports are silly, I disagree with our opinion about daily status meetings. On the team that I work on, every day we have a 15 minute stand-up meeting where everyone goes around and says what they're working on today. Not only does it benefit our manager, but it also benefits the entire team, as it helps us not step on each others' toes, as it were. It also helps with problem solving, as a single team member can ask about an issue, and get feedback from the entire team, rather than having to go around and ask people individually.
We all know what to do, but we don't know how to get re-elected once we have done it
Frankly, I think the opinion that "good programmer == big ego" is nonsense. The best programmers I know are all some of the humblest programmers as well. They know how much they don't know and are always open to feedback and potential improvement.
As I see it, a person with a big ego is more likely to be a bad programmer. They are likely to think that their way is the best and will remain wedded to outdated techniques, leading to obsolete skill sets. Moreover, they're not likely to admit to problems without prodding, even when admitting such a thing would be better for the project as a whole.
Finally, let's not forget the effect that big egos have on those who work with them. It doesn't matter how skilled the big-ego "superstar" programmer is if no one else can get along with him or her.
We all know what to do, but we don't know how to get re-elected once we have done it
How are you going to know where is your project standing in respect to your deadlines?
How are you going to learn about what your charges are doing without reports of some kind? To claim a manager is ignorant of what people are doing without spelling out how exactly he is supposed to know is ridiculous.
Trust is all good and dandy, but I need to manage a project, I do trust you, but that does not mean I will not try to collect objective information about where we are so I can take off your back layers of management higher up in the food chain.
A developer that can't produce a simple report of what he is doing is unprofessional and should not be developing to earn a living.
IANAL but write like a drunk one.
You are joking, aren't you?
Who is going to document that visit? How are you going to control the unwieldy nature of informal chats?
Chats with your charges is a necessary but not sufficient task to keep a project running smoothly.
Although I agree that daily reports are silly, the opposite position of not having reports at all is even sillier.
IANAL but write like a drunk one.
... of somebody that will bring problems eventually.
Pretty much all the professions you mention have regular meetings to report work they are doing.
Honestly, you just need to have been in a hospital ward to know doctors have regular meetings to asses the needs of the patients, and this is not only the junior doctors, senior specialists do this as well to ensure treatment is adequate and to asses possible different course of treatments, and unless I am becoming stupid and my eyes are deceiving me, they write the outcome of the report themselves and put if in the patient's file. Sorry, forgot to mention two relative of mines are doctors, just in case you thought I am talking from my derriÃre.
And to even suggest fighter pilots don't need to be tightly controlled is so stupid that I will not even try to clarify things for you (my dad, an ex high rank soldier, say you must be mad).
Honestly. In which planet are you living?
IANAL but write like a drunk one.
You can have only so many cooks, one more and the broth gets spoiled.
Part of being a team player is to understand what is your place in the machinery of your team and then work efficiently there, if other people are tasked with designing something and you are tasked with implementing it, your snipping to the design may be counter-productive.
IANAL but write like a drunk one.
If you are managing (look up the word in a dictionary) you can't just let people do whatever they want.
If I need a project in Java and one of the divas in my team starts to do the damn thing in Python he will get a piece of my mind or worst.
This mindset that managers have to accommodate their teams and roll over is nonsensical.
There should be a degree of accommodation for sure, but there is a point where you have to draw lines in the sand, otherwise the situation could get out of hand. That is part of your job as a manager. It is not pretty or pleasant but needs doing, then do it properly.
As for this namby-pamby "we are all equals in a team" I could not disagree more. The chunk of responsibility somebody managing a team is much bigger than the one of one individual developer, we all know this, to pretend otherwise is unrealistic.
There should be a relationship of trust and respect, but a good manager knows that he has responsibilities for all the team and the layer of management above him (which means other teams may be waiting for his team to work efficiently).
If a developer starts to go all primadona then it is much easier to contain the problem right there, even if that means the difficult developer will hate the managerial guts of his boss.
If the conflict is completely unsolvable sometimes is much easier and better to build a team from scratch than to waste time agreeing to disagree. Good developers normally understand this and can get along, the guy that thinks is Linus Torvalds incarnation may need to go and play with his penguins elsewhere.
Life is tough and sometimes is not pretty, as simple as that.
IANAL but write like a drunk one.
Then when the business people or people higer up in the chain food show up the developers all of the sudden need their manager to clean the mess they left behind.
Many developers that think they are stars are nowhere to be seen when they overlook something and the ship starts sinking.
You can't have it both ways, if you want to have a manager between you and the people that is going to put pressure on your team you will have to allow this person to do his mangement job, even if you don't always agree.
Otherwise, step up to the plate and lets see how long you last. It may be shorter than you think.
IANAL but write like a drunk one.
Having daily morning standups/status updates with a tech lead where the developer tells the team/tech lead what they did yesterday and what they are doing today. Then make sure that you have the complete loyalty of that tech lead and that you are on the same page everyday. If there is no single alpha-dog tech lead loyal to you, there will be trouble.
cocaine and strippers.
if indeed your team is made of seasoned professionals. Your job focus would be in communication, prioritization, coordination and less about having to motivate or encourage ones to work. Obviously you should be a shining exemplar of optimism in a practical way!
With regards, to the status reports that people seem to have been so focused on in the replies: as some one whose starting on his 14th year in the industry I would have no issues filling reports for status if we as a team determine that is the right sensible process for getting our jobs done.
By the way - work hard or else your job will be shipped abroad!
The only way you can manage more seasoned programmers is by NOT managing them. Follow them instead. Pretend that you are their secretary. Don't tell them what to do, and don't make decisions without identifying and talking to the expert in the group on the topic and aligning yourself with his opinion. Ask others too, but hopefully your experienced enough to recognize the export.
Bottom line is, seasoned people rarely need a manager, you need them. Also, don't pretend that their all at the same level. Figure out the pecking order.
I've worked for some wonderful managers and some terrible managers and I have managed a team of programmers. I love programming, I dislike managing, but I will do it if I must... (BTW, I have always gotten excellent ratings as a manager and as a programmer.)
The manager has a lot of jobs. Perhaps the most important is communicating. Nobody over the age of 12 should ever be expected to accept "because I said so" as reason.
The manager must make sure the programmers understand why they are working on the projects they are working on. They must explain the business needs for what they are doing. Programmers will achieve amazing things if they understand why they are important. But, only if they honestly believe they understand the risks and will participate in the reward.
The worst thing you can do is lie. If you have told me something and it turns out not to be true I will find out why it is not true. If it is untrue because of things out of your control changed, then OK. So long as you tell *when* they change. But, let me catch you just once in a lie and you will never be trusted again. Fact is, you will have lost your group. Programmers value honesty and we tend to see things in black and white. This goes back to communication, keep us informed. Make sure we know when and why things have changed. If I find out (as I have in the past) that a schedule was changed so a VP could get an extra $500,000 bonus, don't expect that schedule to be met unless you are willing to spread an extra %500,000 in bonuses around the group.
The manager must be seen as someone who clears the trail. The manager must foresee problems and clear them before the programmers are slowed down by them. In the cases that the manager can not clear the trail in advance then the manager must take action as soon as possible. It is your job to provide the resources I need to get a job done. When the MTBF of the build server is less than the mean time to complete a build, you better fix it. I might be willing, once, to waste an evening or a week end because you didn't provide the facilities needed to do the job. I won't do it twice.
Don't play games with schedules. If I sign off on the schedule I will work as many hours as I must to meet that schedule. If you write the schedule with no input from me I have no reason the pay any attention to it. If your schedule can only be met by my working evenings and weekends, expect to negotiate with me over how much you are going to pay me for that time. You want me to work more than 40 hours/week most weeks with the *occasional* 50+ hour week you better plan on paying by the hour and yes, I expect time and a half for over time. The law might say I am an exempt employee who is not entitled to overtime pay, guess what, fuck that law. I don't work for free.
OTOH, require status reports, I always hated writing the things and I hated reading them. But, how else do I know what you are doing? As a manager I have a schedule to manage. I have to know what milestones have been met and which are being delayed. No matter who wrote the schedule it is there to make sure that the resources allocated to the project are sufficient for the project. If the schedule can not be met then the resources have to be adjusted and if that means the cost of the project exceeds the value of the project the project must be changed or terminated. I've never found a way to manage a project except to measure progress against a schedule.
Require status reports, I like to see a weekly plan turned in Monday morning. This is the plan for the week and doesn't need to be more than 4 or 5 lines long. Just a list of milestones you are working toward, reminders to the manager of up coming resource needs, and anything that is slowing you down. On Friday afternoon, I want another version of the same report telling me which milestones you met and what kept you from meeting the rest of them. OF course, you have to be willing to stay late on Friday to read both sets of reports. But, hey you are a manager, that is part of th
Assume you are an Engineer. Then think...
How would you lead a team of surgeons in a hospital?
Slashdot = Sarcasm
Seasoned and talented programmers don't need managers. Stay out of their way, unobtrusively maintaining the farce you are 'managing'. They know the game and will maintain the farce as well.
Keep other managers away from them as well.
Linux was written without a single manager. Vista had hundreds.
Don't despair that your life is without purpose. You are free to think about the Next Thing, and can mediate if there's a conflict.