Software Engineers retention: career paths, skills matrix and common mistakes

This chart comes from a survey done in 2021 (source is here) which was definitely a different time for developers and for the entire economy. Looking at the reasons, though, I am pretty aligned with them and I think they are still very valid today.

Look at how important it is for developers to work on new technologies and to have clear growth opportunities: one or the other companies are usually making mistakes in these areas. Everyone knows that if your underpay it will be difficult to retain software developers, but not many companies are investing heavily in designing career paths for their people or are thinking about modernizing their stack to avoid losing people.

Always from the same survey it’s clear that learning and development are two big areas here. If you want to learn a lot more about these topics you should spend 30 min reading some Reddit channels like CSCareerquestions and you will find a lot of these topics constantly being discussed and addressed in the community.

Again, you can find a lot more data online but it’s key that you understand why your software developers are leaving the company.

Let’s take a break here and focus on something I’ve heard many times from managers and other entrepreneurs. When your software engineers quit – in my experience – things cannot be fixed anymore and money is just an excuse that might work for just a few more months. This is true for every employee in your organization.

I have a simple principle: never counteroffer unless the person you are losing is extremely critical for the team. Even in that case, it should be an exception and not the normal approach you keep and I highly recommend you explain to the team why you decided to act that way.

If a software engineer has already decided to leave, that’s rarely because of money (assuming you pay market rates) and offering more money will simply delay your problem if he decides to stay. It will also create a major problem in your organization: everyone now knows that they can simply try to quit to get a raise. Everything you have done to define career paths becomes useless.

I’ve made this mistake and I might be doing that again but every single time it creates more issues than it solves.

If someone in your software engineering team is quitting, in 90% of the situations it’s too late to save him. Focus on understanding why they are leaving and how they got there. Ask them questions, set up exit interviews with your HR team and actively brainstorm the reasons they give.

A lot of engineers (and to be honest, a lot of employees in general) will simply tell you that they are leaving because of a higher salary but they loved things in your organization and there was nothing else that did not work for them. They are lying – there is always something else beside the economics involved. Set up a proper exit interview process and ask your HR team to help you find those reasons, they know how to do it and are particularly good at it.

Software engineers want to invest and stay in companies that will make them grow and advance with their skills and experience. After years of working with digital technologies and tech teams, I think this is probably the most important aspect if you want to retain, attract and motivate the best software developers. It’s right up there together with the ability to build great products and using modern technologies.

Big salaries without any growth opportunities and a lack of development will always push people to leave – often just after a year or so. I’ve seen this often when we have lost great software developers attracted by companies with deep pockets but little opportunity to grow and learn new things.

A lot of the software engineers that you hire in their 20s and 30s will likely want to move to roles that are less focused on writing code and more on product, strategy, and management over time. This is a key issue for all the companies that nowadays have a young cohort of software developers and want to retain them and something that you can solve with well-structured career paths.

I briefly talked about the importance of defining career paths, let’s dive deeper into them and if you are interested in learning more I wrote a blog specifically about the career path for software developers.

Defining career paths might be more difficult for very large organizations. For simplicity let’s say you have more or less 100 people in your software engineering organization. I am also considering roles like DevOps Engineer, QA Engineers, Product Managers and other roles that are not strictly engineering.

These are the steps you should follow:

Map your roles / job titles

This is simply about counting how many unique roles you have in the org. Let’s say 15 roles (e.g. Junior Software Engineer, Sr. Software Engineer, Tech Lead Engineer and so on). Each company has different roles and strategies on how to map them.

Define the most common skills for each role

Now for each role you should define and map the core skills you need – both technical and soft skills. For instance, a tech lead will need to have a lot more soft skills listed in the role. In my experience, these should be a comprehensive list that is easy to understand and explain to your people and something you can easily refer to what’s expected of them in their daily job.

Define the relationship between roles and how you move to the next one

One of the advantages of career paths is the ability to let people know what the future could look like and let them evolve and study to go into a specific career path. That’s why it’s important to have options. For software engineers, it might be about staying into a technical role or getting into management. Even better, if you collaborate with Product or other departments you might consider offering them even opportunities in other technical roles across the organization. Software engineers are a great fit for several tech roles in sales or customer success, more about leaving software engineer career path here.

Select internal and external content that is relevant to each role

The last step is about building a proper list of content for each role. The idea is that your people will be able to prepare for specific roles autonomously so each path should have an ordered list of content related to your organization or coming from external sources (YouTube, Linkedin Learning, Pluralsight, and so on).

The most important thing to keep in mind is to make your paths as real as possible for people in your organization: they should have 30-50% of the content coming from your documentation and be focused on your culture and business. That’s key to letting people feel like they are learning how to grow inside your organization and are not just acquiring skills that are too generic.

Set a salary range for each role

This is key in my experience and will strongly contribute to building trust with your software engineers and ensure retention. For each role, there should be a visible and public salary range.

For your existing software engineers the best way is to have your VP of Engineering or Engineering manager present it and go into the vision and strategy of it. This is always well received by the team and it creates a great sense of trust with the company.

Candidates that are applying for your software engineering roles will love to learn about it even before the interview so I would mention it in the job description and I would send a copy/access to it to everyone you decide to interview. Your talent acquisition team is usually the one explaining it during the first interview.

This is a common question that I am sure your leadership will bring up at some point. The logic is simple: if you tell people that they can get promoted into new roles if they have the skills and experience for it, they will then pretend that.

The reality is that career paths are never a way to automate promotions. First, consulting companies are the only ones that have that type of approach (and even there, it’s not automatic), second because the career path is not something you just need to assign and wait for people to be ready, you should use it to create a culture of growth, trust and meritocracy. Once assigned and explained the managers need to spend time talking about it in their 1to1s and set the right expectations with software engineers.

Your software engineers know that a career path is not an automatic promotion pass but it’s critical for them to know exactly what will be expected in the future and what they can start preparing for – with clarity on skills and content they can use to get there.

Implementing a career path at my previous company has been one of the most successful things to improve our retention. It saves us tens of thousands of dollars per year spent replacing engineers with recruiting fees and time involved and most importantly it allowed us to establish a very transparent engineering culture where people would know that joining our company was also about very clear opportunities for the future.

Two parameters: turnover and number of people promoted in new roles. These are the two most important ones and it will take 6-12 months to see them in your software engineering organization. Turnover should drop while you should start having the first people promoted into a new role – ideally one that you were looking for.

A third one you might want to consider is the number of successful hires. This is more difficult to track but when we implemented paths we have also seen a better conversion rate in our hiring with more offers getting accepted.

As your team expands you should consider not only mapping skills for each job role for your software engineers but also assign a specific competency level required for that skills. This is about describing, for each role in the career path, the list of skills with their level (e.g. Python might be a must for Sr. Software Engineers with a level of at least 3 over 5).

Adding this level of detail allows the team to know exactly what will be considered enough for a specific role and how they compare to that. It creates more meritocracy in the way people get promoted and prepare for their next step but it also gives them an understanding of where they are in terms of competencies.

This is a nice template in Google Sheets that has been built by CircleCI and has a list of skills and seniorities. There are several different templates and approaches to building a skill matrix, so don’t look for a single way of doing it and try to create something that works for your organization.

Partnering with your HR team is usually a great way to discover why your engineers are not staying in your organization and build a proper strategy to solve for it. Sometimes engineering managers and technical leaders tend to act as lone wolves and avoid open collaboration with their HR counterparts. That’s a mistake.

I made that mistake in my early career treating HR as a separate team that had to be involved only in specific situations (and mostly when things were going south with our people).

How HR professionals can help you retain software engineers:

• Build a better relationship with software engineers – as a manager – can’t. And due to that they will discover things that you completely ignore. This is usually something to consider while things are going well. Have your HR business partner spend time with the team from time to time and build a relationship of trust.
• Keep a pulse on market trends and data: they talk to thousands of people and candidates and can spot things that you are not aware of.
• Establish common goals: you both care about retaining your people and build the best culture possible for your engineering team. Start with that and define clear goals and KPIs you can review monthly.
• Evangelize your vision and strategy: back at the beginning of this guide we talked about the importance of setting a clear vision and set of expectations while sharing information with your software engineers. HR can be a strong partner and help you amplify your message. The starting point is involving them in your meetings and be as transparent and clear as you want to be with your software team.
• Career paths definition: this is a must. Of course they can help build it (and most likely they will have more experience than you) but they can also help your organization explain and evangelize the career paths across the entire employee life cycle, starting with the hiring process.

Anthropos is a comprehensive solution to map and develop your entire organization of software engineers with a modern approach that gives you constant trends and data and to them a platform that advances their skills and careers.

When you invite your software engineers into Anthropos we create a profile for each single person and give them access. With that we also automatically map all their skills and help you visualize them in our Workforce Intelligence tool: it automatically categorizes skills on the most common job roles and helps you identify the most critical collaborators in your team.

After that, you can start using Anthropos to create a full set of career paths for your software engineers, based on your job structure and the skills you need. You don’t need to reinvent the wheel with Anthropos: you can build every single path with your proprietary content or connect courses and content you have in other libraries (like Udemy or Pluralsight). Everything is connected by skills so it’s easy to quickly see who among your engineers is progressing and who needs help. And they don’t need to start every time from scratch, our systems know what content they will have to learn and what is not needed because they already have the right skills for it.

This system helps you have a clear understanding of your skills and abilities in the software engineering organization but it also helps give it a clear career path that they can navigate, get assigned to (if you like), and start learning with.

If you want to see how Anthropos can help you, just schedule a demo with us.

A few weeks ago I was talking to a CEO who wanted to understand why their software engineers were not always open with him and had challenges openly sharing what they did not like inside the company. I’ve been there a few times in the past and I could easily relate to what he was experiencing.

I immediately told him he had to try different ways to build a relationship with their software engineers and be aware of how people looked at him as the CEO of their company. I believe that the CEO – or the company owner – should spend time to share with developers the vision and the company strategy and let other people in the management deal with more delicate conversations (hint: your engineering managers, HR leaders etc.). Nobody feels good about telling their CEO what doesn’t work and why, especially if it involves them. When you force developers to do that they simply share less. Even in small companies with a strong and open culture, it’s rare for CEOs to play such a role.

Your objective is to align your team around the same vision and strategy: explain to them what you envision for the future, and share as much information as possible about your company goals and why they matter. It’s something that only the CEO can do authentically and powerfully and it will have a strong impact on your team of software engineers.

Authenticity is your secret power. Don’t shy away from sharing not only your vision but also the challenges you see to get there and how solving them will enable the business to advance. Your software engineers want to know where the company (and the product) is headed, as much as any other role in the company.