Career Ladders

Posted by Darin Pantley on December 2, 2018

Building a Career Ladder

Software engineers of all experience levels, whether they’re highly technical, purely managerial, or some mix, can benefit from a career ladder.

  • Provide a long term view of career opportunities.
  • Clarify job responsibilities and best practices.
  • Identify gaps that need to be filled through hiring and promotions.
  • Retain top talent.

However, even as we attempt to provide a structure for career advancement, we must remember to remain flexible, because no system will be perfect. Career ladders should help employees advance their own careers, not entangle them in corporate bureaucracy.

Let’s explore how titles, levels, and tracks are used to form the basic structure of a career ladder. Then we can dive into some sample expectations.

Titles

Nearly every tech company assigns job titles to its employees. Having job titles helps differentiate the new intern from the experienced senior engineer, both for the benefit of the employer as well as the employee.

Some companies have career ladders packed full of job titles:

  • CEO
  • CTO
  • SVP
  • VP
  • Sr Director
  • Director
  • Manager
  • Technical Lead
  • Senior Engineer
  • Engineer
  • Associate Engineer
  • Intern

Other companies prefer a “flat” organizational structure, where many different levels of experience are pidgeonholed into a select few titles:

  • CEO
  • Director
  • Manager
  • Engineer

Of course, there are many other ways that companies organize themselves. Valve Corporation famously doesn’t rely on titles at all:

  • Employee

Levels

Regardless of how many job titles are in your company’s career ladder, it’s useful to break down certain roles (e.g. “Engineer”) into multiple levels (e.g. “Engineer level 3”) for better granularity.

Imagine a team of engineers, where each person holds the title “Software Engineer”. One engineer may be very experienced, so they are considered to be a “Software Engineer Level 5”. Another engineer may be less experienced, so they are a “Software Engineer Level 3”.

Private Levels

At some companies, each engineer’s level is private information that no one else can see, aside from their superiors and HR. In this environment, many employees share the same titles, which gives the illusion of a flat organization. Since the levels are hidden, compensation can easily be adjusted on a case-by-case basis, or not adjusted at all.

Here’s a sample career ladder with private levels:

  • Manager
  • Engineer (1, 2, 3)

Public Levels

At other companies, full job titles and levels are publicly visible to everyone at all times. In this environment, the levels are essentially synonymous with the job titles. The hierarchy is clearly visible and may effect how employees interact with each other.

Here’s a sample career ladder with public levels:

  • Manager
  • Engineer 3
  • Engineer 2
  • Engineer 1

Tracks

Many engineers love technical work and dread managing people. Other engineers wouldn’t mind moving away from hands-on technical work if it means they’ll gain an opportunity to manage direct reports.

Facebook’s career ladder for software engineers includes titles and levels for a technical track (“E”) as well as a management track (“M” and “D”):

  • Director (D1, D2)
  • Manager (M0, M1, M2)
  • Software Engineer (E3, E4, E5, E6, E7, E8, E9)

Expectations

Each rung of the ladder needs to be described in enough detail that an engineer knows whether they match the description. For example, a management role may require experience in managing direct reports. An intern would quickly see that they don’t meet this criteria, so they are not qualified to be a manager and it’s probably not their next career step. However, a more senior engineer would realize this as an opportunity to ask for management opportunities. Perhaps they could lead a small project to gain experience.

It’s quite possible for a very junior level employee to satisfy certain requirements from far more senior levels of the ladder. This shows that they have potential, but it doesn’t necessarily earn them a promotion if they’re leaving other requirements unmet.

It’s also possible that a senior role may list a basic requirement like “builds team morale”. Obviously we expect the entire team to behave professionally. In this case, however, failure to build team morale doesn’t count against their career advancement until they reach the level where it’s listed as a requirement.

With so many levels available, a software engineer can remain an individual contributor for their whole career, rising from E3 to E9. Alternatively, the parallel management track gives an E4 who is ready for a promotion the option of becoming an M0. An M2 manager can be promoted to become a D1 director.

Sample Expectations for DevOps Engineers

The content below is an example of how to implement a career ladder. It’s riddled with flaws and probably not something you’ll want to lift wholesale into your organization, but the intent here is to provide material to discuss with your coworkers, so you can craft your own ladder at your own organization.

Suggestion: Post your career ladder in a public forum where team members can submit suggestions for improvements. Over time, the career ladder will change to address its shortcomings.

Sample: The Setup

Let’s assume we are creating a career ladder for a DevOps team:

Our mission is to enable the continuous delivery of high quality software by providing self-service tooling and automation.

The career ladder consists of two titles, each with three levels:

  • Senior DevOps Engineer (I, II, III)
  • DevOps Engineer (I, II, III)

This can later be expanded to include more senior roles, like Technical Lead, Principal DevOps Engineer, or Manager.

Sample: Advancement

Finally, we need to define the process for advancing from one level to the next. Vague references to success 10 months ago aren’t going to cut it here. An engineer should be able to show that they are currently exhibiting a sustained track record of success that fulfills their current job obligations as well as the requirements of the next level. As part of demonstrating this mastery, they will be expected to produce convincing concrete evidence before any potential advancement can occur.

Sample: Expectations

Listed below are sample expectations for each step of the career ladder described above.

DevOps Engineer I - learn through doing

  • I ensure that the work I do focuses on our team mission.
  • I complete tasks that are assigned to me in a timely manner.
  • I ask team members questions when I am stuck to unblock myself.
  • I keep my manager and the rest of our team up to date on my progress.
  • I familiarize myself with our documentation and know where to find information.
  • I help our team reduce technical debt.
  • I describe what I’m working on tomorrow.
  • I learn new skills that benefit myself and our team.
  • I promote a respectful and productive work environment.

DevOps Engineer II - expand your reach

  • I proactively assign myself high priority work.
  • I work together with team members to complete tasks.
  • I keep our documentation up to date.
  • I understand the purpose of most of our systems.
  • I deeply understand at least one critical system.
  • I suggest new tasks and socialize them with the team.
  • I help people on other teams solve problems and teach them how to help themselves.

DevOps Engineer III - consistently produce great results

  • I provide a reliable estimate for when my work will be completed.
  • I contribute to discussions about which work is most important.
  • I work on a variety of tasks spanning multiple systems.
  • I describe what we should work on next week.
  • I articulate the business case for significant decisions.
  • I improve the way our team operates and communicates.
  • I bring important matters on our team to the attention of my manager.

Senior DevOps Engineer I - own projects from start to finish

  • I delegate work to team members and help them fulfill their job responsibilities.
  • I take ownership of multi-person projects and lead team meetings.
  • I guard architectural integrity when changes are made.
  • I review and approve changes based on the authority that comes from my technical expertise.
  • I resolve disputes when multiple tasks appear to have the same priority.
  • I create technical debt responsibly.
  • I foster good team morale.

Senior DevOps Engineer II - promote the big picture

  • I test hypotheses using metrics and identify the most valuable areas to automate.
  • I help my team members climb the career ladder.
  • I simplify the architecture of our systems.
  • I share and apply information about potentially useful new features, products, and services in our industry.
  • I describe what we should work on next month.
  • I bring important matters from other teams to the attention of my manager.
  • I gain the support of my team members when I share solutions and ideas.

Senior DevOps Engineer III - maximize our team impact

  • I promote a clear strategy for achieving our team mission that every team member can benefit from.
  • I provide architectural guidance for our projects and the projects we support on other teams.
  • I increase the value and effectiveness of our team.
  • I raise the professionalism of our team.
  • I describe what we should work on a year in advance.