The Software Engineering Job Ladder

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

Sources: here and here

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.

  • 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.
  • 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.

  • 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.
Newb has impressive stats, but can we trust him to take the poorly defined product spec and deliver something by Thursday? (Via Game Dev Story)

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

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 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 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

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:

  • 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.

Tie salary to level, and use equity to reward performance

Promote by ability, not seniority

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.

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.

  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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Chuck Groom

Chuck Groom

Consulting CTO open to projects. I’m a serial entrepreneur, software engineer, and leader at early- and mid-stage companies. https://www.chuckgroom.com