Ads by TechWords
Subscribe to our e-mail newsletters
For more info on a specific newsletter, click the title. Details will be displayed in a new window.
Computerworld Daily News (First Look and Wrap-Up)
Computerworld Blogs Newsletter
The Weekly Top 10
More E-Mail Newsletters 
Eric Lai's picture
Eric Lai

Regarding Redmond

At Microsoft, program managers don't program, or manage

Besides the 2,000 Microsoft developers apparently working on Windows 7, the operating system also has 500 program managers. A reader, Jordan Cohen, pointed out that PMs, contrary to what they sound like (and what I had written), "are on a level playing field right with the developers and testers." And he cites as proof the blog of someone who would irrefutably know: Windows development chief, Steven Sinofsky.

In a blog from December 2005 when he was overseeing the development of Office 2007, Sinosky explains that he first learned about program managers when he was being recruited to Microsoft in the late 1980s.

"I thought 'COOL!' that has to be a job for me--after all it sure sounds like an incredibly cool role, since it has the title 'manager' in it and if you read/hear the description it sure sounds like you're running the show," he wrote. But "the job title 'program manager' is a bit of a misnomer, since program managers do not program nor do they manage--go figure."

According to Sinofsky, Microsoft first began employing program managers with the development of Excel for the Macintosh in the early 1980s.

"The developers were very busy just trying to make things like printing, display, graphics, etc. work," wrote Sinofsky. "That meant that the place where we were not focusing enough attention was on the usability or the scenarios for how people would use the software."

Thus, a program manager's function is "partnering with development and working through the entire product cycle as the advocate for end-users and customers," he wrote. PMs "focus on the big picture...and on the details of the user experience."

In concrete terms, PMs are responsible for researching requirements for new features and convincing developers and managers that these are worth building.

"Your ability to convince people of your ideas is a lot like trying to get funding from venture capital folks," wrote Sinofsky, who was both a developer and PM earlier in his career.

Once that is completed, PMs write up the specs that developers use to go off and write.

So PMs don't manage developers. But they should serve as a "hub" for all team members, including developers, testers, usability engineers, product designers and/or planners, Sinofsky wrote.

Some vendors such as Google Inc. prefer to release beta versions of features to get direct user feedback. But Sinofsky says that isn't as "sophisticated" as employing PMs, who are supposed to represent the needs of all customers, "not just the ones who do beta test or the ones who take the time to send in feedback or use early products."

Interestingly, in an earlier, related blog on managing feature teams in Office 2007, Sinofsky writes that the software was "built by about 30 product groups, each with about 3-5 feature teams, each with 5-8 developers."

Taking the middle figure in each range, Office 2007 was built using about 780 developers, or 60% fewer than Windows 7 has. The number of PMs was even smaller.

"The entire user interface for Office12 (the old code name) was developed by a team of about 12 program managers," he wrote.

-----------

Have you ever been a PM at Microsoft -- or elsewhere? Were your duties similar or different to the ones described? Do you think how Microsoft structures its dev teams makes sense?

What People Are Saying

Rate this
Rated -3
625 Votes

My wife is a PM at Microsoft

Sinofsky's got it pretty spot on.

My wife has been a PM at Microsoft for about 4 years now. She interned at Microsoft for 2 years as a software design engineer (Dev) and came to the conclusion that while she loved CS theory, algorithims, data structures etc. she just didn't like to actually code. Not a great attribute for a developer :).

Then she learned about PM. It truly was a match made in heaven. She focuses on identifying core user scenarios and then designing features to make those scenarios possible. She works with UX designers, usability experts, developers, testers, business managers, marketing, legal, you name it, to gain a big picture overview of what the requirements of customers, the market, and long-term strategy of a product are. She compiles all this, adds her own insights, and comes up with a design, user interaction model and feature requirements and puts it all in a 'spec' (Specifications Document).
This isn't the end of it though. She also builds out a design, development, test and release schedule and works with everyone to keep the project on track for shipping. In fact, I've heard people say, the only reason anything ever ships is becuase of PM's. Dev's would want to keep adding features and functionality (every program would turn into an all-purpose solves every problem you'll never have solution) and test would always want the quality to be a bit higher. The PM makes the call on when enough is enough. Hyperbole to be sure, but you get the point.
The hard part is that PM's can't 'make' anyone do anything. They have to build concensus & get everyone behind a unified vision. Key attributes include - 1.) Strong Design Instincts 2.) Strong Customer Empathy 3.) Amazing interpersonal skills 4.) Ridiculous organizational skills 5.)Short-term and long-term vision 6.) Leadership through influencing people above, below, and laterally in the org structure. 7.) Relentless drive to get things done right.

All in all it's a role that was invented by Microsoft that allows for deeper specialization of labor. Dev's love to Build sweet optimized algorithmically challenging features, Test loves those features to be as robust as possible so everything works the way it should, and PM loves to design and drive a great product to ship.

While I mention "specialization of labor" people often move from one role or another switching between the three core-technical roles in order to gain experiences and build different types of products and learn/impact different technologies.

Since she started, she's worked on 4 different teams in 4 years in vastly different technical spaces (Office for the Mac, MSN Music, Xbox, and Incubation Groups)