Software Engineer Career Ladder: Don’t Copy-Paste—Make Your Own!

Software Engineer Career Ladder: Don’t Copy-Paste—Make Your Own! - Interview with Tim Olshansky (EVP of Product & Engineering, Zenput)

As your tech company is growing, you need to put a software engineer career ladder in place.

There is no way around it.

Once you have about 20 engineers, you can’t take the hands-on approach with every one of them. You need a framework to give clear goals to your developers, and to make your company attractive to new hires.

How do you create a software engineer career ladder?

You don’t want to copy and paste another company’s career framework.

You also don’t want to arbitrarily make up a career ladder.

Take some advice from Tim Olshansky, EVP of Product & Engineering at Zenput. He has recently been through creating a career ladder for his software engineering department, and he has shared his key learnings below to help you build your own career framework. The interview is from episode 29 of the Level-Up Engineering podcast, hosted by Karolina Toth.

We're covering:

• Building a software engineer career ladder at Zenput
• Growth made it necessary
• The first steps of building a software engineer career ladder
1. Articulate company values
2. Build with key stakeholders
3. Keep collecting feedback
• Key stakeholders to involve in the process of building a career ladder
• Key differences between the career levels
1. Impact
2. Skills
• The importance of experience in your software engineer career ladder
• Age doesn't matter
• Technical experience is important
• The transition to engineering management
• Engineering managers need solid tech background
• Senior engineers can move to management
• The role of engineering leaders and managers in the career ladder
• Updating your engineering career ladder
• Review it regluarly
• Key points to evaluate
• Common mistakes in creating software engineer career ladders
• Too many or too few career levels
• Tying compensation to levels too tightly
• Copy-pasting
• The feedback on Zenput's career ladder
• Bonus advice
• About Tim Olshansky

How did you create the software engineer career ladder at Zenput?

When I joined Zenput to lead the engineering department, I spent the first 12 months trying to understand the team, the company and the business. This is what leaders need to do when arriving at a new company. I had many discussions with developers about moving their careers forward.

Growth made an engineering career ladder necessary

We reached the size where it wasn’t possible for me to have one-on-one meetings with everyone or to help their career progression directly. This is when a consistent software engineer career ladder became necessary. I wanted to give the team more clarity and structure on their career paths and on how to find success.

We have many senior developers, and barely anyone wanted to switch from engineering to management. Software engineers tend to reach a peak of hands-on contribution, and as senior engineers advance their careers, they are often pushed into management regardless of their preference. I wanted to avoid this.

We want our engineers to work on what they love and to have impact on the company, without forcing them into roles they don't enjoy.

Articulate your company values

Before we started working on the career ladder, we did an exercise to work out our values as a team and a company. It’s about working out our mission, vision, strategy and values. This became our foundational framework; the cornerstones for every decision our company made moving forward.

It’s essential to scale your culture as the company grows and to implement new processes.

Build the career ladder based on your values

We built our engineering career ladder on the back of these values, and we did many cycles of review. We launched the career ladder at a company off-site, a team building activity we do at Zenput.

We began the process from scratch in late November of 2019, and we implemented it in January of 2020. In February and March, we helped every engineer determine where they fit on the ladder. This gave everybody a clear focus for the next 6-12 months.

What are the first steps when creating a software engineer career ladder?

1. Define your values

We started with articulating our company values.

We did it in a design workshop style. We started with brainstorming, and then we described the most important things for us in the company. This generated a lot of ideas.

Then we went through a series of reductive steps to cull the list and to clear the language. This is how we defined the values precisely.

We created a culture document describing our values, principles, and the traits of our employees based on subjective assessments of each other. We needed this to know what type of engineers to recruit in the future. We put a foundation in place that everybody stands behind.

This means our principles will be reflected in every aspect and every level of the organization.

Example for a company value

One of our company values is empathy, both for our customers and for each other. We aren’t building software for ourselves, so we need to make sure that we prioritize the users’ needs and build the best software for them. Internally, it means to be able to empathize with each other’s position and to communicate effectively.

A practical example of an engineering principle supporting empathy is making sure that we write clean code, so the next person working with your code will understand it.

2. Start building the software engineer career ladder

With that foundation in place, I sat down with the head of people operations, and started brainstorming how our core values might be reflected in the career ladder. We ended up with a long list.

Then we categorized what we thought was essential to reflect on our software engineer career path. Technical competence, and communication were among them. They’re essential to software development.

Coming up with the levels specifically is different for each organization. We had employees at the upper end of our career ladder, and we wanted to give them room to grow. This is why we added extra levels to the ladder.

At this time, the focus for us was to make sure senior engineers could move forward in their career. We settled on four primary levels, and added two stages to two of them.

3. Collect feedback

Once we identified the levels and what they meant, we started to conduct workshops with a wider team to gather feedback. The career ladder was the reason we started working on it, but our company culture document has been helping in every area.

Did you use external consultants to create your engineering career ladder?

We did it internally without outside consultation. It worked in part because I’ve done this before more than once in prior organizations. We knew what to do.

A big part of my job as executive vice president is to give the engineering team opportunities for growth. The team members were on board with the end goal: to measure their own performance and development.

I had support from the key stakeholders in the organization. The leadership, including the CEO, stood behind this. A career ladder is important as you grow and keep scaling your team, and they all recognized this.

The engineering career ladder also helps recruiting engineers for our growing team. This helps newly hired engineers understand how they fit into the company when they join, which makes everything smoother.

All our team members supported it, because they felt they needed a framework like this. The team wanted clear directions on how they needed to develop to move their career forward. This informed our approach when tackling the matter of the software engineer career ladder.

What are the differences between the levels on your software engineer career ladder?

1. Impact

In the early stages of a software engineer’s career, they’re told what to do and how to do it. This is how it works even with the most intelligent people, because they lack experience, so they benefit from clear directions about how to be successful. This includes where to change the code, what tickets to pick up, and so on.

You scale the impact of an engineer by looking at what type of tasks they take on. At the lower levels, they’re specifically told what to do and how to deal with smaller tasks. At the top level of impact, they’re almost fully autonomous and take on big projects.

2. Skills

Technical skills get sharper with experience. A master’s degree in IT may teach people great theoretical applications, but they still have a lot to learn on the job.

Soft skills are also part of this conversation. We want our software engineers to understand how their work connects to the mission of the business. We prefer a customer first mindset when tackling problems, over building the coolest piece of tech nobody’s going to use.

The spectrum goes from handling individual tickets given to them to creating their own projects. These projects may often take months and require a big team to work on them. An engineers’ position on this spectrum is based on their skills.

How much does age, experience, and non-technical experience matter in your engineering career ladder?

First and foremost, we’re looking for a business mindset and a customer-centric way of approaching problems. We don’t require deep domain expertise when recruiting engineers, but we expect them to acquire this expertise while on the job.

Age doesn’t matter

Age isn’t a factor at all. We’ve got engineers at different extremes of age with vastly different levels of experience. Sometimes the oldest people on the team aren’t the most experienced. It gives us a nice mix of people bringing different types of insight to the table.

Technical experience matters

The level we place new hires in the organization is dependent on technical skills and soft skills. We look for a certain range of time spent at a similar level in another organization, but even this is more of a guide than a requirement.

Example from Zenput

We’ve got six engineering levels.

At the first level, we typically expect 0-1 years of experience. This is aimed at fresh graduates, or people coming from a coding bootcamp. Experience isn’t a big factor at this stage.

At the highest level of our career matrix, the ideal candidate has 15 or more years of technical experience. That’s the overall range, and the levels in between require experience between the two end points. If we come across an engineer with only 10 years of experience, but we are confident in their skills, we can still put them on the highest level of the career matrix.

The years of experience can translate to different levels of expertise at different organizations. At some companies an engineer can learn in a year what they might only learn in five years at others. We use years of experience to give applicants and employees direction, not as a hard requirement for career progression.

What level of expertise does a software engineer need before switching to engineering management?

Engineering managers need a technical background

In my experience, the best managers have a deep understanding of their team’s work and how it’s done. They have deep empathy for their teams and can help guide them, eliminate blockers and understand the programming language they’re using.

In my opinion, you can’t be an engineering manager without engineering experience.

In some organizations, the engineering managers are disconnected from the technical aspects. These managers only need experience in project management and people leadership.

Our current software engineer career ladder has six levels:

1. Software Engineer 1
2. Software Engineer 2
3. Senior Software Engineer 1
4. Senior Software Engineer 2
5. Staff Software Engineer
6. Principal Software Engineer

Senior engineers get to move to management

The first half of the career matrix is designed for everyone in engineering to progress through each level. We’ve determined that senior software engineer 2 is the point where our employees can choose not to push their technical skills further. They know enough to switch from software engineering to engineering management.

At this level, they typically have about seven years of experience in software development. It’s not early in an engineering career, but it’s not an unrealistic expectation either. They have experience in building quality software, and they can autonomously solve most problems.

Senior engineers get to fill a pseudo-managerial role as lead engineer on a team. They get to do one-on-ones, give feedback, and help their team members be successful, but they don’t get to make decisions about firing and hiring. This experience puts them in a good position to transition to a career in engineering leadership.

The alternative to management is technical leadership

At the senior software engineer 2 level, our engineers can build anything. As they progress further on the principal engineer path, their role becomes more about making an impact on the organization through technical leadership. They mentor developers, do architecture work, and pair with numerous engineering teams.

It becomes a very different role.

The first four levels of the engineering career ladder are about writing code. Engineers on these levels do their part in supporting their team too, but it isn’t their focus. As they move beyond the senior engineer level, supporting the team becomes their priority.

Either they choose engineering management and do one-on-ones, feedback sessions, and everything that comes with it, or they pick technical leadership, and help people make the right technology decisions.

They end up working with people on the highest levels either way.

What is the role of engineering managers and leaders in making an engineering career ladder work?

Engineering managers

Engineering managers are the ones helping their team members progress through the career ladder. They create opportunities for interesting work to develop the skills of their reports, give guidance, and coach them.

All this primarily happens at the level of the engineering manager. Their job is to make sure the engineers have a path forward.

Engineering leaders

Engineering leaders manage managers. They make sure the career ladder is fair and reflects the company’s values across multiple teams.

If you build a career ladder for a 20-person team, you should probably update it when your company grows to 200. Engineering directors and upper management have to deal with this. Their job is to make sure the path is clear to everyone.

Do you have a formal process to keep your engineering career ladder up-to-date?

We review it regularly

We don’t have a formal process in place, but we intend to review it annually. We don’t want to change it more often, because there are expectations in our career ladder that people can’t realistically reach in a couple of months. We create 6- to 12-month plans for our employees, discuss their development along the way, and reflect on the overall progress at the end.

Then we see whether the software engineer career matrix helped or hindered their development. Even if it helped, you may want to streamline it further. If it hindered their development, you need to change some of the criteria.

Key evaluation angles for a career ladder

1. How clear it is to your employees.
2. How much opportunity it gives to your engineers to develop.

Measuring how your team members develop is an important qualitative assessment to do. If you don’t see development in your team, maybe you’re not giving out enough promotions. It may not be a problem, but you have to investigate and see if there’s something wrong.

It may signal a problem with your engineering career matrix, the managers or something else. As a rule of thumb, development on your defined paths is a sign of a healthy organization.

What are the common mistakes when creating a software engineer career ladder?

Getting the number of career levels wrong

Deciding the right number of levels on your career ladder is essential.

Too many levels make progression unclear, and it may take your software engineers too long to reach the critical thresholds. People may get a lot of promotions, which feels good in the moment, but it won’t have a big impact on their actual day-to-day work. This makes promotions meaningless.

Too few levels don’t give your team an opportunity to mark their progress. If you have three levels, your engineers may sit on the middle level for 10 years. If the goals are too far away, people can lose motivation easily.

Whether you want to use titles or not, the levels are important for people to track career progression. You need to get it right based on the size of your organization.

Tying compensation to career levels

Tying compensation too tightly to career levels is a common mistake. Value is hard to articulate, and salary is a huge topic in itself.

I’ve seen rigid bands for compensation tied to career levels go wrong. Sometimes an employee has a smaller impact at the top level than another employee at a level below, but they still get paid disproportionately more. This happens often.

The career ladder needs to provide fair compensation to your employees. If you define bands for compensation on each level of the organization, at least don’t make them rigid, or it may create a feeling of unfairness and dissatisfaction.

Copying another engineering career ladder

Another mistake I’ve seen is googling a career ladder, and just copy-pasting one to your company. You shouldn’t take a random career framework without context, because it won’t reflect your organization. It may not go terribly wrong, but no one will pay attention to it, and it turns into a meaningless checkbox.

What feedback have you received to your engineering career ladder so far?

Our engineers love it

The feedback has been overwhelmingly positive both at launch and when we created development plans for everyone. It gives everybody a clear understanding of where to invest effort and how to progress. It’s a tool for our engineering managers to give career guidance and to help their team members progress.

We have room to improve

As far as the first year goes, it has been useful and helpful, but we still need to tweak the software engineer career matrix. I have already found an area for improvement.

We introduced a new process in making technical decisions, but it isn’t reflected in the career ladder. The teams put a lot of effort into it, and it works well, so it’ll likely come up when we’re checking how effective the career ladder has been in the first year. Including this process should help employees understand how they are expected to engage with this process on different levels.

Change rarely and incrementally

When you change the career ladder, you potentially change people’s paths. You shouldn’t do that hastily, and it’s best to do it incrementally.

You need to spend time with your employees before a change, so they understand how it affects them. They need to know what to do and how their existing development plan should follow the change. The career ladder affects a lot of things, so it’s a bad idea to mess with it frequently.

Creating a process to check for possible updates annually is a better idea. It lets your employees know they’re not shooting for a moving target.

Bonus advice to creating a software engineer career ladder

Use a formal process to create a career ladder

You need a structured process to create your engineering career ladder, and also to manage any changes you may want to implement. You should include others from the team. I didn’t do it alone either; creating our engineering career matrix was a team effort.

Don’t overthink it

Our engineering career ladder has a lot of detail, but it isn’t necessary. The goal is to give a general direction to your team; keep this in mind. If your team doesn’t want or need much precision, you can define each career level by a few bullet points.

Every organization is different. Don’t let this interview make you think this has to be a deeply complicated process.