Basically how did it become acceptable for software engineers to always be job switching? I am a recruiter for my company of about 250 and we employ 15 software engineers. Half my time is spent replacing them. Only one of them has been at my company for more than a year and he is the lead. The average tenure at the moment is 5 months.

And they are willing to quit over the slightest of things:

  • One quit after his request for a paid software tool (a specific IDE) was denied. (They were instructed to use a specific freeware IDE)
  • Another quit after 3 months as he didn't know how he was evaluated (we use Scrum, so there aren't close performance stats as that defeats the project management style).
  • Yet another quit over not seeing a clear promotion track technically.
  • The rest claimed that they "found new opportunities."

Seriously, why is this behavior considered acceptable in the software community? What can we do to encourage them to stay longer with us?

  • 32
    As a recruiter, you surely have access to those people's CVs. Have those same developers jumped jobs so easily before? And in that case, why don't you only hire people who have a tendency to stay longer? Commented Dec 9, 2019 at 20:54
  • 75
    If I was denied tools to do my job, which would further improve production and quality, do they even care about their products besides sales? If I don't see a possibility to grow I'd jump ship too. To me it could be an indication that: They dont care about their product besides sales. They dont care about quality. They dont seem interested in investing in their employees so they can learn, be more productive and grow. The ones that found other opportunities went to companies that do care about their employees. The ones that stick are just content with not having the things others left for.
    – Wesley
    Commented Dec 10, 2019 at 11:34
  • 19
    One of the most true things I've ever read is that every job pays you in two ways. It pays your bills, and it pays you in knowledge so you can hold a job later (even the same job after the market changes). If either of those stops, it's time to get a new job. And yes; I left my last job because there was no promotion path. In my case, they offered me the moon and a promotion path after I handed in my resignation, but it was too late--they'd been telling me the same thing for over a year, and I had no proof they'd actually follow up on it.
    – user62890
    Commented Dec 10, 2019 at 14:01
  • 9
    @Chan-HoSuh i think the OP cares about what is obviously a very wrong situation - rather than being a typical psycopath who cares only about their KPIs and quarterly bonus. This is to be commended. Commented Dec 10, 2019 at 17:30
  • 14
    If you (try to) employ developers, why won't you let them use developers' tools? Or make sure they have them available? Edit history shows "Jebrains" being denied. As a daily user of PhpStorm, I too would quit if you denied me using it. On the spot. "Sorry, we don't have a licence for you." scoffs "ok, bye". I bet, as a recruiter, you use some sort of CRM software thing to keep track of people you've contacted, is that free? PhpStorm (and pretty much any tool by Jetbrains) are the basic development tools for a host of languages (PHP, Android, and extensions for C# in Visual Studio, etc.)
    – rkeet
    Commented Dec 10, 2019 at 19:59

26 Answers 26


If you have a hard time holding on to people, the problem may not be the people.

Something to consider... Software engineers tend to dislike change to a very high degree. The fact that they are changing from your company should make you think about what is going wrong.

I can see software engineers asking the questions:

  • Why is the company too cheap to buy the tools I need?
  • Why won't the company give me any feedback?
  • Why should I stay with a company where I see no future?

The ones who told you they found new opportunities were just being polite.

Our company is hemorrhaging people now, and for similar reasons.

Software engineering is an occupation where effectively any job will be enough to pay the bills, so if they feel mistreated, they will move on because the job itself has so much stress.

When you are in a career where:

  • Your management rarely understand what you do
  • Deadlines and demands rarely have any basis in reality.
  • People who have never written a line of code tell you how to do your job
  • Whenever there is cost cutting, you are the first ones out the door.

And much much more, your tolerance level for BS is very very low. Software engineers aren't motivated by money, they can get that anywhere, so the environment is what matters, listen to them.

TLDR: Your employees are telling you why they are leaving, listen to them

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Commented Dec 10, 2019 at 12:09
  • While I totally agree with the first part, the bullet points from the second part can likely be applied to nearly every job (with a little adaptation, as other jobs don't deal with code). As a formatting improvement suggestion: I'd highlight the important parts where developers stand out, e.g. that they are very sought after at the moment and most jobs pay the bills anyway. Currently it's the bullet points that stand out making that part a bit ranty imho. Commented Dec 12, 2019 at 12:08
  • 28
    Software developers are not motivated by money: It's the environment that motivates them to do a good job, not money, that's true. But lack of money will motivate the to do a good job elsewhere :-)
    – gnasher729
    Commented Jan 15, 2020 at 23:31
  • 12
    With other words: people join companies and leave managers.
    – virolino
    Commented Jan 16, 2020 at 11:41
  • 2
    @gnasher729 "Software developers are not motivated by money". That's obviously not true. It might not be the main motivator for many people but it's definitely one. Commented Jul 17, 2020 at 13:06

Tl;DR: Raising complaints is expensive. Leaving is cheap. The hunt to leave can be fun. There are lots of places for engineers to go. Companies do a lot of things to make people want to leave without realizing it, including saving $250 on IntelliJ by driving away a dev who cost 10K to recruit.

Here are my thoughts:

  1. It is probably not just your software engineers who are unhappy. They just have the easiest time leaving. I think it is a mistake to believe that everyone else is staying out of a sense of duty or obligation to the company. If every person in your organization had a job offer in hand today, I doubt that the coders would be the only people leaving. Most employees are ready to pack up and go if they find something better. The only reason developers have higher turnover than others is that we get options constantly thrown in our faces and job boards send us new opportunities every week on mailing lists. Every day Indeed sends me job opportunities from when I signed up months ago. Companies have a lot more captives than they realize.

  2. Raising problems requires conflict. Plenty of software engineers are conflict-averse. Many of us got into the field largely because we didn’t want to have to deal with as many human factors as other high paying careers. Engineers also tend to be blunt and over time realize that gets them in trouble around non-engineers so they just shut up. That means that many software engineers would price out that talk with the manager as quite “expensive” in terms of misery. I’ve never raised a frustration with my manager in my life. Same with most people in tech I know. They just endure until they see where the grass may be greener.

  3. Job hunting for engineers isn’t as soul-sucking as it is for other professions. I admittedly kind of miss it as it can be exciting (when you don't absolutely need a job). Many companies want a project, so you get exposed to new technologies and new domains in the course of a couple hours. It’s like a hackathon and I love those. It isn’t the same “write a cover letter and fire into the void” which it is for other jobs. This makes job hunting cheap in terms of misery or even fun in itself. If you don’t need a job, job hunting can just be an individualized hackathon.

  4. Software is software. The industry often doesn’t matter. It is not clear to me that domain knowledge of an industry is valued in software. You use Scrum, as does my team. As a developer, that just means I convert small blurbs of words from the business analyst into a feature. I generally don’t know why the feature is wanted or how it fits into the big picture. Scrum makes it easy for developers to just be added on to a project. This project management approach makes any company using the same tech stack an option, giving every tech employee a myriad of options compared to a HR specialist (where industry matters more).

  5. Not having good tools can make development miserable. If you are not a coder this is hard to understand, but go ask any of your people and they will happily go on for hours about terrible tools. Seriously, not having good tools is worth leaving over. A friend went to a place where they wanted him to use Notepad++ and coding in production (as they didn’t want to pay for a dev site or a QA site). He lasted just a month. The extreme case, but there are plenty of companies willing to pay for proper tools.

I admittedly am not sure on what the solution might be to your problem rather than guess at what will retain them and proactively provide it. Past experiences likely mean they won't be willing to tell you why they are leaving.

  • 103
    #5 is a huge issue - denying developers the tools they need to do a good job doesn't just make management look cheap, it makes them look clueless. It's on a par with refusing to buy the janitor a vacuum cleaner yet still expecting the carpets to be spotless. Commented Dec 9, 2019 at 7:00
  • 16
    Dev here: I have to agree on every point. I am a conflict-averse developer who comfortably earns far more than a living wage in any job I work in. I am in my current job because I like the people and the work represents a dramatic increase in my skillset (and consequently paycheck) for relatively little stress. I get recruiters emailing me dozens of times a day and a lot of those jobs are better on paper than my current one. I'm still here because I want stability for a year or two while I get married and settle down to build a family. Commented Dec 9, 2019 at 9:45
  • 25
    I disagree on your statement of domain knowledge. A sufficient understanding of the application domain is one of the most important things when developing useful software. Developing always requires you to make assumptions how the software is going to be used. If you do not have domain knowledge you cannot judge whether your decision brings the user closer to their goal. Many companies tried to counter this by degrading developers into code monkeys that "convert small blurbs of words from the business analyst into a feature". Absolutely disgusting way of treating developers IMO
    – Manziel
    Commented Dec 9, 2019 at 12:10
  • 29
    "f you are not a coder this is hard to understand" try to maintain a spreadsheet without using an office software. No MS Office, no Google Docs, no OpenOffice, no Libre Office, etc.
    – VLAZ
    Commented Dec 9, 2019 at 12:39
  • 12
    "2. Raising problems requires conflict. Plenty of software engineers are conflict-averse." I disagree with the semantics of this; I dont raise issues because I (a software engineer) am conflict-averse, but because it's a bad idea. More often than not it will mark you as someone who is disgruntled and will (ironically) leave soon without solving the underlying problem. It is more advantageous to me to simply leave and say "it's just not a good fit." Also, while perhaps not entirely inaccurate, this is stereotyping.
    – schil227
    Commented Dec 9, 2019 at 15:03

It's acceptable for software engineers to job hop if they have better opportunities. The unanimous consent of your developer-employees is that your company is not a good opportunity. This is of little surprise, based on the feedback you receive, combined with your disregard for the same.

You are calling

  • "no promotion track",
  • "no feedback" and
  • "no payment of essential tools"

the "slightest of things".

Solely the disregard for your employees, which your company demonstrates makes it acceptable to quit - you call it "job hopping," assuming that the fault is on the side of the employee, and that all other companies experience this issue. They are not "job hopping", they are quitting, as quickly as they came. You should take the feedback you get more seriously and think about the underlying issues. There is a cost involved when changing a job, on the side of the employee, and that people leave so quickly should tell you something.

Software developers may job hop at times, and this may also be a viable strategy to increase salary, but based on your company's numbers, this is not the issue here. Something else is.

  • 32
    I wonder if OP started their recruiting career during the recession. The thought process of this company says that they think people should be grateful for being employed. Commented Dec 9, 2019 at 5:49
  • 11
    @Mars That the employer can't hold ANY of his employees speaks for itself. I'm a software dev, and if I'd quit over JetBrains tools, it's reasonable to think that an (to me) essential request was denied
    – ig-dev
    Commented Dec 9, 2019 at 6:04
  • 25
    @Mars I wonder if JetBrains was just a long line in a list of denied requests. No JetBrains, I would be annoyed, but could live with that. But then there are the companies where they don't want to pay for a QA environment or a 2nd monitor or a bug tracking tool. The kind of company careful about spending $200 once on a tool a programmer will use all day is going to balk at Jira or be picky about the AWS spending for testing on an actual server. Commented Dec 9, 2019 at 6:27
  • 4
    @MatthewGaiser You had a great point about the $250 once vs $10k to rehire, but it's kinda jumping to assume that they won't pay for anything. That's the kind of thing that should be clarified, not assumed
    – Mars
    Commented Dec 9, 2019 at 6:35
  • 18
    If this job is Java based then Jetbrain's IntelliJ is absolutely essential and I'd quit too rather than go back to using Eclipse Commented Dec 9, 2019 at 16:25

The average tenure at the moment is 5 months.

Look at it this way: The company failed their probation period with them. They looked at the company from the inside and said "yeah, not good enough, not what I wanted". Shockingly, that is exactly what a probationary period is for.

One quit after his request for a paid software tool called Jetbrains was denied.

Well, if I request a tool that is for the benefit of the company, making me more productive (at the same price, I don't get a raise) and it gets denied, that means multiple things: the company did not trust my judgement, the company does not have senior that they trust enough to support a 200$ decision and the manager would rather save 200$ than see me more productive. That is not a red flag. That is a parade with a marching band and a flag corps. How would I ever get a raise in a company that is too cheap to spend 200$ on their own success?

Another quit after 3 months as he didn't know how he was evaluated (we use Scrum, so there aren't close performance stats as that defeats the project management style).

So did you change that? If not, why not? Scrum does not mean you cannot have meaningful 1:1 talks about how one does in the company.

Yet another quit over not seeing a clear promotion track technically.

So did you change that? I see no problem building a track of junior, mid-level and senior widget maker, maybe a widget architect even.

The rest claimed that they "found new opportunities."

That means they are too polite to say for what you pay, you don't deliver enough value. Lets face it, it's called capitalism for a reason. If somebody else pays more than you do... they will get the developers. Nobody quits over no clear promotion strategy to go to a competitor and make substantially less money. They have an offer to get considerably more and you offer nothing to keep them. Not money and not the other things they ask for.

Seriously, why is this behavior considered acceptable in the software community? They are the only profession that quits at the drop of a hat.

I wouldn't say it's acceptable. It's still job hopping and it still shows bad judgement on the employees part, because those questions (tooling, project management, career path, money) should all come up in the interview. But if the next employer is happy to have them, then I guess it's not that important.

Another thought though: if you hire people, they show up for work and are not happy and move elsewhere, maybe your hiring strategy does not fit your workplace? The market is looking for developers like crazy, people don't just randomly grab one offer and run with it to quit a few months later. At some point it must have sounded like the best offer and at another point, the reality working at your company was different. Make sure you sell the reality in interviews. Show them what they will be working with, show them the rooms, let them meet their future colleagues. Pay them at market rate or above if your company has less perks than others. Then there should be no reason to switch.

  • 56
    @CrabbyCoderKing So your strategy is too look voor devs that don't mind quiting their job for a different oppertunity, and are then suprised that those same devs don't mind quitting your job for a different oppertunity? Perhaps you should re-evaluate your hiring strategy.
    – Imus
    Commented Dec 9, 2019 at 9:26
  • 19
    "our pitch is mostly to people inclined to quit" Then you act surprised when they quit? What? It kind of to me sounds like you need to go back to recruiting school! Commented Dec 9, 2019 at 12:25
  • 2
    @Imus Every company looking for seniors (or rather non-juniors) would have that problem. This doesn't explain OP's problem of retaining these people. It's more likely they are experienced enough to find out they are in a bad environment and can get a better job once they see the reality. And yes quite a few companies don't hire Juniors or at the least only if they are overwhelmingly good. The company people wondered most that I left one day as it was so rare to happen was exactly one that aimed at only getting experienced people - but they focused on providing an awesome atmosphere! Commented Dec 9, 2019 at 15:47
  • 4
    @CrabbyCoderKing One point about your logic regarding juniors: It's true that training juniors can put a strain/negative for some people/developers (some do like it - if the juniors show the right attitude). It's however also true that there are often simple tasks that fit juniors very well and that bore seniors to death. You need to judge which is more of an issue in your environment. From your current input I don't see the lack of juniors as a problem, but it could also be an issue in principle, you might want to double check. Commented Dec 9, 2019 at 15:50
  • 33
    Our niche is trying to be people's 2nd dev job there is a lot unsaid in this sentence. Wanting to be the 2nd dev job comes from a place of not wanting to invest in your devs. You dont want to put in the effort and cost to train them, so you hope to lure them away from the companies that did do that investment on the cheap. The only reason experienced devs would quit over coaching juniors is because it was the last straw and they were halfway out the door already. I can tell for a multitude of reasons that being a dev at your company is a nightmare worst case scenario
    – Josh
    Commented Dec 9, 2019 at 19:46

You clarified this in one of your comments:

The manager of the dev team doesn't like paying for software

What you are essentially saying is that management doesn't like paying for their developers, beyond just their basic salary. They are probably given sub-par tools for the job. JetBrains licenses are only a few hundred dollars a year. I can practically guarantee that the company is losing more money than that on the turnover rate and on employee salaries. A license for a proper toolkit is a small price to pay.

This is like employing a painter to give your office walls a fresh new look, but the only "paint" given to them is dirty dishwater and some old paint that you found in your tool shed from 20 years ago, because "management doesn't like paying for paint".

If you have the power to change anything, start there.

  • 4
    I agree with this. How can you expect a painter to paint without a paintbrush, edging tape, etc. Commented Dec 9, 2019 at 12:20
  • 4
    "Manager doesn't like" may ultimately translate into them being measured partly on expenses. That's typical in corporate environments. It's devastating to software development where you pay people 100,00's of dollars as others note. Make sure to do time calculations to show the cost of being cheap as part of your argument. Don't exaggerate (really no need to). data usually helps win the day Commented Dec 9, 2019 at 12:29
  • 7
    In the original comments, the manager said that Notepad++ was an acceptable substitute... Commented Dec 9, 2019 at 22:08
  • 6
    @MichaelDurrant - You can easily pay for IDE licenses by offering a few hundred dollars less per position, putting the money towards a yearly budget, and continue to invest in your infrastructure. A couple hundred dollars won't be what prevents somebody from accepting a job, but a management team, that refuses to purchase an IDE that will help with productivity is very often a valid reason. If somebody does not accept a a job offering $xx,750 instead of $xx.950 they are likely looking for something else you cannot provide anyways
    – Donald
    Commented Dec 9, 2019 at 22:09
  • 2
    I've had one project where we had to develop a complete CRM system and the only thing we were allowed to use was the standard office PC for the (government) department which had MS Office and notepad on it and that was it. We weren't allowed to even install a compiler or use the internet to access information. People like OP would probably think that an acceptable situation as well. We ended up giving them stern warnings about the severe limits of an Access database as a multiuser system and were told to build it anyway... Last I heard of it they were trying to implement it for 2000 users.
    – jwenting
    Commented Dec 12, 2019 at 8:26

how did it become acceptable for software engineers to always be job switching?

The software industry, perhaps more than any other, rewards disloyalty and punishes loyalty. You should not be surprised that people do what they are incentivized to do.

So, how then did we end up in a situation where disloyalty is rewarded?

Half my time is spent replacing them.

Are you hiring them away from other software companies? If so, you are rewarding disloyalty, so now we know how we got there. You did it yourself.

One quit after his request for a paid software tool called Jetbrains was denied.

And now we come to the "punishing loyalty" side of the equation. An employee told you how they could be more productive for a reasonable price and you punished that behaviour.

But don't just look at it as punishment; look at the bigger picture. Software engineers typically reduce costs or increase revenues by, let's say 4x their compensation. If you're paying let's say $100K a year, that's $400K in revenues or cost savings. And you're telling this person that a $400 tool that makes them more productive is not worth paying for.

That is, no offense intended, stupid from any reasonable business perspective. Software engineers recognize stupid, and if your shop is being stupid about trivial stuff like a JetBrains subscription, what more important stuff is your shop being stupid about?

Another quit after 3 months as he didn't know how he was evaluated

Whose failure was that exactly?

Yet another quit over not seeing a clear promotion track technically.

Your characterizing this as "the slightest of things" is telling. This is that "more important stuff your shop is being stupid about".

why is this behavior considered acceptable in the software community?

I understand your frustration but getting an answer to that question will not help you solve your problem. The correct question to ask is how can we instill a feeling of loyalty in our new hires? and the answer to that question is loyalty cannot be bought with coin; it can only be bought with loyalty, respect, enthusiasm, and genuine concern for your employees' well-being.

The message you are sending loud and clear to any employees who have the misfortune to work in your shop is "we do not value your skills or contributions, we will not clearly communicate with you, we will not respect you, and you'd be better off elsewhere". The onus on saying why they should not leave is on you.

  • 6
    In order to keep software engineers you must identify reason they are leaving your company. Only when you have identified what your company is NOT offering (compared to other companies) can you start to increase the amount of time your software engineers stick around. 5 months is an extremely short amount of time, and is an indication, the problem is with the company not the employees.
    – Donald
    Commented Dec 9, 2019 at 22:05
  • I'd go even further : software developpers are seen as throwable commodities, not as valuable professionals. They're far from the only ones - they just happen to have more opportunities to give their opinion on the topic (with their feet).
    – gazzz0x2z
    Commented Jul 23, 2020 at 12:59

You clarified this in one of your comments

Our niche is trying to be people's 2nd dev job, so our pitch is mostly to people inclined to quit. [...] So everyone we hire is poached from somewhere or applied to the posting.

You specifically hire people who are prone to "job-hopping", so you must expect for them to be likely to job-hop. People who were more inclined to quit their last job will also be more inclined to quit a new job if management denies them reasonable requests.

  • 23
    Not only that but wanting to be the 2nd dev job is indicative of an unwillingness to invest in your devs. You aren't willing to train them, you want them to come in pre-trained by someone else. You wont cover a $200 license that makes your devs more productive. You wont give them any path to promotion. Any employee with options would feel very quickly in that environment that they were just a paid tool to be used by the company and should have no ambitions or drive outside of their salary. I'd jump ship first chance I got, too.
    – Josh
    Commented Dec 9, 2019 at 19:53
  • 1
    Also, given this is job #2, they have a better understanding of what office life is like. They can directly compare their new experience with the old one. If your workplace doesn’t meet their standards, they already have proof the grass is greener elsewhere. And unless they burned bridges, they may already have a “soft” offer in the back pocket from day 1, either from their old company or someone else they met during their last job hop. Contrast this with new hires, who can’t see these red flags because they don’t know to look for them, and are likely to be more loyal.
    – DongKy
    Commented Jul 23, 2020 at 13:55

The premise is wrong - at least for your case:

It is not generally acceptable for software engineers to job hop!

While it is arguably somewhat more common for software engineers to switch jobs more often nowadays than other more traditional professions, the times OP mentions in the question are well below accepted standards.

Just because people hop away from your position doesn't mean they hop away everywhere.

The accepted average for developers to stay at the same job is around 2 years. At some places developers will stay way longer and at some less - often simply due to project type and structure. Regular hopping with very short stings below a year or even 6 months is typically indeed not acceptable at most "good" companies (unless well explained/due to project structure etc.). Those good companies can be picky as people want to work there. They attract developers. Beggars like your company however, cannot be choosers and obviously don't belong to the places where people want to stay, but rather seem to start looking soon after having started. This is not normal behaviour. This indicates problems at your company.

As other answers have already pointed out, each individual case you mention indicates a clear problem at your company that should be addressed. Be thankful that you have such feedback, it can help to improve the situation.

One quit after his request for a paid software tool called Jetbrains was denied.

By now it should be clear from the comments that this is an easy way to tell a developer you don't care for giving them proper tools. Even if Jetbrains weren't considered industry standard (depending on development language/project), investing a tiny bit extra compared to salary to give developers the preferred tool they will work with every day goes a long way. Proving with your reasoning why you deny them their tools that you have barely an idea what you are talking about (or are close minded at least) goes also a long way - in the other direction...

Another quit after 3 months as he didn't know how he was evaluated (we use Scrum, so there aren't close performance stats as that defeats the project management style).

Doing scrum and giving personal feedback has nothing to do with each other. You can easily have 1:1 and give proper feedback how someone is doing while using scrum to organize your project work. Simply using project stats as a performance basis alone isn't a very good way to provide feedback either by the way.

Yet another quit over not seeing a clear promotion track technically.

Well, do you have a promotion track? Is there any way developers have clear goal posts in how they can move up? Any higher level dev positions like architects or the like?

The rest claimed that they "found new opportunities."

Better opportunities likely. So maybe check where they went if you can and see what might have attracted them. Many position descriptions nowadays list quite a few perks that might include "use the IDE of your choice" and "get free fruits every day" etc.

Side remark: Salary

Some answers mention salary. However, none of your feedback so far mentions salary as a reason. After a certain threshold money isn't the main attractor for developers (and many other professions). It's just the easiest way to compare when switching because company culture (including internal organisation, processes, side-perks etc.) you can hardly judge upfront. On the other hand, company culture is the strongest way to push away people. As OP's company seems to do fine in attracting people, I don't think that salary is a main reason - at least I don't see any indication for that. It's just that the company culture seems to suck from the perspective of a developer.

  • 4
    +1 for going against the "salary salary salary" answers, but it's pretty undeniable that at least US engineers are notorious job hoppers (compared to other industries and countries! Dunno if this is US-based OP though). OP also mentioned that they poach young employees hoping to be their second company, so they're clearly picking job hoppers to begin with
    – Mars
    Commented Dec 10, 2019 at 0:40
  • 1
    The rest claimed that they "found new opportunities” - I take this as a generic reason, something I would say, if I found a job that satisfied some requirement that wasn’t being fulfilled (like compensation or location).
    – Donald
    Commented Dec 10, 2019 at 1:29
  • Salary wouldn't be the reason to leave (I wouldn't have started in the first place if salary was the reason to leave 5 months or two years later). Broken promises about salary might be. And if there are reasons to leave, salary might be the reason to stay.
    – gnasher729
    Commented Jan 2, 2020 at 12:45

The simplest answer is because recruiters are calling and opening up opportunities for them.

To your specific examples....

One quit after his request for a paid software tool called Jetbrains was denied.

Once you get used to certain ergonomics of this software, it's really, really, really hard to live without it. To a non-programmer, it will be like someone replacing your keyboard with a different order of letters with some letters missing and you'd have to type in awkward combinations to get the missing letter to show up. Sure you can learn but what if someone calls and tells you "you will be doing the same thing you're doing there... but with a keyboard of your choice, maybe even a higher pay."

Another quit after 3 months as he didn't know how he was evaluated (we use Scrum, so there aren't close performance stats as that defeats the project management style).

I'd certainly like to know how I'm evaluated too, so this is not exclusive to software engineers. Scrum is not an excuse for skipping over performance assessment, what's the incentive to deliver results if everybody will be treated and evaluated the same? e.g. "You mean I'm getting the same bonus as this developer next to me who sleeps half the time at his desk?"

Yet another quit over not seeing a clear promotion track technically.

Another thing not exclusive to software engineers. The only difference is that there are recruiters getting in touch with software engineers.

The rest claimed that they "found new opportunities."

There's definitely a lot of opportunities out there.

  • 4
    As someone who has to use many different softwares, I can attest that it is not "really, really, really hard" to live without any particular software. For most people in the world, for most jobs in the world, that would just be considered spoiled
    – Mars
    Commented Dec 9, 2019 at 5:12
  • 20
    Well, as someone who uses a specific Jetbrains tool, I can attest that I would consider quitting too, if it were denied. Can I work without it? Sure. Do I want to work for someone who is so mentally challenged with grammar school math that they don't see that buying a 300$/year industry leading productivity tool is a steal? Even if said tool only increased my productivity by 1% , it would still be worth it's price. So it's not whether I can or cannot work with it. It's more about do I want to work for someone that makes my life harder on purpose?
    – nvoigt
    Commented Dec 9, 2019 at 6:34
  • 1
    @mars regardless of experience, this is a personal issues. really really really hard for one person is not a big issue for another. I've gone through various IDE phases and now back to vim. too many factors for black/white i think Commented Dec 9, 2019 at 12:24
  • 2
    @Gaius Scrum by itself on the position description says nothing. It may be they actually do scrum. It could be it works for them. It could be they are forced to do it (from some managerial layer because that's what everyone does now). It could be they do some other Agile approach and don't know better. I'd at least clarify what that exactly means for them before directly flagging based on a single word whose meaning gets more and more eroded (just like 'Agile' on the "other end of the spectrum"). Commented Dec 9, 2019 at 15:53
  • 3
    @Mars welcome to the real world, you've clearly never worked with tooling where one shines and the rest of the pack feel like a horrible grind and constantly try to slow you down and prevent you getting your job done.
    – jwenting
    Commented Dec 12, 2019 at 8:28

Tend not to answer questions having great answers but would like to spotlight different angles:

It is not what you do: Company with a headcount of 250 which employs 15 software engineers or roughly about 6% of its workforce. This means that you are not a software company nor a high-tech one. A difference of our field is that it requires different management style than more rigid/established sectors where things have become more predictable or scripted (see: The Command and Control Management Method). One suggestion to mitigate this would be to outsource development and keep only system administrators or people who will handle integrations on board, if you do not want your organisation to learn how to manage in a different way. Alternatively you can split your software engineering team to a different corporate structure.

Your management is bad: Without knowing the person assuming from your words and resemblance with past experiences, your tech lead has no leading skills. He tolerated the situation more than his ex-colleagues, kept his mouth shut, and now got a tech lead position only by being the "last man standing". Pushing the argument could even suggest that he was worse than the people that left (see: "Dead Sea Effect"). Also do not see any indication of you training him for this role. He will remain a bad manager as the handling of the "specific IDE" incident proves, thus becoming an extra if not the new primary reason for people leaving.

Promotion tracks: Added this to illustrate how the field is different: In most places there is one path: Junior, Senior, Manager, Manager of managers, member board. In creative industries there should be two: managerial and technical. Technical roles can lead to systems architecture, being the expert in something specific, etc. A manager for example should not be paid more than an Architect if the architect is higher in his path even if that person reports to that manage. Think of a Michelin star chef in a restaurant: would you push him out of the kitchen to manage the accountants? Or should he be paid less because he "just" cooks?

For your company and the development roles there seem to be none: Stay here and whenever the current tech lead runs away, the longer employed developer becomes the next tech lead. Period.

Specific to your situation: Why don't you view the whole problem holistically? Like if you invest in people they stay longer so you need to replace them less often. If you give them all the tools they need within reason, you will have a return of investment offsetting recruitment costs.

Jetbrains (was initially on question but then got edited out): if you go to JetBrains store at the time of writing this and from my browser the most expensive product is "IntelliJ IDEA Ultimate" for about £399.00/user/year with a discount on the second year and a bigger discount on 3rd onwards, which translates at about $525 or $44 per month. Can you compare that with recruitment fees? Time to interview? How should a person feel if their employer does not invest $44/month on them? I guess you can get a quote for 15 people which would bring this down even a little. Fuess would recommend another related article: "Why Talented Creatives Are Leaving Your Shitty Agency". People doing design should have large screens, people coding big screens (two) and the IDE of their choice (JetBrains is a company that makes IDEs), and so forth.

Hopping: because there are many "not good places to work" developers either hop until they find something that is OK, with some ending up at the place where they could not hop any more. It is not considered wrong and unfortunately it has become a norm.

Last two highlight a bigger problem: I think most companies do not know how to manage developers like at all. This could happen either because it is a relatively new field, has many differences, and other factors which I miss. I see it all the time: say you have to arrange an office space for an accountant: people know what is needed. For a say biologist: which lab equipment at what level how to replace it etc. What I have observed - there are many questions on this site about it- is that in many (bad to work) places developers have to follow the "main" function of the company: people wear suits (maybe because they interact with clients), developers have to wear suites, People come early/late, well developers have to get up accordingly. There is noise in the environment because people take calls? Well code under noise, etc. There is lots of research today on how to structure what people need to be more productive in our field, you can start checking out that.


"It's not you, it's me"

The rest claimed that they "found new opportunities."

There's always a company that is a little more desperate.
And eventually a recruiter will spam the engineer, even though the engineer wasn't actively looking. The desperate company will offer a higher salary to entice the engineer.

The engineer didn't even have to do anything and gets a nice raise.
They don't even have to be dissatisfied with their current position.

Especially for the short-sighted, this gain can be a higher priority than actual technical growth.

With offers waiting, even the tiniest dissatisfaction become triggers to move!
You also get a lot of switching in other markets with high demand, such as jobs around the minimum wage level.

That's just the reality of the industry.
The only way to remedy this is to make sure your offers remain competitive for the short-sighted and that you provide enough consistent growth to keep the longer-sighted satisfied.

"But actually... it is you"

While the above explains why software engineers, in general, can afford to be picky and fickle compared to other industries, your turnover rate is far higher than normal.

You didn't ask in the question, so I won't give many details, but you should probably consider that you're not just falling victim here, you're doing something that's driving people away.

To fix this, as other answers suggest, analyze what you're missing and fix things internally.

  • 3
    If we're attributing the attrition rate to devs receiving better offers, the obvious solution would be to simply pay more. Then these competing offers will be less than your staff are already being paid.
    – fubar
    Commented Dec 9, 2019 at 5:41
  • 2
    @fubar And I have a feeling, from OP's language, that this is America, in which case, engineers are already getting paid 2-10x to do the same job as people in other countries. As far as I can tell, there is nothing inherent about US engineers that makes them 2-10x more productive!
    – Mars
    Commented Dec 9, 2019 at 5:48
  • 10
    @Mars - US engineers inherently have better communications with US project stakeholders, especially if they're in the same building. It seems like a minor thing, but it's where many outsourced projects fail. Commented Dec 9, 2019 at 10:11
  • 4
    @Mars I wouldn't call outsourcing to cust costs and take advantage of a lower cost of living 'diverse'. As it stands, every single time I've seen a company try to outsource to save money it always goes wrong. Language barriers, poor coding standards, timezones and a number of other issues make this an awful decision most of the time. In the long run (including time to fix the code), you spend more on outsourcing to India/slavic countries than you do just hiring a single western developer.
    – Hex
    Commented Dec 11, 2019 at 13:26
  • 5
    @Connor One of the typical problems with outsourcing is that you get exactly what you ask for, as opposed with a situation where a skilled craftsman gives you what he thinks you need based on what you ask for. This requires communication skills and cross cultural experiences that most people are unprepared for when starting out with this which typically result in the projects not turning out well. Outsourcing can work very well when experienced enough, but it is not just magic that can save money. Commented Dec 11, 2019 at 14:41

Seriously, why is this behavior considered acceptable in the software community? They are the only profession that quits at the drop of a hat.

Okay, your first step is to stop blaming your tools (your hires).

You seem to have developed a sort of dismissive hatred of "the software community", because you have not been able to retain your hires for more than a few months.

Other than the fact that it's a seller's market in the software world right now, this isn't really the point.

The point is the things you mentioned: your organisation is making mistakes, and making your employees want to leave.

It's that simple.

You need to fix that, if you want to fix this absurdly high turnover.

Stop blaming the people who consistently decide work will be better in other organisations.

  • The trouble with high turnover is that once it starts it becomes extremely difficult to stop.
    – Mawg
    Commented Dec 9, 2019 at 12:43
  • 2
    @MawgsaysreinstateMonica That's true! You certainly can't do it by complaining about the tens (or more) of people who feel they need to quit, though. Commented Dec 9, 2019 at 12:55

Software engineering is a buyer's market

Where the buyer is the employee and the seller is the company. You can argue about who is the seller here, but for the sake of consistency I'm going to stick with the definition of seller = company / buyer = dev. If you think it should be the other way, invert the words in my answer, the core answer remains unchanged.

In a buyer's market, the customer has a wide range of choice of stores where they can go buy the product they need. Think of it like a car dealership: many brands of car exist, and I'm sure I would find a suitable and affordable car in any dealership. So you're going to have to convince me why I should be buying a car from your dealership.

This generally leads to dealerships catching consumer's attention through discounts, personal customer care, good service, ...

A good comparison here can be found in the Android ecosystem versus the iOS ecosystem. For this example, assume that people will choose Android/iOS and will never move from one to the other.

Apple intentionally keeps it a seller's market by ensuring that only they produce their iPhones and iPads. This gives them leverage over the customer, leading to higher prices and what most people consider anti-consumer decisions such as removing the headphone jack. The consumer can't go anywhere else to buy their iPhone anyway, so Apple can do this while still expecting the consumer to come to them.

Comparatively, Android is much more of a buyer's market, as there are multiple manufacturers of Android smartphones. If one Android smartphone manufacturer were to drive up costs or make anti-consumer decisions, customers can switch over to another Android smartphone manufacturer easily.
In this scenario, the customers are not guaranteed to return to the same manufacturer (as there are many of them to choose from), and therefore the manufacturer has to work harder at retaining its customer base.

Software development jobs are plentiful, and software engineers have a wide range of companies that are hiring. They're going to find a good job in many companies. So you're going to have to convince them to develop software at your company.

Much like the dealerships, this is going to lead to companies giving incentives to developers that their competitors don't offer (or offer less of): remote working, flexibly hours, above average salaries, great working atmosphere, ...

  • One quit after his request for a paid software tool called Jetbrains was denied.
  • Another quit after 3 months as he didn't know how he was evaluated (we use Scrum, so there aren't close performance stats as that defeats the project management style).
  • Yet another quit over not seeing a clear promotion track technically.

From their point of view, your company is a low-budget company (no money for tooling), offers no clear career advancement (no promotion track) nor any reasonable system for awarding career advancement (no performance tracking).

Right now, your company is failing at the "convince them to develop software at your company" point of things. Simply put, your competitors (i.e. other companies with job openings) have much more to offer to software developers, so it's only natural for them to leave your company for one with a much better offer.

  • I don't feel the iOS/Android comparison really does justice to your point. That's mainly because Android flagship phones followed suit when it comes to prices and removing headphone jacks.
    – Jasper
    Commented Jul 23, 2020 at 9:30

Jetbrains provide some of the best tools available. By denying this request, you are basically saying “we don’t care about your tools” which in turn indicates you don’t understand the needs of those you hire. He just went somewhere where they do...

You might not be the right person for this.

  • 10
    even worse, the company is Jetbrains, not the tool. It could have been ReSharper or any other tool that JetBrains sells, which as said, are fairly commonly used. It's like a recuriter for a construction company saying "I'm tired of these guys asking for some tool called DeWalt"
    – NKCampbell
    Commented Dec 9, 2019 at 23:06
  • 3
    I'd quit over not having a "JetBrains" too lol Commented Dec 10, 2019 at 3:43
  • That said, in my current workload I could use the community edition just fine. Commented Dec 13, 2019 at 8:51

It costs us nothing to leave

As a software developer, leaving is free. My boss abruptly left a few weeks ago. He walked literally a block down to a 30K USD pay raise. I have only once stayed in a job more than a year because recruiters will give you now what bosses want you to wait for.

You should institute monthly salary and performance reviews. That would allow you to quickly match what developers are getting in terms of offers as market value can grow substantially in under a year.

I basically estimate that I cost a company 30k in lost productivity whenever I leave between slowing projects, taking other devs with me, or just performing an "in company resignation" (where I do the minimum to not get fired while I job hunt). Share some of that with me every year and all will be well.

  • 4
    Monthly is a little extreme, but I second the increased rate of salary reviews. Doesn't even have to be much, just enough to trick the into feeling growth, like a Candy Crush addict
    – Mars
    Commented Dec 9, 2019 at 6:00
  • 2
    Monthly is very extreme and really scary... Just the sort of out-of-the-box thinking I like! Might be a great experiment to try and at the end of the day innovating to address the current difficulty of hiring is a great approach to try. Commented Dec 9, 2019 at 12:27
  • 3
    It only costs nothing to leave if we start looking and find a job while we're already at one. Quitting and going job-hunting is expensive due to the money you're not earning. Thankfully with the mass-spam of recruiters, if I'm casually reading any remotely-related recruitment emails I'm sure to find some appealing options at some point. Commented Dec 9, 2019 at 13:07
  • At one point potential employees will notice this and consider if they want this. This of course is nullified if you are really good. Commented Dec 27, 2019 at 13:28
  • If you say 30k, you might/should indicate the currency.
    – guest
    Commented Jul 5, 2020 at 14:57

And they are willing to quit over the slightest of things: ... Yet another quit over not seeing a clear promotion track technically.

I'm not a software engineer, but that sounds like a fairly big thing to me. I doubt there are many people who want to feel like their second dev job is the plateau of their career. If they can't see their way to the next step in their career within your job, of course they're going to pursue it outside.

But more broadly: perhaps I'm reading too much into your post, but I'm getting the impression that in several of these cases the first you knew of their dissatisfaction was when they gave notice. If so, this is part of the problem, and being proactive about staff satisfaction might help with your retention rates.

For instance, I've been in a similar situation to your engineer more than once - I felt like our career structure wasn't a good fit for my aptitudes, that I'd reached a dead end. But I had management who'd made it clear that I was welcome to approach them about such issues, and who proactively made time to talk with us one-on-one about this kind of thing. By talking to them, I was able to get a much better idea of my options (and they were able to get a better idea of my needs) before it got anywhere near the point of "guess the only way for me to advance is to jump ship".


Besides the other listen-to-your-software-engineers posts, I want to add one point to the discussion: re-examine how you do recruitment.

Company culture and market conditions can result in a higher attrition rate for software engineers, but the types of people you recruit matter as well. Computer Science is the new hot trend, so many people will hold a degree in it for no other reasons than jumping on the wagon and making money from it (not that there's anything outright wrong with that)

So when you do recruitment, you might want to focus more on the personal propensities of the candidates than their technical abilities. Recruit for passion/hearts as my company puts it. Of course, technical know-how is important but in this age, that's probably easier to substitute than heart.

Some useful aspects to explore during interviews: - How have they worked in the past? Team-size, structure for collaboration, communication, etc. - How resourceful are they when it comes to handling stress, changing environment, etc? - What motivate them to get to work every day and what do they look forward to getting out of the experience? - Etc.

I'm sure as an HR you will have better questions than this. My answer is simply to redirect more effort into these "soft" areas as compared to throwing another brain teaser at the candidate.

  • "Recruit for passion/hearts" - passion and enthusiasm is more important than technical skills. Enthusiastic people can always be taught. Those without passion can be more problematic Commented Dec 18, 2019 at 8:45
  • @VictorySaber I actually disagree with this... it sounds like the passionate people are the first to leave. Not surprising since they are probably the most hire-able elsewhere and also the most annoyed by crummy culture. I've seen this before, where they somehow managed to hire super enthusiastic, newest and best tools, bleeding edge front end gurus...and then told them their job was to maintain a 10 year old legacy system with minimal UI. And were shocked when all these wonderful devs decided to leave. It's more important to hire the right folks for this job. Commented Dec 18, 2019 at 16:52
  • Oh yeah of course. But those aren't mutually exclusive. My answer is supposed to be an add-on on top of the other answers as I have explicitly stated
    – resnet
    Commented Dec 19, 2019 at 3:51

Even in the software industry, very few people start a new job with the intent of leaving within five months. Every time you switch jobs, you are not employed for some time, which costs money, and for a five month job, that cost is very significant. Believe me, the people you hire plan to stay longer.

But once they start working for you, something happens that makes them change their mind, and makes them believe that staying only five months with your company is better than staying for longer. I would assume that is something within the company, and if you want them to stay longer, you have to find out what it is. And it must be something you didn't tell them when they started, because in that case they wouldn't have started in the first place.

What they all have in common is that within five months they came to the conclusion that switching jobs was better for them. Actually, significantly better, because people tend to risk-averse and stay where they are as long it isn't too bad compared to other places.

Your job is to find out what it is. The useful answers that you received obviously only tell you what was the last straw. The guy who left because your company didn't want to spend money on some software had more than just this reason, it was just the final straw. Any other thing could have made him quit.

Personally, I want a workplace that is fun, interesting, challenging in a good way, and paying well. Most software developers like these things. So: Is your workplace fun? Do people look happy when they arrive at work? Have a good look in the morning. Is their job interesting, or is it the same thing every day? Some people will be really unhappy if you stop them from doing their job. How much bureaucracy is there, and how much freedom? And of course, how is the pay? Especially compared to what they were promised when they joined the company?

If people don't stay, you should look for the fault at your company, because others manage to keep their employees.

And I suspect there may be one specific problem: You say you try hiring people on their second job. So a bit of experience, but not much. What these people want, and what they need, is someone who they can learn from. They can't learn from 15 other developers on their second job. And they need to learn to be able to get good money. Which probably you don't want to pay. So many will be leaving as soon as they figure out this job will do nothing for their career.


With an average tenure of 5 months and a 15-man team, you are successfully hiring approximately 35 software engineers every year. Each engineer requires recruitment effort on your part, but you are possibly also involved in some of the initial interviews and assessments. If I assume that you select candidates that you deem a good fit (for the team, also skillset and experience, possibly exclude job-hoppers) and that you don't aggressively approach candidates that are not explicitly looking, then you are an exceptionally effective recruiter.

The recruitment process is, in my personal opinion, a sales process. You sell jobs to candidates. Part of that process is creating and managing expectations. I'm not accusing you of misrepresenting any aspect of your company. However, you should reflect on the possibility that you are accidentally creating expectations in your candidates that are not met.

Your candidates are software engineers - not recruiters. It may be that they have an entirely different set of needs in terms of performance evaluation, career prospects and tools. They may not be as effective at selling their own needs to their superiors: different careers are associated with different predominant personality types and different communication styles. It is not unheard of that a recruiter enjoys their job a lot, has the tools they need, feels valued, challenged and respected by their teammates and superiors, and communicates this perspective to the candidates. Your personal experience may not apply in equal measure to the software engineering team.

The 200+% yearly turnover rate on a 15-man team is impressive. It indicates that not one candidate felt like their needs or expectations were met by the company. If candidates feel that this was a deliberate misrepresentation on your part, you are very unlikely to receive that feedback during the exit interview.

Once again, I do not want to admonish you. But you need to understand that the exit reasons that you were given are deflections, the final straw or simply examples. They are indications that there is a deeper issue. The management and prospects of the software team are definitely central to this problem, but recruitment may not be without blame. Too many companies try to solve their retention issues by ramping up recruitment.

  • "The recruitment process is, in my personal opinion, a sales process" I think this is part of the problem. Your clients are not your customers. HR should not operate like marketing. Honest, concrete explanation of the job should be used instead of trying to attract your candidates with buzzwrods and slogans like you do with customers.
    – David
    Commented Jul 23, 2020 at 6:50
  • @David I think both sides are true. If you treat hiring people like selling lottery tickets, you run into the problems you describe. If you treat it more like selling <high value brand> cars (including making sure that your cars aren't actually <cheap car brand>s), it can actually help the process.
    – Jasper
    Commented Jul 23, 2020 at 9:41
  • @David Although I agree fully, perfect communication is a utopia. There’s always a sender, receiver and medium involved. Sender and receiver have different vocabularies, different experiences, preferences and underlying motivations. All of the above influences their communication style. Our sales people use jargon and buzzwords they seem to understand, but are meaningless to me. And they have no chance of tracking with discussions between our software engineers.
    – MvZ
    Commented Jul 24, 2020 at 7:11
  • This does not sound as a company that rewards low turnover, but as a company that rewards vacancies filled. Nobody - HR, recruitment, the hiring software manager- is incentivized to produce the level of quality required to produce accurate expectations. That requires very strong communication skills: the hiring party must compensate for a lack of experience in this regard on the candidate’s part, or they become a learning experience for the candidate, who leaves once they’ve learned they got the wrong impression.
    – MvZ
    Commented Jul 24, 2020 at 7:25

Why is it so acceptable for software engineers to job hop? I'm tired of constantly recruiting them

Tl'dr answer: Why do recruiters find it so acceptable to blatantly lie? I'm tired of constantly being recruited, only to find out that I have been blatantly lied to.

Not fibs, little white lies or bending the truth, I mean lied to bigly. Total untruths. Telling me "it's white" and handing me black on the first day.

A common answer to questions here is "an interview is a two way street; you are interviewing the company as much as they are interviewing you".

After *cough* decades of freelancing, I have my interview questions down pat. They are a list of all the ways that I have seen previous projects fail and requests as to whether those mistakes will be repeated. These general revolve around Processes.

I am currently trying to extract my self from a project (which will not take long) where I was told at the interview that:

  • there requirements are reviewed, signed off & fixed - blatant lie. Four years into a "son of" project, new requirements pop up every few weeks which costs us the previous few weeks advances in rework.

  • there is a system architecture - lie. There is a Rhapsody UML model (imported from Rational Rose, I kid you not!) from the project of which this one is the "son". It is mainly incomplete and often inaccurate.

  • we produce design documents - blatant lie. There are none and requests to write some are met with "we don't have time to" (whenever a developer hears that phrase from management, a little switch in his brain truthifies it into "we don't have time not to").

  • we review design documents. Blatant lie - how can one review that which does not exists.

  • we review code - blatant lie. We do not review code

  • we unit test - lying bigly. There exist about 40 or 50 tests for 6,000+ source files (not headers, source code)

  • the code is well commented. Blatant lie. I knocked up a Python script to detect comments. Of 12,000+ files less than 3% have a comment, not even at file level. No one knows what the code does at a classes/package level. Interface functions have no comments to tell you what they do, what inputs the expect & what they return; massive data structures with seemingly meaningless field names have no comments.

In addition, we build from the command line, because there is no IDE project and management won't "waste the time" to have someone import the project to the IDE.

We are scolded if caught using the debugger, because "it's slow & it's quicker to add a few temporary print statements".

I could go on.

And on.

And on.

But, I think that you get the picture.

If this seems like a rant, then consider that it is an answer to a rant. For me, it's just par for the course. And an explanation of why developers have a high turnover.

  • "I mean lied to bigly. Total untruths." At one place where I worked an employee left Friday afternoon, and called Monday morning 9:10 am if he could have his job back. Everything got sorted, documents changed so he officially had never left, and he stayed there for a few years.
    – gnasher729
    Commented Jan 3, 2020 at 14:03
  • 2
    Job descriptions seem to be based on an aspirational goals rather than reality. They know they should test and do design documents but “haven’t gotten around to it.” Commented Jan 3, 2020 at 14:16
  • 1
    Well said but as a quick remark comments are often a bad replacement for good programming
    – David
    Commented Jul 13, 2020 at 15:26
  • Even on interfaces?
    – Mawg
    Commented Jul 14, 2020 at 8:13

I'm going to buck the trend here. I'm a big fan of locus of control and not blaming external factors.

You're blaming the devs. A lot of answers here are blaming the work environment - which isn't wrong, but it's possibly a bit misplaced since the OP isn't a manager but is the recruiter - who can't change that environment.

So instead, here's my answer.

You, as recruiter, are failing. You're recruiting people that stay in the job an average of 5 months.

I mean... those issues you mentioned as the causes for leaving? They're not dealbreakers for everyone. Sure, they might cause a sizable minority or even a majority of them to leave, but if you think that it'd cause every dev to leave, you're way off base. I'm a great example - from the issues laid out, I don't think I'd leave the job.

But you're not looking for me, or someone like me. You're probably looking for someone - anyone - to take the position that looks like they have a relevant skill set. Instead of finding someone that's a good fit for the particular environment, you're probably looking to fill the job quickly.

Stop blaming others. Don't blame the devs; don't blame the environment. Figure out what you need to do to weed out applicants that aren't a good fit. That 5 months figure is just as much a failure on your part as it is the company's environment - take ownership of it.

  • 1
    That the OP is a recruiter is an excellent point. As far as what they can do to weed out bad fits, what tools, project management style, and advancement are all things that can (and should) be discussed in early interviews. Ideally the candidate would know that they should be asking but there's no reason the OP can offer that information themselves.
    – BSMP
    Commented Jul 17, 2020 at 20:31
  • It's the whole "The one common factor in all your failed relationships is you" issue. Commented Jan 18, 2021 at 11:44

First, I don't see why leaving a company should be seen as good or bad. A contract is signed setting the conditions under which the employer-employee relation can be finished. If you don't like that, you'll have to set tougher conditions (if that's illegal in your jurisdiction, setting worse conditions for everyone but then rewarding loyalty would be an equivalent)

I am not a software developper myself and there are already some good answers to this question (at least, the combination of all of them really gets into most of the aspects that lead to such high turnover rates). As a data scientist who also worked alongside many software developpers, I'll show my experience in this different but related field to see a little contrast:

1.- We often don't need the job: many people stay in their jobs simply because they don't have an alternative. They need it to survive. For a profession in high demand, this is rarely the case. There's always another chance. We don't fear long periods as unemployed. There are many opportunities and those are in a wide range of places and sectors, while other type of worker may one be useful to a few companies. We will leave if we get tired of dealing with some of the following:

2.- Not enough recognition: this is probably not so true for data scientists as software developpers but I'll include it anyway. In most present day companies, a faillure in the digital part of the business often leads to a temporal collapse of the business. While software developpers are well paid, it may not reflect the extent to which they are fundamental to the company.

3.- Managers can't manage because they don't know what's going on: it's hard to report to someone that doesn't have an idea of what you are doing. Communication problems arise all the time. You can't imagine how many of those could be solved if only the managers had the most basic knowledge of what the people below them are doing (if you deal with programmers, take a programming course even if it's for one week!!). I've once had an interview with a small/medium size business owner who wanted to implement "machine learning" into his company and when I asked what sort of machine learning-related problem they have, he said "I don't know. I just see everybody is on with that and I don't wanna lag behind"

4.- Expectations are completely alien to reality: despite managers being completely aware of the previous point, they will set all sorts of unrealistic deadlines. On occassion this would force the developpers to rush through their work and then deal with complaints about poor functionality. When complaints are raised, a generic HR/Marketing response about organization, teamwork and "everything is possible if we believe in it" is the response. Other times this will lead to some part of the team having absolutely nothing to do for weeks.

5.- Arbitrary impositions: also in spite of point #3, managers will often make technical decisions for you. I was once told to use the big data servers for what was a 100K-row Excel. On another occasion my boss insisted on using neural networks where a decision tree was good enough simply because he wanted to say we used neural networks.

6.- Managers don't know what your skillset is: they often see me as a "computer guy", so they'll just throw at me anything that is IT-related. Whether it's a problem with the OS or a big data project, they'll expect top-level performance from me.

7.- Eventually, you'll be doing the same thing over and over: In many of the jobs I've had there came a point where there was pretty much nothing new to do. The job became repetitive and that's definitely not what someone like me is looking for.

8.- Motivations are not the same: people in technical positions often have no real understanding on what the company does or how it really operates. Even when they know, they probably don't care. They'll be much more excited about using the new features of the latest library out there than about increasing customer satisfaction. You'll have to understand and deal with that.

9.- HR departments operating like marketing: I've seen HR departments like this time and time again in an effort to attract the best professionals. They'll announce the company as something completely different than what it actually is, focusing on abstract ideas and great-sounding buzzwords rather than explaining what the position you are applying to actually is. So many companies are doing this that it's not uncommon to see workers joining a company not really knowing what they're expected to do. Potential employees should not be treated like potential customers.

Why don't you try experiencing it yourself? If you want to understand software developpers, try to learn the very basics of programming! Not with the intention of being able to produce software, but rather to learn what takes time and what doesn't, what certain tools are used for, why dedicating time to documentation and project organization is important, how coordination problems can appear when working in big teams and so on


You are signalling to your engineers that you don't value them highly. You don't mention how your salary rates are compared to the market, but there are some hints suggesting that you don't invest enough in them. Not supplying software tools, not having a clear path for advancement (and thus improved wages).

If I were working for a company like that I'd probably be looking for another job on the assumption that the current one is going nowhere and the company is either in financial difficulty or doesn't value the work I'm doing.

Try giving everyone a big raise, get the right tools for the job and lay out your vision for their career progression within your organization.


I think some recruiters may have found out your weaknesses, and are using them to get software engineers to move. For example, if you do not have a known career path for long term employees, a recruiter may be saying "Company X has a career path that gets many employees to $Y after working there for 6 years. The sooner you switch to them, the sooner you get to those jobs.".

If that is what is going on you should review your compensation packages, policies, and communication to fix as many weaknesses as possible. For example, it sounds as though you may have failed to communicate how you handle performance appraisals. That should be an easily fixable problem - just tell them how you handle appraisals and pay raises. Similarly, good intentions to look after employees who stay for several years are not enough. You need to communicate what promotions, pay, and benefits they can gain by staying.


An aspect here, that I feel is not mentioned yet: who manages the software developers that keep leaving? The lead that has stayed for 1 year?

Sounds to me you need a better manager for your devs, ignoring all the other stuff. No feedback on how things are going. Does the manager have enough time to do his work? Is the manager able to asess it? No career track progression. No way to handle the growth of employees? Could their manager fix this? Insisting on using free tools. Money issue, or (misplaced) ideology from the manager?


I've been in the industry for a little over a decade now. The two big reasons I've seen is that one, it becomes boring doing the same thing over and over. At some point in the work, everything settles and you don't get any new thing to work on and even if you do, it's molded around all the things you know about the business and company. It's exciting to work on new, fresh business ideas, and new, fresh code base. Your engineers aren't hopping jobs, but probably industry too.

Secondly, it's to do with pay. At some point, your pay equals to that of a new hire, then your growth staggers to the point you're not really that viable anymore. At some point you have to job hop as it makes the most economical sense. Even if you leave for just a measly 5k increase, I think that is smart in the long run because your next job will want to know what your current pay is and justifying a very large jump, even if appropriate, doesn't seem to make sense when you accepted work at the lower pay. It's sort of like eBay and you see something for X dollars, but then you see something way out there at X+100 dollars and you wonder why would you pay 100 more when you can just get the same product for the lower price.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .