Creating a career path
Your engineering team grows and grows. You hire a lot of engineers, the salary you give them is a mix out of what the candidates asked for and your gut feeling. From time to time you increase salaries to equal out the increase in cost of living and sometimes you have to promote someone to a management position and you give her a bigger raise, because it is a bigger responsibility. So all is good, right?
Well, it might be, but chances are, there are problems. See if any of the following points apply to your team:
- In 1on1s you often hear the question: ‘Do I have to become a manager to get more money?’ This indicates that people feel there is no clear path for them to advance as an individual contributor.
- Engineers are leaving your company to get a substantial salary raise. This is the big danger when there are no clear definitions of how engineers who improved a lot, can also make more money.
- A lot of engineers tell you that you pay below market, but you don’t really know if that is actually true. You can compare your salaries to other companies, but this is usually done by comparing engineers on a certain level with each other.
- Engineers are looking for an achievement and that is not necessarily only a salary increase, but they are looking for something they can put on their CV (like Senior Engineer).
- Job titles go crazy and people ask “What do I need to do to get to the next level?”. This also indicates a lack of criteria what job title is appropriate for which level.
So if any of these points apply in your organisation you might want to think about creating a career path for engineers. Typically such a career path consists out of different steps an engineer can go through.
In the following I will present a model for a career path I introduced at different companies — plus some discussion about certain decisions you need to make when creating this.
From the beginning it was very clear that we wanted a model which offers engineers to advance either on a management path or an individual contributor (IC) path. Both paths should be equally valued and paid.
(In a former company you could only get to a certain job grade — which included a company car — by becoming a manager. I saw quite a few very talented engineers with a company car, but without a job who was right for them.)
Taking that as one of prerequisites we looked at the Dreyfus model of skill acquisition which has the following five roles:
Level Name
1 Entry
2 Advanced
3 Proficient
4 Versatile
5 Expert
For each level we chose Technical Skills, Independence, Maturity, Business Perspective as the core criteria (note that technical skills is only one out of four criteria). For the management track we additionally chose management skills and we decided that the ladder should begin on the engineering path only.
(Green indicates the technical path, grey blue the management path)
Technical Skills:
The actual technical skills ranging from mastering the CS basics to successfully creating complex systems to being regarded a leader in the company or even in the industry.
Independence:
Indicates how independent an engineer is on the lower levels and then if she can be trusted with leading other engineers.
Maturity: This is maybe the most important criteria. To cite John Allspaw (http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/) here: ‘Being able to write a Bloom Filter in Erlang, or write multi-threaded C in your sleep is insufficient. None of that matters if no one wants to work with you.’. There should be a goal in every engineer’s career and that is ‘to be the engineer everybody wants to work with’.
Business Perspective:
How engineers build a constructive a relationship with other departments and looking at providing value for the business.
Management Skills:
As the management path starts on level 3, the different stages of a manager begin with leading a team, then leading other managers and in the end to lead a whole department.
Some things you need to consider/discuss when designing this:
- Are there job titles (is the job level visible for everyone) or is this just visible for the engineer? There are several pros and cons for both approaches, the most convincing for not making these levels visible at least in the beginning is that you can easily change from not visible to visible, but the other way around is pretty much impossible. So if you don’t have really good arguments for making them visible right away you should start with hidden job levels.
- Do you attach salary ranges attached to levels? So for example the yearly salary of the Entry level is between X and Y $/year. It is usually wise to let salaries overlap — especially when levels are visible for everybody.
How to introduce it?
As you probably don’t have these levels from the beginning you need to slot a lot of existing engineers into the career path. This is something you need to do very carefully. First try it out by choosing a few engineers — I usually like to take one or more from each of the following groups:
- You are certain that she will be fine with her slot
- You are certain that she won’t be fine with her slot
- You are not sure
and explain to them that you think it is time to introduce a career path and that you chose them to try it out because you value their feedback. Stress in every communication when slotting people that in doubt you always chose a lower level as promoting someone later is easy and the current salary is not affected by the slot anyway. If these discussions go as expected you can continue the roll out to the rest of the organisation.
What happens next?
In a normal organisation you will have a typical distribution of people in the job levels. There will be few in level 1 and 4, the majority in level 2 and 3 and very, very few in level 5. This might cause problems as soon as the organisation grows as it is very hard to get from level 3 to 4 and engineers might feel stuck. One potential solution is to split level 2 and 3 into two levels each.
The most important thing here is to constantly adapt this system to your organisation.
Have fun!
