This explains the blind allocation policy. If knowledge that is not At Google doesn't count, then there's no point in matching people with their expertise or interests, because a Noogler by definition doesn't know anything.
In July 2011, I did some research on the strategy of the Google+ Games team and saw that the going plan was doomed to failure and seriously risked such embarrassment as to kill the entire product. (Lots of Zyngarbage, preferential treatment to mainstream publishers.) I had some domain expertise from designing a game and spending a lot of time hanging around game designers. So it was pretty easy for me to come up with a strategy that had a damn good chance of actually succeeding. I posted it internally and got a huge amount of engineer support. The strategy was to establish a quality-centered community first by providing a platform for independent developers, integrate it with Hangouts, and become a center for the "German-style" board game sphere. The high quality starting community would establish G+ Games as cognitively upscale, creating a comparative brand advantage that would persist in perpetuity.
By the way, the Google+ Games engineers also got wind of what I'd been proposing and they supported me. It was as obvious as it can be to humans (obviously, no one can predict the future) that this strategy would work. I got a ridiculous number of emails from engineers telling me that I was right on and that they wished they were implementing "Real Games" instead of giving ridiculous preferential treatment to mainstream publishers (who were throwing us mediocre product because they didn't expect us to succeed). What got me in trouble was that a lot of high-level people didn't like that an FNG had so much engineer support.
I was a recognized domain expert, but not an At Google domain expert. There were no At Google games experts, because Google had never gone into the Games space before (and that's smart, because Google did extremely well on web search by being ideologically non-editorial, but for the games space quality is so damn important that you must be editorial.) So it came down to politics, because Google's At-Google bias rendered it incapable of recognizing domain expertise and discovering a correct decision.
Finally I got an email to the effect of, "domain expertise isn't relevant here, deal with it. Besides, you're only a SWE 3." Well, fuck you very much. I don't see why job titles matter when you're about to lose millions of dollars and would have been making as much had you listened to me.
A year later, I was proven right, but it doesn't matter in the least. Google+ Games is a non-concern, and I'm not a part of Google.
The lesson I learned from that ordeal is not to try to "save" a company from itself because you can't. You'll be seen as right, and possibly even lionized, long after you leave... but it won't matter in the least. Keep your head down, stay employed, and enjoy the middle-row seat to the show-- that "show" being the people in charge making fools of themselves.
I knew even from the beginning even 5-6 years earlier, when there was immense desperateness among geeks to work there. It was only a matter of time when all MegaCorp problems will eventually plague Google.
this is really interesting - what is the cause of all these problems?
Is it inherent in a hierarchical organization? Is it because you have people who are responsible for the output of others (a manager), but isn't able to actually control that output directly, but is only able to indirectly affect it (and not very well at that)?
I think this issue of "control" is central. Facebook and valve seems to have their structure right (at least, the engineering department). But both is still young and small.
Most companies move toward the closed-allocation end of the spectrum because they perceive a need to do so in executive recruiting. Most executives don't want to take a position where they won't have the power to unilaterally fire people.
A company must be able to fire people (I've been in ones that went down the drain because the founders were too nice to do this, or at least do it soon enough), but this sure sounds like Lord Acton's "Power corrupts, absolute power corrupts absolutely."
Agreed in most cases, but you once said that before:
If Google had been the hottest place in the world to work, and I'd been fresh out of university, then maybe.
People tend to misuse words like "expert" and "fluent" though, when they're really not, but on HN odds are higher that they're using at least "expert" correctly.
It's important for both sides to accomodate. But sometimes fits just don't work. If what someone wants to do isn't something you need, or if they aren't as good at it as the other people you have on staff, then the correct fix is just to part amiably. It's no more Google's "fault" than it is varelse's.
If you hire lots of, I don't know, compiler specialists but you allocate them to write web apps we're all possibly worse off. The issue is, and what you're not cottoning on to, is that in a company the size of Google there's probably a team working on x for all values of x that could maybe use another member.
They're only tolerant of their resource allocation scheme because they probably don't worry about their employee acquisition cost.
With a company the size of Google, it'd be really interesting to deregulate their internal labour market (i.e. what Valve does). Let people switch all the time! If you need to prioritize one boring, yet necessary team allocate higher salaries to it.
Speaking from direct experience, faced with the job of developing a framework for web data entry apps, what I ended up doing was writing a dataflow language for data binding. Another ex-Delphi compiler developer, Danny Thorpe, ended up co-creating Google Gears. IMO compiler development is a great basis for a certain kind of thinking about solving problems; but I'm also biased.
Actually, I was at a presentation today for new grad-students, and one of the older grad-student mentors helping to present mentioned that the coursework phase of grad-school is a good time to get a bit of industrial experience in the summers. Once I actually have real grad-level PL experience under my belt I'd quite like to go and see what it's all about.
EDIT: Sorry, did some research and assuming its this: http://en.wikipedia.org/wiki/Programming_language_theory
A company might want to hire an expert in Q because having expertise in Q means they are of a high skill level, and thus is able to also do D very well. D might be very mundane, boring or inconsequential from the point of view of the employee (and whether it is in reality as well is quite moot at this point).
THe employee might _want_ to do Q, but D is what makes the company money. Hiring someone who does D (but may not come up with novel solutions for D), or hiring someone who does Q very well, and assigning him/her to D in the hopes that they do a great job - which is better for the company?