Running a software team at Google
matt-welsh.blogspot.com
matt-welsh.blogspot.com
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.
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.
Can you provide links to your tutorial?
https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...
I am currently in (a non-ivy) graduate school and should start focussing more on open-source involvement. Thanks! :-)
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 only things that gets you credibility within Google in my experience is delivering good stuff and being helpful/knowledgeable in conversations with your peers.
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.
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.
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...)
[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.
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.
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...)
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.
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 didn't know the term either but he answered it in a post below.
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)
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.
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.
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.
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
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.
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.
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.
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.
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.
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 ?
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.
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.
It'd be really nice if HN was not one of those circumstances.
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.
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".
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?
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?
> Telling Google to "Choke on a fucking taint, Google. Choke. On. A. Taint." [1] is also not nice, in any universe, not even HN.
Neither are _nice_, clearly.
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.
"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.
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 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?
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.
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.
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.
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?
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.
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.
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.
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.
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.
No drama and no hard feelings.
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.
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.
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.
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).
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
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.
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.
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.
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.
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.
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.
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).
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.
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).
A bad manager like the one you've described previously doesn't get a product done faster, cheaper and better. Quite the opposite actually.
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.
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.
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.
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.
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.
What you're describing sounds pretty terrible, is that based on personal experience with Google?
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.
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.
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.
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).
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.
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.
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.
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.
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).
In engineering-centric companies, coding is necessary for credibility.