I’ve come to think a certain amount of attrition is needed to keep a product and the individuals working on it healthy. Back in my consulting days I worked with a few enterprise software companies that had a lot of highly tenured employees (think 10+ years). All the long-timers I met were skilled fiefdom builders with a strong bias toward opposing every change and maintaining the technical status quo because a lot of their value was in their vast knowledge of the way things already are. Without attrition you end up accumulating people you don’t want. Overall it seems like a path to ossification/stagnation for your people and product.
From the individual perspective, staying too long slows down your rate of learning because you aren’t coming into contact with new people and technology at the same rate. Anecdotal, but lately I’ve interviewed some 8+ year tenured candidates that I wouldn’t rate above SWE II because it was literally a “one year of experience 10 times” situation. I try to change things up every 4 years or so to avoid ending up this way myself.
I noticed early in my career that relentless refactoring ended up as de facto empire building because some people would just give up on tracking the changes I was making and abdicated that domain to me.
I think I have a very different way of organizing knowledge, where I worry more about how to answer questions than knowing the answers. This makes me very popular with young and new employees, and quite unpopular with those who think you make Important Decisions by locking everyone in a room until they are made. Oh and using a computer in a meeting is disrespectful so we will make all decisions from memory, then have another meeting when we discover our memory was faulty.
What is your argument that encouraging attrition would cause these people to leave rather than the employees you might value more? That is, why wouldn’t doing things that lead to higher attrition lead to having a all the people you want leaving and the people you don’t want continuing to stay because e.g. it is harder for them to go elsewhere.
I think you have to fire them. If you just non-selectively "do things that lead to higher attrition", you're right, you're going to lose the best employees and just make things worse. It's painful and it's actively painful in a way that "let's just not pay so much everyone sticks around forever". You'd have to yank out someone that has convinced everyone they're essential to the company, but they're mostly essential through a situation they created.
I wouldn't overapply this though. I think terminal mid-levels might be undervalued in a way. A separate conversation, but I think "developer assistant" could be a role in the way "dental assistant" is (but not as much based on gatekeeping).
This is only necessary for single-product companies. Otherwise, just do mandatory career broadening assignments like the military does. You have to learn about and work on many parts of many stacks and regularly change teams and product lines. There is no need to fire people to keep them working in one position forever and building fiefdoms.
Heck, militaries even have interbranch and even international exchange programs. There is no reason in principle companies can't do the same and temporarily trade out employees every now and again to learn how things work elsewhere. It would have to be subject to pretty strict NDAs and limitation of sensitive data access, but given the sensitivity of classified defense data, if the military can make it work, private companies should be able to make it work, too.
That handles the specific problem of people not broadening their skills and I certainly wouldn't say that firing people is the best way to get more perspectives in your company. There's a general question of how to get rid of employees that are entrenched, want to stay, but aren't providing enough value.
I don’t know what goes on in manager meetings, but I think it’s a little too convenient that in many orgs very senior ICs get forced into management positions, which has the same effect. Trying to be both is politically and emotionally fraught, and some people hate it and quit.
You might say it’s constructive dismissal at its sneakiest.
I believe in early days Amazon(and possibly even now) Bezos did not want employees to stay for more than 2 years, for the hope that Amazon was a stepping stone to other places for people.
> From the individual perspective, staying too long slows down your rate of learning because you aren’t coming into contact with new people and technology at the same rate. Anecdotal, but lately I’ve interviewed some 8+ year tenured candidates that I wouldn’t rate above SWE II because it was literally a “one year of experience 10 times” situation. I try to change things up every 4 years or so to avoid ending up this way myself.
Should be noted, this is applicable to the same position specifically, not any one company. Some of the best engineers in the world have only ever worked at places like Google, Microsoft, an academic institution, etc, but they make sure they're constantly learning, working with new teams, switching to new positions once they've mastered their previous one, etc. In many cases these folks actually have a big leg up vs new external hires due to product and institutional knowledge, while also constantly learning new technologies.
> All the long-timers I met were skilled fiefdom builders with a strong bias toward opposing every change and maintaining the technical status quo because a lot of their value was in their vast knowledge of the way things already are.
I worked at the US hq of a .DE manufacturing company, and can attest to this.
My team was about 3 people (Americans, with our manager having worked in the German HQ for a few decades), who worked mostly on separate projects, and most of the headaches I had were due to change being opposed. I would try to do something, or request some sort of access to perform some task, and would get blocked by red tape that wasn't made visible until I was being told that I wasn't following a process that wasn't explained to me in advance.
There was one person whose sole task was managing the company-wide JIRA instance. If you wanted your team's board structured slightly differently, good luck. When I requested permissions to create a Component, the denial went to my manager instead of me, and I got a stern talking-to about 'the way things need to be done'.
On top of that, for a team of 3 people working on projects that are exploratory in nature, I'd expect that the local SQL server install (We didn't have the license key anymore, btw) would allow for us to have admin or developer rights. It originally did, until someone decided to change it, and I was the only member of the team who lacked that access.
I tolerated it for about 2.5 years (First job), but Covid gave me a great reason to quit!
I think some developers don't realize that corporations have a target attrition rate and it is fairly easy for them to enforce.
I would say that Attrition actually benefits employees and companies. The Employees who stay take a pay cut each year either to inflation or to the fact they just don't get paid more. Employees get better pay once they change jobs and companies get to have new people at a lower rate and they in turn may have a different perspective. Avoiding change I think it isn't necessarily the people who will stay for long periods of time but it might be corporate culture instead.
Depending upon the specifics, there probably tends to be some happy medium (from both a company and employee perspectives) between constant churn and very little change over the course of a couple decades. There are exceptions of course.
From the individual perspective, staying too long slows down your rate of learning because you aren’t coming into contact with new people and technology at the same rate. Anecdotal, but lately I’ve interviewed some 8+ year tenured candidates that I wouldn’t rate above SWE II because it was literally a “one year of experience 10 times” situation. I try to change things up every 4 years or so to avoid ending up this way myself.