Some time back I got a question on what I look for when hiring a Program Manager from the leader of a 5 to 10 person startup. I make no promise that what I look for is typical of what others look for – it almost certainly is not. However, when I’m leading an engineering team and interviewing for a Program Manager role, these are the attribute I look for. My response to the original query is below:

The good news is that you’re the CEO not me. But, were our roles reversed, I would be asking you why you think you need PM at this point? A PM is responsible for making things work across groups and teams. Essentially they are the grease that helps make a big company be able to ship products that work together and get them delivered through a complicated web of dependencies. Does a single product startup in the pre-beta phase actually need PM? Given my choice, I would always go with more great developer at this phase of the companies life and have the developers have more design ownership, spend more time with customers, etc. I love the “many hats” model and it’s one of the advantages of a start-up. With a bunch of smart engineers wearing as many hats as needed, you can go with less overhead and fewer fixed roles, and operate more efficiently. The PM role is super important but it’s not the first role I would staff in a early-stage startup.

But, you were asking for what I look for in a PM rather than advice on whether you should look to fill the role at this point in the company’s life. I don’t believe in non-technical PMs, so what I look for in PM is similar to what I look for in a developer. I’m slightly more willing to put up with somewhat rusty code in a PM, but that’s not a huge difference. With a developer, I’m more willing to put up with certain types of minor skill deficits in certain areas if they are excellent at writing code. For example, a talented developer that isn’t comfortable public speaking, or may only be barely comfortable in group meetings, can be fine. I’ll never do anything to screw up team chemistry or bring in a prima donna but, with an excellent developer, I’m more willing to look at greatness around systems building and be OK with some other skills simply not being there as long as their absence doesn’t screw-up the team chemistry overall. With a PM, those skills need to be there and it just won’t work without them.

It’s mandatory that PMs not get “stuck in the weeds”. They need to be able to look at the big picture and yet, at the same time, understand the details, even if they aren’t necessarily writing the code that implements the details. A PM is one of the folks on the team responsible for the product hanging together and having conceptual integrity. They are one of the folks responsible for staying realistic and not letting the project scope grow and release dates slip. They are one of the team members that need to think customer first, to really know who the product is targeting, to keep the project focused on that target, and to get the product shipped

So, in summary: what I look for in a PM is similar to what I look for in a developer (http://mvdirona.com/jrh/perspectives/2007/11/26/InterviewingWithInsightAtMicrosoft.aspx) but I’ll tolerate their coding possibly being a bit rusty. I expect they will have development experience. I’m pretty strongly against hiring a PM straight out of university — a PM needs experience in a direct engineering role first to gain the experience to be effective in the PM role. I’ll expect PMs to put the customer first and understand how a project comes together, keep it focused on the right customer set, not let feature creep set in, and to have the skill, knowledge, and experience to know when a schedule is based upon reality and when it’s more of a dream. Essentially I have all the expectations of a PM that I have of a senior developer, except that I need them to have a broad view of how the project comes together as a whole, in addition to knowing many of the details. They must be more customer focused, have a deeper view of the overall project schedules and how the project will come together, be a good communicator, perhaps a less sharp coder, but have excellent design skills. Finally, they must be good at getting a team making decisions, moving on to the next problem, and feeling good about it.

–jrh