Being a program manager

One of the key things that every software development effort needs is an excellent program manager. That manager's key vision, leadership and customer advocacy drive success. In How to Be a Program Manager, author Joel Spolsky gives us some insight on combining agile programming and program management in a productive way. Since Joel worked on the team developing the next generation of Microsoft Excel, he's qualified to speak authoritatively about dividing up large projects into manageable bite-sized pieces. Like at OS-Cubed Joel believes that one program manager should be responsible for a team of up to 4 programmers, and that work should be divided up by functional area.

The most important part of Joel's article states that the program manager must be the customer advocate on the team. They must look at every interface from the customer (or end user's) point of view, and express that point of view to the programming team. Their job is to help the programming team design something that users will find easy to use and appealing. If users complain that the program doesn't work - it's not the programmers fault it's the program manager's fault.

I think this is an important point about program managers. Too often development teams focus on the program manager's job of coordinating resources and delivering on-time and in-budget without defining their visionary status.

Joel goes on to say that - despite agile programming pushing prototyping as a methodology, the program manager must write specs - detailed functional specs from the user's point of view - not the programmer's point of view. It's their job to advocate for the user and build an interface that is the best for them. I typically fill this role within OS-Cubed, Inc. I have just enough programming and platform knowledge to be dangerous, but not enough to be so buried in it that it's all I think about. I would go on to state that a good program manager probably has a high "DI" in the DISC test and a low "C". I will talk more about DISC and how it integrates into a programming team later.

The program manager should not however, be the person writing up the actual specifications for how the product should be developed (that responsibility is the programming team lead's job), nor should the programmers report the the program manager because that would allow the program manager's ideas to run roughshod over the programmer's. This needs to be a negotiation between what is optimal and what is possible and both the user's and programmer's needs are taken into account.

Agile programming is typically about fast turnaround and constant customer approval. So the program manager must stay ahead of this curve, constantly re-examining the impact that feature and user interface changes have on the full vision. Sometimes it will be their job to control the scope of the project and to do that they need to retain and update the vision as it changes.

Joel's article is a great read, and I highly recommend both the blog post itself, and the links he offers for help and assistance.