When I first joined Microsoft back in 1994 I, like many other outsiders, was shocked by its split of Software Engineering into three (rather than two) disciplines.  Splitting Development from Test was pretty common in the industry.  But subdividing Development into Program Management (PM or PgM) and Software Design Engineers (SDE)  was not.  Sure other companies had Program Managers who handled scheduling and coordination kinds of things, but this isn’t what Microsoft had done.  At Microsoft there are process-oriented Program Managers and technical Program Managers (and quite often people who do both).  The process-oriented Program Managers are like the classic ones found in other companies.  But the technical Program Managers are the ones who drive what features will be in a product, what they will look like, and write the functional specs for the features.  Then a Software Design Engineer does internal designs and writes the code.  Initially I hated this split because I was brought up in a culture where an engineer was held responsible for the entire job of understanding the customer requirement and taking it all the way through to working code.  If you read the book Showstopper!, about the creation of Windows NT, you’ll see that engineers who came to Microsoft from DEC generally didn’t believe in the PgM/SDE split.

I held both PgM and SDE (as well as Architect and General Management) roles at Microsoft and over time I came to appreciate the split.  For one thing it lets people pay a lot more attention to the customer experience than is possible when the same person worries about the external presentation and behavior as well as the internal functioning.  For another, for the majority of people it lets them focus on areas of strength rather than having to be a jack of all trades.  Now for the 10-20% of engineers who are equally good at PgM and SDE responsibilities it can be a little frustrating, but otherwise it seems like a good idea.

The truth is that I really appreciate the Microsoft-style of Program Management when I see good or bad design choices in non-software products.  Take a couple of bad examples from BMW.  Someone at BMW decided to put the interior door lock/unlock button in the center of the console instead of on the front door armrests.  Not only that, instead of it being a rocker switch that you push one way to open and the other to close, it is a single push button that decides what to do based on context.  Think of what this means (besides the fact that no one other than a BWM owner can find the switch).  First of all it means that (assuming you don’t have the remote on you) to open one door and unlock the rest you basically have to sit down in the car!  Second, it often means that you get into the car and press the button to unlock the other doors and instead it locks them!  This complete lack of consideration about how a door lock/unlock switch is used suggests that BMW let an engineer who thought the context sensistive door switch was a cool technical trick make the decisions.  They should have a program manager who understands how drivers and their passengers use the switch making those decisions.  And putting it in the center of the console?  I can’t really figure that one out at all.  Cost savings?  Security feature (i.e., someone can’t reach in the window to unlock the doors, they have to get half their body in the car)?  I don’t know.  But I can tell you it is darned inconvenient.

Of course another example is where BMW got it right and Toyota got it wrong.  Both our X5 and Rav4 offer a switch to lock the window controls.  In the case of the X5 it locks the passenger and rear window control but allows the driver to open or close all windows in the car.  In the Rav4 it locks the passenger and rear window controls, and prevents the driver from opening or closing any window except his own.  Now Toyota’s approach makes no sense at all.  You lock the window controls so that children or pets can’t operate them.  But you still want the driver to operate them.  The driver can, of course, unlock the controls to operate them.  But this provides a window of abuse.  Perfect and real life example, I unlock the Rav4 to open the passenger window a bit and the dog steps on a rear seat window control opening it all the way (to where he could jump out).  He could just as easily have closed it on his neck.  I don’t know if this was a Program Manager making a bad choice, or the lack of Program Management leaving the decision in the hands of the Engineer (who is busy worrying about things like can the switch withstand 10000 pushes, can he reduce the cost 1/2 penny, etc.).

Of course the best automotive advertisement for having a separate (and good) program management department might be the BMW iDrive.  It was a great idea that had a horrible design.  Over the years BMW has made several revisions to improve it, but it still is a largely despised aspect of BMWs.   For those unfamiliar with this adomination, the fundamental design flaw was in not adopting a clear and common navigation technique.  Sometimes, but infrequently, you can go back.  Most quite often you have to jump to the beginning and navigate your way back through a menu structure.  Contrast this with Audi’s equivalent that adopted the web’s back convention allowing you to always go back when you’ve navigated to the wrong screen.  Audi got it right, BMW got it wrong.  If you have good Program Management you get Audi’s implementation.  If not, you get BMW’s.

Lest anyone think I’m picking on BMW too much it should be known that I’m a huge BMW fan.  When it comes to driving I think they “get it” better than any other car manufacturer (some speciality situations aside).  When it comes to non-driving related design decisions they are hit or miss.

When you look at things like the Microsoft Office “Ribbon”, thank or curse Program Management.  When you look at the new Start Page in Windows 8, thank or curse Program Management.  When you like or curse some new T-SQL language syntax in Microsoft SQL Server….    You get the picture.

This is why, at most Microsoft events, you find the Program Managers are the ones doing the presentations.  Or perhaps why even though Terry Myerson runs Windows Phone Engineering it is his Director of Program Management, Joe Belfiore, who has become its public face.  The SDEs make the magic happen, but the Program Managers first write a spec for the trick.