Why you should be tracking the Average Programmer Longevity

Everyone leaves !!!

This was the first piece of advice I got when I first started Cousant. This advice was given to me by a mentor who owns one of the biggest technology companies in Nigeria.  I remember being slightly annoyed that I did not get more advice around the area of who to meet, where to focus etc. That was 7 years ago and looking back, it was probably one of the most important pieces of advice I could have received trying to launch a technology company.

If I could reframe the advice now, it read as such.

Everyone leaves so focus on building a resilient company

Over the years, Cousant has suffered many ills in the hands of Nigerian Software Engineers; from engineers resigning after just one week to engineers that suddenly stop coming to work and don’t bother to pick their calls again. Regardless of the circumstances of exit, the fact remains that most employees (especially in a startup) would eventually move on, and organisations must be prepared to deal with this reality.

Regardless of the circumstances of exit, the fact remains that most employees (especially in a startup) would eventually move on, and organisations must be prepared to deal with this reality.

The impact of such resignations on projects are huge and cost companies millions of naira in delays and productivity. There is also the emotional toll on managers stemming from key resignations. Managers like to think of their organisation as a family and it is very disheartening to see family members leave especially when they are needed the most.  I can’t count the number of times I have had to provide a comforting shoulder to a founder who had a key software engineer resign in the middle of an important project.

Nigeria as with most other countries in Sub Saharan Africa has a high attrition rate for technology professionals. This is due to of increasing demand for a small set of qualified talent. We see this play out too often in our technology recruitment business (Cousant Connect). At any point in time, at least 50% of the job openings our recruiters work on are a direct result of the high job mobility.

I can’t count the number of times I have had to provide a comforting shoulder to a founder who had a key software engineer resign in the middle of an important project.

There are a variety of tools organisations can adopt to reduce attrition rates from remuneration, perks, culture etc. However, for organisations that employ Software Engineers, there is always the real possibility that they would eventually move on due to the massive demand for their skills both locally and internationally.  Managers must therefore plan for this and put in measures to mitigate its impact.

The Average Programmer Longevity (APL)

One of the key metrics managers should be tracking is the Average Programmer Longevity (APL).  The APL is a metric that measures the average time software engineers spend in an organisation before being fired or resigning. 

I started to think about the APL metric recently because I noticed a key trend in the data from our technology recruitment business. Over the years, we noticed there was a pattern to how long it took for our clients to reach out to replace IT staff that had resigned.  This differed for each client depending on factors like size, funding, culture, remuneration, but there was certainly a trend.

Over the years, we noticed there was a pattern to how long it took for our clients to reach out to replace IT staff that had resigned.

The APL is a powerful metric that can be used by managers to better prepare for or stall sudden resignations. Managers that track this metric have a number of options to explore

Review staff incentives

For example, if an organisation has an APL of 24 months, then managers can start conversations around promotions, bonuses, perks at each employee’s 20 months anniversary to further incentivise them.

Kickstart hiring processes for possible replacements

A key issue with the resignation of technology professionals is the length of time it takes to find and hire replacements. To mitigate this, managers can adopt a policy to start looking for possible replacements before the APL.  Should a key team member choose to resign, there would already be a pipeline of possible replacements.

Improve the APL

As the saying goes, you cannot improve what you don’t measure. As part of an organisation’s long term planning process, tracking and improving the APL should be a priority for not just technology managers but also the Chief executives of the organisation.

The APL is a metric that measures the average time software engineers spend in an organisation before being fired or resigning. 

Measuring the APL

The APL is an easy metric to calculate since it relies on data that is readily available in most organisations. The APL is based on employee start dates and exit dates over a period of time.

The first step is to decide the time period for which to measure the APL. The period must not be too short a time horizon in order not to be affected by short-time spikes. A good time horizon can range anywhere from 5 – 10 years.

The next step is to gather the relevant data of all employees that started and left the organisation within over the selected time frame and arrange in a table as shown below

The final step is to calculate the APL using the formula below

 APL = Total Duration / Total Employees

Using this formula, the APL from the sample employee records will b be 222 / 5 = 44 months.

The APL Skills Matrix

From our experience, we have found that the APL can be differ depending on the skillset and years of experience. Certain skill sets are in higher demand than others and there is usually more demand for senior roles. As such, organisations that have a variety of skilled engineers in their teams should track the APL per skillset and experience level using an APL matrix.

An advantage of drilling down with the APL skills matrix in this way is that it helps with resource planning. For example, it may make sense to hire an intermediate level .NET Software engineer over a senior level .NET programmer if the intermediate level engineer is likely to stay longer at the organisation.

…technology managers are most affected by the high attrition rate in technology and as such, should be taking the lead in tracking and improving the APL

Responsibility for tracking the APL

Should HR or IT track the APL?  It may be tempting to assign the responsibility of tracking the APL to the HR function since the APL is similar to the Average Employee Longevity (a HR metric).  However, technology managers are most affected by the high attrition rate in technology and as such, should be taking the lead in tracking and improving the APL. Beyond that, the APL goes a long way in improving the resource planning capabilities of technology managers.

The APL is a must track metric for all technology managers in Nigeria. It helps bring sanity to the resource planning process. It also helps managers better prepare for the inevitable exit of key staff. Are there any other measures you put in place to mitigate the impact of key resignations in your organisation?