*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.
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.
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.
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 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.