As a follow up to my post on Microsoft and Creative Destruction, it’s worth looking at this chart, from Silicon Alley Insider.
It shows the quarterly operating expenses for Microsoft’s Online division. This last quarter, Microsoft lost $466 million. That’s 3 months.
Over the last year (4 quarters) Microsoft has lost nearly $2 billion.
And from what I remember, you’d see losses for the period before what’s shown on the chart, as the division has always struggled with profitability.

It’s an unbelievable chart. I’ve had to stop writing several times just to look at it again.
I’m certainly not arrogant enough to claim I know how to fix an entire division. But I can look at this and ask some basic questions:
If past history is any judge, Steve Sinofsky, the former VP from Office who took charge of Windows for Windows 7, might be the only weapon Microsoft can use to tackle Online. Many other VPs have been at the helm, including David Cole who was my VP for a time in the IE days, but as the chart shows, they’ve been largely ineffective at things other than spending lots of money.
In spirit of my last post, the better question is what did Sinofsky do to the Windows team to turn Vista into Windows 7? Why isn’t there a case study on this, that’s stapled onto the forehead of every manager until it’s read? And how can that be emulated in the Online division? My suspicion is this case study has not been done, and if it has, it’s either not being shared widely or it’s being ignored.
A recent NYT article by former Microsoft VP Dick Brass has caused quite the stir, but for the wrong reasons. Every follow up article I’ve read, including one from Microsoft, gets much of it wrong some key things wrong.
The premise: The core point of the Brass article is how the introduction of middle management and bureaucracy has killed innovation at Microsoft.
My counterargument: Microsoft has always been a conservative, platforms company. Visionary design and creative leaders think in terms of great products, which Microsoft has never been good at. Brass assumes the challenges that hampered Tablet PC were new and local, but they have always been there. Microsoft’s best, and most creative, work has come when a competitor forced one of the few Renaissance-VPs (VPs who were not over-promoted engineers but actually had a diversity of management skills) to take product design seriously.
My credentials: I worked at MSFT 1994 to 2003. I was on the IE 1.0 to IE 5.0 team among others (Windows, MSN, and MSTE/Best Practices, where I worked with many groups across the company). I wrote a bestselling book about Innovation and I’ve spoken and consulted with various groups at the company dozens of times since I left in 2003.
My take:
One common criticism, often mild, I hear about my book Making Things happen is it’s a Microsoft flavored book. I plead guilty. But this wasn’t for philosophical reasons, which some people seem to assume. My goal wasn’t to spread to the world how Microsoft makes software (which had already been done by Microsoft Secrets). Instead it was to use what I’d learned shipping IE 1.0 to 5.0 and other stuff to illustrate all sorts of concepts, tactics and tricks that can apply to any kind of project whether they use similiar processes or not. I needed a spine and that was one I knew well and had the most stories working with. For better or worse, Microsoft is an excellent reference point for how software, or any product is made, for a variety of reasons. But that’s all I meant it for – a system to use as leverage to explore the important stuff, not the other way around.
One of my top gripes at the time was how most project management books seemed written by consultants, people who didn’t write as if they’d actually used what they are teaching themselves (Mythical man month, for all it’s charms, is guilty of this in parts), since they couldn’t point out the common traps of their advice. The best remedy seemed to be specific, be real, tell the truth, and thus, the book came out as it did. I was, and still am, a believer in the idea of program managers, or project managers as true team leaders, and I wanted to tell the story of project management from that point of view.
In fact, if ever I write another project management book I doubt I’d even mention some of the heavier duty process stuff that shows up, however briefly, in the book. MRDs, vision documents, etc. are, as some critics pointed out, artifacts of larger organizations and many won’t have to wrestle with them, which is probably a good thing.
I’m a big believer it’s the soft skills that matter much more, and when I look back at Making things happen I see what could have been two separate books. One about process-y stuff (chapters on vision, specs, etc.) , and another about the human elements of leading projects (leadership, communication, relationships, crisis, risk, politics). I suspect people who like the book have a strong preference for one or the other. In flipping through the book it does seem to hold up the promise in the preface, that you can skip boring chapters and get value from the next – perhaps I suspected there were two books in there when I wrote it.
Anyway, its been years now and I don’t think I ever posted about this, despite how often I’ve seen it surface in reviews or had it come up at lectures.
Microsoft recently announced the end of the product known as Encarata. Way back in the day Encarta was cool. It was one of the few things made in the CD-ROM era that, looking backwards, made sense (Yes, I owned a copy of both Art Gallery and Microsoft Dogs, and as idiotic as it seems now, the later actually got good reviews) – and was actually designed quite well.
It’ was also a curiously successful work of innovation by Microsoft on several counts. Few people remember, but Microsoft bet big on CD-ROMs and consumer software, and of those efforts, many of which flopped, Encarta was a gem. In 1994 it demonstrated many of the things people had been promising PCs would be good for (multimedia, education, instant access to information, etc.). There were other encyclopedias, but (I don’t think) anyone else invested as much in the design and technology as Microsoft did.
Many forget, or were still in diapers, but in 1994, years before web design would be something you could say at a bar without people thinking you were into spiders, Encarta demonstrated much of what we call information architecture, interaction design and consumer aesthetics, all in one high profile consumer product. Many, many companies and software teams used Encarta as a reference for not only what was possible, but for what a good experience should be like. Microsoft didn’t invent many of the technologies involved, but the encapsulation of so many into a well designed experience is similar in some ways to the success of the i-pod. Both are examples of innovation through superior user experience and integration of various technologies made mostly by other folks.
And most importantly, when Netscape and Internet Explorer began the browser wars, many of us looked at Encarta as an approximation of what a great web experience should feel like, with rich media, consumer appliance simplicity, and great search and navigation. In the hallways on the Internet Explorer team we had screenshots of some of the Encarta team’s work, among various other bits of software inspiration, up on the wall. It was definitely a reference used in designing features like Explorer bars, Favorites & History.
Kudos to Bill Flora, Adrienne Odonnell, and Sheila Carter (who are listed here as the design team) and other folks who worked on this thing over the years.
Encarta also was one of the best product names Microsoft has ever had. Sure, that’s not saying much given how notorious MSFT is for lousy names, but like Excel (also a good name, at least it was in 1985, compared to Lotus 1-2-3) it somehow fit the vibe of the kind of thing the product was.
Can’t say I miss loading CDs into my PC (I can’t remember the last time I did that), but Encarta definitely deserves a notable place in the history of software design. They helped raise a bar many people still use today.
I remember the day I started working as a program manager on the Internet explorer team. On my second day, Joe Belfiore, my boss, came to my office, closed the door, and told me two things:
1. Your relationship with programmers is everything
2. There are only two teams at Microsoft to care about, Windows and Office.
Forget for a moment these specific points. Joe did the most important thing in the world as a boss. He gave me clear priorities. Even if they were wrong, from day one (ok, it was day two) he imparted his private view of how to succeed and how to make sense of things. It was amazingly empowering. I could slice through all of the work being thrown at me from across the team and the company, and divide into two neat piles: a) things to care about, b) things not to care about. Joe was a great boss and provided this kind of clarity all the time.
It turns out both bits of advice were right.
Your relationship with programmers is everything
As a program manager (glorified title for project manager), all of my power actually came from the programmers. I only had a job because of the programmers. No programmers means no code, no product, no revenue. End of story. My power was an extension of theirs. I had to treat them with respect and go out of my way to earn their trust over time.
This meant first and foremost I had to earn their respect. Help them make decisions. Bulldoze organizational road blocks out of their way. Prove I was smart, that I could help them make tough decisions, and could make the product much better even though I couldn’t write code as well as they could. And only after establishing that value could I be a team leader and be of true use to the project. With programmers as allies, working with marketers, testers, executives, or leaders of other teams, became easier, and my role as a team leader became possible.
When I visit companies or talk to people, and they tell me they rarely talk to the programmers, a red flashing light goes off in my head. How on earth do you have any power? I wonder. You don’t know the people who actually make the thing you are managing! You have no idea if they believe in what they are doing or not, or if they have better ideas than yours. Something critical is broken if project managers don’t have collaborative and trusting relationships with programmers. If there is a problem between PMs and programmers, it’s the PMs job to fix it. Odds are they’re better at communication, conflict resolution and have more perspective, all of the key skills for resolving differences and building relationships. Put another way: if you’re a PM and your team hates you, what else do you have? Your relationship with your team is everything.
There are only two teams at Microsoft to care about, Windows and Office.
Back in 1995 when Joe gave me this advice, it was true. There were only two groups at Microsoft that were successful and brining in sizable revenue. The problem was working on Internet Explorer during the browser wars, every one of the 100 teams in the company wanted something from me, and every other PM on the team. They wanted us to add features to help promote their work, code changes to fix bugs that bothered them, etc. There was a huge pile of people who wanted to influence the work I managed. My phone rang all the time and my inbox was always full. If I treated everyone equally I’d be doomed. Couldn’t be done. I had to ignore, or say no to, most of the people who wanted something from me. With Joe’s advice I had a rough guide for sorting it out. Tons of exceptions of course, but the baseline advice was right and useful.
Good managers give these little bits of power insight all the time. Dividing up the complex, stressful working world of projects into two piles. A project manager derives his power from this kind of clarity, especially if he can articuate it to others like Joe did to me.
Recently Joel on Software posted about how to be a program manager and he lists UI design as one of the skills program managers should be responsible for. It’s no surprise that people who call themselves UI designers, such as the folks on on the interaction design mailing list, have taken notice and are mostly unhappy.
(Back story: The idea of program managers, roughly a sergeant level generalist who drives projects, is an idea I like. It’s a job role Microsoft started in the late 1980s . It’s a job I had in the 90s).
Which gets to the question of should PMs do design.
The easy answer is yes, if they are good at it. Most are not. Most do not know this because they’ve never met an interaction designer, someone who does it professionally for a living. Simply because Fred is better at it than his peers, he assumes he is good. It’s not his fault exactly. Most computer science programs and business schools never talk to design schools. Certainly not about how much they need to learn from the other. And most program managers in the world are hired from computer science and business schools.
Anyway, the better teams at Microsoft figured this out over a decade ago. They did one of:
VPs that cared about ease of use invested in these assets, and just as important, built a culture around ease of use taking priority over other considerations.
However, in most cases the above investments had moderate impact on product quality because these people never receive sufficient power to overcome the other 20 PMs running around. Sometimes all the PMs are ignored anyway by the programmers but they are in denial about it, so it’s moot until that fight for power gets sorted out.
The program manager model is just one idea for diving up work. It’s a good model, but does have it’s problems. On larger teams it’s too easy for PMs to get lost in their egos and self-interests, each one fighting to make a great feature, inside of what becomes a mediocre product. It’s also a role that depends on culture, you can’t just graft it on and expect it to work as it impacts everyone.
Program management works best on smaller teams, or in organizations where the PM can have significant power. Once you have 15 or 20 of them running around it gets hard to sort things out. Imagine 15 or 20 film directors trying to work on a film together. If you give them enough power, you don’t need many film directors. And if you don’t need many, it’s easier to find ones with all of the talents you want, including the ability to design user interfaces.
The bottom line: program managers are generalists
At the end of the day it doesn’t matter who makes the UI design decisions provided they are good and they ship. If you’re a PM, your primary obligation is the quality of what goes out the door. If you have someone other than you available who is good at design, your top priority should be to get out of their way, just as you would for someone good at programming, testing, or any other role. Find other things to do to keep busy – I’m sure they exist. The value of the PM, or any manager, is their ability to fight for the best use of everyone’s time, including their own.
If ease of use is truly important in what you’re making, odds are it deserves the attention of a specialist or two who can dedicate their energy to it. If nothing else, they can teach you some of the stuff you don’t know you need to know. PMs can rarely dedicate their attention to anything, as their value is their ability to co-ordinate and lead.
The bestselling book I wrote about program management, Making Things happen, has several nice chapters about how to lead design and customer research, and advocates the above advice.