

Ask HN: What do you want in a software PM? - notauser

I have been a project manger for a while know, and really enjoy the work. However, I'm sure there are things I can do better - and as HN seems to have a high concentration of talented programmers you seem like a good bunch to ask.<p>So, what do you guys want from your project managers? When should they leave you alone, and when should they bug you? And most importantly, how many beers is considered fair compensation for pulling a late night to hit a tight deadline?
======
dazzawazza
* a schedule is to measure progress not to dictate progress. When deadlines are missed it is a failure of planning, not engineering.

* Deadlines will be missed and don't always expect me to have a clue either. Together we can nearly always work it out and account for it in the future.

* don't make me update the schedule when there are changes. It's not a good use of my time

* don't change the numbers I give you for time scales

* don't merge the tasks without telling me.

* don't change the order of my tasks without a conversation and realise that by changing the order you may lengthen the overall time it takes to complete the set of tasks.

* don't be afraid to challenge the order I think is best, you understand the entire project, I understand and focus on my code and sometimes little else!

* don't move deadlines without telling me, move them after we've had a chat though.

* don't fear me, although I can at times appear to be a right royal pain in the arse I will respect you more if you are straight, consistent and honest with me. Honesty is a big thing with programmers.

* there is no compensation for late nights. Over time the late nights build up and I get slower, less creative and less willing to compromise.

* when I fail to deliver ask me why and don't accept any bullshit from me. Learn how I, as a programmer, talk and learn to detect the odourless bullshit that comes from programmers at times. Warning, late nights increase the volume of bullshit you will have to wade through over time.

* It's difficult to know when to talk to programmers so encourage me to come to you regularly. In general your work has a lower cost for interruption then mine.

* realise that I love to code but that there is some code I love to write more then other code. Make sure I am getting through some of the shit work and not just screaming through the 'cool' stuff first.

* Coders may seem like robots but there is a lot of ego in code and breaking this ego barrier down will make code teams work better together. If you can foster an atmosphere where programmers are grateful for bug fixes/reports you are doing well.

* Read Peopleware and understand it. Good programmers have all read it and will respect you for seeing them and the project through it.

I've worked as a PM and Senior Coder so I've seen both sides of this. Above
everything be honest and polite. The fact that you are even asking this
question puts you in the top 10% of managers already!

Good luck.

------
gruseom
Well, for starters, don't patronize me: _most importantly, how many beers is
considered fair compensation for pulling a late night to hit a tight
deadline?_

 _most importantly_ : don't talk down to me with cutesy phrases.

 _how many beers_ : don't manage me with a system of rewards like a laboratory
rat. And please don't concoct "fun" activities. If we're not having fun
working together, maybe you should think about that.

 _is considered_ : you sound like an anthropologist asking about the ways of
the natives. Or a high school teacher who wants to build rapport with the
kids... you know, speak the "lingo" of their "subculture".

 _fair compensation_ : what you're talking about is not "fair", it's
irrelevant. If I want to have a beer with you it's because I like you, not
because you're a project manager and I did something you wanted. If there are
problems, don't _compensate_ for them, address them.

 _pulling a late night to hit a tight deadline_ : if you're such a "manager"
why is your team in this position to begin with?

I hasten to add that if we were working together, I wouldn't talk like this!
I'm exaggerating to make a point, which is that I would be sensitive to
indications that you are acting like a boss. If I noticed that, I would lose
respect for you. Partly because I don't want a boss, but mostly because it
would mean that you don't get something fundamental.

The most intelligent people I've met as project managers are the ones who
instinctively understand that the higher status assigned to their (largely
clerical) role is an irrational artifact and don't identify with it. Rather
they identify as a teammate whose role is facilitator for the team.

~~~
derefr
I just have to point out one thing, however tangential:

 _if you're such a "manager" why is your team in this position to begin with?_

It could be the industry. For example, game development is nothing _but_ late
nights to hit tight deadlines.

------
djm
I've never worked as a part of a software project team that had a dedicated
"manager", so take this with a big grain of salt. I have worked for good and
bad managers though and I have one thing to say:

Care about that you do and get stuck in with everyone else.

In my experience doing this will solve all of the worries you are hinting at
above. If you are a) competent & b) only bug people when you consider it to be
about something important then you can bug me whenever you want. I will put up
with being interrupted when being "in the zone" etc if I have respect for you
and you think it's important.

As long as you are pulling the all nighters with everyone else then you won't
need to buy them beer at all, though it's unlikely to be turned down if
offered!

~~~
notauser
The hardest part about (A) is that if you aren't competent, you are not
competent to judge if you are competent.

------
pmjordan
Thoughts in no particular order:

\- Know the limits of your knowledge. This is probably hard. The less of a
programmer you are, the harder this will be. The people you're managing
probably know more about a lot of the detaily that are part of the project.
Try to keep track of who is the expert on what. That's okay, that's what
they're there for. Try to make sure you know your limits, and whenever you hit
those limits, get the experts involved. Hence leaving alone/bugging. (managers
at my last job got that right almost all the time) If in doubt, you probably
don't know better. That's not to say you shouldn't make decisions, just
genuinely use input from the experts. One of the best ways to do this is to
openly admit that you don't know everything.

\- It should be clear to everyone what it is you do and why you (need to) do
it. If the positive impact your job on the project isn't _felt_ by the people
lower down, they won't respect you.

\- Actions speak louder than words.

\- Meetings without substance should be rare. The occasional "you're doing
great, that is all" probably is appreciated, but at my last job it was way
overdone. (daily to weekly) If you expect only you to be doing the talking, 9
times out of 10 you don't need a meeting. Of course, if people are likely to
be asking questions relevant to everyone, it's acceptable.

\- Don't lie. It builds resentment, no matter how smart it seems at the time.

\- Unless you're handing out equity, overtime should be the exception rather
than the rule. For some people, longer periods of overtime (1-2 weeks or more)
won't actually get more work done anyway, they'll just get more tired and
unhappy. Some people do get more done. It's a tricky subject, and I can't
offer any great advice despite having been on the receiving end of death march
orders. In my case the reason was constant orders from waay up to keep
changing key parts of the project combined with bad QA handling of the project
early on, causing bugs to accumulate because no time was scheduled for finding
or fixing them.

------
DavidSJ
Other commenters have said it but it bears repeating: the single most
important thing you can do is be honest and straight. Programmers can detect
bullshit, and it's about the worst thing possible for morale.

------
gaius
A PM's job is to manage _the project_. If someone's falling behind, find out
why and do what you can. But don't ever make the mistake of thinking that
because your title is "manager" that you're in charge. Remember that you need
the engineers on-side to fulfill your obligations. Remember that the demand on
engineers is higher than the supply - they can easily justify working on
someone else's "more important" project, then yours slips and slips and you
find yourself trying to explain to your boss but you don't know why. But you
can easily impress engineers by demonstrating that you are on top of all the
details. You've got a plan, you know what needs to be done (and you trust the
engineers for the _how_ ), you know what everyone needs, you've got all the
dependencies figured out, you've chased all the external suppliers, you've
chased the internal stakeholders, there is _nothing_ stopping anyone getting
right to work. In that situation, your engineers will make you look _great_ to
your boss.

------
mattjung
I expect from a project manager to remove all obstacles from programmers.
Programmers should be able to concentrate on producing the right code and not
to answer support requests, report individually about progress to sales
people, write documentation, worry about testbeds, etc. Another important
point: the project manager should make very clear on what needs to be done -
clear specifications, clear communication, clear tasks. Everybody should know
what the others work on and what the progress and difficulties are.

