Program Manager Syndrome, that is.

A few days ago I called for Microsoft to slash not 5,000 jobs but 50,000 to make the company lean and focused once more. Readers responded by asking which 50,000 Microsoft heads I’d like to see cut off? Wow, what a great question! So great, in fact, that it inspired this column and probably the one after. Because it’s not that simple to just fire half a company. It’s remarkably easy, in fact, to fire the WRONG half.

Restructuring Microsoft has to have a point beyond simply improving profitability, which was pretty darned good to start with. It requires first identifying the systemic problems inside the company that ought to be addressed by thoughtful, if brutal, change.

But people don’t gchange. That kid you knew in high school who was a weasel-rat, well he’s probably a fat and balding weasel-rat today. People are sometimes changed by life- or career-threatening experiences, but generally not even then, which is why organizations that try to change hardly ever succeed.

So you have to cut deep – very deep – to make change stick. One approach to show management is serious about change is to attack the big identity aspects of the concern like its name, where it is based, and who is running the show. Remember Boeing moved its corporate headquarters to Chicago in an attempt to show the world it was a different company. ValuJet merged with a smaller company and changed its name to AirTran. If Microsoft is going to successfully change it will have to make similar moves, at least for some divisions.

Current top management, of course, should go.

Microsoft has several systemic problems holding it back. Like many big, proud, older, successful-if-fading-somewhat companies, Microsoft’s problems are seen by some as the reasons for the company’s past success, which they may well be. It’s just that Microsoft has outgrown those old ways of doing things (or the market has) only they haven’t figured that out yet.

Ignoring completely the company’s anti-trust issues, Microsoft’s primary failing is technical arrogance. Some of this is native and some is a vestige of Redmond’s long association with IBM. Taking the IBM connection first, let’s look at something current Microsoft CEO Steve Ballmer said in my 1996 PBS documentary, Triumph of the Nerds:

“In IBM there’s a religion in software that says you have to count KLOCs (pronounced KAY-lock), and a KLOC is a thousand lines of code. How big a project is it? Oh, it’s sort of a 10 KLOC project. This is a 20 KLOCer. And this is 5O KLOCs. And IBM wanted to sort of make it the religion about how we got paid. How much money we made off OS/2, how much they did. How many KLOCs did you do? And we kept trying to convince them – hey, if we have – a developer’s got a good idea and he can get something done in 4 KLOCs instead of 20K-LOCs, should we make less money? Because he’s made something smaller and faster, less KLOCs. KLOCs, KLOCs, that’s the methodology. Ugh!”

While Microsoft learned a lot from IBM, this whole KLOC-orientation and associated ass-backward reward scheme repulsed them because it led to bloated code. So just like a child who grows to ultimately emulate or rebel against parental examples, Microsoft shunned the KLOC and embraced the power of tight code. And though it might surprise you from looking at their current product lines, they still do.

The way a company that prides itself on tight code can build something as floppy (in every sense) as Windows Vista is because Vista is simply too big for any one Microsoft executive or engineer to understand in detail. So they embrace the idea that piling lots of chunks of tight code somehow won’t turn into a huge steaming mass of not-very-tight product. But it does.

But wait, there’s more! Somehow this mistaking fat for muscle became institutionalized at Microsoft through a unique group of people called Program Managers or PMs. This is a Microsoft invention intended to make their products more useful and elegant, yet in practice the PMs do just the opposite.

Program Managers at Microsoft are the advocates for software usability. They link (or are supposed to link) to the rest of the company development, usability and testing. They write specs and try to optimize the user experience, though with only limited success.

The bloated development, test, and PM teams across the company are a sign of Microsoft’s obsession with technology and all things technical. There aren’t nearly enough usability engineers, designers, writers, editors, and other people who worry about how usable the software actually is. In other words, like the people who run the feature teams at Apple.

A Microsoft designer once said that the biggest difference between Apple and Microsoft was that at Apple designers usually owned the product features, while at Microsoft, PMs always own the features. And most of the PMs at Microsoft are highly technical, often with computer science degrees. This is considered a good thing, by the way, but it isn’t good at all. It means the PMs tend to lean in favor of the developers just as management leans in favor of the developers, too. So in most cases where usability goes head-to-head with development, usability loses. And so do users.

The answer for Microsoft is not to blindly copy Apple because Microsoft will never BE Apple and will never have a Steve Jobs as boss. The answer is to adopt a similar product design philosophy to Apple’s with the focus squarely on usability.

This will not happen EVER with the present culture at Microsoft.

The first head of usability at Microsoft was a woman named Mary Dieli whom I met at Apple in the early 1980s when she was an intern there. Mary, who went on to get her PhD at Carnegie Mellon, ran usability for Adobe Systems and then was lured to Microsoft around the time of Windows 3.0. We used to talk, she and I, about her frustration at Microsoft and how difficult it was to be the champion of something that was considered non-technical, even effete, like usability. Mary could never break into the boys club that runs Microsoft. It’s not just that she was a woman, though, it’s that her field got only lip service, not respect.

At Microsoft the PMs and development managers have the power to control product features, not the usability researchers and designers, who are overworked and without real authority. Microsoft needs to somehow shift its corporate culture away from an obsessive focus on technology and engineering toward creating software that’s much more user-friendly. Until it does this, the company will continue to be slammed for its products.

Next time we’ll consider exactly what sort of tough love will be required to make Microsoft in the 21st century the kind of success it was in the 20th.