I'd argue the biggest hurdle isn't even what you like or dislike, it's that when someone gets used to you being in a given position, that's all they see in you. I actually had that happen at one point in my career, kept getting an "I don't think you're ready". When I finally told them I'm leaving if it doesn't happen, they did the right thing. Afterwards I got a lot of "I'm sorry I pushed back, I couldn't see you in that role but you're killing it!"

I think sometimes management is their own worst enemy in not taking a chance on their own people.

> I think sometimes management is their own worst enemy in not taking a chance on their own people.

I've seen it in start-ups where they are anxious about their own talent, and are somewhat desperate to 'level-up'.

The mindset is like 'I married the first person I kissed, but I get the sense I could do way better now.'

This often leads to overpaying for people who have had the director or VP title in a larger, but minor company, and being told by them that the solution is to hire 5 more people under them.

I'm absolutely convinced this happens -- with roles, with capabilities, with salary. It's got to be related to normalcy bias and other anchoring phenomenon. Probably less than half-conscious, too.

That’s a great point. I have seen secretaries take training after hours to get certificates and degrees. When finished they apply locally and perform well, since they already had an idea what the job is. Some employees who have known the person in the old role find it hard to treat the colleague equitably. In that situation sometimes the best way forward is to take the new credential to a place where no one knew you before you got it.

I worked briefly for a large grocery chain that had a policy of promoting to management internally where possible. However, accepting a management role meant you had to change stores, to break those collegial relationships and establish you with authority somewhere fresh.

The shiny candidate outside the company is always somehow more appealing than the candidate you know 99% of the attributes of.

That sounds like a failure of management, not a symptom of it.

I agree it’s a failure. On the other hand, they failed their way into eventually making the right decision, recognizing they had been wrong, and apoligized. I’ve seen worse!

An excessive bias to internal hires, though, runs the risk of organizational ossification.

I've spent most of my career in consulting organizations, and sometimes our clients have been orgs with a high percentage of "lifer" employees for whatever reason. (Often, this is because the employer is one of only a few good, white-collar employers in an area, which is its own cost.)

Orgs with insufficient new blood get stuck. They think of the Company Way as the only way, and policy begins to replace thought pretty much across the board.

One example, early in my career -- before I went to consulting, even -- was a place I worked for 2 years in the mid-90s. They were a 100% VAX shop much later than the rest of the industry, and were known to pretty much hire new technical people only right of of college. As a result, they ended up technically isolated from the mainstream.

Once they realized that they were spending WAY more on homegrown solutions than they would on a commercial DB, it was really too late -- new grads didn't want to work on a dying platform, and the veterans had no experience working on anything other than the homegrown stuff.

And in the longer term- it builds stronger incentives for employees.

Most devs, if HN is any indication, believe that jumping ship every 1-2 years is the best way to move up. But if you have senior devs who were juniors at the same company just a few years ago, you'll probably be more likely to stick around.

One problem with sticking around is that the number of things you had a hand in, and will therefore be consulted about, grows unbounded. Being peripherally involved in a wide range of initiatives can give you a kind of global view and influence that dovetails nicely with certain visions of a "senior" or "staff" role. But it does come at the expense of being able to go deep on something new.

I've been with my employer for much longer than average. They're taking care of me well financially. Even the variety of projects and domains is pretty good. If I leave, it will be to declare bankruptcy on being an advisor/carrier of institutional memory.

This is my exact problem right now!

I'd argue the same goes for technical leadership that were hired in originally as senior/staff/principal. The bar for breaking into a technical leadership position at every company I've worked for seems impossibly high, while they've been more than willing to hire that from the outside. That doesn't just go for myself, but the colleagues I've seen leave as a result of not being able to break that barrier.

> if you have senior devs who were juniors at the same company just a few years ago, you'll probably be more likely to stick around.

I've had some bad experiences with this one. The devs in the senior positions had only ever worked at this one company, and they'd learnt a lot of bad habits that they then proceeded to enforce on the devs in junior positions, who despite having fewer years of experience were in many cases a lot more competent than the supposedly senior developers.

Speaking from experience in a more positive direction, there's also a lot to be gained from learning a second company's culture and tech stack. I spent several years at a FAANG, and my technical skills improved considerably when having to apply my existing experience to a new set of tools and environment. I'm not sure a third company would have quite a stark difference, but I'm sure I'm a better developer after 5+4 years than I would have been after just a straight 9.

I don't think it's necessary to move every year or two, but I'm not sure it's ideal to go too far in the other direction either.

I think this goes to the importance of promoting on talent, not years of experience.

Good developers look at what they've done, and critically analyze what is good; what can be improved; and what needs to be replaced. It's these people that you want to promote and provide with enough autonomy to do what needs to be done.

> Most devs, if HN is any indication, believe that jumping ship every 1-2 years is the best way to move up.

It's not just developers. The old model of companies rewarding loyalty and actively investing in furthering their employees' skills has declined across the board, and it's no coincidence that the timeline correlates with the timeline of the demise of unions and collective wage/employment condition agreements.

Lots of other things are happening too- people are educating themselves more, people have more jobs available from their locations (remote + commute distance increases + increases in population density), etc.

There's also the simple fact that an internal hire is strictly more work for management / hr to deal with.

If a certain position is filled from an internal transfer, that transfer leaves a new open position. Eventually, you need a hire a new person. A chain of internal transfers beforehand is just extra people to train and more paperwork to deal with.

The Japanese railway JRC or JRE can’t remember which one has a great program for this. Everyone being promoted needs to train their own replacement for leveling up. In practice or works great, and it is much easier to hire entry level then experienced and they even have their own university for training the entry level hires.

HR are lazy. Noted.

> Additionally, someone from outside may have the silver bullet to solve X,Y, or, Z problem that no one else can seem to solve [...]

>* Hint: They don’t.

But they also might. Sort of...

You don't usually hire someone with the expectation that they will come up with a magic bullet solution - Usually you already know the silver bullet and are actually hiring someone who can sledgehammer it in while existing internal teams are reluctant.

Sometimes its easier for an external person to do this, rather than an internal person.

I'm a supply chain consultant and regularly get brought in to implement change where there are often change-reluctant internal teams, which are held back by legitimate reasons why x won't work, even though x needs to be made to work. I say sledgehammer only to mean that sometimes you have to be very steadfast in the fact that the change is happening, and that all the reasons people give you for it not working are problems that you/them need to solve rather than reasons it won't go ahead.

Despite what I said above, personally I think companies just need the right mix of internal and external candidates - too many internal and the company gets too held back in 'the way things are done, and have always been done'. Too many external and there is a total lack of organisational memory and nobody knows how to do anything.

To be fair, I think the same thing is true of individuals, and it's not necessarily a bad thing. Often times the grass is greener on the other side. Granted, it's industry dependent, but if you are in tech then there are countless green pastures to pick from. From a company's perspective, they know they don't want to pay someone significantly more for the same position, so they figure they won't lose much by waiting for employees to leave and hire a fresh new employees for roughly the same wages as the preview ones. It also means any potential baggage created due to office politics and or bad attitudes work themselves out to some respect.

Unless one is an outright wizard at what they do, which is rare, what should make anyone think a company needs to keep them around? We are all replaceable. Companies should only hire internally if it makes sense. The fact is that 99% of us are just adequate in the eyes of our employers, and if they play their cards right, they have more to gain by hiring new team members than ones they know they aren't that enamored with.

Also, there is a desire to avoid disrupting two teams rather than one. "We need you here Bob."

I think the biggest reason is that the company already knows the person is good at their current job, and already have the experience and knowledge to do the job well with no more training.

If you move the internal person and hire someone to backfill, you have two people who need to be trained and who might not be a good fit at for the particular job.

> If you move the internal person and hire someone to backfill, you have two people who need to be trained and who might not be a good fit at for the particular job.

I have 1 opening at my company.

Someone internally transfers to fill it. I still have 1 opening at my company.

Alternatively, someone externally joins and fills it, and the person who was unhappy and looking to transfer leaves shortly after instead for an outside role. I still have 1 opening at my company.

Except in the first scenario the person transferring is most likely familiar with internal tools, practices, systems, deployment, culture, goes on and on. Not only that, I have tangible, full fidelity data on their performance in the form of artifacts produced for their current team. Externally, I'd need to rely on data collected in their interview process.

Alternatively:

I have 1 opening at my company. I set up a team to handle the hiring process for that position. They choose an internal candidate, who then transfers. I still have 1 opening, despite having completed the hiring process for the open position.

Being rejected from an internal position didn't guarantee that the person would quit, just increased the likelihood. From an "expected hiring committees" perspective, having an internal transfer guarantees two hiring processes. Having an external hire, provided the number of internal candidates is somwehat low, should result in (on average) less than two hiring processes.

>Except in the first scenario the person transferring is most likely familiar with internal tools, practices, systems, deployment, culture, goes on and on. Not only that, I have tangible, full fidelity data on their performance in the form of artifacts produced for their current team. Externally, I'd need to rely on data collected in their interview process.

This part I fully agree with. It could definitely turn out that the benefits of an internal transfer more than outweigh the increase in resources used on hiring.

I get it, and don’t think it is a smart long term choice to not hire internally.

I was just trying to think about reasons a company might choose not to. How much training you have to do for the internal transfer is going to depend on how similar the old and new job are.

Also, when you hire from within at some point you still have to bring in a new employee to fill the vacuum, so you end up doing more work.

It's worth doing right as most work is, but managers want fast solutions and typically are not incentivized to take their time.

It makes sense to hire external if you're trying to grow headcount, or trying to "frontfill" before firing people.

Your comment makes it sound like you are biased toward internal hiring being better. Why is that?