Hacker Newsnew | comments | show | ask | jobs | submit login
Running a software team at Google (matt-welsh.blogspot.com)
149 points by phenylene 784 days ago | 121 comments



This is a nice article giving an insight into how it is working for one of the most successful engineering companies of our time.

However, the OP comes from a strong academic background and Google is quite hand-in-glove with premier universities and research institutes. Hence he already has credibility inside of Google.

I however am told that it is quite an uphill task to join Google without an already established credibility and get to work with their core set of products. It'll be nice if someone could shed more light on this. I have always been very curious about how it is working at Google. I mean except a few, using Google products are such an everyday (everyhour?) thing for the average software engineer.

-----


What counts as already established credibility? I've worked in Search since joining 4 years ago; my experience is fairly similar to Matt's, certainly more like his than certain rather vocal personalities on Hacker News. I don't have a management role at all though I've occasionally served as a tech lead, and tend to prefer engineering or product-design roles.

I was about 3 years out of college when I joined Google. I'd spent 2 years as an employee at a financial software startup and a year founding my own company (which failed, but the postmortem is now the #1 Google result for [failed startup]). I'd also done some moderately impressive open-source/volunteer work: I'd worked on a website in college that grew to 100,000 registered users, I wrote one of the top Haskell tutorials on the web, and I ported Arc to Javascript. Nothing with a huge userbase, nothing terribly famous, but enough to demonstrate that I had solid technical chops.

-----


Thanks for sharing your story. That's established credibility right there. You already had stellar open-source contributions which are probably more credible than an ivy league degree.

I am currently in (a non-ivy) graduate school and should start focussing more on open-source involvement. Thanks! :-)

-----


I think that tactic will help quite a bit no matter where you might apply, not just Google (though I can confirm it almost always helps to be an active open source developer. It's consistently help us decide positively on a number of candidates.)

-----


>>I wrote one of the top Haskell tutorials on the web

Can you provide links to your tutorial?

-----


I guess it is "Write Yourself a Scheme in 48 Hours". I went through it and can tell that it is really a nice introduction to basic and some of the more advanced Haskell concepts.

https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...

-----


>However, the OP comes from a strong academic background and Google is quite hand-in-glove with premier universities and research institutes. Hence he already has credibility inside of Google.

I don't think it really works that way. Being associated with a top school helps a lot in getting an interview, but past that I don't think it helps with anything at all (if I'm wrong, please let me know, I am missing out :) ).

-----


The OP taught at a top school which is a much bigger deal than graduating from one.

-----


From my brief view on the inside, it certainly didn't feel like anyone cares what school you went to.

-----


Seconded, I have no idea where my colleagues went to University, and I don't really care either.

The only things that gets you credibility within Google in my experience is delivering good stuff and being helpful/knowledgeable in conversations with your peers.

-----


It does help getting an interview, but can also help tilt the balance in tight interview decisions. I presume it would be easier to make the case for folks with degrees from elite schools.

-----


Is that your actual experience on a Google hiring committee, or are you guessing (can't tell from your comment)?

-----


I would think it would also help in forging the right affiliations with influential alumni, especially in a large corporation. I'm only second guessing though, I didn't go to a top notch school and neither do I work in a large corporation like Google.

-----


> I however am told that it is quite an uphill task to join Google without an already established credibility and get to work with their core set of products.

I joined Google a little under three years ago. I dropped out of college, worked at a startup for a few years, then worked at EA for eight years. So, from Google's perspective I had essentially no cred when I started.

My current project (working on Dart) is basically my dream job and I work with a fantastic set of people. I've never once gotten the impression that my lack of education or relevant job experience was being held against me. Once I got in, I was a Googler. At that point, everyone just assumed I knew what I was doing or I wouldn't be here.

Aside from occasional bouts of imposter syndrome, it seems to work out pretty well.

-----


However, the OP comes from a strong academic background and Google is quite hand-in-glove with premier universities and research institutes. Hence he already has credibility inside of Google.

His academic background helped him. CS graduates and PhDs are a dime a dozen and neither is enough to make you a Real Googler, but the fact that he had 8+ years of research experience definitely gave him an inside track to the best projects.

I would guess he was hired at Senior SWE (which is respectable; unlike the title-inflated startups out there, it actually is fairly senior) or Staff SWE. The Real Googler Line is somewhere within those two tiers. It's not just about title, but location and project play a role. Most Staff are Real Googlers, some Senior are, SWE 2-3 are not unless they're hired as proteges (which is rare).

What's Google like? Well, if you're above the RGL, it's an excellent place to work. Even now, I'd recommend it. Being a Real Googler gives you free rein to transfer about the company. SWE 2-3 are considered a burden so transfer to a good project is very uncommon-- the first thing you'll be asked is why you didn't wait for Senior before transferring as you're "supposed to", but some projects make promotion impossible because there isn't enough visibility-- while Senior are considered about neutral (will add as much as he takes away in on-ramp time) and Staff are slightly favored.

At Sr. Staff and beyond, it actually gets rougher, if only because you can't fully participate in the Real Googler freedoms if you want to keep going. At Staff you should have full freedom of the castle (open allocation) unless you're in a terrible location; above it, you have less freedom if you want to keep getting promoted, because having taken on an important-but-undesirable (2nd Quadrant; see: http://michaelochurch.wordpress.com/2013/01/01/fourth-quadra... ) project is expected in the promotion packet.

I however am told that it is quite an uphill task to join Google without an already established credibility and get to work with their core set of products.

It depends. It's easier to get on Search at Google than to get on the top trading desk at a bank, but I actually hated that about Google. See, banks and trading desks are conservative and risk-averse and slow to promote, but they're fair about it. At Google, front doors have stopped working, but you'll still see a 26-year-old now and then who manages to politick his way into getting a real project. A Facebook offer helps with that. So it creates the impression that everyone is getting this back-channel advancement, but very few actually are. In fact, I think the only way to get fired at Google (advanced rank culture) is for your boss to catch wind that you're looking for transfer or back-channel mobility.

I used to admire Google, and I hate what the recent (post-2008, if it didn't start earlier) crop of terrible managers has done to it, but even now I'd say it's worth it to try the place out. There are good managers at Google and it's a pretty neat place if you get a good one. You can get on a good project as a SWE 3. It's rare, but it does happen. It helps if you're in Mt. View, if you have other offers, and if you have a good manager.

-----


The real story with big tech workplaces is that everyone wants to be in charge, everyone wants to establish credibility, no one wants to do the coding. I see this all the time. "I'm a part time coder" to me gets categorized with non-coder.

The fact is that from day one it's mental and political combat. Everyone is telling everyone else they are a "lead" or building a team, or whatever. Titles are meaningless as anyone can get their title changed to Sr tech lead or some acronym. If you are a software engineer and want to call yourself a lead manager all you have to do is blog about it and hope someone believes you. All that matters is what you know, what you can do, and can you manipulate perceptions enough to get credit for your own work. Having "influence" just means you've found some people that don't understand these thing yet or you got some dirt.

-----


> "everyone wants to be in charge, everyone wants to establish credibility, no one wants to do the coding"

Have you worked at Google? My observation has been that most people here do want to do the coding. Which is not to say that they don't want to be in charge and establish credibility as well, but the culture is much more biased towards engineering than at many other companies.

-----


Saying that you want to code while not coding is the oldest tactic in the book. I have been hearing 'gee, I wish I could code' since the 90's. Keep in mind I am talking about people who are hired specifically to create new software, one part of which is software construction. The trick is to maintain coder cred without revealing your true intentions or actually coding. The company doesn't matter. Maybe Google has more than most that are still trying to code, but I guarantee there are a ton of developers who are trying to maintain the appearance.

-----


This seems largely in contradiction with the original post, unless you're saying Matt isn't being truthful. He says he spends 50% time coding, which seems like a huge chunk of his time considering his "unofficial" title, definitely not a non-coder amount of time.

What you're describing sounds pretty terrible, is that based on personal experience with Google?

-----


The idea that you can be competitive developer with only a couple days of practice per week is not feasible. It's like being a pro athlete that only trains one day a week while telling the everyone you're a coach. They have the outward appearance of being a credible athlete while trying to gain the powers of a coach. When it's time to perform they are a coach. When it's time to celebrate the victory they're an athlete.

-----


Please do expound on that. What do you think is it that a coder needs to do every single day, and what do they gain from it?

Yes, there is some value to practice. But it's perfectly possible to code and manage, and still be a good coder. Once you have passed a certain threshold, you will find that most of the knowledge you need is ephemeral - no need to memorize yet another piece of info, just how to find it.

So it's not knowledge per se. The idea that you forget the basics of software engineering if you don't code every day is hopefully not what you're referring to, either - after a decade or two, those should be settled.

It can't be "typing speed" or "editor efficiency" either, because both of them only matter marginally. Most of your work as a software eng. is with your brain, not with your fingers.

-----


Skill matters and the most important skill is raw problem solving. Designing and typing in the code with tests and all is the easiest part of software development. The hard part are the insidious bugs and malfunctions. These take a HUGE amount of skill to solve effectively. If someone only writes code for a few hours a week they are not solving the hard technical problems. Why does the server deadlock? Why does the application sometimes crash after a click? Each one of these usually is a five hour problem. In a 40 hour week an average developer can solve eight of these if they do absolutely nothing else. The skill that is developed solving these issues cuts the problem solving down to maybe an hour and adds time that can be applied to coding, design, meetings, and everything else. Unskilled people are going to be stuck on the problem for weeks.

There was a recent kernel leap second bug that caused CPU usage to spike in certain applications. A part time coder is not going to have enough skill to even deduce that what they are seeing is this type of bug. They probably would not even know what the kernel is or what the code looks like. The usual reaction to showstopper challenges is to proclaim that there is just a really simple answer that should only take a few more minutes of effort to discover. In reality, for someone without the right skills, it is going to take weeks of full time effort to discover. Does a part time developer/manager go home on the weekend and read release notes and look at kernel code?

As far as raw coding, there are far too many tools and libraries in use to learn even within a full-time job. A modern large application will use several hundred packages (some use thousands). With only a few hours a week, a developer is only going to be able to learn what one or two of those packages do and their API. Looking up the API is not enough. If it can't be determined what the library does then it doesn't matter what the API says. The developer usually has to learn the internals and that takes lots of hours.

Contrary to what most people think, one cannot look up all the practices, idioms, and patterns used in programming. It's like saying a painter can just look up a technique in a book mid-painting. Can a surgeon sit in a surgery with an anatomy book open or a guide on cauterization? A developer has to have a very wide repertoire, not just for one language, but for 3-5 languages that are going to be used in a modern application. If you look up every bit of the thousands of pieces of information, nothing would ever get finished.

People who manage and code a few hours are usually being disingenuous, and I have worked with a couple. They do something very, very simple with one single component and use that as evidence that it's not really that difficult. For instance, make an form and then proclaim that web applications are easy because a form took 30 minutes to set up. The form, however, is microscopic in terms of the total effort needed to run an application or set of applications. They blow off entire requirements areas such as security or performance. Does the form have any security or performance requirements? Who cares, right? They're just part time developers, someone else will finish it. Part time devs are not even going to understand why performance or security are important. Most people that would be in the part time camp have less than two years of experience as a developer and are still in that formative early phase where the only requirement is 'does it work'.

Of course part time devs get to choose where to give up along the way. If the form is too hard maybe they add a few links or something and call it development. A full time developer does not have the luxury of picking and choosing tasks that are easiest. Part time developers simply try to redefine the meaning of 'good developer' to the point that they can reach their own weak standard and gain some developer credit.

-----


> everyone wants to be in charge

Seriously? When I was at Microsoft, it was like "hot potato" to have to give up a coveted dev role and take on dev lead responsibilities. In particular, being a first-level manager was treated as a sort of curse with all of the worst bits --- not enough time to still work on big things (e.g. as a manager, I too owned logging for a while), but not high enough in the org to justify being full-time on hiring, coordinating teams, and fighting for 0.9 offices / headcount instead of 0.75.

Which sounds dumb until you're on a team with 0.9 offices / headcount and you see the productivity soar, for reasons I never bothered to quantify (if free fruit on Friday => productivity, just buy the fruit; don't ask).

-----


What do you mean by 0.9 offices?

-----


By 0.9 offices / headcount I mean the ratio of space allocated to your team (number of physical offices) versus the number of people. The closer that is to one, the more people get their own, private office. At least when I was at Microsoft, private offices were about a 2nd year perk in good teams, and 3rd-5th year one in less profitable / high profile orgs.

I was sort of joking because that was "above my pay grade" - building and floor-level negotiations happen at the SVP->General Manager levels and down at the bottom we were mainly fighting for scraps or percentage of our allocation that was along windows vs. interiors.

-----


> everyone wants to establish credibility, no one wants to do the coding

In engineering-centric companies, coding is necessary for credibility.

-----


Where I come from, an engineering-centric company is like a waiter-centric restaurant - it just doesn't exist.

-----


Consider founding one. Heads you make a successful company which gets preferential access to the best local engineers because you don't suck to work for, tails you learn a new appreciation for all the non-coders in the business.

-----


The real story with big tech workplaces is that everyone wants to be in charge, everyone wants to establish credibility, no one wants to do the coding. I see this all the time. "I'm a part time coder" to me gets categorized with non-coder.

Insightful and mostly correct, but this is a false dichotomy.

There are a lot of people who want to write code and do the real work, but end up in the nonsense you described-- they spend 50+ percent of their time extorting their weaker peers (for credit and image enhancement) and slugging their equals-- because, as you said, they need to win on the credibility market before the company will trust them with real work.

Corporate software engineers are a defeated tribe who work for managers. The nightmare of being seriously underpaid while writing boring software with a boss who thinks he can do your job in half the time, even though he hasn't written a line of code in 10 years (or ever) and has forgotten (or never knew) how hard it is... well, that's the norm for most software engineers.

You're talking about the MacLeod Sociopaths (people who hack credibility markets and rape the system) and possibly the Clueless (middle-managers in the classic depiction; but most startups are Clueless even down to the bottom, because Losers get culled in tough cultures). But there are also the Technocrats (socially positive subset of the so-called, and misnamed, Sociopaths) who bludgeon the credibility market because they have to, but have a genuine desire to do the hard work-- writing code, clarifying ideas, creating. We're not all prima donnas.

-----


As a guy who has a genuine desire to work on actual software but is stuck in corporate hell while being underpaid, this rings too true for me. I spend more time gaming the bureaucratic system than I do actually coding.

The worst part is that in the country I am, software engineers don't get no respect. There's virtually no startup culture here. Companies like Google and Facebook don't hire software engineers here, as far as I know. Enterprise software is the only way to make any decent sort of living here, if you want to be programming.

-----


The worst part is that in the country I am, software engineers don't get no respect. There's virtually no startup culture here.

That's 90-plus percent of the U.S., too. The people you're talking to here are overwhelmingly concentrated in anomalous star cities (San Francisco, New York, Boston).

I grew up in Central PA. 100-200 years ago, Pennsylvania west of Harrisburg was Silicon Valley (that's why the South invaded) so a lot of smart, ambitious people come from western and central Pennsylvania (they don't stay, but that's another story) but there's certainly not the startup culture. Doctor, lawyer, professor, public servant (Harrisburg being the state capital) and small-business owner were the respectable careers. Computer programmers were seen as smart people who didn't have the social skills to get themselves out of grunt work. That's how computer programming is seen in most of the country. New York and Silicon Valley are different because good programmers can generate bidding wars for their talent whenever they want.

It's changing. In 2005, you had to choose between (a) living in a "star city" with hellish COL and suffering for 10+ years while you got established, or (b) having a second-tier career and being miles away from the exciting work. I don't think that dichotomy is as severe anymore. I'm in the job-search process (probably concluding in the next couple of days; I have offers but there are details to work out) and I've talked to people in TX, NC, and OR who are doing some really exciting stuff. Now that the Bay Area VC-istan scene's dominated by scene kids and social media, Real Technology (where 100% per year headcount growth is seen as irresponsible, because it requires lowering the hiring bar and becoming a trust-sparse, two-tier company that kills creativity) is moving out to places like Austin, Portland, and Madison where you can raise a family on a programmer's salary. I think that trend will continue.

This is what (I think) the future is going to look like: http://michaelochurch.wordpress.com/2013/03/26/gervais-macle... . That might happen in 5 years, or in 35... and in other countries, I haven't the faintest.

-----


If you end up in TX, I'd really like to pick your brain sometime.

-----


Sure. If you have questions, please email me at michael.o.church at gmail.

I have a general policy of not disclosing employers or personal clients to the Internet but one of my front-runners is in TX. I'd be working in NYC 75+ percent of the time, but probably visiting.

I'd prefer to stay in NYC because my wife's job is here, and I have yet to visit Austin but I've heard it's great. I spent a year in Madison, which is probably like a smaller Austin with opposite weather (mild summers, harsh winters).

-----


A general policy that doesn't apply to the employer that everyone has heard of, thus automatically giving you some kind of platform to speak from? :)

-----


I did not choose to release that information. Someone else did.

-----


Where are you? I would guess Japan, but they have a decent google job presence. It's a world market for good software talent, so you are high end and have flexibility where to live, there are plenty of ways out.

-----


Not Japan, that would be a step up. I'm in Malaysia.

-----


Got it! Well, you can always try China. We are always hiring here; salaries not as good as the states, but engineers are respected a bit more.

-----


Yeah, I see this all the time. The best people leaves, leaving only the politicians to fight amongst themselves. Then the company implodes, or becomes a Zombie like Microsoft.

-----


> It no longer comes down to making three grumpy program committee members happy with the font spacing in your paper submissions.

As anyone who has submitted a paper written in Word to a technical conference knows: bad kerning over two columns will set your paper back at least one letter grade. Must use Latex instead. (I'm sure he is just joking, but it comes up...)

-----


Honestly, every time I see a job market paper[1] written in Word I can't help but think, "this person must have never worked on anything (mathematically) hard, or needed to automate table generation, or..."

[1] on the off chance that the term is not widely known on HN, job applicants for academic positions (in Economics, at least) send a draft of an (almost always) unpublished paper as the main component of their job application.

-----


Anecdotally, I think you're wrong; I spent three years dealing with PhD people in Economics. All of them used Microsoft Word; none used Latex. Many of them were absolutely brilliant at maths.

Many of them were doing table generation using STATA and some scripting in MS Office.

I don't think it's a stretch to believe that people could be brilliant in maths, but not so great with computers.

-----


What generation were they? I'm thinking of recent PhDs and I know only one or two people working in technically difficult areas that don't use LaTeX. It's possible that Word's equation editor has improved a lot since I last used it, but typing up a proof is painful enough that it's going to force most people to LaTeX (or Scientific Word or Lyx, or some other frontend) pretty quickly, regardless of their computer literacy.

But I know that (for example) Hal White used a lot of Word and he's definitely brilliant at math. I appreciate your anecdote and will rethink my biases. (I do read these papers, though, and nothing's made me change my mind yet...)

-----


They were of mixed generations; most in their 30s, and a few older than that.

If I had to make a wild guess, I'd say it had to do with the fact that most of them were from Asia. My gut feeling is that Latex has a bigger following in the "western" world than the "eastern" one. Again, wild conjecture on my part; especially since I have not yet spent any time in an Asian country myself.

-----


This is probably true, though in China/computer science, we are seeing increased LaTeX usage. The problem is that LaTeX isn't that great of an experience for writing papers in Chinese, which doesn't have the kerning problems of western character sets anyways.

-----


Most importantly, my team's success is no longer defined through an arbitrary and often broken peer review process, which applies to pretty much everything that matters in the academic world.

Oh boy. Don't even get me started on broken processes. When managers can use secret calibration scores to blacklist reports and keep them captive for 5+ years on undesirable projects, what else should it be called exactly?

Matt Welsh was hired above the Real Googler Line, so he has a rosy-eyed view. He's also comparing it against the nightmare of post-PhD academic politics. He also seems, from his account, like a decent guy. He hasn't seen yet what Google turns into for young engineers who don't have external credibility yet, and who end up with managers who aren't decent people... It'd be interesting to read his opinion after he sees that.

If you're above the RGL (~10%) you have the credibility to represent your contribution to the company independently. Peer review gets you promotions, managers are a higher-ranking peer and can help you a little more, but you have enough independent credibility above the RGL that you can't be extorted. If you're below RGL, you have the extortive manager-as-SPOF nonsense of typical rank cultures, and you get none of the upsides of working at Google.

Also, I think the TLM concept is broken. The whole reason closed allocation is a fistful of fail is that, rather than resolving the conflict of interest between project leadership and people management (the best thing for a person might be to change projects) it tends to double down on that.

The only part of people management (aside from HR, at the company's interface) that has any value for 120+ IQers doing convex work is the mentoring aspect... which ought to be project-independent.

-----


I often wonder how someone who was only at Google for 5 months, and never went through the semiyearly review or transfer process could spout so much inaccurate BS about it.

If you are performing well and get poor calibration scores (which aren't secret), then that's something to bring up with HR and your manager's manager. The sad truth is that your poor calibration scores were an accurate reflection of your poor performance (I'll spare you the embarrassment of posting evidence of this). Your inability to transfer teams was a combination of that and the fact that it's almost impossible to transfer teams before you've spent at least 1.5 years on that team.

-----


Recruiters and enthusiastic long-time Googlers should stop claiming that it's easy to transfer teams, then. I was specifically told that it would be easy to leave the "starter project" if I didn't like it, and that all I would have to do would be to find another team willing to take me; in fact, I wouldn't even have to get my starting manager's approval to move, just the approval of the destination team's manager. When I tried to actually do this, it.... didn't work that way.

-----


I often wonder how someone who was only at Google for 5 months, and never went through the semiyearly review or transfer process could spout so much inaccurate BS about it.

Six, and I saw more of Google than most. I'll leave it at that.

If you are performing well and get poor calibration scores (which aren't secret)

You get a range for your calibration score. Whether your manager tells you the specific number is up to him, and you have no way of knowing whether he's telling the truth. Most Googlers will get Meets Expectations (3.0-3.4) which ranges from the 2nd to 70th percentile. For most, it means "solidly OK, but not yet promotable". 3.5-3.9 is Exceeds (70th-95th percentile) and means "on track for promotion" and 4.0+ is Strongly Exceeds (95+) which means "promotable". Almost never are numbers below 3.0 or above 4.5 used, because sub-3.0 requires PIP/termination proceedings (which are a lot of work for the manager) and 4.5+ makes an employee eligible very large cash bonuses (and, occasionally, double-promotes).

If your manager gives you 3.0's but positive verbal feedback, you'll think you're getting 3.3-3.4 (which is perfectly respectable) but you won't be able to transfer. Except for the first quarter, 3.0 means, "you suck but I'm too busy to deal with the PIP/termination process"; 2.x requires the manager to do a bunch of extra work so 3.0 is understood as the "he's awful but I don't feel like doing anything about it" score.

However, there are managers who give positive verbal feedback and 3.0-3.1 ratings to keep good people captive. You didn't see what I saw. I have data but I'm not allowed to share it because I'm not supposed to have a lot of that stuff myself. It's not most managers who do that shit, but it's a sizable contingent and executives are aware of the problem. They don't do anything about it, in my opinion, because they're afraid that it would sacrifice project expediencies to reduce managerial power.

then that's something to bring up with HR and your manager's manager.

Try this out. In any company. Please, I encourage you to do it. You sound like just a wonderful person and I'd love to see you take a crack at it.

Nah... I'll tell you what happens, not because I give a shit about you, but because other people are reading.

If you go to HR, you get fired. Not "officially terminated" because the company doesn't want the lawsuit risk, but HR and your manager will make it look like (a) no one else in the company wanted you so (b) they can PIP and eventually terminate you. You won't be able to transfer because "you have to solve the problem where you are before you move on" and because there will be feces smeared across your personnel file. This known in HR-speak as "passive firing". With passive firing, the employee is technically permitted transfer but it is made impossible. It's a way to give managers unilateral termination without the lawsuit risk.

If you go to your boss^2, you are similarly fucked, because your boss^2 picked your boss, idiot. Who do you think he'll side with? If you seriously think that a boss^2 is going to take the side of an underling, then please, try to make it happen the next time you are checkmated. If you have a shitty boss, your boss^2 knows and is tolerating him because it's expedient, if wrong.

If you want to jump your boss, you have to go to the boss^3 or higher, and the probability of that working is low because the social distance and credibility gap is high. But you have much better odds with a boss^3 than a boss^2. The boss^2 will tip off your boss and you are fucked; the boss^3 will just say, "Who are you?", and tell you to get back to work.

it's almost impossible to transfer teams before you've spent at least 1.5 years on that team.

At least you admit to that problem. Yes, that is correct.

-----


> You get a range for your calibration score. Whether your manager tells you the specific number is up to him, and you have no way of knowing whether he's telling the truth.

No, the calibration score can be displayed in the internal performance tool based on a manager's preference. And if it's not and you believe your manager is lying to you about your specific score, I'm sure he'd be happy to get you to STFU (hard, I know) by showing it to you directly. Regardless, as long as one is "Meets Expectations" or higher, they will have no issue transferring teams after their 1.5 years of service to their current team. Your problem was that you were both new to the team and were performing at the level below "Meets Exceptations".

> If you go to HR, you get fired ...

More bullshit about Google from someone who has no clue. I (and plenty of people I've worked with, including those that have successfully gone through a PIP) have had very pleasant experiences with HR and their boss^2.

> At least you admit to that problem. Yes, that is correct.

I don't believe requiring someone to stay on a team for 1.5 years before transferring is a problem. The honest truth is that no team wanted you, because if they did, there would have been an exception made.

We get it, you had a horrible time at Google, performed incredibly poorly, and continue to blame others/the system for your issues. Even worse, your attempt to garner sympathy and support from other Googlers didn't work out as your illusions of grandeur would have suggested. Now you continue to jump at any opportunity to smear Google as if getting agreement from people who've never worked there will somehow make it all better.

-----


Dear Googler123. Telling someone STFU is not nice, in any universe, not even HN. Also, it is quite inappropriate, and may be illegal as well as unethical, to discuss a person's performance while at a company.

The real culprit is Google, no matter what. See https://news.ycombinator.com/item?id=5296146 for my take on management's responsibility for what happens in a company.

Does Michael have a beef? Yes he does. Does Michael have a right to express himself, give his opinion publicly? Yes he does. If Google is the subject of his smears, Google only has Google to blame.

-----


He is not saying Michael to STFU, he is telling him that if he had accused his manager of lying in the face, he would have been shown what the scores were just so that he would 'STFU'.

-----


Yes, that's literally correct. But I read it as him also implicitly telling Michael to STFU. Interpretations can differ, but that's part of the point: one can be unambiguous by not writing 'STFU' anywhere in the message and since not being unambiguous is a choice....

-----


He's not? It sounded a lot like he was telling him exactly that.

-----


> And if it's not and you believe your manager is lying to you about your specific score, I'm sure he'd be happy to get you to STFU (hard, I know) by showing it to you directly.

It seems entirely unambiguous that he's saying "You can get your manager to show you your scores by making enough of a fuss that your manager will do it just to make you STFU".

-----


Read the whole post as a unit, and realize he's telling him to STFU. He's also hiding behind this man's manager. He assumes the manager would also tell him to STFU, when in fact the manager would probably not have done that. In fact, the manager didn't do that.

The manager may have wanted to do that, although that is purely conjectures, but the manager didn't, perhaps because it's against company policy, but also perhaps because his manager didn't want to go all out on Michael, perhaps realizing that the faults in the matter might not have all been on Michael's side.

So, then, I think Googler123 is telling Michael to STFU not by telling him directly, but by putting words in his manager's mouth, which is I think even worse, because not only is this denigrating to Michael, but also to his former manager, who may still be a Google employee.

Makes sense?

-----


Telling Google to "Choke on a fucking taint, Google. Choke. On. A. Taint." [1] is also not nice, in any universe, not even HN. Not that two wrongs make a right, but I don't agree with your read on the "STFU" line. I think Googler123 meant it conversationally and casually, not like a not-nice direct challenge to Michael like you read it.

Your argument about management is flawed: a company is made up of people, who ALL have to act the way they want employees to act, and expect the same out of each other. Michael absolutely has a right to express himself, and since he was a Google employee, he had the duty at that time to try to make it the best place in the world to work. That he didn't even confront his manager about his real number doesn't speak well to his willingness to try to improve the place. Especially since he had a safety net job offer. What was his risk?

[1] https://news.ycombinator.com/item?id=5508058

-----


  > Telling Google to "Choke on a fucking taint, Google. Choke. On. A. Taint." [1] is also not nice, in any universe, not even HN.
Maybe this is just me, but I think hyperbolically telling a for profit corporation to stuff it (e.g. screw AT&T), is far more socially (normatively) acceptable than making a personal attack against an individual.

Neither are _nice_, clearly.

-----


It's not just a for profit corporation, it's his former employer.

-----


So? Why does that detail matter?

In my first digs at Google I specifically avoided exposing any relationship (it was exposed by an HN commenter, to deflect). All I said was that there was mismanagement at a level approaching the criminal (which is true) and I gave a couple details (accidentally leaking calibration scores-- I thought that had been common knowledge-- and the death of 20% time).

Neither of these are confidential. How a company treats its employees is (with lots of legal precedent) covered under whistleblower protections-- not a trade secret. Therefore, the existence of any employment relationship is irrelevant.

If I leaked a product, I'd be unethical and deserve to be sued. Exposing the existence of calibration scores is fair game.

-----


You're completely ignoring the context of our conversation:

"Choke on a fucking taint, Google. Choke. On. A. Taint."

It is not okay to say that about your former employer. In any context.

If you think it is okay to say that about your former employer, there's something wrong with you. I certainly would never want to work with you.

-----


Google never treated me with any loyalty. What do I owe them? Nothing, as far as I can see it, as long as I don't do anything unethical. (Exposing bad practices and using rude language aren't unethical.)

Still, you're right in a way. Google is 55,000 people and I have no problem with 54.9+ thousand of them. In fact, that company often makes great products because, in spite of the executive malignancy, they have some top-notch engineering talent under their roof.

I shouldn't have said, "Choke on a taint, Google". I should have said, "Choke on a taint; parasitic, psychopathic, incompetent and entitled executive caste that implemented closed allocation at a once-great company, developed a mean-spirited, Kafkaesque 'calibration score' system worse than Enron's, and has destroyed billions of dollars of value."

Sorry, but the people who played a direct role in the managerial destruction (e.g. calibration scores) of Google are human garbage. They took what used to be a great company and destroyed it, and for no good reason. They deserve much more than I have thrown at them.

-----


It's not because of LOYALTY that you're supposed to avoid telling your former employer to not "choke on a taint."

It's because it makes YOU look bad.

Can I ask a question? You keep complaining about closed allocation. What EXACTLY would you want them to have, instead? And I don't mean just say "open," say specifically what you mean, how you think it would work in practice. At a company with 55,000 employees.

Also, you're putting way too much emphasis on calibration scores. Companies record what managers think of their employees. How ELSE would you want a company to do it?

-----


It's because it makes YOU look bad.

After Google, I worked for a company with the most unethical management I've ever encountered. True evil. (Calibration scores are just criminal stupidity; not the same class.) Also, that company is notorious in NYC for having unethical management. Furthermore, I was there for 3 months... after a 6-month period at Google. Now that is a blotch on my CV.

I'm done worrying about cosmetic shit. I already fail on that front. Too much substance, and it's too visible by now.

I also don't buy into the "never make an employer look bad". If you're there for 2+ years, then I agree and would say that the rule applies, even if you were laid off or had a crappy manager at the end, because there's nothing embarrassing about a 2-year stint. If you are at a company for less than 12 months, either you or they like horrible. Make it them by airing enough to prove them the bad guys. (Then you still look bad, but not horrible, because you show it to be their fault.)

Can I ask a question? You keep complaining about closed allocation. What EXACTLY would you want them to have, instead? And I don't mean just say "open," say specifically what you mean, how you think it would work in practice. At a company with 55,000 employees.

Actually, being large makes it much easier to afford open allocation. If you're small, you often have real technical deadlines that put the business at risk, so full-on open allocation isn't always possible.

If you're at Google's size, your moral responsibility to your engineers is open allocation, because you can afford it. It's the 20-person companies that have deadlines and clients that have good reasons not to do full open allocation.

So, that's easy, at least for the engineering organization. That's where you start, and you branch out from there as you build a knowledge base.

Companies record what managers think of their employees. How ELSE would you want a company to do it?

Well... for starters, take that garbage out of the transfer packet.

Does this seem radical? Actually, the law is on my side, here. Until about 1995, most companies didn't have performance reviews in the transfer packet. At all. Those were separate and only came out when someone actually needed to be fired. Enron changed that. It was Enron that made stylish the "innovation" of making performance reviews part of the transfer packet, and Google is carrying the torch.

A manager who interferes with internal mobility is guilty of harassment (plenty of legal precedent here) because internal mobility is considered part of a worker's job performance, and interference with job performance is...? Well, it's one of the most common subcategories of workplace harassment. Ergo, a manager who communicates anything negative about an employee (except a breach of law or professional ethics) is guilty of harassment and can be charged.

That's why the calibration scores and manager-level-only feedback are secret. It's to allow Google (or, more specifically, managers) to break the fucking law.

Yes, companies need to fire severe underperformers, unethical people, and law-breakers. That's true. Performance review for mutual benefit also has some value. Creating a system where performance reviews are part of the transfer process is, while not technically outlawed, essentially giving managers the right to break the law.

When I say that closed-allocation management in the Google/Enron-style company is often extortion, I'm not exaggerating. It's technically civil rather than criminal extortion, but now we're getting into details.

-----


"Make it them by airing enough to prove them the bad guys."

I don't believe I know anyone who would see it your way. This is like complaining about your ex-girlfriends on match.com, it's self-defeating in a way that just makes me feel bad for you that you think it will be effective and help you achieve your own goals. It won't. And I honestly think that if you found someone who it DID convince, that they're not a good person to work for, and that will become apparent in time.

Back to my question - You talk a lot for not actually answering my question:

How do you think open allocation would work in practice. Lay it out for me like I'm 5 years old. It would also be to your benefit, if you could point to companies, of roughly equal size, that do it the way you want Google to.

Everyone in a company evaluates actual worker performance. Yes, it's possible to game that system maliciously, and that would probably be harassment. But it's perfectly reasonable to communicate performance evaluations when considering any promotion, increased responsibility, or transfer to another team.

-----


That he didn't even confront his manager about his real number doesn't speak well to his willingness to try to improve the place.

I don't know where people get this idea. There's a lot of story and I haven't told most of it.

My boss promised a 3.4, then gave me something lower (probably 3.0-3.1). When I confronted him, he said it was because Google+ out in California wanted me to suffer for criticizing a product (that later failed, as I predicted). So I asked him to put a note on the HR file noting that the ding was political and not related to performance. I didn't care what the score was (the difference in bonus between 3.0 and 3.4 is minor) but I wanted the record to show what had happened, and an agreement on 3.4+ for the next 4 quarters to compensate for throwing me under the bus. That's all I wanted, and it's a small, reasonable, request. Everyone knows that "performance" reviews are about politics anyway, so I have no qualms about using one as a negotiation token. It's a game, so play it.

In response to my request, he went and revised my calibration score downward. He also made speculations about health problems (I have very-high-functioning hypergraphia, which is often a symptom of something else but in my case it's just standalone hypergraphia) that were irrelevant to work performance-- just to label me. I was in the process of deciding whether (a) to get attorneys on the case-- most attorneys don't want to appeal performance reviews because there's no money in it-- (b) to offer a side bribe to someone with performance DB access, or (c) to just get another job. The winner was (c); (a) and (b) meant $10k+ for something that might not work and would only pay itself off if I were there for 5+ years.

Also, HR investigated and found out there was no ding from California. Completely made up.

So, I dug around and found out that a mysterious departure of someone (a serious CS heavyweight) who had this same manager was a case of outright bullying that had gone on between approximately Oct. 2010 and July 2011. More digging found a pattern; this particular manager had a pattern of lying. In one case, he was actually reported to HR for repeatedly (and probably intentionally, though he denied it) using last-minute 1:1 reschedulings to conflict with someone's therapy. That was before I came to Google. Predictably, HR did nothing that time, too.

This was a manager who had a years-long history of bad behavior, especially toward people with (otherwise manageable) health problems. It wasn't even hard for me to piece together the story, because so many people knew that it was going on. If he didn't see you as vulnerable, he was very affable and supportive, but if he smelled blood, he attacked. He actually admitted, in one proceeding, that he enjoyed "testing" an employee with panic disorder to find triggers. In my case, I'm fairly normal but I do have hypergraphia and can tell a decade-long story (with increasingly high levels of function; from 2002-09 I had a serious trolling problem, now I focus on writing coherent and useful stuff) about that.

I don't blow whistles over small shit. This was a big fucking rat.

When Google stops allowing Evil, I will stop attacking it.

-----


It sounds more like you had a bad manager rather than Google is a bad company.

-----


"I don't know where people get this idea."

They get the idea that you didn't confront your manager about your real number because:

1) You've repeatedly told us that you don't know what your real number is.

2) Googler123 has made the declarative statement that your manager could have easily shown you the real number in the internal perf tool.

3) You haven't contradicted Googler123 that it's not true.

4) You haven't told us, "I confronted my manager about showing me my real number in the internal perf tool."

From that, we're quite correct in concluding you didn't confront your manager about showing you your real number in the internal perf tool.

I'm sorry you had a lousy manager.

If there's something wrong with your manager, you're supposed to go to HR and you're supposed to go to your boss^2. In any company. It actually sounds like that's what you did, so why are you telling us all that the outcome is guaranteed to be "fired" or "similarly fucked", "In any company." ???

No, in the company I want to work at, if I have a lousy manager, I'm going to talk to HR and my boss^2. That's what I expect from myself, and that's what I expect from you. It even sounds like you did it - so why are you telling us not to?

Google is a company made up of people. Some of them have even bothered to respond to you in this thread. And yet, you're telling them NOT to do what people SHOULD do.

How exactly is ANY company supposed to get better over time, if the employees aren't brave and do what's right, even if it might have consequences for them?

Or should they just quit, and then take every opportunity to smear the company on websites?

-----


Seriously, you make good counterpoints, but the adhoms are not called for. Not cool.

-----


Dear Cowardly Anonymous FAL-Dude,

Name yourself or stop with the ad hominem attacks. Thanks.

You know nothing about my situation, nor why I left Google. Please stop speculating. Even I never found out what calibration score I got. My manager promised a 3.4, gave something lower (his boss confirmed) and it was being appealed at the time I left. Call it -6.2 for all I care.

I was in the process of internal transfer and it was going alright; however, I got an offer from another company and left. I figured that a clean start would be better than an HR file that, while it wouldn't affect me in the short term, would have long-term implications come promo time and that it'd take months of grueling, bureaucratic effort (some of dubious ethical character) for me to fix.

It was like this: Option A is that I transfer, stay at Google, but may have an early-term smear of my Perf history and might have to cut bribes to people with HR database access in a few years when I rise to a level where even early, cosmetic, irrelevant stuff counts. Option B is that I get another job. Option A is unethical and unlikely to work. Option B is much easier. So I chose B.

Some time after I left, Google did something about a few horrible managers on the issues that I'd raised, but I don't know how much progress they've made and it makes no damn difference to me at this point.

-----


> It was like this: Option A is that I transfer, stay at Google, but may have an early-term smear of my Perf history and might have to cut bribes to people with HR database access in a few years when I rise to a level where even early, cosmetic, irrelevant stuff counts

Sorry but that's complete and utter crap.

If you had transferred to another group and consistently performed well no promo committee would have cared about what happened in your first few months. If anything they would have looked at it and thought something along the lines of "well he had a rough first few months, but since then he's been kicking butt. Either his first team was a bad fit, or he learned and grew since then."

Promo committees (and hiring committees for that matter) have to sort through conflicting feedback all of the time. When you're on a promo/hiring committee you are constantly "reading through" the feedback to look for patterns and trends, and trying to build a broader context to help interpret any outliers. A bad patch early on wouldn't have mattered, as long as your trajectory afterwards was positive.

Many (very) senior developers offered to sit down and talk with you privately. I'm sure if you had taken them up on their offers they would have said the same thing. There is nothing that happened in your months here that couldn't have been fixed by transferring to a group that was a better fit and focusing more on producing great software than on posting to the internal mailing lists.

-----


BTW, piaw has several blog articles about problems with performance review committees: http://piaw.blogspot.ca/2010/04/promotion-systems.html

-----


"stop with the ad hominem attacks"

Michael, you're complaining about rude attacks the day after you wrote "Choke on a fucking taint, Google. Choke. On. A. Taint" at https://news.ycombinator.com/item?id=5508058 ?

-----


Rude != ad hominem. Different categories altogether.

Ad hominem attacks usually involve asymmetry of public identity and often place a target between two undesirable options: (a) letting the attacks stand, or (b) further exposing information that's irrelevant to the discussion and possibly compromising, especially with the persistence of the Internet.

I am fine with rudeness. In fact, in many circumstances, I encourage it.

-----


You understand that pretty much any Googler who wishes to defend their employer's practices against you is placed in the same position? I don't like the personal attacks that are made against you either, but you have to realize that how you see your experience at Google is different from how many people who were there at the time see your experience at Google, and that every time you make some assertion about how things work that, well, isn't exactly how we would've analyzed the situation, we're forced to choose between (a) letting the attacks stand or (b) airing dirty laundry.

-----


Maybe it isn't so clear, but I thought it's been clear that I acknowledge the wide variety of Google experiences. Some people have good ones, and that's great.

If I said, "Google is a hellhole and you'll hate your life", then I'd be a liar because some people get great managers and the best projects and Google is really awesome for them.

What I do intend to say is that Google's HR infrastructure and upper management (at least on the people-management front) are irresponsibly bad at their jobs. That usually won't affect you if you have a string of good managers. If you land in the wrong spot, though, look out because there won't be any competent to fix the problem.

Google has a lot of ways it could become a great company again (open allocation) but for now, I'm going to come out and continue to say that their upper management (again, at least on people management) is disastrously bad and they are singularly responsible for ruining what used to be and still could be a great company.

I'm sorry, but I'm not going to let these assholes destroy billions of dollars in value and get away with it.

-----


> I am fine with rudeness. In fact, in many circumstances, I encourage it.

It'd be really nice if HN was not one of those circumstances.

-----


I don't support rudeness for its own sake, but there are some circumstances that call for impoliteness and abrasive questioning.

-----


Any one with work experience and common sense can tell that talking to boss^2 and HR is a recipe for disaster. You are also unwilling to challenge michael's claim that he was meeting expectations and in the midst of a transfer. You also think restricting transfers for 1.5 years is not a problem. Is there any problem within Google that you are willing to admit?

You sound like an HR drone tasked with attacking michael's record with false data. You haven't responded to his claim that his record met expectations. Unless you use a real identity, your claims will have no credibility.

-----


I have work experience and common sense, and I've had success talking to boss^2 and HR.

You get out of life what you put into it. Also, at some point, you have to be willing to take the risk that things won't go well. What's the worst thing they can do? Fire you? Michael was already thinking about leaving anyway.

At some level, you just have to ACT like the company you work for is the company you WANT to work for - and if they don't see it the same way, no hard feelings.

If Google was the company he wanted to work for, and he and his manager didn't get along, what SHOULD he do? Stand up for yourself. Don't quit for the sake of your "permanent record." If there's more to it, then that's fine - but if that's your reason for quitting...?

It's a company, and you have a job. If your manager sucks, say something about it. If that doesn't work, vote with your feet.

Talk to boss^2 and HR.

-----


Is anyone saying that "Talk to boss^2 and HR" will never work, or just that it's very unlikely to work?

I too have work experience, but perhaps not common sense when it comes to dealing with people, and I never got anything accomplished by talking to boss^2, who as Church noted was more invested in their choice of hiring your boss than in you the underling, and indeed then voted with my feet.

-----


Yes, I think Michael is saying it will never work.

Michael: "If you go to HR, you get fired." "If you go to your boss^2, you are similarly fucked..."

I think that's terrible advice.

I'm sorry you had to vote with your feet, but I'm glad that you did. The only way boss^2 or HR have a chance to learn is if employees do what they're supposed to, and Michael is actively telling people to not do what they're supposed to.

-----


    *it's almost impossible to transfer teams before you've spent at least 1.5 years on that team.*

    At least you admit to that problem. Yes, that is correct.
Actually, I've seen two people transfer teams in their first couple of months because they were unhappy with their job, and it was not a big deal at all (find potential new job, talk to new team, talk to manager, notify HR, done).

I think the 1.5 years is the time you're expected to stay on a project because below that you might end up being more effort than gain to the team, but as long as you don't make a habit out of job hopping across the company, it's not an issue.

-----


That's what they told me it would be like when I interviewed at Google, but that's not what actually happened. I believe that it does work that way for some people, but the system is not transparent; it did not work for me and I don't believe that my manager or Google HR were ever being completely straight with me about what was going on.

Perhaps there is some narrow, undocumented window during which you can do this kind of transfer, and I unknowingly passed it? It did take me about three months to understand what was going on well enough to realize just how much I hated the project I'd been assigned, another month to figure out where I wanted to go and to talk things over with the team I wanted to join, and another month for them to deal with some headcount freeze and some apparently-brand-new interdepartmental transfer process (!?). By that time the manager who'd hired me had moved on to something else, and the team was run by some guy in another city who was clearly overextended. When I told him I wanted out, there was no "sorry the starter project didn't work out, enjoy your new team"; instead it was "what the hell do you think you're doing" and a PEP, blocking the transfer.

-----


If there was a PIP involved, you were likely not meeting expectations, and either the new team didn't want the liability, or the transfer was killed by HR to prevent under performers from avoiding a PEP by continually transferring to a new team. It's OK to hate your project but it's not OK to underperform.

-----


The problem is the measure of "performance". Some companies including Google do it via a central committee, but that has it's own problems.

-----


If there was a PIP involved, you were likely not meeting expectations

Or, his boss was resentful of his desire to transfer and, because each manager has a limited number of "review points" (that's how Enron/Google-style performance review systems work; the forced curve means that a manager's generosity in reviews is limited by his credibility) he was thrown under the bus. That's much more likely.

This is called the Welch Effect. "Underperformers" tend to be average-performing, junior members of underperforming teams (who had the least to do with the team's underperformance). The reason is that that the manager (who is also desperate, but in slow motion) doesn't have many "calibration" points to give out and tends to focus everything he has on senior people who are likely to stay because, without superior review scores, they'll flee.

Credible, less desperate, managers look out for all their reports. The ones who are on the bubble tend to scapegoat one every year, and spend all their review points on the senior people who hold the project together in spite of mismanagement.

the transfer was killed by HR to prevent under performers from avoiding a PEP by continually transferring to a new team.

Then the people in HR who blocked the transfer should be fired in disgrace because they're mean-spirited pieces of garbage and it's irresponsible to let them make decisions that affect other people.

It's OK to hate your project but it's not OK to underperform.

Do you know how disgustingly self-righteous you sound? You know nothing about the guy and you're telling him that he's "not OK".

If you actually think more than 10% of people labelled as "low performers" in any company are real problem employees, then you're either (a) under 23, or (b) fucking stupid. Management uses "low performer" labels to brush away its own failures and messes. Most problem employees and true low performers never get caught, and that's why companies tend toward mediocrity and failure over time.

-----


You spin a good yarn, and maybe your theories do apply to someone, somewhere (and maybe to yourself, possibly only in your own head, as your ego attempts to reconcile congnitive dissonance), but in my own observations at Google, I have not found this alternative reality to match reality, ever, so I must conclude your explanation highly improbable. I think Occam's Razor would agree with me.

As an aside, I have found a large number of underperformers in every organization past a certain size. The reason is that hiring is inherently hard, and once employees have exhausted their immediate social circles, it is extremely error prone.

I've found that effectively weeding out non performers, who are inevitably hired, is one hallmark of a healthy organization. As mostly hire As but B players mostly hire Cs, and Cs put you out of business. This goes double for managers (who, incidentally, are continuously rated by their reports at Google).

-----


I agree with you insofar as companies ultimately have to get rid of people who've ceased to contribute (or never were).

The problem is that "low performer" witch hunts rarely do anything about the actual problem employees. If you don't know that, you either have worked for less than 2 months in total, or you're completely fucking clueless. The true problem employees, who have a lifetime worth of experience at hiding their toxicity, stay. It's people who get unlucky (who don't have a whole career of underperformance to inform their strategies) that are swept out.

I'd rather companies just have an honest layoff, the way Wall Street does it. Layoffs have the Welch Effect, but that's not as bad as a system that actively selects for toxicity.

See, here's the impact distribution, where 1.0 is the average employee contribution:

    'A' players :  1.5 to inf
    'B+' players:  0.7 to 1.49
    'B' players :  0.3 to 0.69
    'C' players : -0.2 to 0.29
    'D' players : -2.5 to -0.2
    'F' players : -inf to -2.5
Okay, so the As and B+'s are usually fine (unless they are pre-emptively attacked by competing co-workers). B's are vulnerable and beholden to their bosses when a witch-hunt starts, but there's no good reason to fire them. C's need to shape up; those are the ones you need to improve or get rid of. D's and F's should probably be fired yesterday. It's too costly to keep them around.

It tends to be the B and C players (who could turn into A's, with better projects) who get smacked in a low-performer witch hunt. D's usually survive, and F's become managers in tough-culture systems because they tend to be the ones with severely toxic personalities who love the power.

-----


Interesting--can you elaborate as to how a Google engineer could subvert peer review and the revision control history?

-----


Official policy (when I was there) is 18 month minimum before you can transfer. There can be exceptions, but they are exceptions.

About 3 months in, I talked to my manager about transferring off a project I disliked. His response a month later, which I believe came from the site director, was literally "We don't care."

Which is fine, I just think it's important to know that Google is not generally flexible about initial allocation, and you will generally be expected to stay on your first project for 1.5 years--regardless of how you feel about it. And you may not know what your first project will be until after you're hired, or even after orientation.

-----


I've seen plenty of instances of the same thing - new hires where it was clear he team wasn't a good fit. They had an adult conversation with the current manager and did their best to be productive until they found a team that was a better fit and transferred.

No drama and no hard feelings.

-----


Google depends a lot on your manager. If you have a good manager, then it's still the Old Google and the company is still open to you. With a good manager, you can transfer as you wish, and as long as you don't have a complete don't-give-a-shit attitude toward your assigned project, you're OK no matter how things play.

I'll be the first to say that there are good managers at Google. However, the major reason why people work for large companies is to be protected from the event of a bad manager. Startups fire same-day. Large companies offer transfer for the no-fault "fit" cases. Google does not extend such protection, which means it lacks the one upside of a large company.

That's why I always tell people that if they get a chance to work for Google, they should give it a shot. Nonetheless, their HR infrastructure and executives have failed to do their jobs; that much is clear. The matter of whether that will affect a specific individual is unpredictable.

-----


I'm sympathetic, although your concern about transferring teams in a short timeframe might be misconstrued. I was hired to lead a certain project. If I tried to transfer to a different project shortly after being hired, that would be considered rude.

When I hire someone, I hire them to work on my project. If they immediately transfer, or get sniped by another project, that's a little rude. As a result, the general tone is that you "pay your dues" on the project you are hired on before you start thinking about transferring. I think a year and a half to two years is a good amount of time.

We're a cooperative, non-competitive development environment, so I can imagine that what is a "little rude" in our environment could be interpreted as highly aggressive in a more competitive environment like Google.

-----


When I hire someone, I hire them to work on my project.

Google is different, because employees are hired on a whole-company basis, which I think is the right policy. It means there's a uniform hiring bar, instead of the typical big-company dynamic where hiring standards are relaxed to fill less desirable projects.

I agree with you that, in the typical company where one's immediate manager had to fight to make a slot/get budget, leaving at < 12 months is (with some exceptions) a bad behavior. I don't like the concept of "paying dues" but I think that returning the favor is appropriate.

-----


I think you have to be careful with the whole-company hire business.

It's important to note that not everyone will be able to do every job well, and some people will not be able to do some jobs at all. So while it is important that their ethics, personal drive to learn, and cooperation skills be top-notch, one has to be careful not to try to hire expert generalists, because one ends up with people who are neither true experts nor true generalists.

I think in Google's case, and I speak from an outsider's point of view, that Google tends to try to hire the experts at the expense of the generalists. Generalists, while less technically adept at any one task as experts (I was thinking of using the term specialist there), many times have more experience with communication, managing changes, and, hum, diplomacy.

Again, from the outside, Google looks like a regiment of special forces: each member individually highly competent, and together, when deployed appropriately, quite capable. But one would not expect them to be able to run an orphanage, or, to wrap up the analogy, have very good customer service.

Although, thinking of it, a regiment of special forces would be very effective at running orphanages, since the great majority of soldiers would feel very compassionate toward the children, and not many things would get in the way of them getting the resources needed to care for the kids properly. Not sure Googlers would do as well.

-----


Generally the hiring pipeline at Google does not involve a hiring manager until after the individual has been accepted. There are exceptions for special roles and people, but for the software engineer case, we require that someone be generally competent across the board. Once they're in, then their specialties and interests factor into what team/project they start on.

-----


By generally competent across the board, you mean adept in a variety of disciplines, but only within the general discipline of Software Engineering. Of course, this covers a lot of ground, from networking to kernel development, to web frameworks, database system (RDBMS and NoSQL), and even old-school assembly...

Or no? Perhaps you look at the fundamentals of algorithms, such as types of sorting, binary data operations, that sort of thing...

Either way, many people will not be able to know enough across the board to make the cut, who in one or two particularly focused areas may be quite talented, and there may be people who, having spent all their waking hours in the deep study of bits and bytes, pass all such tests with flying colors and who, once in the company, poison the well of goodness because of their inability or unwillingness to adapt to rapidly changing surroundings, because of their inability to endure tenaciously under, shall we say, difficult managerial arrangements, and because of their inability to genuinely care about the welfare of their peers, Google customers and clients, and Google investors, both in word and deed?

Perhaps this is not what happens, but, from the outside, as far as I can see (and I remember the pre-google days of Lycos, HotBot and metacrawlers) Google the Company behaves as one would expect a talented yet socially awkward and uncouth twenty-something; brash yet caring, uneven in his affections, vacillating between opposites, such as standing up for freedom and privacy one year, then chucking freedom and privacy to the wind the next for a sizable windfall. This person can charm yet irritate, seem brilliant in one area but somewhat novice in another.

This is how I see Google, and I see very little, standing on the outside as I am, that leads me to believe that there sill be change for the better anytime soon.

-----


A year and a half is an eternity in software development. It makes sense if the developer likes the project, feels good about his peers and his manager and feels technically challenged. If those two or more of those criteria aren't met, it just breeds resentment in everyone. As a manager you shouldn't even want someone on you team that is becoming resentful. It's toxic. If a manager were willing to keep someone on their team that is becoming more resentful and tried to change the situation by changing teams and that manager prevented it, then I'd fire that manager. That's not how you lead a team or company.

-----


Thank you for cutting through the ad hominem crap and to a real point.

I'll do unpleasant work on occasion for a manager-- and more often to keep my own promises and see through projects I care about-- but managers who expect reports to subordinate their careers (rather than just doing a bit of work) and keep their heads down for 18 frickin' months are either entitled jerks or extortionists (depending on whether their attitude is subconscious or conscious).

-----


Does Google have mentorship as an official responsibility? As an engineering led organization, I imagine it should. Ideally a mentor should be someone politically separated from your people manager and technical lead. They would be an advocate for your development as a professional and would be like a good college counselor (Between two majors and switching majors and schools once I had five college counselors and two of them were indispensable.). If you're good enough to make it through the Google hiring process for engineers, then you are good enough to deserve an advocate/counselor that can coach you and represent your position as an outsider to a conflict.

Ideally a new engineer would get to choose their Google Counselor and they wouldn't be allowed to transfer to work for their counselor without finding a new counselor. If they didn't find a counselor within 2-3 months they could choose to attend "counselor speed dating" events where people who enjoy coaching and advising can show up and meet promising new googlers and take them under their wing. People who are really good, knowledgable and wise are often not only happy to mentor/coach others, but actually enjoy going out of their way to do so.

In the case of a conflict between an employee and manager (or tech lead) like you experienced, the counselor would act as an advocate for the employee and suss out the truth like a lawyer helps a defendant in prosecutorial proceedings where there is a clear asymmetry of power between the prosecution and defense (like federal cases); The counselor provides a system of checks and balances against the types of managers you've railed against in the past. Having been victim to such a manager myself several years ago, I know that such a mechanism is sorely needed as a company grows and certain poor managers become entrenched in a defensible position despite their toxicity to the organization.

-----


That's a great idea but, no, Google doesn't have anything like that.

You can find mentors, in the sense of people able to teach you things, and there are a lot of great people at Google, but there's nothing like what you described, and managers have unilateral power and the system seems to be described that way (project expediency, I assume).

-----


I would reckon it's more likely due to lack of trying than project expediency. A C-suite sponsored mentorship directive would be a managerial innovation that few is any companies have tried.

A bad manager like the one you've described previously doesn't get a product done faster, cheaper and better. Quite the opposite actually.

-----


In a previous discussion in a subthread started by you there was a concise reply with the most crystal clear example I can imagine about the stupidity of inflexible closed allocation from "russell" (https://news.ycombinator.com/item?id=5177884):

This describes my son's experience at Google exactly. He is a computer engineer with strong software and chip level design experience. He sought and was offered a hardware design job at Google. When he got there he was given a job writing python scripts to manage hardware, not the same thing at all. When he tried to change jobs, he was told he had to wait 18 months, so he quit.

-----


Wow, that sounds like... Microsoft. What happened to Google?

-----


It didn't happen only to Google.

Most companies start-off half-decent and sell off their culture to hire executives, which usually involves zero-sum autonomy transfers and globally undesirable cultural changes.

Usually, if this is going to happen, it happens early in the startup phase (~50 employees) but Google managed to hold it off for several years-- which is admirable-- but eventually hired some evil execs who did the culture in.

I feel like the hiring of executives is where most companies lose their culture. Bringing in a semi-retired burnout with a sense of entitlement, and giving him all the keys, turns out to be a bad move.

-----


Nothing happened to Google.

Michael had a bad time, for reasons that most people believe were due to his own impatience, and now he likes to talk about Google as if his situation is the norm. It's not.

No one minds if Michael talks about his own bad experiences at Google. People just get upset when he pretends his experience is representative of Google as a whole.

-----


My experiences may not be representative. My observations are. I've met countless people who've been screwed over by its anachronistic closed-allocation regime.

Some people have good experiences, some don't, and for 95+ percent of the "don't" category, it's because Google screws the pooch when it comes to people management.

I've never met a Googler who (a) got smacked by its antiquated HR system, and (b) actually deserved it. There probably is one or two out there-- it's a Poisson distribution with parameter around 2.5-- but I've never met one. Most of Google's problem employees (I've been personally attacked by a few) seem to do just fine.

-----


What is the Real Googlers Line? This is the first I'm hearing of it. I don't work at Google though, so maybe this is well known.

-----


Something the OP made up.

To the extent that I've ever heard people talk about "Real Googlers" the criteria have nothing to do with title, level, background or what college you went to.

The criteria are: 1) Get st done 2) Don't be a dick

-----


> I would guess he was hired at Senior SWE (which is respectable; unlike the title-inflated startups out there, it actually is fairly senior) or Staff SWE. The Real Googler Line is somewhere within those two tiers. It's not just about title, but location and project play a role. Most Staff are Real Googlers, some Senior are, SWE 2-3 are not unless they're hired as proteges (which is rare).

I didn't know the term either but he answered it in a post below.

-----


From a search for the phrase, it looks like he's the only one who has ever used it, so I assume it's being used in a pejorative sense.

-----


As is the case with most Important Capitalized Phrases he uses.

-----


It's not an official designation, obviously. It's where your bozo bit starts. If you're a Real Googler, people approach you with BozoBit := false.

Here's the Google engineering ladder:

    SWE 2 (fresh college graduate)
    SWE 3 (fresh PhD or 5+ years experience)
    Senior SWE (manager-equivalent; first acceptable "terminal" level.)
    Staff SWE (serious engineering chops)
    Sr. Staff SWE (rare; candidate for Director/Principal)
    Principal SWE (Director-equivalent)
    Distinguished SWE
    Eng. Fellow (VP equivalent)
I'd say that 5% of SWE 2-3 are Real Googlers, 35% of Senior are, and 85% of Staff are.

Real Googler means you have freedom of the castle. If you want to work on Search, you work on Search. If you want to dedicate the next 6 months to the maintenance of a module on which your work depends, you do it. It's like an open-allocation environment, and similar to what Google was before it got Too Big.

Below the Real Googler Line, you actually sweat performance reviews because your manager can unilaterally reduce your credibility to zero. Above it, projects and managers compete for you. There's probably some room for play (when you're slightly above RGL, you might still worry) but it has a binary feel to it. When you're a Real Googler, you have independent credibility. You don't sweat Perf.

Traditionally, the RGL was the Senior SWE tier. That was the level at which you were trusted to choose projects, and even manage if it were needed.

You're expected to make Sr. SWE in 3 years from SWE 3 and 5 years from SWE 2. If you don't, it's like being denied tenure and your project options (which probably weren't great, since 99% of getting promoted is getting on the right projects) continue to decline.

If you have Real Googler credibility, you can get away with a lot. There are people who start strong and get promoted, then go along for 3+ years without committing any code before they get fired. That's what RG gets you: a 3-year audit cycle. On the other hand, if you're not above the RGL, while it's not technically speaking hard to stay employed, it's extremely competitive to get into a position where you can have a real impact.

-----


michaelochurch, I don't see an 'SWE 1' there. You also don't take into account what I've heard about 'slotting'. Are these two related?

-----


SWE 1 is for interns.

Slotting was abolished. Originally, software engineers were hired at mid-levels and "slotted" about a year in. Downslotting was more common (60-70%, IIRC) than upslotting. Some people even got double-down, which essentially ends your career.

Downslotting doesn't end your career (again, most people go down) but it does send a signal that you're considered to be part of "the rest" rather than "the best" and the scent of mediocrity will follow you.

It's a dishonest HR trick that enables Google to recruit people with the "Senior Engineer" title but then tell them, once they get in, that they're actually "SWE 3.5" who will be evaluated for SWE 3 vs. Senior at some later time.

So, in effect, you have to get a promotion in order to get the job title you were promised. That said, it's fairly harmless if you know about it, because HR will confirm your pre-downslotting title (and titles matter most of all externally in any environment). It's only evil if you go in with half-knowledge and think you're going to be 2/3 of a level higher than you actually are.

Slotting no longer applies, unless they've re-instituted it. It was abolished around March 2011. It was terrible for morale and HR eventually realized it was shitty idea.

-----


There is no SWE 1. Google doesn't believe anyone they hire is below a SWE 2.

-----


There is in fact a SWE 1 title, but it's reserved for interns.

-----


When I was at IBM, I was hired in as a STSM (band 10; the next level up was DE). One of the huge handicaps I had for being parachuted into a very large company at a relatively high level was that I had to work extra hard to establish my "network" with other STSM's and DE's. There was a certain amount of automatic "if you are a STSM, then automatically your BozoBit is false"), but since there were stories of STSM's who had retired in place, it certainly wasn't an automatic grant of credibility.

So your concept of "Real Googler" is (a) not as binary as you make it out to be, and (b) it is a reality in any large company, and indeed, in our entire industry. (You think someone like Guido van Rossum worries about promotions, or doesn't get the pick of which jobs he wants? :-)

If you don't have a good network, where your competence and your work is known outside of your local team, then yes, you are largely dependent on your manager in terms advocating for you for your promotions, and it will be harder to convince another manager in another team to advocate for an exception to the general rules of thumb of transferring early after being hired (yes, it does happen, and yes, it is an exception, and yes there are some really good reasons for that guideline to be in place). I can't speak to whether or not you had a good manager or not[1], but for someone who is more junior, of course your experience at a company is going to be more dependent on whether you had a good manager or not --- that's true everywhere! I can say that all of the managers I've had at Google have been excellent, and they all have had a very similar attitude that which was expressed by Matt Welsh --- the attitude of "servant leadership", where your goal is to remove obstacles that are getting in the way of those who work for you, and for whom you are very glad to shower credit upon them, because a high functioning team reflects well on the manager and on the tech lead.

[1] I can't speak to this because I'm not familiar with your local team or who your manager was; I only saw your behavior on a company-wide engineering mailing list.

Bottom line? If you want to get ahead, you need to establish your competence and your value to other technical people in your company, and in your industry. You don't do this by putting down people who are well known in the company and in the industry, and you don't do this by asserting that you have executive level vision and bemoaning the fact that no one is willing to listen to you and willing to grasp how brilliant you are. No, you put your head down, and you do good work, and you help other people.

I may be the ext4 maintainer, and I may be well known, but far more often than not I'm reviewing other people's code, fixing up other people's code, fixing bugs, and helping users. There's a huge amount of grunt work involved, and I'm happy to do it and I'm happy to shower credit on people at other companies who have invested time and energy making ext4 better. That's how you get ahead in the world, not by asserting how great you are and by putting down other engineers and/or other companies. Other people will be able to very quickly draw their own conclusions.

-----


This don't make closed allocation any less flawed though.

-----


You've never heard of it because MChurch is the only one that uses it. It is something he made up to explain the fact that he came to Google and people didn't recognize his "genius", despite his many high-profile attempts to explain to everyone what we were doing wrong.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: