top | item 23746156

Ask HN: Best ways to retain qualified employees?

100 points| cryptos | 5 years ago

What are the best effective measures to retain qualified employees (in general and developers in particular)?

I'd like to read you experiences and maybe some studies or articles about the topic.

153 comments

order
[+] anw|5 years ago|reply
I can tell you how to not retain employees, and do the opposite of that.

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
>“important to the company” work that has to be done and your own manager always going along with it.

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
> Make sure all managers are spineless and won’t fight for their employees.

> 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
Other things that lead to people leaving:

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
> tie their bonus to hitting some kind of OKR even though that goal may be put on the back burner halfway into the quarter

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
A good old fashioned "corporate re-structuring" will also suffice for #4. While you are at it, cut pay by some percentage that just barely keeps the workers at their job and force budget cuts that systematically strip people of the tools that they need to do their work.
[+] analyst74|5 years ago|reply
My current place suffers from all of that!! But our retention is very high, and you can guess the reason.
[+] artsyca|5 years ago|reply
Have you ever heard of "the culture code?" it's a pretty good outline of what truly matters, and that's extreme belonging.

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
As someone who's been leading people for 8+ years and also who remembers why I have left places... here is a long but comprehensive list.

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
Amazing list!

> 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
So, what company do you work for? (Just asking for a friend :)
[+] Twisell|5 years ago|reply
Listen to them, I mean really.

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
This. When I get the impression that my expertise and suggestions don't matter that's the point when I mentally quit my job. That's always the first step, the original reason. After that it's only the benefits, good pay and all the other suggestions named here that "keep" me, but if those weren't there I will go. So not listening to your employees comes with a heavy price tag if you want to also keep them.
[+] lnsru|5 years ago|reply
I second this too. I started current position 3 years ago. In the first year I wrote 90% of the code and did many many propositions how to manage first development in the department of the very first hardware unit. In second year I saw, that these propositions are completely ignored. It was mind blowing to see how my manager ignored very detailed proposal how to save $200k buying less pricier hardware parts. Test system was never implemented... In year 3 and 4 I am doing bare minimum while seeking other opportunities.
[+] valand|5 years ago|reply
Up.

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.

[+] chrisulloa|5 years ago|reply
Definitely this... I have a manager who always has an answer to every one of my suggestions or comments on 1-on-1s where it feels like he thinks my complaints are unwarranted. You don't need to have an answer for everything, just listen and then come back with a good solution.
[+] gpmcadam|5 years ago|reply
The long answer, I believe, is to read and take to heart Daniel Pink's Drive. https://www.danpink.com/drive./

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
Pink definitely recommends paying above market rate, though. To quote the book:

"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
Pay.

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
1. Give them flexibility eg- work timings, wfh.

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 (2): Not everyone is just chasing money. I know several very good engineers I'd love to work with which have left to lower paid jobs because they got tired of internal politics and a bad culture, terrible tools and horrible projects. I personally value more (1) as long as my minimum for (2) is meet.

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
Promote good mental health.

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
Agency. Give them control over how they organize their work and their work life balance, and to the degree possible, what they work on. It can even be down to little things, like giving them a say in what work laptop they get, or what ide they use, or what coffee machine is in the office.
[+] Aeolun|5 years ago|reply
Unless it’s combining windows and mac laptops! Everyone should be on the same general OS architecture.
[+] silvestrov|5 years ago|reply
They want to things:

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
Personally as a developer I switched jobs multiple times. Most importantly because:

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
Money. We can argue here all day and pretend it is not money, but it is money. And I know people don't like to hear it, so it needs to be repeated. Money. With a capital M. Also applies for any regular employee.
[+] Goesby|5 years ago|reply
While I agree that money is quite important, but it's not the only thing that matters.

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
As someone who has been serially un-retainable to the point that I eventually got tired of it all and decided to take up consulting, here's my advice:

* 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
> do not wait until they are asking for raises.

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
For a lot of companies, a significant profit center is the delta between their employees' market rates and what they are paying them. Asking them to eliminate that profit is tough.
[+] C4stor|5 years ago|reply
Since a lot of good points have been raised already, I'd though I'd mention something else which have seen happening quite often :

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
I think this happens often and it’s because of a combination of two things. First the complexity of software development is not well understood by other teams so they can be fairly aggressive when something doesn’t “work” - like how could that happen. and second is that programming types also aren’t as assertive in defending themselves. They take blame and accept responsibility quickly.
[+] maxehmookau|5 years ago|reply
Ask them. Everyone has different drivers.

Some want money. Some want flexibility. Some want to work on groundbreaking projects. Some want a mixture.

[+] mping|5 years ago|reply
In short, make them happy.
[+] luckylion|5 years ago|reply
From my experience, adding to what has been mentioned: get rid of unqualified/underqualified and lazy employees, because few things are more annoying than having to work around other people's inability or do their work if they are lazy.

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
From personal experience, and as someone who has been in the same company for 8 years, and have turned down multiple offers, even for a compensation that's been magnitudes higher, I can list only one thing: The team(or at large fraction of the team). That's the only reason why I'm still around. Put a shopping cart wheel on a tank and it will break, simple as that. At this point, we can easily deliver large upgrades faster and more efficiently than anyone else. If I were to leave at some point, it will likely be with the entire team coming along.

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
Don't achieve profit at the cost of negative externalities; for example widespread health effects, environmental destruction, financial system collapse, Internet-wide insecurity, patent trolling, underfunded open source projects etc.
[+] dig1|5 years ago|reply
1. Paycheck on time.

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
1 late check completely changes the relationship
[+] PostPlummer|5 years ago|reply
Easily said: give them excellent managers.

People don't quit jobs, they quit a boss.

[+] danaris|5 years ago|reply
I feel like this is sort of begging the question; I mean, what makes an excellent manager? Why, the things that retain great employees!
[+] artsyca|5 years ago|reply
Calling a manager a boss already puts you one foot into employee mentality. The only boss is the investor. That's the team, the client's clients and the client in that order. Not everybody even knows this.
[+] mrkeen|5 years ago|reply
If they want to code, let them code. Facilitate it so they can spend more time coding.

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
Whether or not they know how to use JIRA only tells you whether or not they've used JIRA, not whether or not they're qualified.

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.