Another ex-Microsoft engineer talks about how the company develops operating systems

A few days ago we had an ex-Microsoft designer talk about how the company came to its decision to largely replace pivots with the hamburger menu, noting that the decision was supported by a lot of data and was the result of concerted debate and discussion by a lot of very smart people.

Now we have another ex-Microsoft engineer, who works in the Windows team for more than 10 years, offer an insight into how sometimes great ideas turn into pretty bad implementations, or how bad ideas sometimes makes its way through the whole process to end up in shipping products.

The post was spotted elsewhere on the web, which I am not linking to, as he may not want the possibly negative attention. I was able to verify his identity as a long time Microsoft veteran however.

He writes:

I used to be a Windows engineer, and I’ve been in those Meetings.

Usually you have some outgoing and charismatic Program Manager who announces that the feature team has Made a Decision. Ultimately, the Decision is about compromising on the functionality, or the scope, or the timeline, or occasionally the existence of the Feature. The Feature as originally conceived was going to be fast, adaptive, configurable, intuitive, self-documenting, and above all user-friendly. Often the designs are vetted with users and industry partners who get a chance to sign off on the Feature. Don’t look at me like that. At this stage in the product, the next version of Windows was the most awesome thing conceived, take my word for it. During the course of the release, a steady stream of Decisions whittles that down until what is released looks nothing like what was envisioned.

The thing is, that in context and at the time, the Decision doesn’t look bad at all. The Decision is the result of a careful consensus between the PM, the Dev, and the Tester. These engineers have spent hours in meetings weighing their options, evaluating the pros and cons of each, plotting out the likely effects, and ultimately selecting the best among many competing options. (Or possibly the Decision was handed down from upper management; but the result is the same) The process is foolproof and meticulous, and guaranteed to arrive at the best possible outcome for all of the parties in the room.

The problem is who is not in the room. At this stage, often during week four of a six-week milestone, there’s no time to go back out and consult the User. In theory, almost everybody in engineering at Microsoft is an advocate for the User. PMs get inside the User’s head during planning, so the Feature can anticipate their every need. Testers are the first ones to feel the User’s pain when it doesn’t. Management meets with Partners, who are kind-of like users, but with a lot more money and influence. Devs … Devs actually don’t really care about the user. But anyway. In practice, this doesn’t work because nobody in Windows engineering has ever actually met the User. They instead rely on an idealized mental model of a generic user which has attributes assigned to it by higher-paid engineers.

The feature team consult this model and a ouija board and carefully rationalize all of the considerations that led to the Decision. But the Decision is ultimately made from engineering considerations and not user considerations, simply because the User isn’t at the table. It’s extra work to maintain multiple UIs for a product. We don’t have enough time to test multiple configurations. The other guy has higher market share than we do; if we just copy him maybe we will do better. All of these are true, more or less, and all of them are good reasons to support the Decision. But all of them are asked and answered from the perspective of Microsoft.

So on the day of the Meeting, the PM will go on and on about how the Decision benefits the User. They come up with facts that support the Decision. We don’t want to confuse the User with too many options. Only 3% of people used it that way, so clearly it’s okay to remove. Consistency is good for Microsoft, so it must be good for the User. Everybody smiles and nods and agrees this is the best way. The newest to the team, because it just makes so much sense. The veterans, possibly because they secretly know it’s about the engineers and not about the User, but more likely because engineers are inherently lazy. The meeting ends and the Feature has a new direction. It’s a little bit farther from the vision, and maybe little bit worse user experience, but writing software is about compromise. This was a good compromise. It’s not that bad, anyway. It was the best option available. If only the User was there to see it, they’d understand that.

I used to be a Windows engineer. As I watched this video, I suddenly felt like I was back in that Meeting.

The take away message is that despite all the data Microsoft’s planning and decisions are not infallible, and if no-one does actually represent users inside Microsoft we should certainly not be keeping quiet when we have feedback.