Sunday, June 6, 2010

Important qualities and best practices for project managers

Please keep in mind this is not a comprehensive list and I am by no means an authority on the matter. However, these are some things I've discovered over the years that get me good/better results with engineers than not trying to incorporate them. Maybe they will help you too.

1. Assume you have 2 hours per week in which to schedule meetings with any given engineer. Any more than that and you've lost her productivity, her time, and probably a little bit of her respect for you. If she thinks you can't get the information you need from her in 2 hours every week she will probably start to also think of you as ineffective. Honestly, if its taking you 5 hours per week to get information on a project from a person, maybe you are ineffective. Or at least not empowered to do your job correctly.

2. Most people don't go to work in the morning with the intention of doing a bad job. Assume competence on an engineer's behalf unless you get explicit actions to the contrary. He is probably working on that thing you asked him for as fast as he can, even if he's not checking in with you as much as would make you happy. He's also probably trying to do a quality job on it and take pride in his work instead of just being a code monkey churning out shoddy tools on a regular basis. Don't pester him about it. Trust him to work hard on something and give him space.

3. Don't keep checklists. I mean checklists in a literal and also slightly metaphorical context here. Don't just assume you can write down everything an engineer is doing for you and then send constant pings on a daily, weekly, or monthly basis to get it done faster and checked off your list. This also extends to things you don't have context on - if you don't know what's required or involved in any particular task, you should assume you don't have the space to keep asking the engineer about it. I'm not saying you need to have the same technical savvy as her, but you do need to be able to have an informed discussion about it when she comes back to you saying, "I couldn't get this done today because of X reason and I need some ideas on how to change it."

4.Protect the engineers from your management. I'm sure most of you have read the article on the maker's schedule vs. the manager's schedule (if you haven't, its a great article). I'd like to take it one step further and say that as a project's manager it is your job to protect the engineers on your project from managers constantly pushing for deadlines, making everything important, and generally meddling. You talk to management and let the engineer do his job. Everyone will be happier for it.

5.Only use the emergency button when it really, really is an emergency. The less you tell an engineer that it's absolutely crucial this feature ships today the more you'll build respect. It will be slow-earned, but once she understands that when you say you need something today you really mean it (and you're not going to say the exact same thing tomorrow about some other feature) she will be a lot more likely to work through lunch time for you to get it done.

6. Build respect and karma with the engineers. Everyone has their own way of doing it - I bake cookies. Maybe you bring him chocolate he likes or send him emails thanking him for the work he's doing on your project. Whatever it is, do it regularly and do it without expecting any return. He will be thankful and much more likely to give you the extra little things it is in his power to give when the time comes for you to need it.

7.Add two weeks to any date you get from a engineer. This is not because I don't trust engineers. In fact, its because I trust engineers too much to try to give me the right answer instead of the realistic answer. Two weeks, of course, can be modified for your purposes - if it's a task she's saying will take a day, maybe you add two days to that number. I think it is human nature to want to say that you can do something well in a short amount of time. No one ever wants to hear from a peer, "What? It's going to take you that long?" People want to hear, "Wow! You delivered that so fast!" Underpromise to your management and then overdeliver when it comes in a week early.

I may amend this entry at some point, but that's the list for now. Your comments and experiences welcome.


  1. In regards to a 'conversation' (read: rant) we had (read: I had) a while ago: you've made me a believer in regards to the role of PMs.

  2. #4 is really the most important part of a PM's or tech manager's job (depending on org structure). only slightly less important is the inverse: protecting managers from being frightened by engineers. #7 is part of that; managers and techies just have such fundamentally different ways of thinking about risk, time, and complexity that a good PM needs to be able to translate. as you said, everyone will be happier.