Menu

Quitting Time: Engineer Ramp-Up Cost

I’ve seen estimates that say that it costs a person’s annual salary when they leave the company. This seems to vary wildly as shown in [1], and [2]. I have heard estimates as high as twice the salary of the person leaving, in terms of the cost of his or her replacement.

Ramp-Up Cost?

Dear reader, replacing any employee has a cost, including many factors:

Lowered Productivity

Interviewing

Recruitment and Recruiters

Training

Administration

Relocation, if applicable

…and the list goes on. From what I have observed, human resources (HR) staff have a good understanding of the costs around recruiting candidates. Suzanne Lucas mentions some of these factors in one of her posts here.

Unfortunately, HR folks sometimes have no easy way to estimate the cost of ramp-up of a replacement person, particularly of an engineer or software developer. This is completely understandable, because it is not something that lends itself to quantification.

For the sake of this discussion, I will use the word “engineer” generically, to mean any person in a highly technical or technically-facing role.

So, I want to focus on ramp-up costs of an engineer. I recently took some time to ponder a very simple, seat-of-the-pants way to calculate this cost. My requirements for the calculation:

it must be simple to use.

it must be easy for non-technical people (like my HR friends) to apply.

a person must be able to do the math in their head.

it must hold up to a simple, non-empirical litmus test based on my own experience.

The Litmus Test

Let’s start by thinking about the Definition of Done.

Since I have had a large number of different software roles, I have “ramped up” too many times to remember. So, I will estimate that the time it takes for me to become “comfortably proficient” in a role based on my own experience.

Of course, this approach will be slightly biased to my skills, limitations, and opinion. But this is my blog. So my estimate goes something like this:

Junior level engineer on a small-scale, constrained product with little inter-group communication requirements: one to two months to ramp-up.

Chief architect in a large scale role: one year or more. In fact, I think this is a conservative estimate, if we are considering someone with well-rounded technical skills and good interpersonal/corporate skills (hint: I talk about this in my book) in a key role.

This may be optimistic if the company has unclear or chaotic organizational bounds, and the engineer must have a solid internal network to be remotely productive.

If you have been following along, you might notice that I already reasoned about some of the variables involved:

the technical characteristics of the role itself,

the non-technical challenges of the role itself, and

the characteristics of the organization.

Okay, enough analysis, let’s take a look.

Simple Cost of Turnover Formula

Here is my super-simple formula:

Replacement Ramp-Up Cost, In Months = Monthly Wage * (T * R * O)

All complexity metrics (T, R, and O) are T-shirt sized (i.e. Small/Medium/Large…) and I will assign a seemingly-arbitrary number to them:

Small = 1

Medium = 1.5

Large = 2

Nasty = 2.5

But wait! What are those factors, really? It looks like they basically turn into a month representation, right? Yes. Remember, I wanted it to be simple.

T is for Technical Complexity

Technical Complexity represents the complexity of the technical demands of the job itself.

If the company is a small business with a sub-100,000 SLOC (source lines of code) web app, some C# .NET MVC server side code, a fairly recent Javascript-driven front end, and a small database, then the complexity is probably Small.

If there are multiple products, say into the million SLOC territory, with multiple technical frameworks involved, then it is a Medium.

I don’t want to imply that SLOC is a great metric overall, but it does give a very rough sense of magnitude.

If the company is a large enterprise organization with a sizable product portfolio, a long technical history and large amount of mixed technical baggage, then this presents a far more complex challenge and is probably a Large.

If the company is large and software is not necessarily its core competency, then this might be a situation where technology is freely mixed, ungoverned, and chaos rules….perhaps it warrants the “Nasty” category, because everyone must have a certain command over a large set of deep technical baggage.

R is for Role Complexity

The “Role Complexity” factor refers to the level of savvy, or non-technical skills required for the “operational” part of the role in question.

If the role is a junior developer that is engaged with controlled work with direct oversight, explicit constraints, and not much in the way of business acumen, then that person need not have much savvy; this is a Small.

For a role that involves some higher level understanding, broader perspective, some decision making, and some ability to understand and operate within and between organizational structures, then it is a Medium.

If the role is a key player with broad skills and deep understanding of the technical products, the ability to communicate across audiences, or evangelize key strategies, then this person must have their wits about them on a daily basis. This takes a particularly savvy person (take my word for it), resulting in a Large for the Role Complexity factor.

If role is Large, plus heavy conflict or contentious interactions with others, then this might quality for Nasty. It might be hard to see this going in, but I would expect people to be leaving already at a regular pace!

O is for Organizational Complexity

Organizational Complexity refers to the company structure. Here, I am talking about the number of teams involved in day-to-day work, the health of those teams, the structure of the involved parts of the organization, and their effectiveness in executing toward the company goals.

For the small business example I mentioned previously, where there is probably a single small development team, and not many other involved groups, so this is a Small.

For a mid-sized company with, for example, 10 to 50 developers on the immediate team, a separate but co-located QA group, and a co-located product team, then it is a Medium.

If it is an enterprise company with a on- and off-shore resources, very large development teams, remote product teams, remote QA teams, and day-to-day interactions with different cultures, timezones, and audiences, then it is a Large. A new hire has to be a more operationally effective in this type of environment.

If the company is Large but there are organizational silos that prevent progress unless there is high-level intervention for each and every initiative, this might qualify as Nasty. Of course, this is subject to interpretation.

Eating The Dog Food

Revisiting my own litmus test above yields the following.

The Junior Engineer

For a simple, small company, the replacement junior engineer’s ramp up, assuming a $70K salary, is:

This is not an enormous number, but when you consider that this is a month of pay for little value in ramp-up, it is not trivial to a very small business.

What if the case is a junior developer hired into a “Nasty” organization? It is still a Simple for the Technical Complexity, and Simple for the Role Complexity, but the organizational characteristics impose constraints on everyone:

$70K/12 * (Small * Small * Nasty) = $5,833 * (2.5) = $14,583.33

The ramp-up just got bigger. Indeed this might make sense if even the junior developers have to determine that they must navigate around organizational challenges or silos to get their work done.

This makes conceptual sense, because learning to effectively navigate an organization does not come for free. It can be as difficult as the technical demands of the job.

The Chief Architect

The Chief Architect is normally at or near the top of the technical career path. For a large organization, assuming a $200K salary:

Ouch. But this reflects the challenges of becoming effective in such a high level role.

How about the chief architect in a large company that is rife with interpersonal conflict, while having a very silo-oriented organizational structure that makes it almost impossible to push architectural agendas to fruition? That might look closer to this:

In other words, with an increase in role and organizational challenges, comes an increase in the cost of bringing someone up to speed to deal with those challenges.

Reality Check

I used variations on the above numbers for some equally seat-of-the-pants hypothetical scenarios and generated the chart below. Here I assumed that, for example, the junior developer is shielded from uglier parts of even a Nasty-level organization, but the chief architect is exposed to it all (click for a larger image):

Obviously the ramp up time increases quickly as the new recruit is exposed to more complexity. I would imagine that these variables would carry a variable degree of weight depending on the person’s personality. It would be interesting to fuse a Myers-Briggs correlation in there somewhere.

Obviously I am playing with numbers at this point, and your mileage will vary. If organizations track their “actual” ramp-up time, they probably do have enough historical data to determine some rough T * R * O numbers that could be used in performing equally seat-of-the-pants calculations like those presented here.

If they track ramp-up time. That assumes, of course, that they actually care to track it.

At minimum, ramp-up time seems like it would be an interesting ball-park number to know, through directly survey of the newly-hired engineers, once they feel that they are productive or effective.

But Wait, There’s More

Wait! There are still all those replacement costs I mentioned at the start: recruiting, marketing, HR overhead and so forth. That new recruit probably goes through orientation, which is never free.

There is a nice online calculator here that can be manipulated to show almost any numeric range, but you can see that including relocation costs, agency fees (check out [3]), and so forth, could easily add up to a large percentage of the ramp-up numbers themselves.

Others have explained these costs better than I can. So for this discussion, I am satisfied simply to be aware that ramp-up is one piece of the puzzle, making turnover a possibly expensive challenge.

Conclusion

It seems obvious that ramp-up cost of replacing engineers can be high indeed. While the estimate of two times salary might seem like a stretch, it might be true in cases of extreme skills or organizations.

Replacing technical staff is certainly not as simple as getting people off the street to shovel rocks into wheelbarrows. Technical and abstract work, particularly in the software space, is fundamentally different than manual labor!

Post navigation

great post! Also a very interesting but difficult topic. Would add a couple other things that really puts a company in a pinch when someone leaves:
-taking or removing IP or sensitive data (happens more than we like to admit…especially in data science)
-person had strong customer relationships
-as it turns out, software people actually become deep domain architects as well which can make them key innovation assets. Obviously for higher roles this goes beyond just the ramp up phase and I would say might be enough to kill a company in the early phases
-moral side effects, time from others needed to help with ramp up results in a period of decreased productivity. Actually this peaks I would say for sr. Engineers (high technical hands on) and is then lower for entry and chief

But as far as coming to a mathematical model you have laid the groundwork for the next steps. Any idea how you could find some data here?