Tech sector has enormous turnover rate, but have you ever wondered why software developers leave their jobs? Discover 5 things companies do that make them loose their developers.
Finding and retaining talented software developers—including web app developers—is a major cause for celebration for most companies. At least it should be because, at 13.2%, the tech sector has the highest turnover rate out of all business sectors, according to a report from LinkedIn.
Software developers don’t hesitate to pursue better opportunities because such opportunities are everywhere. The global IT talent shortage has escalated to become the top emerging risk companies face globally, forcing them to stretch their budgets and provide all kinds of attractive employee perks and benefits to not only find the talent they’re looking for but also retain it.
The companies that don’t succeed in retaining their software developers lose big money. The total cost of losing an employee ranges from tens of thousands of dollars to 1.5–2 times their annual salary, and the national average salary for a Software Developer is $80,000 in the United States, according to Glassdoor. That’s a loss of as much as $160,000 in recruiting and training expenses alone for every unsuccessful hire.
With the monetary costs of hiring new software developers being so high and the competition for talent in the marketplace so fierce, companies must do whatever they can to avoid losing their software developers.
While there is no universally applicable strategy on how to hire talented software developers and retain them, IT job offers are riddled with red flags that are guaranteed to make experienced software developers flee away immediately and inexperienced software developers eventually. Let’s look at the top five of them and decipher what they really mean.
You should be cautious every time you encounter this job description because it most likely means that you will be dealing with incomprehensible legacy and spaghetti code if you decide to accept the job offer.
The reality is that legacy code plagues most larger companies. The story is usually more or less the same:
The problem is that maintaining legacy code often creates a disconnect with personal or professional goals and creates dissatisfaction.
<blockquote>As new technologies are released at an increasingly fast pace, good developers will seek to keep up with the latest software updates and language. If a developer foresees the remainder of his career at a company locked in an antiquated technology, he will likely look for new work,”</p><p> – writes Sean McCosh, Partner at Differential.</p></blockquote>
All companies that don’t want to see their software developers run away to play with newer, shinier toys should provide plenty of opportunities for developers to learn new skills. For example, Google is famous for its “20% time” policy, which encourages employees to spend as much as 20% of their time on personal projects, so even software developers who are tasked with maintaining legacy code can play with Go, Scala, Kotlin, or R if they want to.
<blockquote><p>“We are young, dynamic, and eager to succeed! Are you young and feel that your life is still ahead of you? Are you ready to work in a team where you can work with similarly young and open colleagues? Are you able to tolerate incompetent coworkers with limited knowledge and zero experience? If so, you should join us because you will feel right at home!”</p></blockquote>
No, this isn’t a real job description—at least the second part isn’t. The first part, however, is all too real and can be found in many IT job offers. While there’s nothing inherently bad about working in a young, dynamic team, such teams can easily become toxic due to their limited problem-solving ability and experience.
When the blind are leading the blind, accomplishing even the most straightforward objectives can be depressingly difficult and lead to employee burnout and valued members of staff leaving for the sake of their own survival.
<blockquote>“A toxic environment can really affect an employee’s mental health and outlook on their job; it can make them question their worth and job security, which often makes them feel like they would be happier in another company,”</p><p> — Frances Geoghegan, Managing Director of Healing Holidays.</p></blockquote>
Seasoned teams have already demonstrated their problem-solving ability and acquired plenty of experience in finding solutions for even the most complicated development problems, and being a part of such a team can be an enormously positive learning experience. What’s more, it’s not like seasoned software developers have somehow forgotten how to have fun. It’s just that they can have fun and be productive at the same time.
Scrum, the agile process framework for managing complex knowledge work, has many benefits, including better product quality, quicker release of usable product to users and customers, more control, reduced risk, improved customer satisfaction, greater ability to incorporate changes as they occur, and increased collaboration and ownership.
However, with Scrum also come meetings—lots of them. Scrum teams are supposed to break their work into goals that can be completed within timeboxed iterations, called sprints, track progress, and run 15-minute time-boxed stand-up meetings, called daily scrums, that help keep the whole team updated and motivated.
Many software developers don’t find daily scrums to be very useful. In fact, they often consider them to be a complete waste of their valuable time and would much rather use those 15 minutes to organize their work, respond to emails, and get to the right mindset for programming.
<blockquote>“I do not find daily stand-ups useful. Having worked at startups for 6 years and large companies (Google, Oracle for 5) I have yet to experience a situation where they have benefited the team,”</p><p> – comment of a software developer published on Quora.</p></blockquote>
When software developers start feeling that standups do nothing but waste their time, they often skip them altogether, which can lead to a plethora of other issues down the road. Scrum meetings are an essential part of agile methodology, and they serve as a communication tool capable of bringing to light obstacles that may impede work.
However, even the most useful tool in the world can be used both efficiently and inefficiently, and companies that worship Scrum often lean on the side of inefficiency. If they don’t want to lose talented software developers who prefer to spend their time solving problems rather than talking about them, companies strive to improve the effectiveness of their daily scrums.
Software developers are creative and value autonomy to choose the tools and technologies they work with. They especially hate when someone whose background isn’t in technology makes technical decisions for them without listening to their feedback or asking for it in the first place.
Companies looking to hire talented software developers are aware of this, and they advertise the freedom to choose a technology in job offers. It’s just that sometimes software developers get to choose only between a bad technology and an even worse one.
When software developers are forced to work with tools they don’t like, they may feel stuck, with little to no opportunity for growth and development.
<blockquote><p>“Good employees always want to continue moving up, forward, earning more, learning more, etc,”</p><p>“If they aren’t offered continuous opportunity to grow their skills, grow personally and learn new things that interest them, grow their salary, or earn enough in compensation and benefits to make them feel comfortable, then they will look elsewhere for a career and company that does offer these things.”</p><p> – Stephanie Troiano of The Hire Talent.</p></blockquote>
Granting the freedom to choose their own tools means not only happier software developers but also greater efficiency and better products. After all, who else better understands the tools that can be used to turn an idea into a working software application than the people using them to do the work?
Giving software developers this freedom may require some organizational changes to create a flexible culture with minimal to no barriers or bureaucracy, but such changes are always well worth the effort it takes to implement them.
Communication is a core part of software development, and companies prefer software developers who are able to speak clearly and with conviction, attentively listen, and empathize with others. Some companies value communication so much that a minute doesn’t go by without an email or Slack notification going off on the computer or smartphone of some software developer who is desperately trying to focus on a difficult problem but can’t because all he or she does is read, send, and forward emails.
Working in such an environment can be extremely tiring, and managers are typically the ones to blame.
<blockquote><p>“Unfortunately, a bad manager is one of the most common reasons good employees quit,”</p><p>“If your manager makes your work environment toxic, it’s only a matter of time until it wears you down and makes what would otherwise be a perfectly fine job, well, not perfectly fine.”</p><p>— Roxanne Williams, Marketing Director at Full Stack Talent</p></blockquote>
There are many managers who have apparently fallen in love with micromanagement, and there are just as many companies that love managers of this sort because they seem to be always doing something productive even though most software developers would beg to differ.
In fact, one survey by Fierce Conversations and Quantum Workplace, asked 1,300 employees to rate their conversations with coworkers and managers, and only about half answered “great” or “excellent.” Many responders were unhappy with frequent interruptions, saying that the endless barrage of emails and messages they have to deal with prevents them from accomplishing their tasks.
Managers should do similar surveys from time to time and let employees anonymously suggest improvements. Sometimes the best thing a manager can do is let software developers work their magic and trust their ability to communicate when they have a reason to communicate.
Get actionable product building tactics in your mailbox, monthly.
No previous chapters
No next chapters