Here’s an interesting phenomenon — a guy who has left Google to work for Microsoft. In his blog he explains why. First the good news:
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 he leave?
Several reasons. Firstly it seems that he prefers writing software for users who are willing to pay real money for it.
Secondly, he doesn’t like the way Google approaches software engineering. Its orientation towards cool, but not necessarily useful or essential software, he writes,
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 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.
As I say, it’s an interesting perspective. And he’s probably done himself no harm with his new bosses at Redmond by writing about it. Or is that too cynical a view?