Why good developers leave small teams

The strongest motivator for software engineers across 92 studies is not pay, perks or career progression. It is identifying with the task: having clear goals, understanding why the work matters, and owning a recognisable piece of quality work. That creates a problem for small teams.

Developers often have broad responsibilities, shifting priorities and little visibility into how their work contributes to the wider business. The result can be a job that looks attractive on paper but feels disconnected in practice.

The usual tools for finding out why people leave do not necessarily reveal this. Exit interviews happen after the decision has already been made. Pay reviews focus on compensation rather than whether someone finds their work meaningful.

Instead, managers can ask four questions in a regular one-to-one. The answers can reveal problems while there is still time to fix them.

Last updated: 2026-10-04

Key facts

In this article

• What are the signals before someone resigns?
• What does the research actually measure about why engineers leave?
• Which reasons are inside your control, and which are not?
• How do you ask, while it is still fixable?
• What do you do when they have already decided?
• What does one departure cost a five-person team?
• Where RocketDevs fits
• Conclusion
• Frequently asked questions

What are the signals before someone resigns?

The signals are real but weak. The honest way to use them is as prompts for a conversation, not as evidence that someone is about to leave.

The surprising part is how few developers actually move. Most people showing one of these signals will still be with the company a year later. That is why treating them as a dashboard is a mistake.

Start with the base rate. In Stack Overflow's 2025 Developer Survey, 45.6% of developers were not actively seeking a new role, 28.8% were somewhat considering a change, and 14.8% were strongly considering one. A further 8.8% had voluntarily moved roles during the previous year. The figures come from 35,451 responses. Roughly one developer in eleven moved, while roughly one in seven was seriously considering it.

The broader labour-market data tells a similar story. The US quits rate for the Information sector was 1.1% in August 2026 and averaged 1.19% over the twelve months to August. The corresponding average for total nonfarm employment was 2.15%. The Information sector recorded about 30,000 quits in August. Developers are therefore leaving at a lower rate than the workforce as a whole.

The mood is less positive. The same Stack Overflow survey found that 24.5% of developers were happy at work, 47.1% were complacent and 28.4% were unhappy, based on 26,622 responses. Happiness had increased from 20% the previous year, but complacency remained the largest group by a wide margin.

That middle group matters. A complacent developer is not necessarily looking for another job. They may not even be unhappy. They are simply not strongly engaged with the work. That makes them more vulnerable to an attractive opportunity when one appears.

The difficult job market also helps explain why more developers do not leave. JetBrains surveyed 24,534 developers across 194 countries and found that 61% of junior developers and 54% of senior developers described the job market as challenging. A low quits rate during a difficult hiring market does not necessarily mean people are happy. Leaving is simply more expensive when good alternatives are harder to find.

With that base rate in mind, use the following signals carefully. Every row is a reason to ask a question, not a finding about the employee.

The last row should be deliberately ignored as a resignation signal. Acting on someone's calendar can make a happy developer feel watched, which can create the very trust problem you were trying to detect.

The other signals should be treated with the same caution. A developer who speaks less in meetings may be tired. Someone who stops volunteering may have too much work already. Someone who is learning a different technology may simply have developed a new interest.

The useful question is therefore not “Are they about to resign?” It is “Has something changed that is worth talking about?”

What does the research actually measure about why engineers leave?

Most research measures whether someone intends to leave rather than whether they actually resign. Two concepts have been particularly useful for understanding that intention over the past 25 years: job embeddedness and perceived organisational support.

This distinction matters because many of the percentages quoted online about developer turnover come from entirely different sources. They often do not have a published methodology or dataset behind them. The research discussed here is much more cautious about what can actually be measured.

The largest synthesis of software engineering motivation remains a 2008 systematic review by Sarah Beecham, Nathan Baddoo, Tracy Hall, Hugh Robinson and Helen Sharp (open-access copy). The researchers examined 519 papers in full and selected 92 for their final review. Retention was measured as an outcome of motivation in 12 of those studies.

The paper is now 18 years old, so it cannot tell us how remote work or AI-assisted development has changed the experience of software engineers. It is still the largest systematic review in this area. Its central finding also lines up with much more recent developer survey data: people are strongly motivated when they can identify with the work they are doing.

Job embeddedness explains why people stay

Job embeddedness looks at the forces that make leaving a job difficult or unattractive. The concept covers three areas: a person's connections to other people and groups, how well they feel they fit their job and community, and what they would have to give up by leaving.

Research by Terence Mitchell, Brooks Holtom, Thomas Lee and Chris Sablynski found that embeddedness predicted both intentions to leave and voluntary turnover, even after accounting for factors such as job satisfaction, organisational commitment and the availability of other jobs.

There is an important complication for managers, though. Later research separated on-the-job embeddedness from off-the-job embeddedness. Off-the-job embeddedness significantly predicted whether people actually left, while on-the-job embeddedness did not. On-the-job embeddedness predicted job performance and organisational citizenship instead.

In plain English, being deeply rooted in your local community and personal life can make someone less likely to leave. Being deeply connected to their work can make them better at that work. Those are not necessarily the same thing.

That finding also complicates the usual advice to solve retention problems with team bonding. Team relationships can matter, but the evidence does not support treating stronger workplace social ties as a simple guarantee that someone will stay.

More recent research found that these two forms of embeddedness can even behave differently during periods of job insecurity. People who were strongly embedded in their jobs were less likely to search for another position when they felt insecure. Strong off-the-job embeddedness could have the opposite effect under some conditions.

Software-specific evidence is growing

A 2025 study of 224 software professionals examined job satisfaction, embeddedness, work-life balance and organisational justice. Job satisfaction and embeddedness were associated with lower intentions to leave. Work-life balance did not have a direct effect on turnover intention in the model.

One of the more useful findings for small teams was the role of organisational justice. This means whether people believe decisions are fair and whether those decisions are explained properly. On a five-person team, that is not primarily an HR process. It can mean something as simple as how you decide who gets the interesting project, who gets stuck maintaining old code and why priorities changed.

A 2024 systematic review of software engineers' well-being reached a more cautious conclusion. It examined 44 quantitative survey studies published between 2000 and 2023 and found that the predictors and outcomes of software engineers' well-being remain under-researched.

Another study involving software engineers and CEOs identified 19 reasons for software engineer turnover and 18 strategies used to reduce it. The broader point is that there is no single explanation for why software engineers leave.

Perceived organisational support matters too

The second major construct is perceived organisational support, or POS. This is essentially whether employees believe their organisation values their contribution and cares about their well-being.

A meta-analysis covering 558 studies found support for the theory across a wide range of outcomes. Leadership, organisational practices and working conditions all contributed to how supported employees felt. Perceived support was also associated with how employees approached their work, their performance and their well-being.

For a small company, this makes the concept much more practical than it might sound. Employees form their view of organisational support from everyday decisions. They notice whether managers listen to them, whether good work is recognised, whether resources are available and whether decisions appear fair.

Leaving is not always a slow process

Quitting does not follow one universal sequence. Lee and Mitchell's unfolding model describes several different paths to leaving, each involving different psychological processes and external events.

Some employees gradually become dissatisfied and eventually decide to leave. Others experience a specific event that changes their calculation. That could be a reorganisation, a promotion they were passed over for or an attractive offer from another company.

This matters because there may not be a long warning period. Someone can be reasonably content with their job and still decide to leave quickly when circumstances change.

Be careful with precise turnover statistics

The software-specific research is useful, but it does not support many of the precise turnover claims commonly repeated online. Figures such as "62% cited scope creep" or claims that engineers are "5x more likely to leave" because of a bad manager often trace back to staffing or recruitment blogs without a published methodology or identifiable dataset.

Those numbers should not be treated as established research. A retention statistic should tell you where its sample came from, how many people were included and how the result was measured. If it cannot do that, the number is not useful evidence.

The better approach is to hold two ideas at the same time. The research gives us useful patterns about intention, motivation and retention. It does not give us a reliable formula for predicting what one particular engineer will do.

That is why the practical response is not to build a resignation dashboard. It is to create regular opportunities for people to tell you when their work, growth, support or sense of fairness is starting to break down.

Which reasons are inside your control, and which are not?

Most of the reasons researchers identify are within an operator’s control. That is the uncomfortable part. The strongest motivator in the research and the strongest de-motivator are both shaped by how a team operates, and many of the changes required are inexpensive on a team of five.

The 92-paper review found that the most frequently cited motivator was the need to identify with the task. This includes having clear goals, understanding why the work matters, seeing how it fits into the wider product, and owning an identifiable piece of quality work. It appeared in 20 studies. Good management and employee participation appeared in 16 studies each. A clear career path appeared in 15. Rewards and incentives, variety of work, and a sense of belonging each appeared in 14. Recognition appeared in 12 studies, feedback in 10, autonomy in 9, making a contribution in 6, and trust and respect in 4.

The de-motivators are different. Poor working conditions and lack of resources appeared in 9 studies. Poor management appeared in 7. Uncompetitive or poor pay appeared in 6. Stagnation and a career plateau appeared in 5, as did poor communication and a lack of feedback. Unrealistic goals or artificial deadlines appeared in 4.

The distinction matters. The things that make work satisfying are not simply the opposite of the things that make work frustrating. A developer can have good pay and still feel disconnected from the product. They can also care deeply about the product while being frustrated by broken tools or poor management.

The last two rows are important because not every departure is a management failure. Research on job embeddedness found that connections outside work can affect whether someone actually leaves. The unfolding model of turnover also shows that some departures follow a sudden event rather than a long period of growing dissatisfaction. Someone can therefore be happy with their manager and still leave because their circumstances change.

Pay is a hygiene factor, not a retention strategy

The evidence does not support either extreme of the usual pay debate. Money is not irrelevant, but it is not a complete retention strategy either.

Competitive compensation was among the top contributors to job satisfaction in the Stack Overflow survey, alongside autonomy and trust and solving real-world problems. The 92-paper review also identified uncompetitive or poor pay as a de-motivator in 6 studies.

Being underpaid can therefore push someone out. But pay was not the strongest motivator in the research. Identifying with the task was cited more often.

The practical conclusion is that compensation should be treated as a baseline to get right rather than the main lever for retaining someone who is already disengaged. Fix an unfair rate when you find one. Do not assume that a raise will solve a problem caused by poor work, weak management, or a lack of meaningful responsibility.

Your metrics can become part of the problem

There is another factor that operators control: how they measure contribution.

JetBrains found that 66% of its 24,534 developer respondents either did not believe or were unsure that their current metrics reflected their real contribution. If developers do not recognise the measurements used to evaluate their work, those metrics can create a sense that decisions are being made on an unfair basis.

That matters because organisational justice was the strongest predictor of job embeddedness in the software-specific research. On a five-person team, this does not require a complicated performance-management system. It means explaining what you measure, why you measure it, and what the numbers are actually being used to decide.

Measure the work rather than turning the measurement into surveillance of the person.

Remote work changes the equation

Some factors are structural rather than managerial. In the Stack Overflow survey, 32.4% of developers worked fully remotely, rising to 45% in the United States.

Remote work does not automatically make someone more likely to leave. The point is narrower: job embeddedness depends partly on the links people have with their workplace, their community, and the people around them. A fully remote contractor may naturally have fewer of those workplace links than someone who works in the same office every day.

That is not an argument against remote work. It is a reason to build those connections deliberately. A small distributed team cannot assume that relationships, context, and a sense of belonging will develop simply because people work together.

For the practical side of reducing communication and handover problems in distributed teams, see Why your remote team is not slower.

The useful question for an operator is therefore not simply, “Can I stop this person from leaving?” Some reasons are outside your control. The better question is, “Which parts of their working experience can I make better before leaving becomes the easiest option?”

How do you ask, while it is still fixable?

Ask four questions in a normal one-to-one. Do not introduce them as a retention exercise or tell the developer that you are trying to find out whether they might leave. The purpose is to understand whether the work still makes sense to them. If you ask directly whether they are thinking about leaving, you are more likely to get a reassuring answer than useful information.

The approach comes from the strongest finding in the research: identifying with the task is the most frequently cited motivator for software engineers. You are not testing loyalty. You are checking whether the person can still see a connection between what they do and why it matters.

1. What are you working on at the moment that you actually care about?

A useful answer names something specific and explains why it matters. A concerning answer might be a ticket number, a shrug, or a description of how something works without any explanation of who it helps or why it is important.

That distinction gets directly at what the research means by identifying with the task. The review found this motivator in 20 studies, more than any other motivator.

2. What did you wait on last week, and for how long?

This question looks for the leading de-motivator in the review without asking whether the person feels frustrated.

Poor working conditions and a lack of resources appeared in 9 studies. On a small team, the problem is often mundane: a staging environment that does not exist, a CI pipeline that takes 40 minutes, an access request that nobody approved, or a code review that sat untouched for three days.

These problems are often easier to fix than the deeper retention issues. The important part is asking for a specific example rather than a general assessment of whether the developer has enough resources.

3. When did you last change my mind about something?

Employee participation and involvement appeared as a motivator in 16 studies, equal with good management. This question tests whether the developer feels that their input actually changes decisions.

It can be difficult to answer diplomatically. That is useful. If they cannot think of an example, it may indicate that they have learned their opinions do not materially affect the work.

That matters because the software-specific research found organisational justice to be the strongest predictor of job embeddedness. If decisions appear arbitrary or employees believe their input has no effect, their connection to the organisation can weaken.

4. What would make the next six months worth staying for?

Ask this one last because it is deliberately forward-looking. It can reveal stagnation or a missing career path without requiring someone to say that they are unhappy.

A specific answer gives you something to work with. If they say they want to own the billing service end to end, you have a potential development plan. If they cannot think of anything that would make the next six months worthwhile, that is information too.

The review identified a clear career path as a motivator in 15 studies and stagnation or a career plateau as a de-motivator in 5.

What do you do with the answers?

Choose one issue raised in the conversation and fix it visibly. Then tell the developer that you fixed it because of what they raised.

This is where perceived organisational support becomes practical. A meta-analysis covering 558 studies found that perceived organisational support is influenced by factors including leadership, HR practices, and working conditions. On a small team, you do not need a large programme to demonstrate support. One visible change that can be traced directly to something an employee told you can be more meaningful than a general promise to improve things.

Do not turn the four questions into a team-wide survey in the same week. People will compare notes, and the exercise can quickly start to feel like a formal retention programme rather than a normal conversation.

There is also an important distinction between the answers. If a developer can clearly explain what they care about but cannot describe anything they want from the next six months, the problem may be the roadmap rather than the person. They have found meaning in the work they are doing now but cannot see a future they want to work towards.

What if they joined recently?

New hires need a different conversation. Research involving 102 software professionals found that support for new employees played an important role in onboarding success, while training was less important. The study also found that job satisfaction mediated the relationship between onboarding success and turnover intention.

That means a new developer who is struggling may need better support and integration rather than more technical training. If the person you are concerned about joined within the last six months, When a new engineer is not working out is the more relevant framework. The problem is different, so the conversation should be different too.

What do you do when they have already decided?

Accept the decision quickly and use the notice period for knowledge transfer rather than trying to reverse it. Once someone has decided to leave, the immediate business risk is not the vacant position. It is the knowledge and responsibility that may leave with them.

The unfolding model of turnover helps explain why a counter-offer is often the wrong response. Some departures follow a specific shock, such as a reorganisation, a missed promotion, or an unexpected external opportunity. In those cases, there may be no long-running workplace problem for you to fix. The decision was triggered by an event.

A counter-offer can also create a problem on a small team. If someone only receives a meaningful pay increase after resigning, everyone else now knows that resignation is the route to getting one. If the person's compensation was genuinely below market, correct the underlying pay problem separately and apply the same reasoning to the rest of the team.

Start the transfer immediately

Begin the capability transfer in the first week of the notice period rather than waiting until the final week.

Focus first on the responsibilities that would create the greatest operational risk if nobody else could perform them. This usually includes deploying the product, restoring it when something goes wrong, and diagnosing production or on-call problems.

The person taking over should perform the task themselves while the departing developer observes. A handover document that nobody has tested is not proof of knowledge transfer.

For the practical method and tests, see What happens to your product if one person leaves.

Ask what they would change

You can still learn from the departure, but the traditional exit interview is not necessarily the best way to do it.

Instead of asking why they are leaving and expecting a carefully worded answer, ask what they would change if they were staying. This makes the question less about defending the decision they have already made and more about identifying something that could improve the team.

The answer may still be incomplete. Treat it as one piece of evidence rather than a definitive explanation of the departure.

Look for patterns, not individual explanations

Separate what you learn from what you can act on. One person's reason for leaving may be specific to their circumstances. The same complaint appearing across several departures is more useful.

This is particularly important with online advice. There is a huge amount of discussion about resignation and remote work, but individual experiences are not a substitute for evidence about your own team.

Your own repeated patterns are more valuable. If three departing developers independently describe unclear priorities, poor feedback, or a lack of meaningful ownership, that is a management problem worth investigating even if none of them used exactly the same words.

Accept that the decision may have happened earlier

The resignation letter is often the end of the process rather than the beginning. A developer may have been considering the decision for some time before telling their manager, a pattern that recurs through threads such as Ask HN: Why did you quit your last job?

That is another reason not to spend the notice period trying to persuade them to stay. Once the decision is made, use the remaining time to protect the business and learn what can reasonably be learned from the experience.

The goal is not to make every departure preventable. Some people will leave because their circumstances change, because an opportunity appears, or because they have simply decided that they want something different.

The goal is to make sure that when a good developer does leave, the business does not lose the knowledge required to keep operating, and the team does not repeat a problem that was within its control.

What does one departure cost a five-person team?

There is no published study that gives a measured replacement cost for a software developer on a five-person team. The honest approach is therefore to build an estimate from a published wage and state every assumption used.

The wage anchor is the US mean annual wage for software developers: $148,100 in May 2025, equivalent to $71.20 per hour, according to the Bureau of Labor Statistics for occupation 15-1252.

The calculation below uses that hourly rate. None of the individual cost assumptions is a published benchmark. They are operating assumptions that you can replace with your own numbers.

This is an estimate built from the BLS wage and the assumptions shown above. It is not a published replacement-cost benchmark. Change the notice period, vacancy period, productivity assumptions, or ramp time and the result changes substantially.

The value of the calculation is therefore not the $36,000 figure itself. It is the shape of the cost.

The vacancy and ramp are more expensive than recruiting

The largest costs in the example are the vacancy gap and the time required for the new developer to reach full productivity. Together, they account for most of the estimate.

That changes where a small team should focus. Reducing interview time by a few days has relatively little effect on the total. Reducing the time the role remains unfilled has a much larger effect.

That is a strong argument for knowing where your next candidate could come from before you need to hire. It is also an argument for keeping the work documented well enough that a replacement can become productive without reconstructing the entire system from scratch.

The biggest cost is the one we cannot quantify

Knowledge that does not transfer is deliberately left out of the calculation because there is no reliable published figure to put against it.

It may also be the most important line. If the departing developer is the only person who knows how to deploy the product, restore a failed service, or diagnose a particular production problem, the financial impact can continue long after the vacancy has been filled.

That is why capability transfer should happen before someone resigns wherever possible. A notice period gives you a final opportunity to transfer knowledge, but it is a poor substitute for having more than one person capable of performing critical work.

For the same reason, What a bad engineering hire costs approaches the problem from the other direction: the cost of getting the hiring decision wrong can continue well beyond the hiring process itself.

Know where the evidence stops

There is an important limitation to the research used throughout this article. The studies cited here generally examine employees in larger organisations. They do not provide measured turnover costs for a five-person software team, and they do not establish a replacement cost for a contractor engagement.

The research can still be useful because the underlying mechanisms are relevant. Task identification, organisational justice, job embeddedness, perceived support, and the conditions that make work satisfying or frustrating can all help explain why someone stays or leaves.

The dollar figures are different. They are an operating model built from a published wage and explicit assumptions, not a number the research has measured for your team.

That distinction is important. Use the model to understand the order of magnitude, then replace every assumption with your own numbers.

Where RocketDevs fits

RocketDevs cannot stop a developer from leaving. We can make sure the business is not exposed when they do.

Our role is the operational side of the problem: transferring critical knowledge, reducing the gap between one developer leaving and another taking over, and keeping the work moving while that happens.

RocketDevs developers complete 6-8 hours of assessment per developer, with the current cohort accepting only the top 2%. They work remotely from their own countries with full EU timezone overlap.

When a placement ends, the account team's focus is capability transfer rather than simply finding a replacement. Deployment, restoration, and on-call diagnosis are transferred to a second person while the original developer is still available. The search for the next developer can happen in parallel rather than starting only after the placement has ended.

A new placement also comes with a 14-day money-back trial. This gives the client a defined period to assess whether the developer is a good fit before committing further.

There are two important boundaries.

First, a remote contractor may have fewer workplace and community ties than an employee working within a permanent organisation. That can make the engagement easier to leave. The answer is the same as it is for any small team: make the purpose of the work clear, give the developer ownership of an identifiable part of the product, involve them in decisions, and make sure the rate is competitive.

Second, RocketDevs does not currently publish a figure for how long placements last. We therefore cannot claim that our developers stay for a particular period or that our approach produces a specific retention rate. The capability-transfer approach is an operating practice, not a published retention statistic.

When there is a number supported by a meaningful sample, we will publish it with the sample size. Until then, the honest claim is narrower: RocketDevs can help a small team reduce the operational risk when a developer leaves. It cannot remove the management reasons why someone might decide to leave.

Conclusion

For a founder, the takeaway is simple: you cannot control whether a good developer leaves, but you can control how easy it is for them to want to stay and how much damage their departure does.

If a developer cannot explain why their work matters, cannot see where they are going next, or spends their week waiting for broken processes and missing resources, those are management problems. Find them while they are still fixable. Four questions in a normal one-to-one can reveal more than a retention survey conducted after the decision has already been made.

You also need to build a company that can survive the loss of one person. On a five-person team, that means critical knowledge cannot live in one person's head. Someone else should be able to deploy, restore the product, and handle the important operational problems before you need them to.

Some departures will still happen. A developer may move, receive an opportunity they cannot ignore, or simply decide they want something different. Do not treat every resignation as a failure to be corrected.

The founder's job is to create work people want to stay for and a business that can keep moving when they do not.

That is the real retention strategy for a small team: make the work meaningful, make the environment workable, and never let one person's departure become an operational crisis.

Frequently asked questions

How early can you tell that a developer is thinking about leaving?

There is no reliable timeframe. Some people become increasingly dissatisfied over months, while others leave after a specific event or change in circumstances. The research does not support a single warning period. Regular one-to-ones can help you spot problems that are developing gradually, but they cannot predict every departure.

Can a pay rise stop a developer from leaving?

It can fix an underpayment problem, but it cannot guarantee that someone will stay. Competitive compensation is an important contributor to job satisfaction, and poor pay can be a reason for leaving. However, the strongest motivator identified in the software-engineering research is identifying with the work itself. If compensation is below market, correct it. Do not assume that a raise will fix poor management, meaningless work, or a lack of future opportunity.

Should a founder conduct exit interviews?

You can learn from a departing developer, but a traditional exit interview should not be your main source of retention information. Someone who has already decided to leave may give a simplified or cautious explanation. A better question is what they would change if they were staying. Then compare that answer with feedback from other departures. Repeated patterns are more useful than any one person's explanation.

How much does replacing a developer cost a five-person team?

There is no published figure that measures this specifically for a five-person software team. The estimate in this article uses the US BLS mean software-developer wage of $148,100 and a set of stated assumptions, producing a cost of roughly $36,000 before untransferred knowledge is included. The number is not a benchmark. The important finding is where the cost comes from: the vacancy and the time required for a new developer to reach full productivity account for most of the estimate.

What should a founder do before someone resigns?

Do two things at the same time: make the work worth staying for and make the business resilient when someone leaves. Give developers meaningful ownership, explain why their work matters, remove unnecessary obstacles, involve them in decisions, and keep compensation competitive. Then identify the responsibilities that only one person can currently perform and make sure someone else can handle them. You cannot prevent every departure, but you can reduce avoidable turnover and make an unavoidable departure much less disruptive.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• Beecham, Baddoo, Hall, Robinson and Sharp, Motivation in Software Engineering: A systematic literature review, Information and Software Technology 50(9-10), 2008. Open-access copy
• Mitchell, Holtom, Lee and Sablynski, Why People Stay: Using Job Embeddedness to Predict Voluntary Turnover, Academy of Management Journal 44(6), 2001
• Lee, Mitchell, Sablynski and Burton, The Effects of Job Embeddedness on Organizational Citizenship, Job Performance, Volitional Absences, and Voluntary Turnover, Academy of Management Journal 47(5), 2004
• Lee and Mitchell, An Alternative Approach: The Unfolding Model of Voluntary Employee Turnover, Academy of Management Review 19(1), 1994
• Peltokorpi and Allen, Job embeddedness and voluntary turnover in the face of job insecurity, Journal of Organizational Behavior, 2023
• Kurtessis, Eisenberger, Ford, Buffardi et al., Perceived Organizational Support: A Meta-Analytic Evaluation of Organizational Support Theory, Journal of Management, 2015
• Kuutila, Ralph, Qiu, de Souza Santos et al., Staying or Leaving? How Job Satisfaction, Embeddedness and Antecedents Predict Turnover Intentions of Software Professionals, arXiv:2512.00869v2, December 2025
• Carvalho, Cruz, de Almeida, Silveira Neto and Prikladnicki, Please do not go: understanding turnover of software engineers from different perspectives, arXiv:2407.00273v1, June 2024
• Godliauskas and Smite, The well-being of software engineers: a systematic literature review and a theory, Empirical Software Engineering, 2024
• Sharma and Stol, Exploring onboarding success, organizational fit, and turnover intention of software professionals, Journal of Systems and Software 159, 2020
• Stack Overflow, 2025 Developer Survey, Work, accessed 4 October 2026
• JetBrains, The State of Developer Ecosystem 2025, and the full report
• US Bureau of Labor Statistics, Occupational Employment and Wage Statistics, software developers, May 2025, and the annual mean series
• US Bureau of Labor Statistics, Job Openings and Labor Turnover Survey, quits rate, Information sector and total nonfarm, read 4 October 2026
• Stack Exchange API, resignation tag, Workplace, read 4 October 2026
• Wikimedia pageviews API, Turnover (employment), twelve months to September 2026
• Hacker News, Ask HN: Why did you quit your last job?, item 17619599