Ask HN: Best ways to retain qualified employees?
100 points| cryptos | 5 years ago
I'd like to read you experiences and maybe some studies or articles about the topic.
100 points| cryptos | 5 years ago
I'd like to read you experiences and maybe some studies or articles about the topic.
[+] [-] anw|5 years ago|reply
1.) Make goals unclear or constantly changing. Bonus points if you tie their bonus to hitting some kind of OKR even though that goal may be put on the back burner halfway into the quarter. Even more so if this includes their holiday bonus, and you have a minimum threshold of “accomplish 80% of your quarterly OKR and get 80% of your bonus. Get 79% or less accomplished and take home 0%”
2.) Make sure all managers are spineless and won’t fight for their employees. This includes managers from other teams piling work onto people who don’t report to them, but add “important to the company” work that has to be done and your own manager always going along with it.
3.) Make sure there’s a lot of good old boys club going on, especially if the “principle” engineer and the CTO go out to clubs every other night trying to wing man for each other. Also make sure there’s no accountability for these favorite engineers (or employees in general)
4.) Have a career framework that lets your employees know what they can do in order to get promoted or grow into another role (manager? senior level?). After a couple years of not promoting (most) people, then get acquired or change the entire structure so all of your employees are unsure if their work is actually going to help them get a promotion, or if that’s even an option anymore.
Finally, make sure feedback is treated like the plague. If somebody notices that the checkout page crashes every time someone uses PayPal, just ignore it. Somebody who isn’t the web dev has PR that fixes it? Let it live in limbo forever. Features require login but don’t tell customers until they get an auth error, and then have to refill out the form all over again? Not a problem. Why do you keep bringing up issues with the UX instead of rewriting our site in Angul...Reac....Vue.
[+] [-] apohn|5 years ago|reply
I've worked in some highly political large companies and one of the best managers I had would basically say "I know this is basically BS but there is lots of visibility on this so we have to show something." He'd then work with us to find the bare minimum we needed to do to to make it seem like we did a lot more.
It's a lot easier to tolerate crap if people just admit it's crap and your job is to shovel it. It's awful when a bunch of managers hand-wave and act like you're smelling roses instead of crap. Then they make you work 10X harder then you need to just so they can show their boss you are growing roses, not shoveling crap.
[+] [-] mrkeen|5 years ago|reply
> If somebody notices that the checkout page crashes every time someone uses PayPal, just ignore it.
Oh my god. So much these - especially the combination of the two. It's not hard to identify with the customer when building a service (especially if you use the product yourself.) It really angers me when I encounter a customer-facing problem, try to fix it, but instead I get shut down by my manager, who explains that it's not one of the company's OKRs this quarter.
[+] [-] chrisbennet|5 years ago|reply
Cut total compensation without cutting salary. A favorite cut is to reduce the quality of the insurance (and the cost to the company). The unilaterally changed your compensation without telling you let alone negotiating a new contract.
Pay people the minimum instead of what they are worth. The guy who can walk to work from his house - you know he's not going to leave if you underpay him.
[+] [-] sdiupIGPWEfh|5 years ago|reply
Been burned by this a couple times. Especially infuriating after all the effort that goes into crafting "acceptable" OKRs every three months. Mandatory training sessions, the stress of identifying metrics that are both measurable & meaningful, multiple one-on-ones with management to review them, acknowledging and signing copies, and then toss it all in the trash because we're changing priorities. But it's the core of your performance review and tied to compensation. The hell.
How common is this nonsense?
[+] [-] mbielski|5 years ago|reply
[+] [-] analyst74|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] artsyca|5 years ago|reply
We give out all sorts of signals and most in the tech industry are ambiguous, toxic and uncivilized.
Learn to read the signals and you'll break through to what matters most: culture.
[+] [-] mharroun|5 years ago|reply
1) Pay Fair at hire and try to keep it within the market as they grow in experience/skills.
2) Give opportunities to learn and grow based on their own personal/professional goals.
3) Be Communicative and Transparent when it comes to everything.... company/leadership asks, values, deadlines, hiring, firing, promotions. Attempt to have documentation/processes for these things so theirs no question in ambiguity or favoritism.
4) Have check-in's often and Listen to the wants, needs, issues of each individual. Attempt to quickly get back to them with a solution or at least an answer/explanation.
5) Create a 'culture of winning' where wins are always celebrated and mistakes/failures are treated as actual learning opportunities to improve.
6) Ensure everyone has a voice, it is heard, and people feel safe to be critical as long as its constructive.
7) Do everything you can to eliminate toxicity... weather is from members on/under you or above you. You cant stop others from being toxic but you should be able to shield most of it from those who report under you.
8) Since you should have the authority EVERY problem you have or those under you has and its then YOUR problem and your job to fix it (or at lease respond/escalte).
9) Judge people based on objective results not on "optics". Ass-in-seat time is a lazy and pointless measurement in most cases.
10) Delegate and empower those under you as much as you can. Lack of autonomy/ownership are signs of micromanagement, over-control, and poor leadership/delegation.
11) Accept a truth... your reputation/success as a leader is a direct aggregation of the success of those under you. If in anyway this is not the case there is a problem and that problem is you.
[+] [-] kevsim|5 years ago|reply
> 9) Judge people based on objective results not on "optics". Ass-in-seat time is a lazy and pointless measurement in most cases.
I'd only point out that as a manager one also needs to be aware of the optics because those can affect other team members. "So and so is never here" kinds of murmurings need to be dealt with (and dealt with by, as you said, ensuring that the team judges based on results and celebrates winning together).
[+] [-] alexeiz|5 years ago|reply
[+] [-] Twisell|5 years ago|reply
Especially when they suggest organization wide changes to improve workflow or work environment. Don't be the guy always dismissing suggestions or you can slowly but surely turn a proactive A player to someone that just do the bare minimum while seeking other opportunities.
[+] [-] emsign|5 years ago|reply
[+] [-] lnsru|5 years ago|reply
[+] [-] valand|5 years ago|reply
Also, this kind of people tends to be loyal to your product success more than you.
This will seem like they are fighting against you, but train your eyes to see the difference.
Also pair this kind of people with similar one. The goal is for them to counter and correct each other. It'll give them opportunity to grow.
[+] [-] PascLeRasc|5 years ago|reply
I've also really enjoyed Jason Fried's talks and writings about managing employees.
[+] [-] chrisulloa|5 years ago|reply
[+] [-] gpmcadam|5 years ago|reply
In short:
1. give them the ability to apply their own solutions to your problems - don't force-feed solutions as part of your problems. let dev teams use their own expertise to collaborate with the business to come up with the right answer
2. allow devs to pursue mastery of their field, give them opportunity to learn and experiment and become great at what they do
3. make sure that the thing you're building matters to your customers, so that your devs have a feeling of purpose. nobody wants to ship code that does nothing, for nobody. start measuring whether you're building the right thing (see Lean Startup)
People will say 'pay', but I think that only matters up to a certain point. I don't think anyone leaves a company offering all 3 of the above just because they aren't paid above market rate.
Best of luck!
[+] [-] muzani|5 years ago|reply
"Type I behavior does not disdain money or recognition. Both Type X's and Type I care about money. If an employee's compensation doesn't hit the baseline that I described in Chapter 2 — if her organization doesn't pay her an adequate amount, or if her pay isn't equitable compared to others doing similar work - that person's motivation will crater, regardless of whether she leans toward X or toward I. However, once compensation meets that level, money plays a different role for Type I's than for Type X's. Type I's don't turn down raises or refuse to cash paychecks. But one reason fair and adequate pay is so essential is that it takes the issue of money off the table so they can focus on the work itself. By contrast, for many Type X's, money is the table. It's why they do what they do. Recognition is similar."
[+] [-] odshoifsdhfs|5 years ago|reply
I know everyone says no, I want this or that, but at the end of the day, you are trading time for money. Only when people have enough money to not worry do they care about other things, and unless they are were getting 300k+ in a FAANG company for the last few years and now can live ok for a few years, pay is the important factor.
If you can't save a penny, even if work conditions are great, people will change to start building their 401k or to get their kid to a better school.
Then there is also the cultural factor that if a manager asks 'what kinds of things motivate you' if you just say money, you are branded an heretic, so people say independence or agency or whatever.
I would say (assuming they have another option of course) more than 95% of the people here and everywhere would change jobs if they got a 20% payout or something, so that probably says a lot about it.
[+] [-] mr_puzzled|5 years ago|reply
2. Pay above market rates and promote when it's deserved.
3. Allow them to retain IP of their side projects. People who want to build startups will eventually leave, but you can delay it with this. Considering most people will never reach product market fit, it's a win win.
[+] [-] midrus|5 years ago|reply
About (3), that just makes things worse in my opinion, people end up working for their CVs, their side projects, and their future company. You would certainly retain them, but not sure if that's the kind of people that will make your company successful.
After a given minimum figure for my salary, I personally would value more WFH, having good tools, being able to make progress and not feeling stuck because of bulls??t and a nice manager and team that focuses on getting things done and shipping. No amount of free avocado would compensate it for me.
So, to OP, (as someone commented elsewhere) just LISTEN to them and ACT to help them fix what they see wrong. That's it. I'd be surprised if the only things they want to stay is more money.
[+] [-] thomastjeffery|5 years ago|reply
There are so many social dynamics in employment that are detrimental to an employee's mental health: Arbitrary/unclear goals/deadlines, management not responding to criticism/feedback, favoritism, career stagnation, overwork, etc.
The most common reaction to an employee's deteriorating mental health is for the employer to get confrontational with the employee, and demand that they fix all the side effects. This just piles an extra stressor onto the employee. Very rarely is the deteriorating mental health addressed directly.
Employees are not machines; they are humans. Machines work with very tight tolerances, but humans are better suited to diverse problems. Machines require physical maintenance, but humans require a different sort.
Vacations can help, but they cannot solve or redeem the day-to-day frustrations an employee has. Paying well can help, but that is only valuable if the employee has enough personal time to spend it.
There are external factors, too. When an employee rolls an ATV during the weekend, and needs a few weeks to physically recover, it's totally normal to give them that time off; but when an employee is going through a divorce, losing their religion, etc. it is very uncommon for their employer to even know, let alone help.
The real goal should not be to retain (hold) employees, but to cultivate a workplace where they want to attend. Don't turn your workplace into a cult that demands too much of an employee's time or focus. Instead, make it a place for people to fulfill their need to work. Make it a place where ideas are shared, and things are made.
[+] [-] Joeri|5 years ago|reply
[+] [-] Aeolun|5 years ago|reply
[+] [-] silvestrov|5 years ago|reply
1) to work with people just as qualified, including managers who are just as qualified at managing (a rare unicorn in the IT sector)
2) not having roadblocks for doing good work. This includes being kept in the dark, micro-management, simplistic "all employees have exactly same computer" policies, workplaces that makes concentration difficult due to e.g. noise or splatter of meetings, weird requirements which can't be discussed at all and doesn't make sense.
[+] [-] clktmr|5 years ago|reply
1. I expect to be trusted. If there is no possibility to work from a remote location and excessive time tracking (e.g. punch cards) because of a lack of trust, I realized that my work was not valuated at all.
2. I expect to be able to use my own workflow. If I get micromanaged and am forced to use buggy toolchains and processes with lots of dependencies, my productivity will suffer and so will my passion. Define the inputs and outputs of my work, but not anything in between.
3. Growth is more important than high pay. I am not talking about a 2% raise every year. There really needs to be a difference based on performance. I throw myself into something and get the same pay rise as if I had been slacking the whole year. This will not lower my performance, it will make me leave.
[+] [-] a_imho|5 years ago|reply
[+] [-] Goesby|5 years ago|reply
A few weeks ago I interviewed for a job with a 50% salary increase compared to the current company I work for. All went well until I had an interview with the manager. He was the kind of guy I would not want to work with. He gave me the micro-manager vibe and mentioned a few things that made me turn down the job.
I'd rather work with a good and nice manager than have a 50% salary increase.
[+] [-] ryandvm|5 years ago|reply
* Pay them their market rate. DO NOT WAIT UNTIL THEY ARE ASKING FOR RAISES. Nothing makes you feel unappreciated like not being fairly compensated. If I have to ask you not to rip me off, the relationship is already on very rocky ground.
* Give them interesting things to work on them and empower them to solve them creatively. Do not micromanage competent people.
* Let them have skin in the game by giving them a non-trivial stake of ownership. Nothing makes you go the extra mile like knowing that doing so is furthering your own success.
[+] [-] Joeri|5 years ago|reply
This really annoyed me with a previous employer. They gave me every raise I ever asked, but they always made me ask, and they never gave me more than I asked. It took all of the goodwill out of the raise.
[+] [-] jnwatson|5 years ago|reply
[+] [-] C4stor|5 years ago|reply
Often times development teams are applying all kind of processes and reporting are taken accountable for the bug they make, and are overall held to a high standard of quality. All the company is able to consult the backlog, ask questions, whatever, it seems good, and they're ok with it in general.
But then, the dev team may very well fell like all the other team are basically doing the exact opposite. Maybe the sales team will never admit a single failure to close on its team side, the product one will never admit its specs were flawed, the marketing will never admit its creatives where delivered too late, etc...
And that perceived unfairness may be a deal breaker for engineers in my experience. They don't care for example (or even know) if the sales guys have to go to nightclubs until 1am to land a deal while they clock out a 6.30pm, they value visible equality of treatment.
So to retain certains developers, company wide "fairness" may go a long way. (I use quotes because I'm not 100% sure this is the correct english term).
[+] [-] ajeet_dhaliwal|5 years ago|reply
[+] [-] maxehmookau|5 years ago|reply
Some want money. Some want flexibility. Some want to work on groundbreaking projects. Some want a mixture.
[+] [-] mping|5 years ago|reply
[+] [-] luckylion|5 years ago|reply
You can keep the un-/underqualified by improving their skillset, I've not seen the lazy improved, but maybe that's possible as well.
[+] [-] axegon_|5 years ago|reply
So yes, be clear about what the exact responsibilities everyone has and build up a solid team where everyone fits in.
[+] [-] pabs3|5 years ago|reply
[+] [-] dekken_|5 years ago|reply
https://en.wikipedia.org/wiki/Tragedy_of_the_commons
[+] [-] dig1|5 years ago|reply
2. Be honest regarding company state and finances. The worst thing is that you tell everything is OK, the company is doing well, and suddenly you have to lay off half of your staff.
3. Flexible hours and projects. Development (and solving problems) is an art, not cranking something like in a factory.
[+] [-] treeman79|5 years ago|reply
[+] [-] PostPlummer|5 years ago|reply
People don't quit jobs, they quit a boss.
[+] [-] danaris|5 years ago|reply
[+] [-] artsyca|5 years ago|reply
[+] [-] mrkeen|5 years ago|reply
If they're qualified, they know how to use Jenkins and Jira, when to script and whether to automate. If you start regulating Jira with excessive rules (classifying as epic or story, team, feature, sprint, component, DOD, estimate, only work from top of backlog, etc.) then a dev is is really going to be disincentivised from using it.
[+] [-] pc86|5 years ago|reply
And in my experience, most developers (myself included) will just not use those tools if they're not required to. And if you have no idea what level of information you're going to get from an epic, story, bug, task, or subtask until you know who wrote it, the tool is largely worthless.