Get Your 100+ Scenes ProThemes Right Now! & 50+ NEW Scenes Every Month! FULL Developer Rights Included!
Published On: Tue, Oct 10th, 2017

4 Mistakes That Could Make Your Best Developers Leave

Get Your 100+ Scenes ProThemes Right Now! & 50+ NEW Scenes Every Month! FULL Developer Rights Included!

Heading into 2017, Future Workplace and Kronos found that 87% of employers said that improving retention was a critical priority. As a tech recruiter, this might not have come as a huge surprise to you. After all, 62% of developers are open to new jobs, and they have plenty of options to consider.

Retaining developers is just as important as finding new ones. But if you’re not careful, your best efforts to do so could actually drive them away. To help you avoid losing your best developers, let’s discuss four employee retention mistakes that you should avoid at all costs.

You Wait for Them to Come to You With Feedback

A developer will come to you when they’re unhappy with their job, right? At some point, yes. But if you take a “no news is good news” approach to retaining them, you probably won’t hear about it until they’ve accepted a new position elsewhere.

Even if they have regular check-ins with their managers, take it upon yourself to meet with your developers on a recurring basis. More importantly, don’t prepare a long agenda for these conversations. Instead, let them do most of the talking. This will give you a much clearer idea of the challenges they’re facing. Plus, it’ll show them that you’re committed to helping them achieve their career goals.

You’re Asking Developers for Too Many Meetings

On the other hand, it’s important to remember that developers hate unnecessary meetings. You might have the best intentions, but if you start filling their calendar with too many check-ins, it won’t be long before they start ignoring you completely.

The most effective employee retention strategies keep developers top of mind. So ask every member of your team how often they’d like to touch base with you. Some might want monthly meetings, others might only need to speak with you once every year, and a few might not want any check-ins at all. Communicate to the team that there’s no wrong answer, but also that you have an open-door policy to discuss how things are going for them at work.

You’re Dismissing Their Suggestions for Improvement

Most developers have strong opinions, especially when it comes to their job situation or their work environment. When they share feedback with you, they want to know they’re being heard. Listening to them means doing more than nodding your head and jotting it down in a notebook.

While you should avoid making promises you can’t keep, be transparent about what you can do to address their concerns. If it’s a quick fix that you have the power to make, go ahead and take care of it. But if a developer asks for something that requires more work, tell them what is and isn’t in your power to change. They might not like your answer at first, but they’ll appreciate your openness over the long-term.

You Forget to Recognize Their Achievements

Quality code is easy to take for granted. When everything is working and customers are happy, it’s easy to forget to acknowledge the work that your developers did to make those things happen. But recognizing their efforts goes hand-in-hand with employee retention. If they feel that their contributions consistently go unnoticed, your developers could start testing the market.

Work with your engineering managers to discuss employee recognition ideas that will resonate with your developers. That doesn’t necessarily mean creating a cash bonus program. Maybe your team wants more time to learn new programming languages or the chance to attend a conference. It could also be as simple as letting them purchase some new reading material they’ve asked for in the past.

hr leadership

Get Your 100+ Scenes ProThemes Right Now! & 50+ NEW Scenes Every Month! FULL Developer Rights Included!

About the Author

Leave a comment

XHTML: You can use these html tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Pin It