Between the Lines

 Posted by at 1:17 am  Work
Jun 302008
 

There has been a bit of pot-stirring on the blogs this weekend. Dare Obasanjo reflects on recent migrations of Google engineers to Microsoft, using the “e” word (exodus). Dion Almaer fires back, pointing out that people move between companies all the time, hardly justification for the “exodus”.

Both are right, and both are wrong.

First off, I have to agree with Dion that Dare’s use of “exodus” is a bit excessive. A dozen or two Googlers joining Microsoft would be an exodus when Google was a few hundred employees, but a dozen out of 20,000? Perhaps noteworthy on a case by case basis, but not an exodus.

However, Dare does make some good points that Dion sidesteps by omission. Google’s interview and hiring process are infamous, both from those who didn’t make the cut and from those who did. Dare cites Sergey Solyanik as an example of a dispassionate Googler taking up the Microsoft yoke and Svetlin Nakov‘s close encounter with the b0rg. Both mention the oddities of the Google hiring system.

From my personal experience, I’d say that Google’s hiring system is highly optimized for acquiring fresh college grads straight out of school – bright, idealistic, inexperienced, don’t know what they want to do with their lives, few or no time demands in their home life, and would be thrilled to do anything at a place as cool as the big G. The Google interview style – evaluating the person as a whole on intelligence and creativity, with no particular interest in experience and no particular job title in mind – reflects that.

A Google offer letter looks more like a college acceptance letter than a job offer: “Congratulations! You’ve been accepted. Your base pay is X. Please show up to orientation on Monday to receive your work assignment.” In many cases, you literally don’t know what project you have been hired into until you step out of orientation. As you exit orientation, you step into a sea of managers holding up signs with names on them, just like limo drivers waiting outside airport customs.

For new college grads, I’m sure this is all terribly exciting (and vaguely familiar to college life), but for old farts like me that have opinions about the world and know what they don’t want to work/waste time on, it leaves a lot of room for nasty surprises. The job you get can have little or nothing to do with the people you interviewed with or the topics that were discussed. Why? Because the people doing the interviews are in no way related to the job that needs to be filled. Matching new hires to job openings is done by a small committee dealing out cards to projects in priority order. Your name gets put into that deck only after you accept the offer blindly.

These odd procedures make for a very efficient hiring machine.  It’s a great way to feed Google’s insatiable appetite for new hires, but it leaves those being hired feeling distinctly bovine.

On my first day at Google (Oct 31, 2005 – everyone was dressed up for Halloween), I met my manager after orientation and was informed what I had been assigned to work on. In the space of about 15 minutes, I decided that wasn’t worth the commute or the money and headed for the door. I give a lot of credit to my manager (Linus Upson) for being quick on his feet and catching me before I had a chance to slam the door. He asked if instead I might be interested in this other project that he had been trying to get off the ground. I was, and that became Google Gears.

If you’re a senior engineer looking for a senior engineering position in a particular topic at Google, don’t go through the front door.

Dare makes a few observations at the end of his post:

1. Startups don’t have career paths for employees.

Agreed. The draw of a startup is the chance to get rich when the company “makes it big” or gets bought by a bigger company desperately seeking innovation. But let’s face it – the days of employees becoming millionaires on company stock are long gone for Google, Microsoft, and Yahoo. I knew I was too late to the stock party when I joined Google in 2005.

2. There is no legacy code at a startup, so fast and loose rules the day.

Agreed. Startups often pride themselves on how many nights and weekends went into the latest release. They also often don’t know exactly what code went into that latest release.

2b. As organizations mature, they add PROCESS to protect against human failures and past pain points.

Agreed, but this is a double-edged sword. Some startups pride themselves on having no process at all, because if you have no process then you have clearly avoided the evils of bureaucracy that live under the process banner.

Microsoft’s greatest enemy is itself. As a company that has succeeded despite decades of litigation and human error, Microsoft has accumulated so much process that an entire employment category spontaneously evolved to deal with it: PM! Program Manager, Product Manager, or Process Manager? You decide.

I’m pretty sure I fall into the category of senior developers Dare mentions as having an appreciation of the value of process. I definitely value dedicated testing, repeatable testing, and comparing results over time. The last time I saw all of these was at Borland in the mid 90’s. I haven’t seen them since, in all my wanderings. Others have commented on Google’s lack of testing discipline. I’ll just add that Microsoft’s corporate commitment to process that Dare mentions is no guarantee of quality either. Processes created out of pain exist primarily to protect the corporation more than anything else.

3. There is less politics at a startup.

True, but not for Dare’s reasons of consensus. Microsoft is all about consensus. For startups, though, it’s not that startups can reach consensus more easily than a larger company because they’re smaller / have fewer people to bring to consensus, it’s that startups don’t have to bother with consensus at all. Startups can often trace their creative energy back to one or two key people, key decision makers who make decisions, be they right or wrong. In some companies these thought leaders are on the management side, in others they’re on the engineering side with support from management.

Gary Whizin, R&D manager of the Turbo Pascal / Delphi team during Borland’s heyday, made it clear and simple: “We value your input, we need your input, but let’s be clear: this is not a democracy.” Gary didn’t make the decisions, and he wasn’t overly concerned with building consensus, but he did have the uncanny ability to get decisions made by the people who needed to make them. Many times “all” Gary had to do was lay out options A, B, and C that the expert had discussed earlier and say “Ok, now pick one.” They’d squirm, they’d protest, but more often than not a course would be plotted by the time Gary left that meeting.

Microsoft isn’t ideal either

We can pick apart Google’s peculiar hiring process all day, but that doesn’t mean Microsoft’s process is beyond reproach. Many people in the Delphi community were surprised I went to Google and not Microsoft as many Borlanders before me had. Why did I choose Google over Microsoft in 2005? Because Google made an offer, while Microsoft continued to drag its feet.

Microsoft’s recruitment system is highly segregated – plenty of inside recruiters, but none of them talk to each other. A recruiter is responsible for filling the job openings of a particular team. If a particular candidate isn’t a perfect match for that team, the recruiter doesn’t seem to have much incentive to shop that candidate around to other teams, or to inform the candidate of other possibilities. In six months of off and on conversations with Microsoft in 2005, I often found myself informing Microsoft of what other groups within the company were looking for!

The main obstacle between me and Microsoft was that I had (and continue to have) no interest in moving to Redmond. Microsoft is extremely Redmond-centric. Google is even more MountainView-centric. Both place a lot of emphasis on face time – in meetings, meetings, and more meetings. It is extremely difficult to break into either of these companies as a remote employee. You have to find a team that is motivated to work with you even across the remote chasm and a manager who knows how to manage remote staff effectively. That requires time and perseverance. In other companies, the notion of having a remote team member is less exotic, even commonplace. Chad Hower runs his whole software team as a network of remote workers! A truly distributed system.

Microsoft is gradually warming up to the idea of remote workers.  This is partly driven by the perpetual office space crunch in Redmond and the terrible traffic congestion in the whole Redmond / Seattle area.  More of the corporate internal apps work over remote VPN connections now (compared to a year ago), and the VPN itself is a thousand times better (more reliable) now running on Vista than it was a year ago on XP.

Dare’s blog post will undoubtedly stir up a lot of responses, both from the Google-can-do-no-wrong fan club and from Google employees who still drink the corporate Kool-Aid. I do find movements of individuals between projects or companies interesting news to follow.  Changing jobs is never an easy step to take, and often justified with emotions and reasons laced with disappointment or disillusionment with the old company and perhaps overly optimistic hopes for the new company.  Rarely do such movements of individuals have a significant impact on a well-run company.