[IceMetalPunk]

You don't lose the output of the coasting team member (even if you get rid of the right person); that workload just gets transferred to the other 4 people. So let's say you have 5 people, 4 of which each are doing 22% of the work, leaving the one "coaster" to be doing only 12%. You fire the coaster, and now you've got 4 people doing 25% of the work each. An already burned-out team is now filled with people who have a larger workload.

And this of course is a simplification that assumes workload is a continuous rather than discrete measure. If the fired guy had two or three Jira tickets he wasn't making progress on, now you've got two or three of the remaining workers getting another entire feature dumped on their pile of work. The burn-out is higher than 3%. Until they quit, of course, transferring their workload to the remaining 3 people, increasing their burn-out, etc... it's a dangerous chain reaction.

[PuppyTailWags]

Yeah generally even a coasting employee is doing some minimum amount of work. If burnout is a concern it's actually better to hire someone with the intention of PIPing and kicking out the coaster after. Since the coaster has been there as long as they have, a bit of extra time won't really change the situation.

[Note: This is WILDLY different if the coaster is actively generating more work for peers. I'm talking producing mediocre code that needs extra code review or not completing assigned tickets forcing peers to pick up that slack to finish the sprint. Get the team's opinions on the situation in 1:1 and boot ASAP if folks find this is a source of friction for them.]