3 ms·

I suspect this is going to be a long thread ;) Probably not, unless someone else jumps in, since I actually agree with you and am merely exercising skepticism

• jacquesm 17y ago
  At the risk of quibbling, this strikes me as a couple steps removed from anecdotal. I expect a degree of subjectivity, but without direct observation, it's merely hearsay (not entirely unlike some interviewing techniques, but I digress). It's not even removed, it is anecdotal, I don't even know for sure if they are telling the truth, and possibly neither do they. But the universal component seems to be that they all agree that it takes time, so the only thing left to argue about is how much time, and hence roughly how much cost. We're talking about a fair sized sample though, so even if it isn't a research project it will hold some water. The question is born out of my own experience that it can take some time to get a new hire trained, coupled with a bit of information about the complexity of the subject matter it usually gives me some insight in to how well their documentation is and how good their teams are at communication and dealing with integration issues. That's a big assumption, and one I would suggest is false for experienced technical people, especially non-programmers. I detect an additional, implicit assumption, that a new hire's productivity will ever reach (and/or not surpass) that of the veterans around them. Not necessarily, there is probably some correlation with how fast someone gets up to speed and how far they'll go, sometimes you get lucky and you find someone that managed to outperform the people that you already had. But as time progresses the chances of that are smaller and smaller, simply because of the body of accumulated knowledge by the 'old hands'. Similarly, you're assuming that they will, at some point, cease to be a drain on the team. Well, everybody is a 'drain' on everybody else in that respect, but during the initial period where someone is entirely new to something that drain can be considerable. Especially in those 'rare' cases where the documentation leaves something to be desired. Of course that would never happen in real life ;) I don't think it's any of an employer's concern what an employee's personal/family situation is, nor appropriate to base hiring/firing decisions on it. Fortunately, the labor laws in my jurisdiction support such a view quite strongly. No, but that doesn't mean that it hurts a lot more to fire someone for whatever reason if you know that it will affect his or her dependents as well. I agree that's arbitrary but I'm by no means perfect. Downsizing is the hardest in this respect, it causes no end of grief, nobody did anything really wrong, but still you would have to let people go. This may be true, but you haven't pointed out where capriciousness or callousness (beyond a separation of business and personal) is advocated, either by the OP or the OC. I think the capriciousness is in the part where he says 'in startups, where you hire fast and loose', which is something that I don't think is necessary at all, and then corrects the failure to invest enough time in the hiring process by firing an overly large portion of his hires, most likely people that he would have never hired in the first place if he had spent a bit more time in the beginning.