This is a great way to earn loyalty from the person not being fired and at the same time alienate multiple other employees who may have to work with someone who just might be a bad fit or incompetent. I've seen the situation happen too many times where a company's reluctance to let one person go without a long, dragged-out process of formal correctional measures caused several other, much more valuable team members, to leave instead.
Improving "behavior" (I would say "fit" -- the problem can often be on the company's end as well as the employees, and if you want to take the family analogy even semi-seriously, the employer needs to be able to be introspective enough to recognize this) needs to be taken just as seriously as "fire only as a last resort" in these cases; and if you don't have a credible plan to improve fit, you are at the last resort.
(Lots of places that give lip service to an ideal like this, especially places that are still afflicted by heavy bureaucracy, take it the wrong way, and it amounts to "never impose negative consequence and just try to sweep any performance problems under the rug as long as possible"; that's at least as bad as "fire at the first sign of trouble, and never try to understand what went wrong and how it could be improved".)
Internal processes only take as long as you make them. Correct the issue in 2 weeks. Not solved? Let them go. It doesn't have to be some 6 month ordeal of trying to get things worked out. The point is to have a process to deal with these things rather than telling the employee to pack up their shit and get out.
It's alright to fire as a "last resort", but make the process to come to that decision a swift and confident one - your other employees are watching.
"Last resort" does not mean "long process", it means, "only when there is no reasonable expectation of being able to improve fit to an acceptable level".
Whether it takes a while to reasonably determine that or not depends on what the problem that has manifested is and what opportunities there are to alter conditions to address the problem.
Firing somebody who is doing a decent job causes a lot of damage. The first company I worked at fired two devs after implementing new metrics and determining they were 15-20% less productive than the rest of the team.
In reality these two guys were doing a good job; just not quite as good a job as the rest of us. I immediately started looking for a new job and within six months the entire rest of the team left.
Besides, if they did let me go after a month, I'd have resented them for not giving me a fair chance.
How they didn't see it coming… Well, we informally discussed the project, my OOP knowledge etc… But they didn't read my blog, where my biases are quite clear. Come to think of it, my colleague didn't read the coding style rules he asked me to write either. If he had, some issues would have been addressed right away.
I was also told I would work on equal footing with my colleague, participate in technical decisions… He was my elder, and in the project from the very beginning, so he wasn't really my equal. But I failed to treat him like my boss, and it turned out to be such a big problem that the hierarchy made it official 10 weeks after my arrival.
My first commits weren't object oriented, so my colleague deduced I didn't know OOP. I lost all credibility at that point.
Finally, I was too careful. My unwillingness to rush the next feature as fast as possible without any regard for technical debt was interpreted as "doing research". Sorry, I just can't work that way. I was told we would "rewrite the code 50 times over", which would indeed have compensated. In practice we never rewrote anything. The first version always ended up being set in stone. Even code we both agreed was a mistake.
On the bright side, I did adjust over time, and they even said so (to me and my hierarchy). Maybe that's why they kept me for so long. But it wasn't enough to keep me in the middle of a general downsizing.