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.

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.

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.

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

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.

Amazon employees attempt to rotate to Google every 2 years.

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.

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.

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.

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.

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

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.

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!

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.

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.

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.

I would really appreciate that as a developer, I have definite gaps in my skillset that I haven't needed (been paid) to fill. But everyone would have to get out of the mindset that developer Joe 'knows everything' about X.

The perfect match would be pairing a developer that can explain some technology to a 12 year old with a developer that has the equivalent knowledge of a 12 year old (for that technology.) That would keep things interesting and build a very resilient organization.

I used to manage a team of mixed very-experimented / very-juniors and I'd make sure every senior worked on stuff I knew were not in their comfort zone, and assign tasks in their expertise domain to juniors. They'd act as consultants, while checking other parts of the codebase/docs (as noobs) for incoherencies, sand-in-gears, and improving them. Over time, the experts kept things getting better, up to their common standards, and the juniors would level up far more quickly than other parts of the org.

To keep things interesting/challenging for the experts I'd have them also reach across domains (to system eng, safety, quality assurance, bids, R&D) and sometimes even overreach (blur the boundaries) while protecting them from corporate-strife. Software is far more interesting in the context of the product, the customers, actors on every critical team. I'd also have them try new techs, or find some innovation/maturity budget for 'pet peeve hunts' and we'd often end up with new tools, large-scale improvements in code, perf, readability, robustness, observability, or testing. I'm going off topic here but I'm sad that 'Slack', the book, isn't more widely read.

I stayed at my previous company for five years, but worked in four different roles across that time:

- 1 year doing iOS frontend/product - 1 year doing low-level iOS systems - 2 years as a PM - 1 year doing backend

I was never bored. I think giving engineers the flexibility to move around (provided they stick with one thing for a year or so) is a great way to retain folks. I can also say my efficiency during year 5 was fairly absurd (I won't necessarily say overall productivity was higher at the very end, since my interest in the company was waning, but I saved a lot of time by knowing exactly who to talk to and how systems across the stack worked).

That's a great idea on TJ's part. I have also wondered how giving some amount of project ownership to low level employees would help with morale. In grocery stores you see every little thing optimized by a marketing team; from the way products are stacked, to what the cashier is allowed to say to you. But what if some of these jobs were given to the employees? I think we need to let workers be more creative. Give them a reason to feel invested in what they're doing and reward them for trying hard. You can find what they're good at over time, the hard part is making them feel like what they do matters.

It seems like modern management theory has gone out of its way to optimize out the impact that any one low level employee can have on the company. And that makes sense when the goal is to make money. But what you're left with is a society full of people in mind numbing dead end jobs developing psychological issues.

> But what if some of these jobs were given to the employees?

This seems like another thing Trader Joe's does—I've been to their stores in a few places I've lived, and while they always have a similar aesthetic, a lot of the specific decorations seemed to be unique per store with nice local details. Of course, this could still be done in a totally top-down way—hiring local consultants or something—but I wouldn't be surprised if a lot of that was done by the store employees.

> And that makes sense when the goal is to make money.

Abstractly, I expect that this isn't the best way to make money. Modern management practices seem to value legibility and control even at the expense of expected income and company resilience. This probably says something fundamental about our culture, philosophy and incentives, but I'm not sure exactly what!

Exactly. And if you're curious what this says, I'd recommend reading Spender and Locke's "Confronting Managerialism". It's a great look at the dominant ideology of MBA-style management. And for me Rother's "Toyota Kata" was a good inspiration as to how to think of management not as control layer, but where teaching and support are the most important functions.

>Trader Joe's

It's only been a year since they were in the news for not letting people wear things that say Black Lives Matter.

And there was also the employee fired for sending a letter to the CEO about working conditions.

https://www.inc.com/suzanne-lucas/trader-joes-dan-bane-firin...

I think there was a boycott, but people move on so quickly.

There's no need for employees to be able to run personal political campaigns directed at customers at work.

Would you also insist that TJ allow employees to wear "Meat/Abortion is Murder" buttons?

> employee fired for sending a letter to the CEO about working onditions.

Allegedly. The journalist made no attempt to investigate or disprove TJ's side of the story, not even to ask the employee about it.

>The journalist made no attempt to investigate or disprove TJ's side of the story, not even to ask the employee about it.

They did! The TJ response is right there, after the termination letter, and the way I read it, they confirmed the story beyond a reasonable doubt by producing a denial that only sounds like a defense without context.

It says, "store leadership terminated this Crew Member's employment because of the disrespect he showed towards our customers. We have never, and would never, terminate a Crew Member's employment for raising safety concerns".

Their excuse is that he was not respectful enough to the customers...by demanding management exclude people (after 3 strikes) who refuse to wear masks and are abusive. And this is not a health concern, nor did they have any problem with the other health concerns. Really??

This is how every professional defends the indefensible these days. They craft a "non-denial denial" that communicates a falsehood to people who don't have the context, and doesn't technically lie or deny anything to people who do have the context. It is truly having your cake and eating it too.

Absolutely this. Where I work, changing teams isn’t frowned upon. I was in one role for a few years, then moved to another. I know the systems that are used most widely, the data, the business, I know a particular side of the business inside and out, and I already have important relationships and lines of communication.

And now things are interesting again.

This approach reminds me of the DevOps practice of breaking down information silos: make everyone learn a little bit of everything so that no one becomes a risk.

The Japanese corporation I worked for had engineers and managers change jobs every two years.

One of the reasons was that they wanted to "cross-train" people. They liked to have a lot of process, and tended to think of employees as "Swiss army knives," that could adapt. They had style guides, and a whole infrastructure (HR and technical), to support this. Lots of training.

Not sure how effective it was. I feel that they weren't as productive as I'd like, but they were really good engineers. I had a lot of respect for them (which doesn't mean that I didn't want to strangle some of them; from time to time).

The Japanese university where I work is similar.

Much of the administrative work related to educational and research program management is handled by the tenured faculty, and we get rotated regularly through administrative positions. In the sixteen years I've been there, I have, like most of my colleagues, served on a dozen or more committees and have managed programs for periods of several years each. The result of this process is that faculty members tend to become, over time, reasonably competent administrators with a broad understanding of how the university functions, and that in turn helps the university—a large, necessarily complex bureaucracy—to function reasonably well.

We also have a small professional administrative staff, and they also get rotated through positions every few years. They must keep really good documentation of what they do, as staff members are usually able to get up to speed on their new jobs very quickly.

Yes, but this won't work because there's just not enough different things for an engineer to master. ;)

More seriously, your observation is brilliant (and almost makes me wish I hadn't just accepted a new role). Because the software field contains such a breadth of things to know and breadth of potential applications, it's hard to get very far without having the kind of mind that is motivated by some level of intrinsic interest, and that can be a currency in its own right.

This is something I love about Facebook, fwiw. Engineers have tremendous liquidity in movement.

True, but Facebook also reorgs every six months, moving team responsibilities across orgs and cities all the time.

Surprise! Your team is shutting down and being moved to New York! Go back to the dating pool!

FB is a company that is successful in spite of all its internal failures.

I worked for a company where devs would rebel because teams were partly re-shuffled at the beginning of a new year! I guess people are different.

Yeah, I don't think it really has to be mandatory, but it certainly should be allowed and encouraged.

In the case where people were objecting to being re-shuffled, did they get to pick where they went? Or were they just told? a little agency can help a lot.

In the first year we just told people, which was obviously very stupid in hindsight.

In the second year, we had a survey where devs could say what their preference was: (a) team/specific devs (b) topic (c) none

That worked pretty well.

Glad to hear it!

I am currently a SWE student, and non-traditional. I am a full time student with wife and kids. I work full time and prior to starting school and current job, was in the Navy. Now that I am close to graduating and looking at companies, I am trying to find tech companies that offer a breadth of areas to work in so precisely I hope I can find a place where perhaps I move around. Being in the Navy and working in chemical manufacturing, I know how dull and boring doing the same job over and over gets. On deployment (on a ship), we referred to it as ground hog day like the movie.

One more point of anecdata: I've been with my current employer for just over 14 years, and I've worked on probably about that many different projects--generally two or three at the same time--in a variety of roles and with a variety of technologies (often with some degree of leadership, both formal and informal). There are many aspects of my current situation that I appreciate, but the plethora of options available for me to work on certainly feels like one of the big reasons I've stayed for so long.

Didn’t know that about Trader Joe’s, it’s really smart. To your point: for many companies out there it may be easier to raise compensation a bit rather than to figure out interesting tasks for their engineering force. Business usually wants its employees to solve specific problems, most of them mundane.

This. Most companies pay lip service to internal mobility, but I still see managers trying to talk people out of it (presumably so they don't have to hire and ramp up a replacement).

And that ends up being self-defeating over the long term, because oftentimes the developer will quit the company entirely if their requests for internal transfers are stymied for too long.

Something that really helps me at my job is I have 2 primary roles that kind of wax and wane. When I get bored with one, there's always something to do in the other.

Did Henry Ford figure that out like 100 years ago? That people get bored on the job.

A software dev changes between a wide range of tasks pretty frequently, if "stock shelves, cashier, repeat" is your basis of comparison.