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

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!

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.

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.

* 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.

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.

Sexy legs

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.

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.