Back to Microsoft

Last week I left Google to go back to Microsoft, where I started this Monday (and so not surprisingly, I was too busy to blog about it).

I think I am the first person in the Seattle/Kirkland area to do so, so this merits an explanation. Isn't Google an insanely cool place to work for? What about the free food???

There are many things that Google does really well, and I plan to advocate that some of these things be adopted at Microsoft.

Among them is the peer-based review model where one's performance is determined largely based on peer comments, and much less so based on the observations of the manager. The idea that a manager is far easier to fool than the co-workers are is sound and largely works. A very important side-effect that this model produces is an increased amount of cooperation between the people, and generally better relationships within the team.

The wide employee participation in corporate governance through a concept called "Intergrouplets" is a good one and merits emulation. Unlike most other companies where internal life is regulated largely by management, a lot of aspects of Google are ruled by committees of employees who are passionate about an issue, and are willing to allocate some of their time to have this issue resolved. Many things, such as quality of code base, testing practices, internal engineering documentation, and even food service are decided by intergrouplets. Of course, this is where 20% time (a practice where any Googler can spend one day a week working on whatever he or she wants) plugs in well, for without available time there would have been nothing to allocate.

Doing many things by committee. Hiring, resource allocations at Google are done by consensus of many players. If you are to achieve anything at Google, you must learn how to build this consensus, or at least how to not obstruct it. This skill comes in very handy for every other aspect of work.

Free food. More than just a benefit, it is a tool for increasing communications within the team, because it's so much easier to have team lunches. I don't think making Redmond cafeterias suddenly free would work (maybe I am wrong), but giving out free lunch coupons for teams of more than 3 people from more than one discipline to have lunch together - and at the same time have an opportunity to communicate - I think, has a fair chance of success.

There are other things that I would want at Microsoft, but which will probably not happen simply because there is far too much legacy. I will miss the things like one code base with uniform style guides and coding standards - there's too much existing code at Microsoft to try and turn this ship around.

So why did I leave?

There are many things about Google that are not great, and merit improvement. There are plenty of silly politics, underperformance, inefficiencies and ineffectiveness, and things that are plain stupid. I will not write about these things here because they are immaterial. I did not leave because of them. No company has achieved the status of the perfect workplace, and no one ever will.

I left because Microsoft turned out to be the right place for me.

First, I love multiple aspects of the software development process. I like engineering, but I love the business aspects no less. I can't write code for the sake of the technology alone - I need to know that the code is useful for others, and the only way to measure the usefulness is by the amount of money that the people are willing to part with to have access to my work.

Sorry open source fanatics, your world is not for me!

Google software business is divided between producing the "eye candy" - web properties that are designed to amuse and attract people - and the infrastructure required to support them.

Some of the web properties are useful (some extremely useful - search), but most of them primarily help people waste time online (blogger, youtube, orkut, etc).

All of them are free, and it's anyone's guess how many people would actually pay, say $5 per month to use Gmail. For me, this really does make the project less interesting if people are not willing to pay for it.

This orientation towards cool, but not necessarilly useful or essential software really affects the way the software engineering is done. Everything is pretty much run by the engineering - PMs and testers are conspicuously absent from the process. While they do exist in theory, there are too few of them to matter.

On one hand, there are beneficial effects - it is easy to ship software quickly. I've shipped 3 major features (a lot of spell checker and other stuff in the latest Gmail release, multi-user chat in Gmail, and road traffic incidents in Google Maps), and was busy at work on my fourth project in just a year. You can turn really quickly when you don't have to build consensus between 3 disciplines as you do at Microsoft!

On the other hand, I was using Google software - a lot of it - in the last year, and slick as it is, there's just too much of it that is regularly broken. It seems like every week 10% of all the features are broken in one or the other browser. And it's a different 10% every week - the old bugs are getting fixed, the new ones introduced. This across Blogger, Gmail, Google Docs, Maps, and more.

This is probably fine for free software, but I always laugh when people tell me that Google Docs is viable competition to Microsoft Office. If it is, that is only true for the occasional users who would not buy Office anyway. Google as an organization is not geared - culturally - to delivering enterprise class reliability to its user applications.

The culture part is very important here - you can spend more time fixing bugs, you can introduce processes to improve things, but it is very, very hard to change the culture. And the culture at Google values "coolness" tremendously, and the quality of service not as much. At least in the places where I worked.

Since I've been an infrastructure person for most of my life, I value reliability far, far more than "coolness", so I could never really learn to love the technical work I was doing at Google.

The second reason I left Google was because I realized that I am not excited by the individual contributor role any more, and I don't want to become a manager at Google.

The Google Manager is a very interesting phenomenon. On one hand, they usually have a LOT of people from different businesses reporting to them, and are perennially very busy.

On the other hand, in my year at Google, I could not figure out what was it they were doing. The better manager that I had collected feedback from my peers and gave it to me. There was no other (observable by me) impact on Google. The worse manager that I had did not do even that, so for me as a manager he was a complete no-op. I asked quite a few other engineers from senior to senior staff levels that had spent far more time at Google than I, and they didn't know either. I am not making this up!



At Microsoft, the role of a manager is far more obvious. A dev lead is responsible for the success of the feature and the health of the feature team. A dev manager is responsible for the success of the product and the culture of the dev team. A PUM is responsible for the success of the business, and interoperation of the three teams that work on the product. And so it goes...

Given all this, after a year at Google I realized that I had no idea how my career was going to progress. By contrast, my Microsoft career goals were pretty clear within the first month after I joined the company in 1998.

This is when I knew it was time to go...

Am I sorry that I spent this year at Google? Not at all! It gave me a different perspective. It gave me new ideas. It cleared my mind. It gave me a much needed change of pace after the death march of the Windows Home Server release. I enjoyed the company of quite a few really good people from whom I learned a lot...

Good-bye, Google, hello Microsoft. It's good to be back!