Replacing a developer: the hidden costs

We've all been in the situation of having to replace a developer due to unforeseen circumstances or their departure. Do you know how much this process costs the company?

When Scrum is misused, it can be a regrettable experience. This situation leads the developer into a cycle of disappointments from the moment they wake up, starting their day with anxiety, striving to break free from the daily downward spiral that has them finishing each day much later than the previous one. As the sprint's progress stalls and the progress line remains worryingly above the expected ideal curve, the developer begins to blame themselves. "I'm not working hard/fast/effectively enough; my client/boss will get upset." So, they work longer hours, developing a strong caffeine addiction and neglecting their basic self-care needs (the gym equipment is gathering dust...). When the sprint finally ends, with the user stories (HU) almost complete, we find a slightly disappointed Product Owner (PO) who has to explain to their client why they haven't delivered everything committed to, and a tired, demotivated developer who remembers the job offer they received from another company the evening before on LinkedIn... contemplating whether to respond...

A not-so-smart Product Manager (PM) might think, "So what? This developer was hired to deliver results, and that's precisely what is expected. If they can't meet the sprint commitments, we'll replace them with someone who can. I have several resumes from boot camp graduates I met the other day, and they're real whizzes." What this "professional" doesn't understand is how incredibly expensive high developer turnover can be. Most studies on the cost of replacing a developer estimate the cost at 0.75 to 2 times their annual salary. Therefore, for a developer earning 40,000 euros, the true cost of replacing them ranges from 30,000 to 80,000 euros. Why are turnover costs so high?

Knowledge is Power

In software development, knowledge truly is power, and this knowledge extends far beyond being a "hacker." Achieving a high level as a developer means mastering multiple aspects that are the main differentiator between a good developer and someone who can code.

Engineering Knowledge

The most obvious characteristic of a good engineer (a developer is an engineer, creating solutions) is their ability to develop secure, usable, maintainable, scalable, viable, effective, integrable, efficient, and testable solutions to meet complex requirements in any language or technology that suits their mission. This requires a range of skills, from having a solid architectural vision to thoughtfully applying effective solutions, thoroughly testing the system's response to any imaginable scenario (because if an end user can break it, they will), and quickly understanding and fixing the root cause of errors. That's why engineering is such a well-paid field.

Fortunately for many companies willing to invest, engineers carry these skills from one job to another, refining them throughout their careers. You can almost always find another good engineer if your offer is enticing enough. Unfortunately for these companies, these skills represent only part of what makes a great engineer.

Business Knowledge

Most companies hope that with a brief business explanation, the developer can create a solution that meets their expectations. This rarely happens and leads to mistrust, creating an insurmountable barrier between IT and the business. Product Managers (generally not POs) understand end-users' needs and dream of a product vision, but they often can't write detailed requirements with enough scenarios and data for the developer to estimate and define a viable architecture. Nevertheless, these PMs are the bosses and wield authority over the development team.

This approach may seem "logical" as it appears to give the PM more direct control over development. However, it shows a lack of understanding of the software product development process. This method is also favored by developers with strong persuasion skills, who are often seen as gurus, and by many project or consulting firms that end up steering the project toward their own personal vision, forcing the client to accept it. Unfortunately, project after project has shown that this approach usually doesn't work (80% failure rate).

The language of business is drastically different from code, and even though Behavior-Driven Development (BDD) tools like Cucumber have tried to mitigate this issue, there are always implicit requirements that Product Managers fail to express in words, leading to misunderstandings by the developer. This is where the role of the Product Owner becomes crucial. Business knowledge is a task for which they are prepared, and they possess the tools to convey those needs in a format suitable for the developer, whose expertise should be technical.

The problems associated with acquiring Business Knowledge represent the primary cost of developer turnover. Good development/engineering practices transfer from one company to another, and any qualified developer can learn new languages/frameworks/technologies/systems. Undoubtedly, the Business Knowledge a good developer acquires during their time with a company can work wonders in terms of adding value in the future. However, this effort is measured by experts at around 18 months. Considering that the average developer turnover is 6-9 months, does it make sense?

A developer with expertise in a specific business not only interprets requirements more accurately than a newcomer but can also advise the product owner on delivering value effectively, as they understand both user desires and the work required to fulfill them. Losing these developers means losing a significant portion of valuable knowledge. However, they are unlikely to attain the same level of business knowledge as a PO within the same timeframe and with less turnover.

Interpersonal Skills

Interpersonal skills or knowledge are acquired through experiences and interactions as developers move from one company to another. It is a fundamental part of a good developer's job to establish contacts and connections in the software field that help them improve both technically and professionally.

Our society often portrays programmers as eccentric individuals, overweight, averse to natural light, with a sickly coffee addiction, and an inability to relate normally (an Asperger's profile). While this might fit some members of our community, software development attracts a diverse range of people, as projects require various profiles and roles, and there is a lot of interpersonal communication in the daily life of a professional developer. Yes, perhaps too much for some. In addition to effectively working with a team of highly skilled individuals from diverse backgrounds, developers in many companies must frequently interact with other departments, sometimes on topics entirely unrelated to their work. Establishing bonds with these people can be advantageous at times, but it is an effort (deemed unnecessary by some developers) that may not be required (since they have no employment issues) and can steal precious time needed to complete the committed sprint.

Turnover is Costly

Organizations must consider the pressure they place on these professionals with families, hobbies, pets, and quirks (pet ownership can be quite challenging). So, while I'm not suggesting that we pamper developers more than others, it's important to be aware that their role in the business is vital, even if only for a certain period, and that a manager often lacks the knowledge to understand the effort involved in a development project. The usual practice is: when I don't understand, I apply pressure. This "churn-and-burn" personnel management model is not advisable in software development.

Our experience with our clients' Squads is clear: it's better to hire an additional person to support the developer rather than let them go and search for someone new who can perform all the project's functions. In the end, the project is completed faster and with better quality, and the developer feels grateful for having helped fill that crucial gap, having learned or improved skills for the next project.