Software companies should put careful deliberation into their engineering job levels, and make available a job ladder explaining what is expected of employees, the distinction between roles, and areas for career growth.

In this post, I’ll discuss why having a job ladder helps everybody; what makes for a good job ladder; the way I think about software engineer job levels; and I’ll end with some related advice. While the intended audience is management, engineers may gain some insights by seeing things from the company’s point of view.

Note that this post only covers the individual contributor (IC) engineering track. I will not discuss parallel tracks (management, product), moving between tracks, or whether the leap from IC work is permanent. Those are all worthy topics but are beyond the scope of this piece.

Yes, the idea of a job “ladder” is a bit weird

The notion of a job “ladder” implies a highly structured and stable industry with a long-term path to a meaningful endpoint, like making partner. But modern careers are much more fluid with many possible (or unforeseen) branches. Employees often change jobs every few years.

Don’t think of the career ladder as a long-term life plan. It’s easy to pay too much attention to the top of the ladder (“what am I really doing with my life?”), but it’s the next rung that matters most. The ladder is a tool for setting expectations about the next few years.

Suppose you don’t have a job ladder

New companies or teams often don’t have well-defined titles or roles. In fact, this may be a perverse source of pride; you may hear things like “we’re a flat organization” and “titles don’t matter.” While people may have very different salaries, there’s a general sense that it’s a meritocracy.

Well, if things are working without a job ladder, why go through the hassle of making the change? Let’s look at some examples.

• Frank wants a promotion to a “Senior” title, but we don’t feel he’s ready yet; he asks why not? → We need a way to explain the difference between levels, and give Frank guidance on which skills to develop.
• We’re interviewing a candidate. We like her, but in our hiring debrief we’re split on whether we should offer a level-2 vs. level-3 role. → Without a clearly defined hiring bar, this important decision becomes highly subjective.
• Our startup didn’t have formal titles. We just raised a Series-A round, and along with it we brought on new leadership. After some intense closed-door discussions they assigned everyone job levels and many engineers are angry to discovery they’re “Junior.” → Oh crap, titles don’t matter until they matter. Now lots of people are angry and upset.
• We hired Karen a few years ago at $85k/year. We hired Noreen this summer — after a bidding war with Facebook, her salary wound up being $120k/year. Karen and Noreen do the same work. Over drinks, Karen finds out how much Noreen is paid. → This is a disaster. We can’t afford to pay everyone $120k. But Karen has every right to call foul.

Everyone wins when there’s a job ladder

A job ladder helps employees and companies.

• Management: a good manager should provide regular feedback about how well employees are meeting their current obligations, as well as developing and demonstrating the career skills they’ll need to grow. A job ladder provides an unbiased framework to structure these discussions.
• Recruiting: a good job ladder should make it fairly easy to level-set prospective candidates. Teams can establish a standard set of questions and hiring bar for each level, and do an apples-to-apples comparison between people.
• HR compensation ranges: as soon as you start hiring employees, you need to decide what to pay them. You’ll want internal tiers and a way to match these to industry market rates.

Company principles

A job ladder communicates which skills and traits are important. These must align with your company’s mission and values — the culture of problem-solving you want people to use for staying focused on the end customer, resolving conflict, and making difficult decisions. The phrases used in your company’s principles and mission should be included in the job ladder and also used for employee feedback. Amazon’s leadership principles are a great example.

What goes into a good job ladder

A well-crafted job ladder should do the following:

• Explain and justify the difference between job levels. As much as possible, each job level should be a different role, not just degree of skill; you want a step function, not a gradient.
• Show employees what attributes matter for promotion (and self-improvement). The job ladder is the career development plan of record, and it should explain the criteria you’ll use in employee evaluations.
• It’s easy to understand and read. Less is more. This should be a reference guide with clear structure and pithy statements.

Antipatterns include:

• The roles don’t match what we do. The description of levels and values don’t jibe with our day-to-day experiences and needs.
• Long lists of specific skills and achievements. Employees may treat these as a checklist for promotion. It can be easy to get lost in the specifics and forget the essential differences between levels.
• Written like an algorithm. Some tech companies seem to believe they can build an objective, mechanistic process. Sorry, but people-management is, and always will be, messy and somewhat subjective; you’re better off writing a humanistic job ladder with aspirational goals that are fuzzy but ring true.

My job ladder for software engineers

I lean towards a job ladder based on spheres of ownership and responsibility, rather than defined skill levels. I prefer this model because it maps well to how tasks are broken down and assigned, and there’s a clear difference between each level.

Skills matter too, of course. All software engineers must be able to write code and solve customer problems in a team environment. I’ve found the essential traits to be:

• Programming ability: coding, design, testing, system maintenance.
• Communication: effective emails and Slack notifications, proactive status updates, structured fact-based arguments, collaboration.
• Critical thinking: balances short-term needs with long-term goals; thinks about what could go wrong; finds requirements.
• Initiative: scrappy, takes ownership, follows through to the very end.

That being said, these abilities are fairly “sliding scale” with no obvious step function where you can point at any one skill level and say “aha! This means you’re a level 3 instead of a level 2!” My job ladder assumes these traits matter, but avoids specific guidelines.

The exception is Level 4 engineers (and beyond); for these, very deep and specific technical and architectural experience is a requirement.

Level 1

• External title: [Junior] Software Engineer
• Role: Builds defined features, investigates and fixes bugs, writes tests. Communicates progress, identifies blocking issues. Finds a work-life balance.
• Anti-patterns: Poor code quality. Not self-motivated; needs someone to tell them what to do next. Constantly veers into the weeds. More inclined to blame-complain than roll up sleeves. General helplessness. Disregards team process.
• Experience: ~0–3 years

Junior engineers bring a lot of raw energy and potential to a company. They “do work” you give them — often, quite a lot of it. They need help with up-front project planning and the breakdown of tasks into specific chunks of work. Team leads should check in fairly often to make sure they’re on-track and have direction.

I prefer to use the public title “Software Engineer” (dropping the “Junior”) because nobody wants to called “junior.” Internally, you can call this level-1 without insult.

I find level-1 interviews to be the hardest to arrange because candidate skills levels are all over the place. Initiative and critical thinking are what matter most, but these are difficult characteristics to measure in an hour or two. Let go of level-1 engineers who won’t be promoted to level-2 within 2 years.

Level 2

• External title: [Senior] Software Engineer
• Role: Owns a functional area. Breaks large requests down into sub-tasks, gives higher-level status updates. Writes test plans. Takes operational responsibility. Sets measurable goals, and meets them. Reviews code changes. Helps mentor new hires.
• Anti-patterns: Disappears into projects that don’t matter to the business. Fails to identify or communicate big roadblocks. Us-vs-them attitude. Continually underestimates timelines. Doesn’t take operational excellence seriously. Solutions are more complicated than necessary.
• Experience: ~1–8 years

Level-2 engineers can take ownership over a body of significant software. You can trust them to take loosely defined requests and do the right thing — break down complex tasks, make reasonable decisions, and operate fairly independently between periodic check-ins. Communication and critical thinking skills are essential.

Should this be called a “Software Engineer” or “Senior Software Engineer”? I’m on the fence, but lean towards using the same external title “Senior Software Engineer” for both level-2 or level-3 engineers on business cards and LinkedIn, while internally referring to them by level.

While someone can be a level-2 engineer for several years, eventually they should demonstrate they can take on more ownership and be promoted to level-3, or leave the organization.

Level 3

• External title: Senior Software Engineer
• Role: Owns the development and rollout for an entire product, or large project. Champions process (Scrum, TDD, etc). Writes tech specs and identifies risks before starting major projects. Sets standards. Goes out of their way to reduce complexity. As needed, takes on additional “tech lead” responsibilities for driving an initiative to completion.
• Anti-patterns: Arrogant jerk. Doesn’t delegate. Always says “yes” and suffers burn-out. Jumps into execution without careful consideration. Lets details slip through the cracks. Fails to raise awareness of projects at risk or people-problems. Doesn’t follow new technologies or industry tends.
• Experience: ~5+ years

Level-3 engineers take ownership over a whole product (e.g. an entire application, or suite of services). In additional to delivering solid and maintainable software, they understand company dynamics and good process.

Senior engineers often wear an additional “tech lead” hat. This means they take on the (thankless) work of project management and process oversight. They keep the trains running on time. Note that a tech lead does not have direct reports and does not boss people around; they lead by gravitas.

This can be a career position. It’s perfectly normal to have solid level-3 engineers who are happy being individual contributors, and don’t want to move to management or general architecture.

Level 4 (and beyond)

• External title: Architect (or Principal Engineer, or invent a cool title)
• Role: Owns cross-team shared infrastructure. Works with CTO and other architects to choose new technologies, and promote culture / process. Has deep technical expertise in a business-critical area. Does serious research to evaluate and test options. Understands implications (and trade-offs) of reliability, scalability, operational costs, ease of adoption by organization, recruiting, etc.
• Anti-patterns: Over-emphasis on scaling or high availability far beyond business needs. Spends too much time chasing the newest “shiny” technology. Doesn’t collaborate or ask questions. Condescending. Has “pet” agenda. Pisses off senior leadership.
• Experience: ~8+ years

Level-4 engineers are architects who can evaluate system-wide platform decisions and set long-term company-wide technical strategy. They often have two roles, working both as individual contributors on a feature team and also as architectural reviewers working with the CTO. Your architects should be humble and outgoing; they are your engineering cheerleaders.

Other job ladders

Of course, you should compare this job ladder with the many other excellent blog posts and ladders out there. Here’s a few:

• Gilt
• Rent the Runway
• Foursquare
• Fog Creek (Joel on Software)

Some areas you’ll see differences of opinion are:

• How many individual-contributor levels should there be (3? 6?) What do you do with your super-senior folks?
• How detailed should your job ladder be? (This runs the gamut of complex point systems, spreadsheet matrix, paragraphs of text, or just a few general guideline bullet points)
• What are the specific roles and responsibilities for a “tech lead”?
• Who’s responsible for project management?

Related advice

When do you need to create an engineering job ladder?

I’d say by the time you have 5–10 software engineers and are starting to think about asking someone to become a full-time manager, you should also start thinking about clarifying job roles and career paths.

Who writes the job ladder?

It’s hard for a committee to write a good job ladder from scratch. I suggest that one engineering manager writes a draft and brings it to the engineering management team to kick off discussion and workshopping. Another approach is to ask all engineering manager to write separate drafts independently, and then meet to compare notes and then merge by committee.

Titles matter

Even if someone sincerely tells you “titles don’t matter,” all that really means is that “titles don’t matter at this point in time.” As companies grow, job leveling is inevitable; title will be used as a proxy for level, which dictates your salary and career options. When you switch jobs, you will be recruited and compensated based on your previous title.

Always make sure your title and role are spelled out.

Tie salary to level, and use equity to reward performance

Manage salaries as if you had to post them outside your office door.
 — M. W. Mantle, Managing the Unmanageable (2013)

Employers should establish a salary band for each job level, based on industry comparable data. This does restrict their ability to recruit star candidates on the basis of salary, or to reward stellar performers with a big raise; but it’s the only tried-and-true way to keep budgets under control and avoid unfairness.

One-off equity grants with a future vesting cliff, e.g. a grant over 2 years that starts vesting in one year, are one way to reward extraordinary performance. This shows key employees that even though you may not be able to give them a big raise, you still value their contribution and want them to stick around for the long term.

Promote by ability, not seniority

Promotions are generally not rewards for past performance. Instead, management uses promotions to advance those who display the potential to tackle the next level of bigger, tougher problems.
 — Ray Weiss, The Technical Career Navigator (Prentice Hall, 1994)

Promote people who are already functioning at the next level. If a level-2 engineer wants a promotion, they should demonstrate they are doing level-3 work. It’s your job as a manager to give them projects where they can cut their teeth (and land gracefully if they’re not quite ready).

Never create the expectation that promotions are a function of time at the company, or open the door to promoting someone above their ability.

Don’t require CS degrees

For level 1–3 engineers, I haven’t found formal education to be a reliable predictor of success. I’ve had several excellent hires who were self-taught, or who came from vocational 6-month code academies. I no longer require candidates to have undergraduate C.S. degree, and I’ve stopped asking algorithm-heavy interview questions.

The level 4 (principal) engineering role is the exception; the role requires a solid academic foundation in algorithms, systems, architecture and bits-and-bytes.

Do contractors fit on the job ladder?

No; they’re hired guns. Your assessment isn’t about their level, but whether they’ll finish a particular project.

Where do interns fit into this?

Again, they’re not really on the job ladder because you’re not hiring them full-time. Here’s my rules on interns:

1. The reason you have an internship program is to recruit the good ones as level-1 engineers next year. (Yes, there are additional positives, but this is the main reason).
2. Therefore, only recruit interns who will graduate and be on the job market next year. Avoid sophomores and grad students who aren’t definitely wrapping up.
3. The criteria for hiring an intern is: will this person probably meet our junior engineer hiring bar next year? Avoid the ones you’re lukewarm on; the great students really stand out. I usually wind up picking the ones who have written a significant chunk of code they’re excited to talk about, like a side project on Github.

Final thoughts

Employees want to know where they stand in an organization. Having well-defined career milestones with expectations and objectives makes everyone’s jobs easier.

When writing a job ladder, the key things are:

1. The job levels match how your company is organized (roles, reporting structure).
2. The criteria for hiring and promotion mesh with your company’s values.
3. It is fair.

You can fine-tune your roles and values over time; but never violate the principle of fairness. Everyone must be held to consistent standards or else your morale and productivity will crumble. A good jobs ladder levels the playing field and lays out the rules to the game.

This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.