1. After some probation period, fire only as a last resort or for really terrible behaviour. Have a plan to correct behavior in all other cases.
2. No layoffs unless the firm's very existence is threatened. It's a tough year? Too bad, that's part of the risk involved in being the owner.
3. Keep pay up to market/replacement rates. If someone is 20% more valuable with his new knowledge, pay him 20% more. 4. Have good benefits/vacation policies.
5. Make sure there's lots of interesting and challenging work to do. Allow people to switch roles/teams on a regular basis if they're interested.
6. Hire good people.
That's a company I'd be loyal to, and I think a lot of others would be too. Sure, you'd get people who would leave for their own thing, or a dream job, or because their husband/wife got a job 2000 miles away, but I don't think you'd see people jump ship nearly as often.
The other stupid thing is companies trot out how much it costs to hire a new person, but never want to invest in just retaining their employees.
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.
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.
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.