Posted by
timothy
on from the don't-be-a-jerk dept.
TrippTDF writes "I just took a new job at a small software company as an assistant project manager. While I have a little management experience, none of it is related to software. What advice can you guys give me on not becoming a PHB? What are qualities that you wish your manager(s) had?"
Use goals, not deadlines...
by
LostCluster
·
· Score: 3, Insightful
Programming is an activity based upon trial and error. As a result, it's very hard to predict how long writing any given piece of code is going to take. It's good to have a schedule of targets for the progress of a program, but you can't turn those target dates into deadlines without the risk that your programmers will rush through the task and deliver buggy code.
Re:Use goals, not deadlines...
by
shufler
·
· Score: 4, Insightful
In an ideal world, this is how all programming projects would operate.
However, we live in a world where deadlines are very real, very important beasts which will gladly destroy us if we ignore them.
Upper management, shareholders, customers, or whoever expects the product by a certain time, not because they are fucking inconsiderate pricks, but because without the program, they cannot do whatever it actually is, that they do.
What advice can you guys give me on not becoming a PHB? What are qualities that you wish your manager(s) had
Speaking as someone who has been on both sides:
Don't be a fake, your people will pick up on it.
Don't pick sides. You aren't there to make friends, you're there to get a job done.
Don't be afraid to say "I don't know" and defer to one of your people. It boosts their morale.
Ensure you can back up your decisions with facts and data. Bad decisions will cost you respect and potential promotions. They may even get you demoted or unemployed.
Don't talk shop with your people outside of work on a social level. Those that don't go out socially could perceive your decisions as biased. Ideally you'll minimize social interaction with small groups of your people.
You can't demand respect from your people, it must be earned.
A good manager should be though of as firm yet fair. Not a friend, not a drinkin' buddy, not someone easily influenced.
Basically: you're a Grown-Up now. Your options are quite simple: take the ball and run with it or fail and go back to where you were. Heh, I re-read that and I thought "Man, you sound old." and I'm only 38...:)
Heh, I re-read that and I thought "Man, you sound old." and I'm only 38...:)
38? Dude, you are old!
Re:My advice?
by
egarland
·
· Score: 3, Insightful
I agree with everything in the parent post. I'd add some more:
Remember, you're job is important. Doing it well will make everyone's lives easier.
Work hard but don't get buried. If you are too busy you can't do your job right.
You're a coordinator. Just like in a real-time device, things break if they get overloaded. Managers are often ridiculed for not doing real work but this is actually important. All my good bosses had free time in their day. All my bad ones have seemed overworked. It's ok to get involved in doing actual work but it's best to say away from the deep projects (ones that require a lot of time to wrap your head around and pick back up if you get interrupted) and remember to keep a little time in your day to sit around and just let whatever's going on stew in your mind. Part of a project manager's job is to see obstacles that will show up in the future. It's hard to do that when you are head down working.
-- set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
Plan to debug, you'll have to anyway.
by
LostCluster
·
· Score: 4, Insightful
A good rule of thumb is that you should allocate the same length of time to debugging as writing the original code, because a program that works under pristine conditions might look finished to the untrained eye, but it isn't. Every possible "exception case" such as when the user gives an out-of-bounds valus needs to have a specific error trap written to handle the error before it crashes the program.
Learn how to say "No"
by
GoofyBoy
·
· Score: 4, Insightful
Actually, learn how to say "Go to hell and leave me and my programmers alone.".
Note: I'm not saying to not listen to your end-users/customers and understand them. Just don't become this mindless "Yes-man" and sacrifice your team.
-- The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
Re:Learn how to say "No"
by
j3110
·
· Score: 4, Insightful
Well... It's the managers job to be more tactful. Get the priorities of the end user and have them rank the issues in terms of importance. A lot of times, you'll find that the end user is just saying "Wouldn't it be cool?" instead of "I would be willing to go over budget and wait a week for that!" They tend to get irrate when you go over budget and pass deadlines, especially when it's because of something they requested. No one wants to hear "I didn't know it would cost me that much!".
The best thing to do is try to weed out the genuine concerns of the end user and present them to the dev team before making any estimates. Nothing angers a developer more than telling him that he has to stay up all night trying to meet an impossible deadline; and nothing angers an end user more than not having what they asked for for the price you give them or when you promised it. Always overestimate to the end user, and underestimate to the developers... it will all come out somewhere in the middle, and everyone will be happier. You won't have to slave drive your employees if something comes up (there is always something), and you won't have to apologize to the client.
When doing your job, a manager must maintain respect and integrity. If you aren't given enough freedom to do that, I would resign and go to development or look for another job. Don't let them corner you into failure quietly! Let them try to find someone else who thinks they can do the job.
-- Karma Clown
Re:Learn how to say "No"
by
dutky
·
· Score: 3, Insightful
Actually, learn how to say "Go to hell and leave me and my programmers alone.".
I'll second this, but it is only half the story: A good project manager has to be able to say "no" to everyone. You have to say "no" to unreasonable requests from clients/superiors in order to keep your team-member's plates clear to work on the important stuff. You also need to say "no" to your team-members when they either want to go off the reservation for whatever reason.
A good manager, of any kind, acts as a wall between their people and the rest of the organization. They take care of conflicts and keep the team from getting distracted. They get the team what it needs to do it's job, and keep everything else out as much as possible.
Read Slack and Peopleware by Tom DeMarco and Timothy Lister.
Communicate, and use good tools
by
revans
·
· Score: 4, Insightful
The Project Managers job is not to:
design the product
code the product
build the product
QA the product
release the product
sell the product
nor fix the product.
Your job is to try to get all the people who do these jobs to communicate with one another, and to try to be aware of and consider solutionS for ALL the issues involved with the product. To that extent you need good tools to make all the issues as plainly visible to all the constiuents as possible. Which leads to the question: what is the best toolset to do this?
Work Breakdown Structure
by
Godeke
·
· Score: 3, Informative
As the project manager, you will be responsible for the time the project takes to actually build, and reconciling the differences between what the team can actually do and management's desires for instant turnaround.
The only way to resolve these two conflicting forces is with good hard data to back up any timetables you are presenting. The only way to achieve *that* is to break the work to be done down into the smallest chunks you can pallet. I personally refuse any time estimate larger than three days and look skeptically at those of one or two days.
The reason for that is that any estimate of "oh, that will take a week" implies that the task has not yet been broken down far enough to actually understand the task. It is perfectly acceptable to say: "yes, but what is that week going to be used doing". Usually you will get "well, I need to revise A, B and C". At that point you can say "give me an estimate of A, B and C separately".
Don't be surprised when the response is "but A B and C all require revising D". You have now achived forward progress understanding your work breakdown structure. D is a prerequisate for A, B and C, and yet your original estimate of one week may not have even considered that. Once you have tasks of "a couple of hours" and "half a day" you can be fairly sure that you have a handle on the tasks. But more importantly, if a task takes longer than it should, at the end of the day you can say "hey, I notice task D isn't done: what's up with that". It may turn out that D is an iceberg task... and you would have found that out a week later under the original estimate, now you have only spent a day learning that you have an iceberg and need to revise the schedule even more.
The truth of the matter is that all programmers are optimists when confronted with a simply stated task and they will give overly optimistic time estimates until you actually start analysis of the problem. Creating a work breakdown structure that is fine grained (don't go completely overboard: "a couple of hours" is a good target point) will help you create your broad schedule with more realistic targets.
Management will appreciate being able to back up your schedules with a fine grain detail (even if they ignore the detail itself) and your programmers will appreciate not being hit with iceberg tasks that kill the apparent productivity. Don't be suprised if the total of the fine grain schedule exceeds the initial WAG (wildly accurate guess) by a factor of 2 or more. Front loading the analysis usually uncovers many things that were ignored.
-- Sig under construction since 1998.
Re:Project management 101
by
jeif1k
·
· Score: 3, Insightful
MS Project is your main tool - learn it - live it.
Maybe it's your main tool.
You'll eventually become an old hand at doing project estimates!
That's nice. But projects aren't about delivering estimates, they are about delivering products.
You are both a leader and a salesman
by
gristlebud
·
· Score: 3, Interesting
As a Project Manager, you are responsible for interfacing between your clients and the team that reports to you. You are the face of the company. Dress nicer. Tighten up the e-mail etiquette. Use capital letters, punctuation, and spell check. Every time. Always assume that someone will forward your emails to your team, your client, and your boss.
You are the leader of your project. You need to set an example for the attitude and morale of the teams that report to you. Always show up on time, and leave late. Never, never bitch about the customers or senior management. Never appear frazzled or irritated, as that attitude invariable trickles down to your team.
You are responsible for everything that happens on the project. Not just the technical execution of the work, but also the accounting, invoicing, reporting, vendors, and subcontractors. Follow up on everything, because if it doesn't happen, it's always your fault.
Always take opportunities to sell yourself and your company. Take every opportunity to call, or preferably visit your clients. I'm serious about this. Find out what your marketing budget is, and spend every nickel on visiting your clients. Eventually, they'll give you more work just to get rid of you. When dealing with a client, always keep your game face on. Know that you represent the best damn (whatever) company out there, and don't be afraid to take risks. Ask your clients often for more work. This can be a little uncomfortable, but rest assured that your competition is chasing the same work you are.
Expect excellence from your teams. If you don't know enough about the subjects to judge whether the people are producing what they should be, find a trusted advisor who does know, and get their opinion. After clearing it with senior management, quietly solicit some bids from other companies (even overseas companies) on a task-by-task basis to make sure that you are getting the most out of your teams. However, don't be an ogre. Find out the difference between regular, everyday complaining that technical people do all the time and the honest-to-gosh complaining that signals something's really wrong.
Limit senior management involvement. Always ask for help when you need it, but always propose a solution or a set of alternatives. You should try and schedule project reviews monthly or quarterly between senior management, QA, yourself and the task leads to make sure the project is on schedule and meeting performance objectives. Don't cc: half the damn company on every e-mail, and never when you chew someone's butt.
Try and grow scope whenever possible. This ties into face time with the customer, but also knowing what other services your company can provide, and also knowing the specific scope of your project, so that you know when the client requests are going out of bounds. When you do win more work, make sure everyone knows it. This will be one of the things that your boss will be evaluating your performance on.
Clients will always try and get more than what they are paying for, but limit the amount of freebies you give them, and ham it up a little when you give them one. ("You know, I could get fired for this, but since you're one of my best customers, I can make this happen.") Also, don't ever be afraid follow up on an invoice that is getting late. This might be a little embarrassing to the client, so this is probably best done over an e-mail.
As much as possible, define what your requirements are to the teams that report to you. Not just "I need XYZ done," but "I need XYZ done by 21 December. You have 64 hours to do it in, and use charge code ABC123.QQ." If the teams have problems delivering, find out whether it's a problem with your schedule, the team's resources, or if you have unreasonable production estimates.
Celebrate your teams' performance. Even if you're managing the project from hell, find something they're doing right, and send out a quick e-mail to your boss an
-- OK...
I can do this. I am, after all,
a superhero!
Slashdot Mirror
Programming is an activity based upon trial and error. As a result, it's very hard to predict how long writing any given piece of code is going to take. It's good to have a schedule of targets for the progress of a program, but you can't turn those target dates into deadlines without the risk that your programmers will rush through the task and deliver buggy code.
What advice can you guys give me on not becoming a PHB? What are qualities that you wish your manager(s) had
Speaking as someone who has been on both sides:
Don't be a fake, your people will pick up on it.
Don't pick sides. You aren't there to make friends, you're there to get a job done.
Don't be afraid to say "I don't know" and defer to one of your people. It boosts their morale.
Ensure you can back up your decisions with facts and data. Bad decisions will cost you respect and potential promotions. They may even get you demoted or unemployed.
Don't talk shop with your people outside of work on a social level. Those that don't go out socially could perceive your decisions as biased. Ideally you'll minimize social interaction with small groups of your people.
You can't demand respect from your people, it must be earned.
A good manager should be though of as firm yet fair. Not a friend, not a drinkin' buddy, not someone easily influenced.
:)
Basically: you're a Grown-Up now. Your options are quite simple: take the ball and run with it or fail and go back to where you were. Heh, I re-read that and I thought "Man, you sound old." and I'm only 38...
Trolling is a art,
A good rule of thumb is that you should allocate the same length of time to debugging as writing the original code, because a program that works under pristine conditions might look finished to the untrained eye, but it isn't. Every possible "exception case" such as when the user gives an out-of-bounds valus needs to have a specific error trap written to handle the error before it crashes the program.
Actually, learn how to say "Go to hell and leave me and my programmers alone.".
Note: I'm not saying to not listen to your end-users/customers and understand them. Just don't become this mindless "Yes-man" and sacrifice your team.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
- design the product
- code the product
- build the product
- QA the product
- release the product
- sell the product
- nor fix the product.
Your job is to try to get all the people who do these jobs to communicate with one another, and to try to be aware of and consider solutionS for ALL the issues involved with the product.To that extent you need good tools to make all the issues as plainly visible to all the constiuents as possible. Which leads to the question: what is the best toolset to do this?
As the project manager, you will be responsible for the time the project takes to actually build, and reconciling the differences between what the team can actually do and management's desires for instant turnaround.
The only way to resolve these two conflicting forces is with good hard data to back up any timetables you are presenting. The only way to achieve *that* is to break the work to be done down into the smallest chunks you can pallet. I personally refuse any time estimate larger than three days and look skeptically at those of one or two days.
The reason for that is that any estimate of "oh, that will take a week" implies that the task has not yet been broken down far enough to actually understand the task. It is perfectly acceptable to say: "yes, but what is that week going to be used doing". Usually you will get "well, I need to revise A, B and C". At that point you can say "give me an estimate of A, B and C separately".
Don't be surprised when the response is "but A B and C all require revising D". You have now achived forward progress understanding your work breakdown structure. D is a prerequisate for A, B and C, and yet your original estimate of one week may not have even considered that. Once you have tasks of "a couple of hours" and "half a day" you can be fairly sure that you have a handle on the tasks. But more importantly, if a task takes longer than it should, at the end of the day you can say "hey, I notice task D isn't done: what's up with that". It may turn out that D is an iceberg task... and you would have found that out a week later under the original estimate, now you have only spent a day learning that you have an iceberg and need to revise the schedule even more.
The truth of the matter is that all programmers are optimists when confronted with a simply stated task and they will give overly optimistic time estimates until you actually start analysis of the problem. Creating a work breakdown structure that is fine grained (don't go completely overboard: "a couple of hours" is a good target point) will help you create your broad schedule with more realistic targets.
Management will appreciate being able to back up your schedules with a fine grain detail (even if they ignore the detail itself) and your programmers will appreciate not being hit with iceberg tasks that kill the apparent productivity. Don't be suprised if the total of the fine grain schedule exceeds the initial WAG (wildly accurate guess) by a factor of 2 or more. Front loading the analysis usually uncovers many things that were ignored.
Sig under construction since 1998.
MS Project is your main tool - learn it - live it.
Maybe it's your main tool.
You'll eventually become an old hand at doing project estimates!
That's nice. But projects aren't about delivering estimates, they are about delivering products.
As a Project Manager, you are responsible for interfacing between your clients and the team that reports to you. You are the face of the company. Dress nicer. Tighten up the e-mail etiquette. Use capital letters, punctuation, and spell check. Every time. Always assume that someone will forward your emails to your team, your client, and your boss.
You are the leader of your project. You need to set an example for the attitude and morale of the teams that report to you. Always show up on time, and leave late. Never, never bitch about the customers or senior management. Never appear frazzled or irritated, as that attitude invariable trickles down to your team.
You are responsible for everything that happens on the project. Not just the technical execution of the work, but also the accounting, invoicing, reporting, vendors, and subcontractors. Follow up on everything, because if it doesn't happen, it's always your fault.
Always take opportunities to sell yourself and your company. Take every opportunity to call, or preferably visit your clients. I'm serious about this. Find out what your marketing budget is, and spend every nickel on visiting your clients. Eventually, they'll give you more work just to get rid of you. When dealing with a client, always keep your game face on. Know that you represent the best damn (whatever) company out there, and don't be afraid to take risks. Ask your clients often for more work. This can be a little uncomfortable, but rest assured that your competition is chasing the same work you are.
Expect excellence from your teams. If you don't know enough about the subjects to judge whether the people are producing what they should be, find a trusted advisor who does know, and get their opinion. After clearing it with senior management, quietly solicit some bids from other companies (even overseas companies) on a task-by-task basis to make sure that you are getting the most out of your teams. However, don't be an ogre. Find out the difference between regular, everyday complaining that technical people do all the time and the honest-to-gosh complaining that signals something's really wrong.
Limit senior management involvement. Always ask for help when you need it, but always propose a solution or a set of alternatives. You should try and schedule project reviews monthly or quarterly between senior management, QA, yourself and the task leads to make sure the project is on schedule and meeting performance objectives. Don't cc: half the damn company on every e-mail, and never when you chew someone's butt.
Try and grow scope whenever possible. This ties into face time with the customer, but also knowing what other services your company can provide, and also knowing the specific scope of your project, so that you know when the client requests are going out of bounds. When you do win more work, make sure everyone knows it. This will be one of the things that your boss will be evaluating your performance on.
Clients will always try and get more than what they are paying for, but limit the amount of freebies you give them, and ham it up a little when you give them one. ("You know, I could get fired for this, but since you're one of my best customers, I can make this happen.") Also, don't ever be afraid follow up on an invoice that is getting late. This might be a little embarrassing to the client, so this is probably best done over an e-mail.
As much as possible, define what your requirements are to the teams that report to you. Not just "I need XYZ done," but "I need XYZ done by 21 December. You have 64 hours to do it in, and use charge code ABC123.QQ." If the teams have problems delivering, find out whether it's a problem with your schedule, the team's resources, or if you have unreasonable production estimates.
Celebrate your teams' performance. Even if you're managing the project from hell, find something they're doing right, and send out a quick e-mail to your boss an
OK...
I can do this. I am, after all,
a superhero!