If you’ve ever experienced a period where it felt like the majority of the engineers in your team (or company) have left, this article will hopefully give you some insights and areas you may need to focus on to turn the situation around or potentially improve future retention.
Firstly, it happens. It normally happens over a period between 6 and 12 months. The tech market is growing so rapidly that engineers are in very high demand (there are never enough of them) and they can move as often as they like — and regularly do. Before going into detail, let me state a couple of very obvious points here: when you lose an engineer (or anyone for that matter) in your business, that comes with consequences in terms of costs and retraining someone new. Just think about it: if the engineer had been in your company for 3 years, you probably hired them at a much lower price that you will need to pay to replace them with an equal.
The second very obvious point to state is that when an engineer leaves there is a lot of knowledge that leaves with that person, that could be system knowledge, codebase knowledge or process knowledge. Therefore if your engineering team does not have anything in place for knowledge sharing, it will be harder to get all the remaining team members up to speed, especially whilst also hiring, and that will just add on top of the frustration of losing a team member and their increased workload.
There are two key sets of reasons why your engineers may start considering looking for a new opportunity. The first one is normally related to business management, the second the tech stack.
Management and a lack of clarity or direction
Engineers normally get very frustrated when instructions are not clear. This is true at a task level, but also very true at a business level. Clarity influences every team direction, workload and sense of belonging. When the direction of the business is not passed down (or kept consistent) from upper-level management through to the engineers (or team in general), developers will struggle to understand the reasons for building what they’re told and they can quickly become frustrated or even hostile. Moreover, when there is no clarity, it’s also very hard for people to accept the constant change of priorities in business. A shift in the path to a target is only accepted if the target is still present and very visible.
How can you address this?
As part of the management team make sure you keep showing progress towards the targets your company or vertical has. Show your team how the new workload fits into that (both in text and graphically… so it can really capture their imaginations). Measure the cost of any diversions from your targets and do make sure to justify them. Do not be scared to admit and share wrong decisions, but make sure you learn from them and show improvement. Keep making sure the company targets feed into the personal team member goals in a practical way and make sure you pass that down to the inline managers and that they’re discussed during one to ones. As a team member, if you see that someone in your team regularly complains about clarity, try to help either directly or indirectly. Mention to your manager that maybe your team needs more sessions on the topic.
Management and process
Related to the lack of clarity and management, is either the excess or lack of a process in your engineering team. If you think about it, the process is very closely related to clarity.
If the direction your business is heading is crystal clear and passed down to everyone it will become much easier for your team to decide which tools to use in order to achieve the company or vertical’s goals. This is because every team has something to measure their success or failure against and tells whether or not they’re helping company goals. When it’s about “process” there are a lot of ramifications the discussion could have, but they could be grouped into two: too much process, or too little, and both can affect your tech team’s retention. Remember, the process is organising the workload, not your people.
How to address the “lack” of process
Firstly, and most obviously, talk to your engineers. Try to have their managers talk to them, but also make sure every team member can take part in an open forum where they can express any problems they see in how the workload is organised. Ask the team and the managers what are they trying to fix by putting a process into place. A process is a tool to make things easier, it’s never the answer to a problem.
Try to follow the chart below.
Once you know there’s a process issue, you will need to bring in an expert. Please, do not just assume the current people you have can put the correct process in place, whilst they might be able to, something has stopped them from being able to do it so far.
How to address the excess of process
Again, speak to the team first. Pinpoint what are the most painful parts of the process. Are they painful because they’re badly executed or because your team sees no value in them? If they see no value in them, how are the instigators justifying the presence of that particular process? Can you do a trial without these process steps and measure the impact of that? Once again, you may need external or impartial help to make this analysis.
Tech
If you have identified tech as one of the main issues for retaining engineers, then you may have a chance here to turn the tables or even become more relevant in the technology sector. Is your tech old? Is your tech not scalable and hard to maintain? Is your tech not supported by the community? Is it a monolith of hacks built on top of hacks? (I do appreciate that non-technical people may not know the answers to these questions, but at least you can get a general feeling on what a “tech stack” is all about). Engineers love technology: experimenting, improving, changing and making systems and codebases more powerful, up to speed with the evolution of the business.
Engineers want to make sure that tech can support the goals of the business, ideally ahead of the competition. Engineers love using tech in the right way mainly because they hope not to have to do more than needed when building features or executing tasks and this can help your business.
How can you address retention from a tech perspective?
Most of all, refactoring, scaling and automating all have to be seen as a business priority, not just something that belongs to the tech team. It can be addressed by itself with its own process or (even better) as part of every feature your team works on and tracked by itself without the need of a separate roadmap — either way, make sure that you have a way of measuring success and failure and give updates to the business. You could even push it one step further and make this “tech upgrade” a business case that your engineers could present at conferences so that you could attract more talent. Secondly, let engineering make it actually happen! Let engineers shape, improve and push the product forward using technologies they think will best do the work. If the technologies used are not the issue but rather the way in which they have been used, let them fix it! Make sure you do ask them questions on why it’s important and ensure you keep on track of the changes they are planning to do.
I hope this article was useful enough to emphasize the main reasons why you may struggle at keeping your engineers happy. We are very hard people to please (quoting my colleague Zoe here) but we do love technology and we stand behind its principles!
