DEV Community

Cover image for Suffering Developer Attrition? Remember: Replication Rarely Replaces Recoverability
femolacaster
femolacaster

Posted on

Suffering Developer Attrition? Remember: Replication Rarely Replaces Recoverability

The opportunities in tech these days are overflowing. There has been a significant attrition rate in many companies due to the abundance of opportunities in the tech space and the fast growth of the industry with so many offers out there that cannot be refused.

An offer that can not be refused

The disruption is intense and has come to stay and methods for business continuity must be instilled from the first day of business or employment to reduce the risks.

You CAP?

“No cap”, the CAP theorem might rear its head when it comes to employees’ division of labor and a distributed network of LEAN employees. More especially, employees in the tech space. With the abundance of opportunities, you probably would get only employees that guarantees either of the two of always being consistent, available, and being able to function well in the event of a partition resulting from a functional failure of an employee in the system due to absence or other factors. So how do we manage this CAP effect and instead improve capability among the limited capacity?

In this piece, I take you through how we may prevent and manage the effects of attrition using principles from site reliability engineering. You also want reliable employees and not just systems, don’t you?

Smiling and happy

Here, I give some points to ponder.

You probably have archives, not backups

Archives are a replica of a leaving employee’s skills, experiences, ideas, legacies, etc. You are probably looking for a suitable replacement that fits exactly the profile of the leaving employee. A handover which is an archival note by an exited employee may help the replica process. Employees who have the potential to function in some aspects of the leaving employee but the company is not training in those aspects or given a trial to explore those aspects can only serve as archives. Archives are great, but you should be keeping backups

What is a backup?

A backup is a mechanism that ensures recoverability for leaving employees. Useful system documentation tested to be efficient are backup notes. A business process model implemented over time and independent of a particular employee is a backup. Always seek to have more backups in place than replicas to tackle the problem of attrition. Because even if employees are replaced without the proper backup models in place, it only prevents faster onboarding and creates toil for the new employee. As new business opportunities come, employees need to be trained continually to serve as backups for the future scale.

Do you test your backup in attrition drills?

Now you have your backups. How often do you test them? How often do you test how employees would perform when another employee is unavailable. Leave and emergency days are one of those days to have these drills to know whether your backup is efficient.

You are not storing your backups in other media

You probably had attrition drills and when eventual attrition takes place, you still feel the grunt. It may be you are probably testing your backups only in the same media or in the same circumstance as the original entity was. It could also be you are not doing proper “employee geofencing”. Storing your backup in a different media would mean replacing leaving employees with having diversity in mind. This also helps that the same conditions that made the former employee leave should not also affect a new replacement. For instance, it could be the years of experience or geographic location, etc. characterized with the leaving employee are in high demand. And that would mean not diversifying your replacement could mean another leaving employee in some time. You may want to be intentional about diversity in the new employee(s) coming in. By the way, companies that have a more diverse workplace are perceived as better employers.

Avoid immediate permanent attrition (soft delete)

To ensure a safer relationship between the leaving employee and a company, always allow for an easy, unstrained exit. Avoid burning bridges through delayed or avoided due compensation. Communicate and offer negotiation options to the leaving employee till the last day of leaving. A day of extra communication could be the ice breaker. And make sure the attrition process is streamlined. Guide the leaving employee on the proper attrition processes and how backups can be made available for the period. Celebrate them on their way out. And create a channel for future redress, especially for promising talents. That way the attrition process is soft and you may achieve a soft delete.

Necessitate a blameless attrition postmortem

When employees eventually leave, it is always important to have a postmortem with employees working closely with the departed employee. This exercise should be blameless, expressive, and insightful. In this exercise, you should thrive to find out the root cause and the output should help derive major attrition service level indicators(SLIs) for the future or even improve employee contracts in line with the company objectives.

Reduce the influences of the Brent

Brent Geller is a character in the Phoenix Project, a novel about IT, DevOps, and helping your business win who was super-skilled and has a knowledge of the entire IT systems. Although he was a Lead Engineer, he ended up adding virtually anybody’s work to his. He grew until this became a norm and throughput reduced for other employees that most times consulted him. The Brents are bottlenecks and a reason for attrition as they unknowingly prevent continuity. Allow the Brents to focus on their focus. Intentionally leave them out of those matters that don’t concern them even though you think it can be solved by the Brents. Be intentional about letting other employees grow in face of challenges, incidents, priority tasks, etc. Embrace the risk to allow them to make the mistakes that the Brents won't.

Employee Observability and Monitoring

What metrics, patterns, and signs are you noticing in the attritions? Are you automating these metrics? SLIs for attrition? Has employee throughput dropped? Or employee availability reduced? Note that availability is not about how often the employee shows up at work, but how useful to function when needed as regards the employee’s contract. Or is the employee’s latency to tasks high? Are employees not trained enough to be durable for the company’s long-term objective? Do employees understand the company's objectives and how they should resonate with their working objectives(SLO) with the company? The best form of monitoring for humans is listening. Look for creative ways to instill listening to both verbal and non-verbal signs. Active communication is important. You should from these indications and mutual objectives constantly improve the contract or service level agreement(SLA) of employees and the company. Your attrition SLAs should be SMART(specific, measurable, assignable, realistic, and timely). Realistic especially. Since you are dealing with humans and you have to be human. If employees haven’t been meeting up with the attrition contracts, it needs to be reviewed.

Conclusion

The cost of non-replication or non-archival may deal with not having proper history or records of how past employees worked or losing some employee-dependent working process. However, non-recoverability could cost your company from moving on. It could cost your development team legacy codes, legacy processes, technical debts, etc.

So, plan for recoverability.

Remember: Replication Rarely Replaces Recoverability

Top comments (0)