How much is turnover costing your company?

The software industry has a turnover problem. The general consensus is that it takes around 6-12 months to fully onboard a new hire. Essentially, you hire someone for 100k a year. Then it takes roughly 6-12 months before that person starts producing work at the 100k level. This would be fine if Software Engineers did not change jobs frequently, but we tend to switch jobs every 1-3 years for higher pay. 

Let us consider the case of a company with a complex project and slightly high turnover. They need a full 12 months to onboard a new engineer and they can expect that engineer to stay at the company for 2 years in total. If onboarding proceeds linearly that company ends up paying 2 years pay for 1.5 years worth of results. The company is spending 25% of salary on training for the lifetime of that employee. 

If the company managed to get the average lifetime per employee up to 3 years they would spend 3 years pay on 2.5 years of work or roughly 17% of salary on training. 

A company in this situation could afford to give an 8% raise if it kept an employee around for an additional year. 

Onboarding Preparedness Quiz

I am working on some materials around onboarding new engineers.

The Quiz

When was the last time you onboarded a new engineer?

Do different team members use different development environments to run integration tests locally?

Do you have architecture diagrams that are up to date as of last month? 

Do you have an up to date list of the APIs you consume and what their SLAs are? 

Do you have a list of all the internal tools your team uses to complete their work? 

Do you have a list of all the 3rd party tools your team uses to complete their work? 

Do you have a list of all the configuration files that your services use? 

Do you have a list of all the resources your services consume, object storage, disks, caches, VMs, queues, etc?

You can’t estimate a story in 2 minutes.

The typical agile process involves 5-10 people in a room. They go through one sentence descriptions of tasks, and each secretly comes up with their own estimate before every turns over their cards like in the final round of poker.

Then there will be a couple minutes spent discussing the estimates which will end with the average of the “votes”.

These meetings are usually confused by someone misunderstanding the breakout of one particular feature into one sentence descriptions, causing the group to backtrack and re-estimate several of the stories.

Most of the team will think about each task for a total of 2 minutes total. 

The intention is that the project manager will take all this data and gradually calibrate the estimates.

I have spent a great deal of time participating in these agile “estimation” sessions and I can assure you that the estimates I produce in this setting have almost always been far off the mark.

Projects commonly run over what they were estimated, and sometimes a project estimated to take a month actually takes a day if you get the right person to work on it.

After 3.5 years working in this environment the whole process seems pretty pointless. Everyone knows the estimates are wrong and plans for it. Why do we bother doing this process that is known to be unreliable at best?

In construction estimates are done off of detailed blueprints using well understood heuristics, equations and the price of materials. 

In software estimates are done off of one sentence descriptions of heterogeneous tasks and the gut feel of developers about how long something will take.

Continuous Delivery of Bugs

Agile Rapid Delivery means you deliver bugs to your customers everyday. 

Every once in a while I read an article about how software has become horrible over the last decade. Software has gotten slower, it uses too much memory, it has too many confusing features, why are developers producing worse software? 

Part of this is coincidence. We remember software being fast, but that was during a time when CPU speeds doubled every year. By the time you had used a program for a year, there was a processor out that could do it in half the time. Now Moore’s law ambles around at low double digit performance improvements. 

Another issue is feature complexity. “The old software just worked, why did they have to change it?” With the move to Software as a Service we can constantly add new features. 

Frequency matters if you deliver buggy code to your customers once a year on CD-ROMs. They are going to complain about buggy code once a year. If you deliver buggy code to your customers everyday, they will probably give up and accept their fate.