How to develop career paths for your software engineers

Opportunities for professional development are hugely important in software engineering.

In fact, in Stack Overflow’s 2020 survey, Growth or leadership opportunities were voted as the fourth most influential factor that drove developers to look for a new job.

This shouldn’t be surprising, as it’s natural for employees to want to advance and grow their skill set.

Your duty as a team lead is to support them in this ambition, because, in the end, it benefits your organization as well.

That’s what this article is for—we’ve outlined the process of developing career paths for your software engineers. If you want to help your employees achieve their goals, read on.

Define your promotion process

Your engineers’ career path should adhere to a fair, inclusive framework that evaluates their performance honestly and impartially.

The first step to creating such a framework within your company should be firmly defining your promotion process.

Otherwise, your employees might wind up in a situation like this one:

As you can see, Matt Grannell felt like he was progressing in his job, but that was all. He only felt that way—there was no external confirmation or denial.

With a transparent promotion process, however, he’d likely tell a different story.

The visual below shows what a promotion process might look like:

The initial step is determining who deserves a promotion the most.

Some factors that you should take into consideration include your engineers’ performance, their time at the company, and their level of potential.

Consider the defining characteristic of a promotion—getting more responsibilities.

That means that the central criteria for engineers who are up for promotion should be whether or not they perform above their current station.

Ray Weiss has touched on this:

If one of your employees works exceptionally well, give them a more challenging task than usual or even assign them as a project lead.

If that goes over well, you can rest assured that a promotion is warranted.

Following this, ascertain who can approve the promotion, be it the CTO, the employee’s direct manager, the HR department, etc.

Next is deciding when to promote the engineer. It’s a good idea to offer promotions consistently, e.g., every quarter. That way, your employees will know when to expect one.

The penultimate task is deciding on the type of promotion. Should the engineer progress to a management or individual contributor role?

We discuss this in more detail in the following section.

Finally, announce the promotion to the employee and the company.

When doing so, highlight why this engineer earned the rank increase so that other employees understand the promotion criteria.

The layout we’ve presented in this section is a basic template but is nevertheless helpful.

Treat it as a starting-off point, and develop your own unique, company-specific promotion process over time. With fully defined guidelines, the possibilities are endless.

Create a roadmap for each track

Once you’ve established your promotion process, the next step is to create a roadmap for each progression track.

Contrary to popular belief, engineers don’t have to become managers to advance their careers. There’s another option open—the individual contributor role.

Simply put, the individual contributor does not manage other people. Instead, they push product strategy by working on their assignments independently and excel in their engineering niche.

These are engineers whose focus is entirely on coding.

The graph below shows a typical individual contributor roadmap:

Junior engineers typically perform routine tasks under regular supervision and then slowly gain autonomy as they advance to more complex assignments.

On the other end of the spectrum, there is the staff engineer, who will headline and decide on company-wide projects, yet without managing them.

In sum, the individual contributor role is for engineers who prefer a position that focuses on coding to a people-centric one.

On the other hand, the classic managerial roadmap focuses much more on interpersonal relations.

An engineering manager’s primary role is to create the best possible work environment for other engineers, removing blockers and coordinating across multiple departments.

To put it simply, they support all other engineers.

The visual below depicts the typical managerial track roadmap:

A team lead manages one small team of engineers who work on projects, whereas more senior engineers oversee several teams until finally, the vice president is responsible for every engineer in the company.

These roles should be reserved for engineers with strong social and communication skills who enjoy working in a team setting.

These two career tracks both require technical knowledge but cater to two different skill sets. A good manager won’t necessarily be an excellent individual contributor and vice versa.

Multiple companies have realized this, which is why the split has become more widespread.

For example, here’s Brandwatch’s take on the two roadmaps:

As you can see, the two pathways are clearly divided, and engineers can decide on their chosen route after graduating from an engineering role.

With this table, each engineer knows exactly what to expect from the career path they opt for.

Discuss software engineers’ career goals

After you’ve created roadmaps for the two career tracks, it’s time to sit down with your engineers and discuss their future.

Now that you have the options for them, together you can decide which one is best for them.

After all, you can’t help your employees progress without knowing what their career goals are in the first place.

A one-on-one setting is usually the most suitable for this conversation, as it will prompt your engineer to speak openly about their aspirations.

The privacy should ensure an honest and sincere discussion.

If you’re not sure how to begin the conversation, here are a few starting questions:

These inquiries will provide insight into your employees’ preferred working model and professional interests.

From there, you can sketch a picture of what career path would suit them best.

With a rough idea of what they consider to be the ideal career, you can move on to discussing the specifics and establishing the exact goals to work towards.

A good framework you can use for this is the 30/60/90 rule.

Sarah Drasner explains the concept:

In other words, you and your engineers decide on their short-term and long-term goals.

Choose one grand, overarching goal, such as Fully take over 3 tasks from a senior developer, and then break this ambition into more digestible chunks.

For example, within 30 days, the developer could start by enrolling in a course to learn a new language or framework required to take on those new tasks, such as Go and echo.

Then, the 60-day goal could be to master this new language.

This approach means your engineers will have tangible, concrete objectives to work towards, supporting their long-term career goals.

However, when discussing these topics with your engineers, it’s important not to put words in their mouths.

It isn’t your job to decide for them or dictate their ideas. Instead, your role is to help them reach these conclusions about themselves on their own.

Sir John Whitmore perhaps explained it best:

In other words, let your engineers reach their own conclusions and use these discussions to guide them toward advancing their careers.

Support them, offer advice and ideas, but don’t teach—all with the goal of helping them realize their own career aspirations.

Evaluate software engineers’ professional competencies

Now that you know your employees’ goals, your next agenda item is to examine their current capabilities.

In other words, to evaluate their strengths, weaknesses, and experience—their general professional competencies.

Being a software engineer doesn’t start and stop with your coding abilities.

For example, a lead developer should have superb mentoring skills, whereas an engineering manager should excel at task delegation.

The list is lengthy, and each capability is as important as the next.

If you’re unsure which traits to assess, don’t worry. Other companies have had the same dilemma and have decided on some standard benchmarks you can use as inspiration.

For example, these are the core skills Songkick looks at:

As the blurb emphasizes, each role’s responsibilities are based on the employee’s competence in these seven skills.

Case in point, these are a principal architect’s competencies:

The position is described through the lens of an engineer’s proficiency in these areas.

We recommend taking the same approach—use these seven skills as a starting point, and then add or detract skills based on your company’s values and business model.

Then, whenever you consider an employee for promotion, compare their current capabilities to the standards required for the role.

Your company’s core values are essential when evaluating an engineer’s capabilities, as each culture celebrates different principles.

For example, consider some of Amazon’s Leadership Principles:

Leaders at Amazon, by default, must exhibit some of these principles.

Your company likely also has its own values, and you can incorporate these standards while evaluating your engineers’ capabilities.

If their competencies align with your company’s values, chances are, they’re well-suited for a promotion.

For the actual evaluation process, Vectorly has developed a fantastic tool to help you out—an engineering skill matrix template.

This resource will help you carefully map out and weigh each professional competency.

Here’s what the skill matrix looks like:

You can then use this matrix to numerically rate your engineer’s abilities, therefore providing a clear, transparent overview of all of the relevant factors and significantly facilitating the evaluation process.

With this tool, you can tell at a glance how developed your employees’ professional competencies are.

Do a formal assessment

The final part of promoting your engineers is formally assessing them. This means officially reviewing their suitability for the new position in line with your company’s processes.

Every company has a different approach to this.

Some will ask their employees to make their case for being chosen for the new advanced position before a promotion panel, others will interview the candidates, a few will test their candidates and conduct assessments, etc.

It’s up to your company to find which approach suits you best.

However, as a general rule, it is always crucial for the employee to realize their worth and have a clear understanding of their own abilities.

The engineers have to be able to advocate for themselves, and it’s on you to push them in the right direction.

The experience of Arquay Harris of Webflow aligns with this:

No matter the medium—interview, promotion panel, or assessment—your engineer will have to make this type of statement.

They will have to demonstrate their current abilities and prove they can handle the next level of responsibilities.

Another vital characteristic of your formal assessment is transparency. It’s important to thoroughly explain the review process to the employees, so that they aren’t caught unawares.

For example, this developer recently outlined their company’s process on Reddit:

The level of detail in their answer indicates that each engineer in that company knows precisely what each step up the career ladder requires.

Sometimes this is a portfolio of their work, whereas sometimes it involves others vouching for them.

Whatever stage an employee is at, the requirements for progressing are widely known and not kept under wraps.

One fantastic example of an assessment process that encompasses both transparency and engineer advocacy is GitLab.

The software giant insists on engineers filling out a promotion document, which includes the following features:

GitLab has made the process publicly available, and all employees can view the promotion document template.

Furthermore, the template also summarizes the promotion candidate’s abilities (which aligns with what Arquay Harris said earlier).

Whatever formal assessment process you decide on—written assessment, a promotion panel review, or an interview—follow GitLab’s example, and ensure that the process is transparent, and that it gives you a good overview of the candidate’s competencies.

Conclusion

Like any professional, it’s natural for a software engineer to want to advance in their career.

Just think about when you were a junior developer—you wouldn’t remain in that same role indefinitely, would you?

To help your engineers advance in their careers, it’s essential to first define your promotion process and create a roadmap for each track.

After that, it’s time to discuss your engineers’ career goals and then evaluate their professional competencies.

Finally, the last step is a formal assessment to judge if they’re ready for the promotion.

Keep this process in mind, and you’re sure to assist your engineers in their continual professional development.