Tag: engineering

Joel Spolsky wrote a love letter to program management on his blog. For the most part, it is a pretty reasoned and reasonable description of what a “good” program manager at Microsoft (and Fog Creek) is like. In my career at Microsoft, about 25% of the program managers fit that bill. The problem was that they had too many conflicting roles and required skillsets to be effective. At Microsoft, Program Managers are not only responsible to be user advocates, they are also responsible for functional specifications, user interfaces and schedules. A single person can’t be a user representative, a UI designer/interaction specialist, and a project manager. Combining them into a single role worked for Microsoft initially, but in the modern world each of these roles are full disciplines of their own.

Joel claims that PMs are partners with development and that developers have the upper hand over PMs because they write the code. This might have been true of Microsoft in Joel’s (and my) time, but as MS switched from being an engineering-driven company since Ballmer took over to a program management-driven one, it isn’t true any more. PMs took the upper hand because they had far too much control over the final look and feel of the product and could essentially name themselves the final arbiters. Development and QE were isolated from the customers. PMs dictated the features; meaningless meetings and committees abounded and the products suffered (every MS product in the last 8 years for example).

How to be a program manager – Joel on Software

Writing a functional specification is at the very heart of agile development, because it lets you iterate rapidly over many possible designs before you write code. Compared to code, a written spec is trivial to change. The very act of writing a specification forces you to think through the design you thought you had in your head, and helps you see the flaws in it quickly so that you can iterate and try more designs. Teams that use functional specifications have better designed products, because they had the opportunity to explore more possible solutions quickly. They also write code faster, because they have a clearer picture when they start of what’s going to be needed.

This claim is just wrong, or rather, doing this in the large scale is just wrong. I’ve worked under that system at Microsoft for years and I never saw it be very successful in practice. Maybe for a small part of a product, or a small iteration in a larger cycle it might work; but at the product level it is nearly always a bust. Why? Because you will not anticipate everything in your functional specs. Ever. A competing product will be released with better features. Flange A will not fit Bracket B. User testing will hand you your hat. Beta testers will tell you that it wasn’t really what they needed. And then you are back to the drawing board. Except you are two-thirds of the way through the cycle because you spent a huge amount of time iterating over the spec and then building to that spec. Now everything is screwed up, but QE needs to start testing to the spec RIGHT NOW. So what do you do? You hack. The spec goes out the window and development codes for dear life while program management throws out ideas and changes like pieces of spaghetti against the wall. At the end of the cycle you have a tarball mess of code with incongrous, hacked, features that came crashing onto the deck of the carrier and just caught the last wire. Watefall development is resistant to change, agile development embraces it. Change happens faster in our industry every year, why lock your developers into software methodologies from the 70s?

Is there a role for Program Management? Absolutely. Not for the Microsoft-style Program Manager, but certainly for the jobs that the Microsoft Program Manager has. UI design and look and feel is best managed by professional user interaction specialists working with a project manager and development. The project manager can also be the primary representative of the client, but not the sole conduit. One of the primary jobs of QE is to be a user representative. Isolating development from the users just means that they don’t understand why they are doing what they do. Isolating QE from the users mean that they can’t represent a user of a product in their testing. The Program Manager can also work with development and QE to manage the schedule.

My experience with great program mangers post-Microsoft are folks that coordinate across all the functional groups to make sure that development has what they need, QE understands the user, experience design is delivering on time and all the clients are feeling well represented. In this view, the program manager acts as a lynchpin connecting development, QE and XD to their customers. Do they set the schedule? no. Do they write the specs? Maybe (in a non-agile team, working with the other groups). Is that less fun for the program manager? Maybe, but it produces much better products in my experience.