Recently I’ve been bumping into more and more people who’ve either left Google to come to Microsoft or got offers from both companies and picked Microsoft over Google. I believe this is part of a larger trend especially since I’ve seen lots of people who left the company for “greener pastures” return in the past year (at least 8 people I know personally have rejoined) . However in this blog post I’ll stick to talking about people who’ve chosen Microsoft over Google.

First of all there’s the post by Sergey Solyanik entitled Back to Microsoft where he primarily gripes about the culture and lack of career development at Google, some key excerpts are

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)
…
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.
…
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)
…
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…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
…
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.
…
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!

Sergey isn’t the only senior engineer I know who  has contributed significantly to Google projects and then decided Microsoft was a better fit for him. Danny Thorpe who worked on Google Gears is back at Microsoft for his second stint working on developer technologies related to Windows Live.  These aren’t the only folks I’ve seen who’ve decided to make the switch from the big G to the b0rg, these are just the ones who have blogs that I can point at.

Unsurprisingly, the fact that Google isn’t a good place for senior developers is also becoming clearly evident in their interview processes. Take this post from Svetlin Nakov entitled Rejected a Program Manager Position at Microsoft Dublin - My Successful Interview at Microsoft where he concludes

My Experience at Interviews with Microsoft and Google

Few months ago I was interviewed for a software engineer in Google Zurich. If I need to compare Microsoft and Google, I should tell it in short: Google sux! Here are my reasons for this:

1) Google interview were not professional. It was like Olympiad in Informatics. Google asked me only about algorithms and data structures, nothing about software technologies and software engineering. It was obvious that they do not care that I had 12 years software engineering experience. They just ignored this. The only think Google wants to know about their candidates are their algorithms and analytical thinking skills. Nothing about technology, nothing about engineering.

2) Google employ everybody as junior developer, ignoring the existing experience. It is nice to work in Google if it is your first job, really nice, but if you have 12 years of experience with lots of languages, technologies and platforms, at lots of senior positions, you should expect higher position in Google, right?

3) Microsoft have really good interview process. People working in Microsoft are relly very smart and skillful. Their process is far ahead of Google. Their quality of development is far ahead of Google. Their management is ahead of Google and their recruitment is ahead of Google.

Microsoft is Better Place to Work than Google

At my interviews I was asking my interviewers in both Microsoft and Google a lot about the development process, engineering and technologies. I was asking also my colleagues working in these companies. I found for myself that Microsoft is better organized, managed and structured. Microsoft do software development in more professional way than Google. Their engineers are better. Their development process is better. Their products are better. Their technologies are better. Their interviews are better. Google was like a kindergarden - young and not experienced enough people, an office full of fun and entertainment, interviews typical for junior people and lack of traditions in development of high quality software products.

Based on my observations, I have theory that Google’s big problem is that the company hasn’t realized that it isn’t a startup anymore. This disconnect between the company’s status and it’s perception of itself manifests in a number of ways

1. Startups don’t have a career path for their employees. Does anyone at Facebook know what they want to be in five years besides rich? However once riches are no longer guaranteed and the stock isn’t firing on all cylinders (GOOG is underperforming both the NASDAQ and DOW Jones industrial average this year) then you need to have a better career plan for your employees that goes beyond “free lunches and all the foosball you can handle".

2. There is no legacy code at a startup. When your code base is young, it isn’t a big deal to have developers checking in new features after an overnight coding fit powered by caffeine and pizza. For the most part, the code base shouldn’t be large enough or interdependent enough for one change to cause issues. However it is practically a law of software development that the older your code gets the more lines of code it accumulates and the more closely coupled your modules become. This means changing things in one part of the code can have adverse effects in another. 

   As all organizations mature they tend to add PROCESS. These processes exist to insulate the companies from the mistakes that occur after a company gets to a certain size and can no longer trust its employees to always do the right thing. Requiring code reviews, design specifications, black box & whitebox & unit testing, usability studies, threat models, etc are all the kinds of overhead that differentiate a mature software development shop from a “fly by the seat of your pants” startup. However once you’ve been through enough fire drills, some of those processes don’t sound as bad as they once did. This is why senior developers value them while junior developers don’t since the latter haven’t been around the block enough.

3. There is less politics at a startup. In any activity where humans have to come together collaboratively to achieve a goal, there will always be people with different agendas. The more people you add to the mix, the more agendas you have to contend with. Doing things by consensus is OK when you have to get consensus from two or three people who sit in the same hallway as you. It’s a totally different ball game when you need to gain it from lots of people from across a diverse company working on different projects in different regions of the world who have different perspectives on how to solve your problems. At Google, even hiring an undergraduate candidate has to go through several layers of committees which means hiring managers need to possess some political savvy if they want to get their candidates approved.  The founders of Dodgeball quit the Google after their startup was acquired after they realized that they didn’t have the political savvy to get resources allocated to their project.

The fact that Google is having problems retaining employees isn't news, Fortune wrote an article about it just a few months ago. The technology press makes it seem like people are ditching Google for hot startups like FriendFeed and Facebook. However the truth is more nuanced than that. Now that Google is just another big software company, lots of people are comparing it to other big software companies like Microsoft and finding it lacking.

Now Playing: Queen - Under Pressure (feat. David Bowie)

I've spent all of my professional career working at a large multinational company. In this time I've been involved in lots of different cross-team and cross-divisional collaboration efforts. Some times these groups were in the same organization and other times you would have to go up five to ten levels up the org chart before you found a shared manager. Surprisingly, the presence or lack of shared management has never been the key factor that has helped or hindered such collaborative efforts.

Of all the problems I've seen when I've had to depend on other teams for help in getting a task accomplished or vice versa; there have been two insidious that tend to crop up in situations where things go awry. The first is misaligned goals. Just because two groups are working together doesn't mean they have the same motivations or expected end results. Things quickly go awry when one group's primary goals either run counter to the goal(s) of the group they are supposed to be collaborating with. For example, consider a company that requires its technical support to have very low average call time to meet their metrics. Imagine that same company also puts together a task force to improve the customer satisfaction with the technical support experience after lots of complaints from their customers. What are the chances that the task force will be able to effect positive change if the metrics used to reward their tech support staff remain the same? The funny thing is that large companies often end up creating groups that are working at cross purposes yet are supposed to be working together.

What makes misaligned goals so insidious is that the members of the collaborating groups who are working through the project often don't realize that the problem is that their goals are misaligned. A lot of the time people tend to think the problem is the other group is evil, a bunch of jerks or just plain selfish. The truth is often that the so-called jerks are really just thinking You're not my manager, so I'm not going to ask how high when you tell me to jump. Once you find out you've hit this problem then the path to solving it is clear. You either have to (i) make sure all collaborating parties want to reach the same outcome and place have similar priorities or (ii) jettison the collaboration effort.

Another problem that has scuttled many a collaboration effort is when one or more of the parties involved has undisclosed concerns about the risks of collaborating which prevents them from entering into the collaboration wholeheartedly or even worse has them actively working against it. Software development teams experience this when they have to manage dependences on their project or that they have on other projects. There's a good paper on the topic entitled Managing Cognitive and Affective Trust in the Conceptual R&D Organization by Diane H. Sonnenwald which breaks down the problem of distrust in conceptual organizations (aka virtual teams) in the following way

Two Types of Trust and Distrust: Cognitive and Affective
Two types of trust, cognitive and affective, have been identified as important in organizations (McAllister, 1995; Rocco, et al, 2001). Cognitive trust focuses on judgments of competence and reliability. Can a co-worker complete a task? Will the results be of sufficient quality? Will the task be completed on time? These are issues that comprise cognitive trust and distrust. The more strongly one believes the answers to these types of questions are affirmative, the stronger one’s cognitive trust. The more strongly one believes the answers to these types of questions are negative, the stronger one’s cognitive distrust.

Affective trust focuses on interpersonal bonds among individuals and institutions, including perceptions of colleagues’ motivation, intentions, ethics and citizenship. Affective trust typically emerges from repeated interactions among individuals, and experiences of reciprocated interpersonal care and concern (Rosseau, et al, 1998). It is also referred to as emotional trust (Rocco, et al, 2001) and relational trust (Rosseau, et al, 1998). It can be “the grease that turns the wheel” (Sonnenwald, 1996).

The issue of affective distrust is strongly related to lacking shared goals while working together as a team which I've already discussed. Cognitive distrust typically results in one or more parties in the collaboration acting with the assumption that the collaboration is going to fail. Since these distrusting group(s) assume failure will be the end result of the collaboration they will take steps to insulate themselves from this failure. However what makes this problem insidious is that the "untrusted" groups are often not formally confronted about the lack of trust in their efforts and thus risk mitigation is not formally built into the collaboration effort. Eventually this leads to behavior that is counterproductive to the collaboration as teams try to mitigate risks in isolation and eventually there is distrust between all parties in the collaboration. Project failure often soon follows.

The best way to prevent this from happening once you find yourself in this situation is to put everyone's concerns on the table. Once the concerns are on the table, be they concerns about product quality, timelines or any of the other myriad issues that impact collaboration, mitigations can be put in place. As the saying goes sunlight is the best disinfectant, thus I've also seen that when the "distrusted" team becomes fully transparent in their workings and information disclosure it quickly makes matters clear. Because one of two things will happen; it will either (i) reassure their dependents that their fears are unfounded or (ii) confirm their concerns in a timely fashion. Either of which is preferable to the status quo.

Now Playing: Mariah Carey - Cruise Control (featuring Damian Marley)

From the press release entitled Microsoft Makes Strategic Changes in Technology and Business Practices to Expand Interoperability we learn

REDMOND, Wash. — Feb. 21, 2008 — Microsoft Corp. today announced a set of broad-reaching changes to its technology and business practices to increase the openness of its products and drive greater interoperability, opportunity and choice for developers, partners, customers and competitors.

Specifically, Microsoft is implementing four new interoperability principles and corresponding actions across its high-volume business products: (1) ensuring open connections; (2) promoting data portability; (3) enhancing support for industry standards; and (4) fostering more open engagement with customers and the industry, including open source communities.
...
The interoperability principles and actions announced today apply to the following high-volume Microsoft products: Windows Vista (including the .NET Framework), Windows Server 2008, SQL Server 2008, Office 2007, Exchange Server 2007, and Office SharePoint Server 2007, and future versions of all these products. Highlights of the specific actions Microsoft is taking to implement its new interoperability principles are described below.

• Ensuring open connections to Microsoft’s high-volume products.
• Documenting how Microsoft supports industry standards and extensions.
• Enhancing Office 2007 to provide greater flexibility of document formats.
• Launching the Open Source Interoperability Initiative.
• Expanding industry outreach and dialogue.

More information can be found on the Microsoft Interoperability page. Nice job, ROzzie and SteveB.

Now playing: Timbaland - Apologize (Feat. One Republic)

Given that I work in Microsoft's online services group and have friends at Yahoo!, I obviously won't be writing down my thoughts on Microsoft's $44.6 billion bid for Yahoo. However I have been somewhat amused by the kind of ranting I've seen in the comments at Mini-Microsoft. Although the majority of the comments on Mini-Microsoft are critical of the bid, it is clear that the majority of the posters aren't very knowledgeable about Microsoft, it's competitors or the online business in general.

There were comments from people who are so out of it they think Paul Allen is a majority share holder of Microsoft. Or even better that Internet advertising will never impact newspaper, magazine or television advertising. I was also amused by the person that asked if anyone could name 2 or 3 successful acquisitions or technology purchases by Microsoft. I wonder if anyone would say the  Bungie or Visio acquisitions didn't work out for the company. Or that the products that started off as NCSA Mosaic or Sybase SQL have been unsuccessful as Microsoft products.

My question for the armchair quarterbacks that have criticized this move in places like Mini-Microsoft is "If you ran the world's most successful software company, what would you do instead?"

PS: The ostrich strategy of "ignoring the Internet" and milking the Office + Windows cash cows doesn't count as an acceptable answer. Try harder than that.

Now Playing: Birdman - Hundred Million Dollars (feat. Rick Ross, Lil' Wayne & Young Jeezy)

Over a year ago, I commented that sometimes it feels like working at Microsoft is like working in Dinosaur Country. Every time, I hear the phrase “software as a service” or it’s cousin “software plus services” it makes me feel this way. Most of the people uttering this crap don’t realize that this makes them sound as dated as the old codgers who kept on talking about “horseless carriages” when everyone else called them automobiles or just plain cars.

Case in point, this article from the Telegraph entitled Microsoft powers up for change which contains this humdinger of an opening paragrapgh

Chief executive says free software, downloadable online, is on the horizon for consumers. Josephine Moulds reports

Steve Ballmer, chief executive of Microsoft, yesterday signalled another step towards a dramatic change in the software giant's business model.

In London on a whistle-stop tour, Ballmer was discussing the delivery of software packages over the internet. "We are a software company, and yet in a sense, the very form of our core capability is changing. We need to change our capabilities so that we are not just good at writing bits that you put out on CD and deliver, but rather writing this thing that is a living, breathing, dynamic, organic thing."

What’s next? A press release announcing that pasteurization may not be a fad? A news story conceding that heavier-than-air aircraft may just be the way to go after all? 

*sigh*

Now playing: The Verve - Bitter Sweet Symphony

Marc Andreessen (whose blog is on fire!) has a rather lengthy but excellent blog post entitled The Pmarca Guide to Big Companies, part 2: Retaining great people which has some good advice on how big companies can retain their best employees. The most interesting aspects of his post were some of the accurate observations he had about obviously bad ideas that big companies implement which are intended to retain their best employees but end up backfiring. I thought these insights were valuable enough that they are worth repeating.

Marc writes

Don't create a new group or organization within your company whose job is "innovation". This takes various forms, but it happens reasonably often when a big company gets into product trouble, and it's hugely damaging.

Here's why:

First, you send the terrible message to the rest of the organization that they're not supposed to innovate.

Second, you send the terrible message to the rest of the organization that you think they're the B team.

That's a one-two punch that will seriously screw things up.

This so true. Every time I've seen some executive or management higher up create an incubation or innovation team within a specific product group, it has lead to demoralization of the people who have been relegated as the "B team" and bad blood between both teams which eventually leads to in-fighting. All of this might be worth it if these efforts are successful but as Clayton Christensen pointed out in his interview in Business Week on the tenth anniversary of "The Innovator's Dilemma"

People come up with lots of new ideas, but nothing happens. They get very disillusioned. Never does an idea pop out of a person's head as a completely fleshed-out business plan. It has to go through a process that will get approved and funded. You're not two weeks into the process until you realize, "gosh, the sales force is not going to sell this thing," and you change the economics. Then two weeks later, marketing says they won't support it because it doesn't fit the brand, so we've got to change the whole concept.

All those forces act to make the idea conform to the company's existing business model, not to the marketplace. And that's the rub. So the senior managers today, thirsty for innovation, stand at the outlet of this pipe, see the dribbling out of me-too innovation after me-too innovation, and they scream up to the back end, "Hey, you guys, get more innovative! We need more and better innovative ideas!" But that's not the problem. The problem is this shaping process that conforms all these innovative ideas to the current business model of the company.

This is something I've seen happen time after time. There are times when incubation/innovation teams produce worthwhile results but they are few and far between especially compared to the number of them that exist. In addition, even in those cases both of Marc's observations were still correct and they led to in-fighting between the teams which damaged the overall health of the product, the people and the organization. 

Marc also wrote

Don't do arbitrary large spot bonuses or restricted stock grants to try to give a small number of people huge financial upside.

An example is the Google Founders' Awards program, which Google has largely stopped, and which didn't work anyway.

It sounds like a great idea at the time, but it causes a severe backlash among both the normal people who don't get it (who feel like they're the B team) and the great people who don't get it (who feel like they've been screwed).

Significantly differentiated financial rewards for your "best employees"  are a seductive idea for executives but they rarely work as planned for several reasons. One reason is based on an observation I first saw in Paul Graham's essay Hiring is Obsolete; big companies don't know how to value the contributions of individual employees. Robert Scoble often used to complain in the comments to his blog that he made less than six figures at Microsoft. I personally think he did more for the company's image than the millions we've spent on high priced public relations and advertising firms. Yet it is incredibly difficult to prove this and even if one could the process wouldn't scale to every single employee. Then there's all the research from various corporations that have used social network analysis to find out that their most valuable employees are rarely the ones that are high up in the org chart (see How Org Charts Lie published by the Harvard Business School). The second reason significantly financially rewarding your "best employees" ends up being problematic is well described in Joel Spolsky's article Incentive Pay Considered Harmful where he points out

Most people think that they do pretty good work (even if they don't). It's just a little trick our minds play on us to keep life bearable. So if everybody thinks they do good work, and the reviews are merely correct (which is not very easy to achieve), then most people will be disappointed by their reviews. 

When you combine the above observation with the act if rewarding does that get good reviews disproportionately from those that just did OK, it can lead to problems. For example, what happens when a company decides that it will give millions of dollars in bonuses to its employees if they "add the most value" to the company? Hey, isn't that what the Google Founder's Awards were supposed to be about...how did that turn out?

The company has continually tinkered with its incentives for people to stay. Early on Page and Brin gave "Founders' Awards" in cash to people who made significant contributions. The handful of employees who pulled off the unusual Dutch auction public offering in August 2004 shared $10 million. The idea was to replicate the windfall rewards of a startup, but it backfired because those who didn't get them felt overlooked. "It ended up pissing way more people off," says one veteran.

Google rarely gives Founders' Awards now, preferring to dole out smaller executive awards, often augmented by in- person visits by Page and Brin. "We are still trying to capture the energy of a startup," says Bock.

Disclaimer: This is my opinion. It does not reflect the intentions, strategies, plans or stated goals of my employer

Ever since the last Microsoft reorg where it's Web products were spread out across 3 Vice Presidents I've puzzled about why the company would want to fragment its product direction in such a competitive space instead of having a single person responsible for its online strategy.

Today, I was reading an interview with Chris Jones, the corporate vice president of Windows Live Experience Program Management entitled Windows Live Moves Into Next Phase with Renewed Focus on Software + Services and a lightbulb went off in my head. The relevant bits are excerpted below

PressPass: What else is Microsoft announcing today?

Jones: Today we’re also releasing a couple of exciting new services from Windows Live into managed beta testing: Windows Live Photo Gallery beta and Windows Live Folders beta.

Windows Live Photo Gallery is an upgrade to Windows Vista’s Windows Photo Gallery, offered at no charge, and enables both Windows Vista and Windows XP SP2 customers to share, edit, organize and print phot