[neffy]

If you take the truly non-performing folks, well sad to say you can probably get rid of most of them and improve performance.

Otherwise, get rid of any engineer and the minimum impact is 3-6 months code and culture familiarisation before they get up to speed with your particular application/code base/equipment. Can easily be more than a year - especially with some of the big systems.

So yes there is an impact on business performance, and a highly damaging one, far more often than is realised. Companies compete - and companies go under and get replaced, all the time.

[ChrisLomont]

>get rid of any engineer and the minimum impact is 3-6 months code and culture familiarisation

On a big project, say 100 devs over 3 years, 6 man months is 1/600th of the work, so a single person is replaceable and it's not even noise. If the replacement takes 6 months to get up to speed the replacement is certainly not a very good developer, even on the biggest projects. At that size, there's lots of small side projects, testing groups, and the like, so there should be plenty of smaller pieces to work on, and some on those small projects are always happy to jump into the main work, not needing 3-6 months to be useful to it.

This is not highly damaging on any but the smallest, shortest projects. And even there people move around all the time and don't destroy projects.

[clavalle]

>If the replacement takes 6 months to get up to speed the replacement is certainly not a very good developer

I think you're mistaking 'becoming a contributing member of the team' for 'contributes at the level of the developer that left'.

[SideQuark]

Often the person leaving has not been that good of a contributor due to wanting to leave, while a replacement is new and likely more inclined to work hard.

On a big team, people fit a bell curve, and most likely those leaving are not going to cause much harm (otherwise no big project would get done - all have people coming and going over the lifespan of the codebase).