It amazes me how someone thinks he can generalize something about a 15,000-person organization having worked with a tiny piece of it for a short time. I think the author should have stuck more to Sergei's tune, when he said: "I left because Microsoft turned out to be the right place for me".
Want promotions and management positions and fancy titles? Then a flat organizational structure is not for you.
Want exhaustive tests, project managers, and countless meetings? Then a "startup mentality" is not for you, either.
I also think that Dare is suffering from a bit of confirmation bias. Without mentioning the net exchange of people between Microsoft and Google, there is no way to gauge which company is "best" to work for. Dare only provides anecdotal evidence - "at least 8 people I know personally have rejoined".
Considering the possibility that most Microsofties have returned or will return to Microsoft is however still not proof that Microsoft is unconditionally better than Google (and vice-versa, if most ex-Microsofties stay at Google, we don't have unconditional proof that Google is better). Many Microsofties might have grown used to the MS environment and might - if only through force of habit - prefer the MS environment.
I'm not sure whether Dare wants to correct the perception that there is a debilitating exodus of people from MS to Google; I can understand such a motivation, since Yahoo's recent woes prove how a little bad news can cause massive demoralization. But still, I can't agree with his relaxed anecdotal method.
Google might still have a chance to do interesting things. Somehow they're managing to avoid adding huge amounts of "process" to building projects? They ship code fast?
Actually, Google does have one major challenge -- how to motivate its people. I'm not talking about fresh college graduates, but rather people who are high up in the organization because they happened to join early on. Many of these people are worth a lot of money, and presumably see day to day work at Google as a way to spend their time, socialize, and to flex their political muscle.
In such a place, bringing in new hungry blood is very difficult to do, especially since the old crowd will try very hard to protect their power structure. In the long term, this does cause problems in the ranks, since success within the company starts to become a measure of how well you can navigate politically, vs. the quality of work produced.
Since most of Google's applications are web-based, releases can happen just about any time and can happen frequently as well. This is not the same thing as shipping code fast -- the delta between any two consecutive releases might be quite small, much smaller than what a startup might do in the same period of time.
Speaking as a newly-minted ex-Googler myself, I can say that for some projects, development is not what anyone would consider "fast".
"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."
Sounds to me like he thinks Google is in need of some "process" (in fact, he specifically uses random breakage in Google apps to illustrate why this might be so).
I'm not saying he's right (wouldn't know, I've always worked for small companies where there was little need for a lot of "process") but the argument he puts forth is that everything at Google is not, in fact, going fine.
I've always been fascinated by and impressed with NASA's software methodologies, but they are neither cheap nor fast.
I'm not sure it's something to aspire to as much as one extreme on a continuum of code quality vs. code cost.
I would suggest that it would not be in Google's nor in most companies' interest to do anything like this. Where a company falls on this line depends on their organization's size, purpose, and business model.
So you think Google ships code fast? How do you know?
There are a lot of services Google tries to build that never see the light of day. And there are yet others that took a year or more to be released even as beta. There are some projects that seem to have gone from concept to launch in a few months, but I'd say those are usually the exception.
Also: there is a lot of necessary process that comes with launching a Google service. Version 0.1 for a startup can be buggy, embarassing, ugly, contain security bugs, or be non-scalable. In fact, you might go all the way to acquisition and still have all these problems. Pretty much anything on *.google.com has to be ready for Digg on day one.
I will say that there are many teams at Google that deliver quality, polished software faster than almost any other company. But that's more like winning marathons rather than sprints.
Not necessarily. Even pg will agree that a lot of the things that make a startup so productive and exciting fundamentally break when you have 15,000+ people.
I don't know if you meant it like this, but the original sense of "prove" was more like "test". That is, an apparent exception is a test of the rule's generality.
According to that wikipedia page, Nucor believes in decentralization and objective metrics, so they are indeed a good test of the rule. If that page is accurate, Nucor employees can't get very far on politics alone.
I think the focus on critical thinking in addition to an understanding of fundamentals is a quick way to find people who can learn any existing technologies. What one knows shows what they're interested in, but can they learn new things fast?
I do agree that a title of junior-developer for people who've been in the industry for a while seems silly.
Want promotions and management positions and fancy titles? Then a flat organizational structure is not for you.
Want exhaustive tests, project managers, and countless meetings? Then a "startup mentality" is not for you, either.