You are here

You are here

Why developers leave big-name software companies

Dave Fecak Principal, Fecak Inc.
Google HQ

Although there is a healthy volume of written content lamenting the challenges of hiring software developers or debating the existence of a shortage, the topics of employee turnover and retention are often overlooked as contributing factors in the proverbial war for talent.

With so much time and attention invested into designing multifaceted recruitment efforts to attract a pipeline of qualified applicants, and to then curate the ideal candidate experience for those in that pipeline, it's reasonable to think that managers and entrepreneurs who rely on programming resources might be curious about why employees decide to leave. 

Exploring the possible motivations behind developer exits becomes even more intriguing when those departures are from the most exclusive big-name software companies that have mostly benefited from:

  • Stellar corporate reputations
  • Celebrated engineering brands
  • Above-market compensation packages
  • Famous perks

Google, Microsoft, Facebook, Amazon, and Apple are the big five that usually come to mind when developers talk about the most lucrative positions, but there are others with strong reputations in the technology community as well.  So, why would anyone ever leave one of these companies?  

What developers want

Even casual readers of blog posts about developer wants and needs won't have difficulty identifying the characteristics of engineering environments that inspire developers and, in contrast, the shortcomings that motivate employees to update their resumes.

The Joel Test

By now we've all (hopefully?) heard of the Joel Test, which serves as a rather primitive gauge that checks whether a certain set of practices is used within a given company's software development process. High scores indicate that a company is probably developing software the right way.

Having mature development processes in place is typically high on the list of criteria when programmers evaluate new employers. Even though the entire Joel Test is rather simple and weighs in at just 12 terse yes/no questions, the test's results are widely accepted as a fairly reliable tool for grading a development group.


Autonomy is frequently cited as a basic desire of developers (or freedom from micro-management at the very least). Google's renowned "20% time" policy has been one common source of inspiration for giving devs a slice of project independence and it has been implemented by other notables as well (see Atlassian's ShipIt Days, LinkedIn's [in]cubator, et al).

Beyond the ability to choose your own projects, developer autonomy can refer to a number of freedoms. Those cited likely include:

  • The freedom to use a wide range of tools and open source software
  • Minimal to no barriers or bureaucracy that prevent shipping code
  • Substantial flexibility in when and how the work is actually performed

Companies imposing new restrictions on developer autonomy have endured significant criticism from the developer community in the tech news headlines. For example, the remote worker policy changes at Yahoo and Reddit.


The quest to build new solutions to solve complex problems is another strong motivator for a number of developers. That's why it's relatively normal to see engineering teams lose members once an initial product is delivered—the exciting part, in some peoples' minds, is over.  

There's a whole contingent of the developer population that moves nomadically, mostly between startups and any other new product initiatives. Greenfield projects are highly sought after and relatively hard to find. Conversely, jobs focused on maintaining mature products that aren't introducing many new features are much more common and less attractive. Product maintenance comes with its own new set of challenges and requires a different mindset.

Human impact

Developers are also typically driven to build products that impact lives, where the job provides some satisfaction by having real purpose. Because so much software is largely invisible to the general public, being able to point to an application and say "I helped build that" is somewhat uncommon in the industry. 

If a developer's work is going to make a difference to users, the product first must actually have users. Thousands of companies both large and small who lack traction may find this to be their most difficult recruiting challenge and the hardest objection to overcome when trying to attract developers seeking purpose. In the eyes of most industry professionals, these are non-issues that don't often relate to employees in the big shops.

Big shops have a big advantage

Many of the common reasons that people (even outside software) leave typical companies simply don't apply to these major players. These firms are largely stable and financially secure. Their employees are usually compensated with above-market rates and reasonable work/life balance. Plus your colleagues at these high-profile shops tend to be considered the industry's elite talent. They appear to provide an opportunity to work with the best people using the best tools to build the best products used by millions of people.

Thousands of engineers spend years in college and countless hours of their personal time coding to improve their skills while in pursuit of being hired by any one of these favored employers. If you listen to today's students, these jobs are regarded as the holy grail with almost no thought given to the obvious—everybody can't work for Google. So after all that effort, why do they leave?

Reasons for leaving are plenty

Being that exit interviews are not a matter of public record (not to mention that the data wouldn't be useful anyway), we should be grateful for the many developers who have composed detailed accounts of their choice to leave and the reasons behind it.  In exploring individual accounts like the ones in that screenshot earlier, some clear patterns emerge that may explain the motivations of at least some.

Frequent job changing is fine

Over the past fifteen to twenty years expectations have evolved regarding acceptable job tenures for developers, and this change has played a major role in changing the overall landscape for technology employment. The big players are no exception.

In years past, anyone who changed employers every couple of years was branded a "job hopper," and that label was a potential red flag with employers during job searches. As it became more acceptable (and even expected) for developers to exit jobs after relatively short durations, and as demand for developers continued to rise, the decision to move on to new opportunities was able to be made without any hesitation related to the potential for an attached stigma or associated career repercussions.

When we talk specifically about employees of these well-known tech companies, that brand name on the resume signifies to recruiters and hiring professionals that the candidate comes somewhat pre-vetted and certified by an exclusive yet imperfect hiring methodology.

The industry assumes (sometimes wrongly) that engineers at Facebook and Google are fundamentally sound and not going to be tripped up by whatever FizzBuzz or Big O questions are thrown at them, so competitors are prone to target them in headhunting efforts and present the type of highly competitive offers required to entice them away from the big name company. Startup founders looking for a CTO or technical co-founder may feel these are less risky hires that will immediately improve their own engineering brand.

Any engineer from these companies who has a LinkedIn profile or a GitHub account gets enough recruiter spam to choke their inbox. We can assume that eventually one of those emails might offer something compelling to even the most passive of job seekers. 

For these big names, it's a perfect storm of factors that makes retention a complex problem. By hiring a developer, the person instantly becomes minted as the newest member of the most coveted subset of engineers in the industry. When members of this group are offered challenging work with other firms at a competitive wage and can leave their BigNameCo jobs even after the shortest of tenures without the slightest fear of reputational damage, they often will.

We grew apart, you changed

Although rapidly growing companies desperately attempt to adhere to the tenets they were founded upon, scaling often results in an organization that is wholly unrecognizable to the earliest employees. "The company changed" is a common theme within developer farewell addresses, which should come as no surprise when considering that the major players doubled in size multiple times over a handful of years.

Organizational motivations can either shift or reveal their true selves during expansion, and the developer's interests in helping to further these corporate goals may dwindle. Many goodbye posts allude to a sudden sense of disillusionment upon the realization that all of the innovative software development work being performed serves an entity now driven by their ability to gather personal data or to entice users to click links. 

It's easy for a company to lose its identity and culture when it goes through explosive growth phases, and even the most admired firms are not immune. 

We started losing

Everybody loves a winner, and when developers start to sense that things are changing for the worse they may head for higher ground before it's too late. Based on exit interview blog posts, losing can mean everything from high-profile product failures (see Google+), reductions in product traction due to changing tastes and stronger competition, or even the brain drain associated with a sudden exodus of co-workers. Even for companies this successful, the specter of becoming Just Another Big Tech Firm can make developers jumpy, and (as mentioned earlier) those inundated with opportunities leave.

The mythology was just that

The aura of working for these companies is magical, and those that leave tend to suggest that the reality falls far short. This is inevitable. For every developer working on the newest version of the company's flagship product or service, there may be dozens maintaining some internal tools that never see the light of day. The high demands placed on developers may not be fully understood when accepting the job, and the sheer volume of high-level talent in one place is bound to result in a competitive environment.

When both employer and employee have unreasonably high expectations of each other, something has to give.

Fast track to wealth

Although compensation at the big names is generally above market, the developers are not getting filthy rich like executives and startup founders with big exits. The big firms that rely heavily on stock packages to compensate employees have experienced price fluctuations that resulted in what are essentially cuts for their employees. Companies can't slash salaries without expecting some subsequent turnover, and reliance on stock value as a compensation component puts them seemingly at higher risk. 

Programmers wishing to swing for the fences and a shot at early retirement may explore early stage startup opportunities that include equity components as their best chance at a quick payday. The most entrepreneurial of the bunch may start their own companies. Their membership in the exclusive developer fraternity may serve as a distinct advantage while pursuing funding, in no small part due to the large number of investors created via IPOs.

This ride is a long one

With the documented career springboard-effect developers experience after even a short tenure with a superior engineering brand, you can't help but wonder if development jobs at these favored employers are still the end goal by most, or if they have instead become the means to a different end. With the rise of each new tech unicorn, a new developer Mecca is spawned, and big five defectors seeking the promise of new challenges and a chance at a life-changing liquidity event will be warmly accepted. The ride only ends when the money runs out. 

Keep learning

Read more articles about: App Dev & TestingDevOps