Ever since I started my new job, I’ve been trying to get up to speed as quickly as possible as there is so much to learn when joining a new organization. I’ve met a lot of people, spent some time in the product’s code and am already involved in the development of a major product that will snap in to the existing product suite.
Note: I never know if I am violating NDA by disclosing product names, so until I read or hear otherwise, you’ll just have to bear with me through the purposely ambiguous pronouns.
As an architect and program manager on the company’s flagship Environmental, Health and Safety product team, it is important for me to not only learn the framework upon which the product is built so that I can help to extend, maintain and improve it, but it is also critical that I come to understand the business domain. Dealing with domain entities such as chemical, air, water and waste is complex indeed and the detail and metrics that our product tracks is amazing. Fortunately, there are some very smart people here that understand this stuff inside and out, and together with the engineering teams; they have been able to produce some very interesting software.
One of the first things I always do when I either get promoted or move into a new job is ask for a job description. If one doesn’t exist, then I usually write one and bounce it off my boss. I think its important to understand what is expected of me so that I can focus on meeting (and hopefully exceeding) those expectations as well as look for opportunities to tweak the job to my liking (work is supposed to be fun and rewarding, right?)
My role as an architect is straight forward enough. Formally or informally, I’ve been in this role since I led the design and development of the national home and auto collections portal at Bank One (now J.P. Morgan Chase). This was my first major enterprise project and was my first real stab at playing the role of an architect. I've come a long way since then and am pretty comfortable with the competencies that make a good architect. I continuously administer gut checks to asess where I stand so that I roadmap myself to ensure I maintain core strengths in this area. The key is A.D.D.: Academics, Doing and Discipline (yes, I came up with that myself, but my wife would agree with the clinical condition instead).
Enough (at least for now) about being a good architect. In learning my new job, I want to also understand what makes a great (or at least decent) program manager.
One Google query returned this result for ‘program manager’:
“The person with authority to manage a program. (Note that this is a role. The program manager may also be responsible for one or more of the projects within the program. They would be project manager on those projects as well as overall program manager.) The program manager leads the overall planning and management of the program. All project managers within the program report to the program manager.”
Program managers are customer focused, working to ensure that the products Microsoft produces will delight users and enable them to do their best. Program management is also an opportunity to flex technical muscles: your technical decisions and direction are what drive products and features through to completion.
Working across multiple groups with marketing and sales personnel on the customer end, program managers translate customer requirements into product features and create functional specifications. On the implementation end, they prioritize and deliver on those features, working closely with key technical resources, such as software development, testing, documentation, localization, tech support, and more.
Program managers typically have a software development background. This technical expertise is blended with evangelism, empathy, conflict negotiation skills, and a passion for driving projects through to completion.
It turns out that the title “program manager” has its roots at Microsoft.
According to Chris Pratley, Group Program Manager for Office, the first program manager was a self appointed developer within the Microsoft Excel team in the late 80’s that was capable of both coding and holding a conversation. This unsung hero saw a void between the customer/marketing team and the engineering team and sought to fill it by acting as a go between both teams. The marketing people loved this idea because they could talk to someone who was interested and empathized with the customer and sales cycle and could be trusted to carry the message to the engineering team. On the engineering side, developers loved this guy because he understood the technology, its capabilities and limitations; and, unlike most folks with a sales background, this guy empathized with the developers and kept it real, y’all. Before long, the Word and PowerPoint teams started taking a similar approach and they saw that it was good, so the program manager role was born at Microsoft. It has since permeated into the Microsoft Solution Framework on which we base our SDLC.
As Chris puts it, program managers “define the APIs and write the technical documentation”. They enforce processes and design guidelines. They have lots of meetings with the business and the technical team. In short, program managers “not only pick up and run with the ball, they go find the ball".
After reading the entire post, I couldn't help thinking back to my last couple of jobs where I held titles like “Senior/Lead Developer” and “Development Team Lead”. In addition to architecture, there was so much more to these jobs than merely managing teams, doing code reviews and enforcing standards. These roles all had the unwritten requirement of GET THINGS DONE.
The main difference, as I see it, is that as a program manager, there is a much more concentrated focus on meeting deliverables and expectations at the product (and not so much organizational) level. The product really is the bottom line and leaves no ambiguity of success or failure- you either ship, or you don't.
P.S. I later came across some more information on program management while reading the blog of one of my favorite software authors, Joel Spolsky. Having been a Program Manager on the Excel team, Joel shares some highly amusing thoughts on the matter: http://www.joelonsoftware.com/articles/fog0000000034.html