If your engineering org is 50-weeks-a-year structured around delivering stories and fire-fast and doesn't build in time for ramp-up, it has a good chance of spitting out ineffective hires. But most organizations --- and we worked with lots of them as a high-end engineering consultancy --- aren't structured like this. More importantly: it's disproportionately the larger organizations with bigger brand equity that tend not to be run entirely out of Pivotal Tracker, which feeds the resume effect.

At many large organizations, there's even political pressures that keep employees from being let go early in their employment. If a hiring manager says yes to a candidate and they go through training/onboarding, there's a certain amount of clout to be lost if you jettison that employee early on. It is, instead, better for the manager to make the employee appear to be productive to make it seem like the manager did a good job in hiring.

Team accomplishments can be embellished, stronger team members can cover for the weaknesses of weaker team members, but admitting that a decision you made was incorrect gets punished. It's obviously better to hire someone competent in the first place, but the next best alternative, for the manager, is to live with their bad hiring decision.

I used to work at a company with thousands of staff, and the HR policy was pretty clear:

As engineering managers, we were expected to "manage out" about 10% of the lowest performing staff on a yearly basis. The way that worked was basically that the 10% under-performers were to be put on strict personal improvement plans, and were under no circumstances given raises at all, and it should be made clear that no raises would ever come their way unless they improved.

That was it. Sounded harsh if you were used to 10% a year raises, as many of the good performers got. Not so harsh for those who were used to live in fear of getting "exposed" and fired.

And as a manager, if I were to designate a lot of my team as under-performing come review time, it'd reflect badly on me, so managers also had an added reason to push for good reviews for their reports: You'd end up getting paid more by getting good reviews yourself if your reports were helping create a good impression through rankings that you as a manager could trivially fudge (we did "360 degree reviews" were the manager and report could both designate some co-workers to review the person, which was of course trivial to game for those who wanted).

There was also an implicit expectation of a bell curve. If you had an under-performing team, that'd be awesome news for at least some of the weaker members on your team (and conversely, I several times had reports who got short-changed because I was told too many of them were designated "above expectations" even though my manager and other people who had worked with them agreed, and so several of them were ranked lower to get the "correct" spread - it was absolute lunacy).

Unsurprisingly, come hiring time, I felt like we were under siege by an army of ineffective developers hoping to find refuge somewhere safe and hard-to-get-fired.

There are scarily many places like this for ineffective people to hide. Sometimes for many years.