The IT Industry has one of the highest turnover rates, with an average of around 15% in the past years. We can’t ignore this phenomenon, and even though you invest in increasing the retention of your tech teams, people will sometimes desire a new challenge. A reasonable strategy would be to consider both people’s wellness in your company and tackling risks due to turnover, one of the most important being knowledge loss. Even though that topic obviously concerns all departments within an organization, we narrow the focus to technical knowledge.
I’m pretty sure you’ve already lived this panic feeling around you when a developer (let’s say, Lucy) announced their incoming departure from the company. Why such a reaction? It’s not only because you had good relationships with them, because you don’t get panic about that, but you can feel sad. No, one of the reasons you panic is you’re afraid to lose skills and highly-valuable knowledge.
Lucy is used to being solicited when people seek advice, answers to technical issues, or best practices to follow. She’s very active and stands as a referent for many developers in the team and even for the whole product team. Although she trains people, she’s still overwhelmed and doesn’t have enough time to write down all kinds of documentation that would make the team autonomous.
And it’s precisely when she announces her departure that colleagues embrace her to ensure knowledge transfer until her last day. She’ll do her best, but she’s likely not leaving all the necessary documentation in the Wiki because her role is critical, so she’ll need to work on other tasks every remaining day.
NB: This “hero” is just an illustration; it does not mean that other developers don’t have any knowledge to transfer since everyone does.
This knowledge is heterogeneous, and here is a non-exhaustive list:
- Technical procedures: how to set up the project on my laptop and access the different tools we use weekly in our team, …
- Best practices: the coding standards and guidelines we should apply daily in the source code, regarding a programming language, a framework, security/performance/architecture aspects, the testing methodologies, …
- The CI/CD overview: what is the magic happening between a Git Push and the redeploy a few minutes later?
- The “production” overview: what’s the architecture of the app in the Cloud Provider, how to monitor/debug it, how to connect to the different servers, …
Commonly, not all developers in a team have a complete overview of these topics. But it’s often that a kind of “hero” developer has.
“We might have some difficulties when she’ll leave”. And yes, you’ll start to feel it when you’ll face some technical issues and have no expertise in the team to address the situation. Consequently, this can directly impact your business due to:
- A slower delivery time: when problems need more time to be resolved, tasks take longer to be completed. And delivery gets delayed, and that impact your customers and users.
- An increased risk of bugs: less expertise means that problems are less likely to be caught during code reviews, and as in the previous bullet, this might have undesired consequences.
- More accidental complexity in the code: if best practices tend not to be applied, the source code will lose uniformity and will probably need unplanned rework later. So this also impacts maintenance costs.
Developers leaving an organization can have a non-negligible impact on your business, so you should be prepared for that.
While it’s a huge challenge to prevent any loss because there’s often too much to know, we know how to mitigate the risks with practices we can use every day:
- Mob/Pair programming: Designing and implementing solutions with other developers is excellent for fostering technical interactions and discussing best practices. Tools like Visual Studio Live Share support remote pair/mob programming.
- Code reviews: Established in our industry, code reviews are usually performed on GitHub/GitLab/BitBucket/your_favorite_tool, and support knowledge sharing while promoting code quality.
- Craft Workshops: This is a regular meeting dedicated to best coding practices, where developers submit proposals and decide together which practices to keep for the project. It’s also a time to get updated with other teams’ best practices in an Inner source model. Packmind is a tool that supports this model.
- Internal Workshops: BBL, Meetups, or technical sessions are a great time to share knowledge and learn from each other. The CI/CD expert can take 30 minutes to explain how things work to everyone in the team.
Have you ever faced issues after someone left your company? Feel free to share your story with us :)