Common Startup Sin #1: No Engineering Career Ladder
You can't just say you need to move fast and take the elevator
Career ladders are often overlooked in startups and early stage scale-ups.
This is exactly why once of the first initiatives I kick off when joining a new company is to address this gap, and establish a career ladder for the Engineering team.
The decision often received with skepticism or even push-back, as some expect I'll just roll up my sleeves and dedicate 100% of my time to tactically helping the team push more code to production.
The good thing is that usually once the ladder is in place, most people realise its value and start using it as a tool.
Before we delve into what a good career ladder for Engineering teams should include, let's first have a look at the main reasons why early stage companies tend to underestimate their importance.
👀 Common reasons why we overlook the need for career ladders
I have encountered a combination of the following reasons. None of them is usually a good enough reason to further delay this work.
It's perceived as pure corporate bureaucracy, distracting the team from relentlessly shipping value to users
A lot of people might be at their first job, as such they are not used to structured career ladders and development paths. They just care about regularly getting salary bumps and fancy titles.
People simply don't know how to come up with a good career ladder
It is not considered an engineering problem, but something “HR should fix for us”
Plain and simple inertia: there are fires and urgencies everywhere, nobody has the time to even think about anything else
As Engineering Leaders, we have the responsibility of establishing clear expectations and growth opportunities for people in our teams.
People in other areas such as HR can help with advising on the numbers of levels, compensation ranges, etc. The responsibility of actually delivering a career ladder lays on our shoulders.
💪 The benefits of a good career ladder
When you do a good job in establishing a career ladder for your team, you'll see many of the following benefits:
Each member of the team has clear expectations for their current role and level
Managers are well equipped to set development goals for their team members
Managers can build stronger and more objective cases for promotions
Individuals are not forced to become Managers as the only way to grow beyond a generic Senior Software Engineer role
Promotion calibrations become more objective and less dependent on the negotiation skills of individual managers
Salary adjustments are structured and less ad-hoc, leading to a fairer overall compensation
Expectations and salaries for new joiners are aligned with existing employees operating at the same level
Your recruitment process can be tailored for different levels
A great ladder in an of itself is not a guarantee of such results, as they also depend on other dimensions career development that might or might not be implemented in your organisation.
It is a very good starting point to create a more holistic approach to it.
👍 Good ladders, bad ladders 👎
These are some of the traits I've observed in good and bad career ladders after dealing with multiple examples from both categories.
✅ A Good ladder…
… Lists explicit responsibilities at different levels
If you want an engineering manager to be responsible for the team's delivery and performance, write that down.
If you want engineers beyond a certain level to take part of the on-call rotation for their team, write that down.
If you expect Staff engineers to operate beyond the boundaries of their team, write that down.
… Is opinionated in accordance with your organisation and principles
You might be tempted to just copy-paste a generic career ladder you find on the internet. I discourage you from doing that. And no, asking ChatGPT won't five you significantly better results. Instead, be very opinionated on the principles you want your company to align on.
If you want software engineers to make test automation, security, DevOps practices part of their responsibilities, write that down
If you expect everyone to be able to ship code in production (hopefully in an automated and safe way), write that down
If knowledge of specific technologies, languages or frameworks is fundamental to be successful in your company, write that down. Keep that number to a minimum though, as you want optionality.
If you expect Engineering Managers to be hands on a certain percentage of their time, write that down
… Has room to grow upward
You will want everyone in your team to have at least one next level to work towards, with the exception of the CTO. Well, unless you want to send a signal to your CEO.
It's OK to include levels that currently do not exist in the organisation. Some of them can even be included as a placeholder signalling a future intent of creating them.
Think about multiple levels for Managers even if you currently have a single layer. You want your managers to know what their next level is.
… is not framed around “years of experience”
This one should be quite obvious: years of experience do not imply experience
The reverse can be true though. With some exceptions it will probably be unreasonable to appoint to Staff+ Engineer someone with 2 years of experience in a single company.
The simplest solution is to focus entirely on specific and demonstrable skills and competences. Leave years for bottled Wine or Tequila.
… Focuses on specific ability rather than abstract knowledge
Write down what you expect people to be able to do, and to what degree of autonomy
Avoid generic statements about “knowledge”, as this is often hard to demonstrate. Knowledge and Experience are different beasts, and one doesn't imply the other.
…Covers a broad range of both hard and soft skills
Both hard skills and soft skills are important for software engineers at every level
Soft skills become more crucial as people move up the ladder
🚫 A Bad ladder…
… Doesn't mention explicit responsibilities
If your ladder only focuses on generic abilities, it doesn't provide full clarity on what is expected from people
It will not help addressing ambiguity for many leadership roles, leading to further confusion
It is ineffective in evaluating a team member against their responsibilities
… Is just a copy of “Company X”, with no adaptations to the specific reality
It's very tempting to say “let's just pick this one, and then we'll customise it”
Managers and ICs will see the ladder as a burden, rather than a tool
Worse even, you might end up setting expectations that are not in line with what you really need at your company
… Has too little room to grow
A percentage of your employees will lack a clear next step to work toward
This can lead to loss of motivation, frustration and even turnover
People might turn into extenuating ad-hoc negotiations to get a salary bump
… Covers only hard skills
People in other teams or areas will find it increasingly hard to collaborate with your team
People will push back on feedback on behaviours, communication and leadership as those are not considered part of their job
You might end up creating an army of brilliant jerks 🙂
🔥 Smoke tests after implementing a career ladder
There are a few smoke tests that I found useful in gauging whether the ladder is usable and useful.
The most common ones are the following:
✅ It is easy to assign people to various levels
❌ If managers consistently struggle to assign people to levels of the ladder, this might be a sign that you've been too ambiguous and might want to spend some time refining the work.
✅ People refer to the ladder when discussing their expectations and responsibilities
❌ If you notice a general lack of usage of the contents of the ladder in conversations about team members and their expectations, it might require you to refine the ladder and make it more specific to your own context
✅ It is used by managers to evaluate, promote and develop people
❌ If the ladder is not consistently used in performance evaluations and promotion discussions, it means the tool is not fulfilling one of its main purposes. You might want to go back to the drawing board.
✅ They are used to calibrate the hiring process for different levels
❌ Having a single standardised process for all the levels might be due to a few causes: you haven't had time to tune the process yet or you find it difficult to turn expectations at some levels to interview questions, or both.
If your ladder is passing the majority of these tests a few months after its inception, that is a strong indicator that you have put together something solid.
If the majority of the tests are still failing, that might indicate a more structural issue with the work you've done. In these cases it is advisable to perform a thorough review of the work done so far, trying to identify the gaps in the ladder.
👋 Conclusions
In this article I've shared with you my thoughts on career ladders for Engineering Teams. The main takeaways are:
Career ladders are often deprioritised in startup
As an Engineering Leader it's your responsibility to build one if it's not in place
Good ladders and bad ladders are quite different. Make sure you build a good one
Test your ladder in practice after a few months of implementation, inspect the results and decide what to adjust
Once the outcome is clear, the next obstacle is execution: what process should I follow to build a useful career ladder for my team?
In the next article I'll guide you through the process I typically use.
In the meantime, please share comments on your experience:
Have you dealt with bad ladders in the past?
Have you designed one yourself?
Or maybe, are you still convinced that this is just a waste of time?
I'd love to hear your thoughts on the topic.
Until then, see you in the next article!