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.

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

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?

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.