Firing under-performers is one thing, doing it decimation-style en masse is another. Employees who don't measure up need to be judged on a case by case basis and removed from the company in a timely, individual manner.
Mass firings, however justified, represent broken management. It means some poor performers were allowed to remain much longer than they should have, and that some poor performers have not been given sufficient opportunity to work with management to resolve issues. It also means morale is going to suffer - even if every single firing here is well justified, mass firings make everyone nervous.
I fully expect a healthy organization to trickle away bad hires one at a time as their unsuitability becomes evident. I don't expect healthy organizations to disgorge unsuitable employees in large globs.
I don't think you've supported this opinion very well. Here's a counterpoint: Hiring and firing are a completely normal part of a business cycle. Every company should expect to have some ratio of hiring to firing. And yes, a firing typically means imperfect hiring practice (which is not the same as imperfect management) -- but here's the key I believe you may not understand: The world is imperfect. We can bank on the fact that we make mistakes; we will always make mistakes.
Your other assertion that morale will suffer is empirically false. I know many folks at companies with this sort of practice in place and it boosts their morale because they don't feel like they're dragged down by under-performers. Maybe it lowers the morale of those who are under-performing, but that's not exactly a problem, is it?
Those all sound like armchair Aristotelian arguments to me. In my experience "this policy" or some varient thereof seeks to indicate a management failure and has sparked exoduses from profitable companies. Of course every business and every culture is different.
A business that seeks to rate people at failing at something there were at once determined capable and then later not needs to take a hard look at themselves. Perhaps the individual has mitigating personal issues; maybe the job hasn't grown with the person; maybe the company itself has changed and is less compelling as a person.
At least having given them 6 months of value to prove their worth and then changing your mind indicates something somewhere has changed.
Also what is this definite metric of performing you just invented? Either the individual is doing the job or when they slipped you didn't help put them back on track.
If it is a skilled job I can't imagine the cost of firing then rehiring and retraining someone to do the job in your company simply because you failed to pay attention to an employee at once every couple of weeks to see how they are getting on.
The only nonsense here is your belief that a hiring process can accurately predict future results. Hiring is incredibly difficult: Vast volumes of literature have been written on the subject. Mistakes are common; your idea that business ought not correct for mistakes is pure fantasy.
I think you failed to read the entirety of my post. Of course firing is a normal part of company operations - I stated that explicitly, multiple times in my post.
Mass firing however, is not.
Hiring will be imperfect, no matter how hard we try. Once in a while someone bad will make it into the company, and it's of great importance that the company identify and fire these people in a timely manner.
Note the last part: timely manner. Unless a company has been completely asleep at the wheel, there is no scenario under which people will suddenly go "woah woah woah! these 200 people must go!". To let go of so many all at once suggests you either weren't policing bad hires actively and let too many under-performers stick around for too long (and are just now getting around to cleaning house), and/or suggests a knee-jerk overreaction to some stimulus, and now you're about to throw some baby out with the bathwater.
Firing is normal. Mass firings are not.
And your "empiricism" is backed by your own personal anecdotes. Funny. In any case, I agree that individual firings can be morale-neutral (never morale-positive, despite your claim). When you fire Bob, who's been underperforming, only the people who work with Bob hear about it. Everyone knows Bob is hard to work with and not very good at his job, and people don't feel threatened by Bob's firing.
This isn't true when you're firing 200 people. People in the company hear about it, but they don't know everyone on the list - in fact, they may not know anyone on the list. So now the "obviousness" of the firings isn't so obvious, and people start wondering just how bad these people were to get fired, and they start wondering about their own performance. This is the start of a bad cycle, and morale is going to drop no matter which way you play it.
Firing 1 person has a tremendously different dynamic than firing 200 people.
So, we agree that firing people who can be saved is a good idea. We disagree fundamentally on whether or not mass firings are a good idea.
'Unless a company has been completely asleep at the wheel, there is no scenario under which people will suddenly go "woah woah woah! these 200 people must go!".'
Of course there is. You're projecting this as black and white, but in reality performance is a curve and the company's economic context determines where that curve ends. Companies growing rapidly hardly ever fire. Companies faced with a squeeze (and perhaps a shortage of profitable work) will be willing to move higher and higher up the performance curve.
Your platitudes about morale are simply untrue. I mentioned before specific peers as counter-examples, so let's also name the company: Netflix has a policy of firing people who aren't top-level performers. It's flatly impossible to make these kinds of determinations reliably before a hire -- the ONLY way to maintain a team of A-level players is to fire people who you've hired and who turn out not to perform.
This is not theory, this is fact in practice. It works great. People who don't make it don't like it -- and that's largely unimportant. People who actually are A-level performers love it. It's great for morale.
What is the cost of a system where a third of the employees or so live in fear of being stack ranked out of their jobs? I can't see that leading to a good environment, rather I would predict blame games and general bullshit to proliferate. The derision against Microsoft's stack ranking was pretty universal here.
Targetting a percentage to fire for underperformance is nuts. I hear stories from companies that have incredibly broken incentives as a result: Managers try to hoard bad employees so they have people to fire when word from the top comes down to drop the bottom 5%, you've got people to let go.
What is a good solution to deal with under performers from your perspective ?
- Keep them ? Let them suck and just be compassionate. They have stomachs to feed.
- Let them go over time, one by one. Can create a very fearful atmosphere where there is a sword hanging over anyone who can be let go for any definition of "under performance".
- Let them go at once, within a x% range, which probably gets decided based on a ton of things. But at least it is not slowly degrading the morale day by day. The downside is that if this a regular periodic thing, it can create a fiercely competitive and insecure environment in the company.
i'm not at Microsoft. But, think from prospective that someone could be having life event. Some put years worth of efforts that including physical, mental energy into MS ( or previous Nokia ) , planned something and now potential job loss could be trigger to disaster.
Boo hoo. That's how the world turns. Microsoft is not in it to save jobs, it's in it to make money. They have absolutely no obligation to keep someone if they don't need them anymore, just like any other company. It sucks that people are being laid off, but that just comes with having any job. You have to realize that at some point, it is going to end. It will suck when it does, but life goes on.
"i would suggest that you ask questions first or be quiet
the postfix author is using a VCS but he do not need
to provide access to you or me "
Anyone can criticise anything for any reason.
Criticism is so easy to generate that it is worth absolutely nothing.
The process they use works for them.
I guarantee that I could come into your place of work and criticise pretty much everything you do, pointing out that there is a better way of doing it (because there will be, from some angle).
This is not useful, and whether or not I am correct on any specific point it is unlikely to be well received.
If you can come into my place of work and find out that we don't have backups, we're not hashing customer passwords, everyone is sharing a single user account, or we don't lock the doors at night, please do criticize.
Rejecting widely accepted good/necessary practice like that for no apparent reason other than "it's working for us so far" is stupid, arrogant, irresponsible, and wrong.
In this case, however, the criticism is unfounded because Postfix is using source control internally. Whether the system is exposed to the public is inconsequential as long as it's being used.
There is no way you can spin it as anything even remotely close to okay if there was no change tracking in the Postfix project at all.
Not really, at least not in the sense that you mean here: The generation of machine code in shared objects. There is a distinct lack of definition between C syntax and the resulting machine code.
> The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages.
You can create C shared objects from Rust (or from a ton of other languages which generate native code). No big deal. It can do what you want.
> There is a distinct lack of definition between C syntax and the resulting machine code.
And more importantly: there is a distinct lack of similarity in behavior in this respect between vendors, versions, architectures, language features, ambient temperatures, and times of day. Change any of those things and you can get different output from your C compiler.
That's just because Rust is still in development, and tooling like that is developed incrementally. There's already an issue about automatically creating C headers representing a Rust library, https://github.com/mozilla/rust/issues/10530 (and Alex Crichton has even started working on a tool for it, see his comment).
Most of the non-technical people I know are very VERY upset with facebook and privacy, but are still using it in much the same fashion as they're still using their AT&T phone or Comcast cable despite their distaste for policy.
There's a good deal of nuance to these sorts of questions. For example, police may look at your house from the street in the visible spectrum, but may not look at your house from the street in the infra-red spectrum without a warrant.
The objectionable part is that it's not a regional issue. Vampires chasing money are everywhere and will relocate to follow the cash teat. This would've happened anywhere in the USA.
A few popular database drivers use escaping under the hood for parameterized query arguments. mysql2 ruby gem (and any rails stack on top of it) for example.
