Hacker News Reader

Comment by Justsignedup | Hacker News Reader

I worked with an engineer. She told me that when working at her previous company they permitted you to switch teams every 2 years. Every 2 years she would take that opportunity and got to work on a huge variety of projects with lots of different people. Some of them good, some of them not.

It kept her there for 12 years or so.

View on HN

I've worked at a (giant well known) company/bank in New York that basically mandated that people switch jobs internally every 18 to 24 months. It was part of the expectations. I was there for 4 years. I had 3 different roles in 3 different teams.

It helped a lot in fact in doing quality work. Thinking that you will inherit things you didn't do. That some other people will inherit your work / decisions. And always learning new things / keeping best practices in mind.

It's something I've kept in mind everywhere I've been.

Is there a trade off between depth and breadth here? While not the SV tech scene, I remember working for an aerospace company that had some people in the same positions for a couple decades. For the administrative positions it seemed to breed complacency, but for the technical positions it seemed to provide a very deep level of technical expertise that would be difficult to cultivate within a couple years

the other side from my experience at a previous engineering job is that it can also breed deep defensive layers around bad engineering work.

the same 3 core people stayed on the project for 11 years from the begging and hired and fired around weither you're a threat to their position. managers would come and go, they were helpless and held no real power in the project, until they settled for a puppet manager who would defer every decision up to them and act as a secretary.

the result was a huge pile of tech debt that only they could touch and they kept getting raises because the project couldn't afford to lose them, until the project died of it own weight.

same, i joined a place where it turned out a small group of people basically held all the power and had created a byzantine system only they could reason about. management was also trapped because the devs who knew the system held all the power.

For finance, the primary goal is to prevent corruption, the intent is not quite the same as tech.

This is smart. I left GS right around the time they were starting such an (similar?) initiative. It also makes employees more fungible, on average, which is nice.

This was GS indeed. I personally liked that a lot. I've learn a lot there.

I don't know of any such mandate in GS, was it for a specific division or group of teams? The company culture supports moving internally, but I never heard of anything like a mandate in my very recent stint there.

Circa 2014 they started a program where Analysts temporarily work on teams that did not hire them, following their three-month orientation. Based on the parent comment, it sounds as if it was taken even further. I was in the Tech Division before it was rebranded as Engineering and merged with SecDiv / Core Strats by Eli Wiesel et al.

Ah, good guess!

I suspect there is a correlation between companies that have a culture of letting engineers change roles/departments (and a clear process for doing so) and retention/average tenure.

As much as everyone hates on Amazon, no manager can block a internal transfer, maximum they can do is keep you for 4 weeks (with a very, very good reason).

The average tenure on many, many teams is 6 months.

Does help starve off the boredom.

As long as you don't talk to your manager ahead of time. I watched a colleague tell our manager that the job wasn't in line with what was explained (colleague was right, he wasn't a fit). Instead of the manager moving him into a new roll, my colleague was PIP'd. When my colleague did try to transfer, the PIP blocked it.

If you have a good manager, maybe its fine. But if your manager needs some headcount to cut.... don't trust them.

IBM

That's untrue, a manager can put their employee into a performance improvement program (without even needing to inform them) which would block them from any internal transfers.

How does a pip effect improved performance when the employee isn't even aware they're in one? Is trying to switch teams the only way to discover that, or are there other indirect ways?

But HR sees it as a way to prevent a subpar employee from escaping the natural HR process. The fact that you have not been informed yet is just a failure of current management to follow process, but does not obsolve you of your subpar performance. HR is there for the company, not for you.

But really, if the only goal is to not be able to shirk a PIP by repeated team-hopping, the PIP should just follow you as you move teams rather than blocking your progress, right?

"Here's Joe Candidate, he applied for your open position, and he has a 3 month old PIP on track to be resolved in 3 months. Accept or decline the transfer to your team?"

In theory that would be good. The issue is that a lot of managers don't like dealing with problems. If somebody is doing badly and maybe should be fired (which is what a PIP is supposed to indicate) you don't want a manager just passing the buck to some unsuspecting team.

Ultimately, I think you're right. It's impossible to build a bureaucratic pachinko machine that will make the correct personnel decisions. You really need line managers dedicated to coaching staff, and higher-level managers coaching line managers. One-size-fits-all rules are not the optimal solution. But bad management is endemic in so many organizations that I'm sure these abuses go on all the time.

Amazon employees attempt to rotate to Google every 2 years.

False. In many teams half of the engineers are randomly put on pip and cannot switch team.

Half?!? In most companies, a manager with half their people on PIPs would indicate the manager is really fucking things up somehow. Bad at hiring or bad at managing. That's not the case at Amazon?

People will believe everything (negative) they hear about amazon. And not bother to verify any of it.

It would take several weeks to get to grips with a new team / project - must be very hard to get much work out of a team member before they are off.

Changing projects is only half of it, though.

Let's say I want a new project. I can search for a new team internally, find a mutual match, sign on, start and.....keep my current salary.

Or I can search for a new team externally, find a mutual match, sign on, and get (in most cases) a significant raise and a new sign-on bonus.

Even at a company I like, there's a significant incentive to leave.

This is true in many cases but internal transfers can still make sense.

Searching costs are a lot lower internally (no leetcoding needed in most cases, hopefully) and you are more likely to be able to land something outside of your current skillset, increasing your long term compensation and job security.

Only difference would be, that in current company it is more easy to get an understanding if new project management sucks.

> People hire at companies, bbut leave their boss.

In my anecdata thus rings true.

Many large organizations do this for promising workers who are being groomed for managerial or leadership positions. The goal from the company's POV is to have people who are familiar with many aspects of the business and are comfortable with working with new teams/challenges, but I think it also appeals to people who like being challenged ... or are willing to do whatever it takes to reach the top levels of the organization.

Usually companies don't increase pay when you switch internally so the only reason to do that would be because you love the workplace so much that you don't care if you get payed much more somewhere else.

Where I work, switching teams basically requires a full reinterview (technical questions and all). At that point I’m going to have to interview prep again so I may as well interview around other companies for a pay bump. If there was less friction to a team change I’d be much more likely to stick around.

Interesting. Not for developers, but essentially the same thing happens in the UK civil service.

Reply on news.ycombinator.com