Hiring, firing and more
minnenratta.wordpress.com
Hiring, firing and more
1–10 of 19 posts
Re: Hiring, firing and more
#2As an experienced software engineer, I did not find this to be particularly insightful. Some decent suggestions mingled into a whole bunch of bad ones. I also could not find info about who wrote this.
Re: Hiring, firing and more
#3As an experienced software engineer, I did not find this to be particularly insightful. Some decent suggestions mingled into a whole bunch of bad ones. I also could not find info about who wrote this.
I for one found the bad suggestions to outnumber the good ones by a large margin, to be honest.
Re: Hiring, firing and more
#4[deleted]
Re: Hiring, firing and more
#5This being on the front page makes me question the standards that the HN community has for managerial advice...
Anyway, bad hiring/firing advice is a lot like a bad hire/fire... Really bad. And this is almost entirely bad hiring/firing advice.
This is with the caveat that there are a lot of other good learnings in the original post.
Re: Hiring, firing and more
#6“Hire only for good reasons.” Well, yeah, that’s good if painfully obvious advice.
“Fire people whenever you can.” Don’t do this. “There’s often someone to fire, but not many opportunities to do so.” I thought you were hiring for good reasons, why the bloat?
“it is good to at least apply a low-frequency filter when passing along the “news”, so that good and productive people can carry on without too much hassle.”
Only if you’re their only connection to the real world, otherwise you’ll be quickly spotted for the bullshitter you are.
This is a weird article.
Re: Hiring, firing and more
#7I think I understand what the author is trying to get at - people are sometimes clearly incompetent to do the role they're in - but firing them is a necessity, not an opportunity.
In fact, taking every available opportunity to fire people is biased by the metrics you use. No metric of developer productivity is ever as good as actually working in the same team, and so you'll probably lose:
- anyone who writes tests and refactors code, for being slow
- anyone who maintains the profitable parts of your software, for not having a list of impressive new features they worked on
- anyone who takes time to help their co-workers, because they'll look less productive on paper
- your most senior, most multidisciplinary, and most intelligent employees, because they'll appreciate the first three groups the most, because they can get another job faster, and because firing competent employees sends the message that the business is struggling
Re: Hiring, firing and more
#8“Hire only for good reasons.” Well, yeah, that’s good if painfully obvious advice. “Fire people whenever you can.” Don’t do this. “There’s often someone to fire, but not many opportunities to do so.” I thought you were hiring for good reasons, why the bloat? “it is good to at least apply a low-frequency filter when passing along the “news”, so that good and productive people can carry on without too much hassle.” Onl…
Firing is not because of bloat, but because that person needs replacing - it takes time to detect bad hires; and also people change, even if they were a good hire a few years ago, now they may not any longer be good at that position in that company.
Looking back with hindsight at the firings I've participated over the years, in all cases it would've been better if they would have been done much sooner; and most of the doubtful decisions that didn't result in a firing actually should have.
In essence, firing/not-firing usually turns out into a tradeoff between avoiding some short-term pain ("it's hard to get a replacement right now, it will affect schedules") and a significant long-term productivity cost. And people tend to prioritize the short term problems, while almost always it's actually better to take the short term hit to build better results in the long run - so, as a rule of thumb, it should be expected that right now you're firing a bit too carefully and should be firing a bit more (but not too much, naturally).
Re: Hiring, firing and more
#9I think I understand what the author is trying to get at - people are sometimes clearly incompetent to do the role they're in - but firing them is a necessity, not an opportunity. In fact, taking every available opportunity to fire people is biased by the metrics you use. No metric of developer productivity is ever as good as actually working in the same team, and so you'll probably lose: - anyone who writes tests an…
This holds even at the largest companies. For instance it is reasonably well documented that when working for Microsoft the only way to get promoted is to work on new stuff.
Re: Hiring, firing and more
#10> #9 Hire only for good reasons. Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.
Being overworked is an excellent reason to hire. It shows that you are about to lose your team due to burn-out or extended sick leave. Good managers know that the work load has to be such that there is some built in 'down time' in the schedule and no amount of pressure cooking or death marching is a substitute for bad planning. Overworked employees are a management failure and if you are reading this to get actionable advice that means you.
> #32 Delivery dates…
The lesson learned should be to release incrementally, rather than in one go.
> #8 Fire people whenever you can. There’s often someone to fire, but not many opportunities to do so. When you are given a lot of opportunities to fire people, it is often due to a crisis situation and you’ll likely fire or otherwise lose the wrong people. People appreciate when you fire the right people, so don’t worry about morale.
No, fire people when you have to, and for the right reasons, definitely not 'because you can'. If you fire without having a good reason it will affect morale and in the worst possible way.
> #2 Don’t be prudish. If you fear that people will lose faith in you because of the foggy goals and dire situation statement you are painting yourself in a heroic corner.
I can't even parse that in the current context.