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

  • 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

  • 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

What goes into a good job ladder

  • 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

  • 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

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

Who writes the job ladder?

Titles matter

Tie salary to level, and use equity to reward performance

Promote by ability, not seniority

Don’t require CS degrees

Do contractors fit on the job ladder?

Where do interns fit into this?

  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

  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.

--

--

--

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

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to Draw Useful Technical Architecture Diagrams

Aspiring Programmers – Here is your First Step to Being Industry Ready — Start with GitHub

My First Project with DDD — 1.Planning

A Smart Feature Flagging System for iOS

Continuous Deployment with Travis and CONDA

Just in Time Cloud Infrastructure

Containers in the Cloud

How to build a PostgreSQL database to store tweets

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

More from Medium

The 2 Things You Ask Your Team When You Pass $1B w/ Hippo’s VP of Engineering

Knowledge Leaders and People Management — Why Engineers Need to Lead Engineers

How Do I Deal With Underperforming Engineers?

In defence of tech debts in software engineering