Defining expectations is a big piece of our job, and having clearly defined and usable leveling or growth frameworks can make a lot of things easier. Luckily a lot of folks have open sourced their thinking, frameworks, and job descriptions, so we don't have to start at zero.

If you're just getting started on creating a job ladder or framework, my goal is to provide you with the subset of resources that had the most impact on my own thinking, as well as a distilled starting point I've pulled from those resources and reviewing 30-40 open frameworks I've run into.

Table of Contents

• Defining Ladders and Roles
• A Starting Framework
  • Some Key Takeaways
  • Some Key Questions
  • Five Paths for Senior Developers (not one)
  • A Common Starting Ladder
• References

Defining Ladders and Roles

Job positions and titles drive a lot of decisions in companies, and often a lot of bias. They can drive what we hire for, our first initial bias when we read a resume, how we evaluate people during interviews, reviews, changes to compensation, and more. On the receiving end, they can impact retention, satisfaction, and feelings of achievement and visibility.

We don't have common terminology or expectations across the industry, which makes this both harder and more important. When we rely on in the moment gut calls to provide guidance and feedback, we're creating turmoil, poorer returns, bias, paranoia, and many other future management jobs.

Terms for the post

Since we don't have common terms in the industry, I find it just as hard as you to communicate clearly. For this post, I'm going to try and use the following terms/meanings:

Job Position: This is what we're defining. It's the title or level granted to an employee, with general expectations on what their role or roles are.

Examples: Junior Software Engineer, Senior Software Engineer, Principal Architect

Role: A named set of responsibilities that may be part of a given job position. The difference between a position and role is a future post, but think of a project lead or someone who takes point for team communications for a month as a role, a focus or subset of the skills necessary for their position.

Requirements: The defined requirements or expectations for a Job Position

Promotion: Promotion is the company granting a position to someone. Promotion could be automatic, in the sense of skill progression (Junior to Mid-level), or it could be granted to someone to reflect a change in expectations or responsibilities (Developer to Manager, for instance).

A Starting Framework

I've taken common characteristics from 30+ ladders and frameworks (and wider reading and hands-on experience), and created a general ladder.

Before I get into that general ladder, I want to share a set of key takeaways I found, some questions I think are valuable for you to ask as you consider your own ladder, and a deeper dive into the 5 paths I think a developer can take after "Senior" level.

Some Key Takeaways

1. There are common elements in our expectations as engineers progress, regardless of what we call the titles
2. These common elements split into several defined groups at higher levels
3. Companies are often not clear on whether you can naturally Progress up the ladder or if each step is a granted Promotion by a manager
4. Folks that fit in the early levels of their career have a high chance of not fitting the specifics at higher levels

Also, it's becoming common in the industry to recognize that:

1. Manager is a different type of role than Engineer, not a natural progression that all folks should work towards

Some Key Questions

1. Promotion vs Progression?

Mentioned above, this is the idea that folks can naturally grow into some roles, while others are enough of a responsibility change that it should be granted by the company to communicate those new responsibilities. In the sample ladder below, I would suggest making Associate to Mid to Senior progression-style steps, then define the shift to later stages as promotions. Keep in mind you may have to provide a way to have your compensation strategy support this or accept that folks may choose to leave the senior role for a new company and role (and that may be ok).

An interesting follow-up is to consider when you will promote someone for progression. Do they have to display some of the aspects of the next role? all of them? Also, be careful using wording like "Can build a ..." in either case, it's hard to prove or disprove "can".

A good quote from the Medium posts (Engineering growth: assessing progress) linked below:

To achieve a milestone, the review panel must have a good faith belief that the engineer has been performing to the appropriate standard. In general, the engineer must have demonstrated a Conscious, Comfortable, Continuous, Consistent Competency
...
As a natural consequence, an engineer does not achieve a milestone the first time they demonstrate relevant behaviors or tasks.

2. Career levels - what are acceptable terminal levels?

I've run into several discussions lately on what levels are acceptable "Career" levels. This is the level where someone choose to grow at only the rate necessary to keep up with technology advances and doesn't intend to advance to new responsibilities. Generally any level Senior and above seems to be acceptable, some folks are also willing to have Mid-level career folks. Very few people seem willing to accept a complete lack of learning.

Five Paths for Senior Developers (not one)

As I've read through a lot of these frameworks and posts, I started to notice that ladders tend to overlap less at the higher levels. I suspect there are three drivers for this:

1. These roles are expected to be high impact, across large numbers of organizations or the whole company, for smaller companies
2. Less than 5% of developers in the company will hold these roles (think 1-2 principals/architects for 4 teams of 5-8 folks)
3. There are a lot of small companies that have no one in these roles but need to offer some professional development goals to senior developers

Comparing definitions across companies (and drawing on my own experience), I've seen several patterns emerge.

Significant defined roles for Software Engineers (vs common titles on right)

1. Deep Specialization (Expert): Developers become deep, technical experts in an area (for instance deep understanding of a mobile technology, chipset, browser performance tuning, security, devops, etc), and grow towards becoming an industry leader in that specialty

2. Internal Leadership (Architect): Developers that enable the technical organization to better execute against the business needs, drive and maintain technical roadmaps, connect technical teams, and ensure functional and non-functional requirements are understood and met

3. Domain/External Leadership (CTO): Developers become experts in the business domain and use the combination of domain and technical knowledge to find opportunities to create new features and product lines, generating greater business success and becoming technical leaders in their business industry

4. Career Change (Manager): Developers discover an interest in managing people, projects, or product and make a career change, focusing on areas that grow into roles such as VP of Engineering, (COO/Chief of Staff?), or Chief Product Officer.

5. Steady State: Starting at Mid or Senior Developer, it's common to see some number of folks achieve a steady state. There is a lot of value in a Senior Engineer that keeps up with the industry, motivates the team, mentor's junior folks, but doesn't want to pursue the paths above. I don't think the nature of the earlier roles allows them to be steady state, but from Senior forward this is an option.

Some companies are large enough to identify these as distinct roles, some will have a single career ladder that gravitates heavily towards one of these, with elements of the others. And, unfortunately, some companies will have ladders that try to combine all of these things in ways that no one can achieve.

A Common Starting Ladder

To create a common starting ladder, I deconstructed a number of job ladders and frameworks into their individual expectations and started looking for common patterns. I also compared the high-level categories across many other frameworks that used non-standard terminology or complex micro-leveling.

Comparing defined positions across companies

I tried to pick enough ladders and descriptions so I could pull out the 60-70% that makes up the common foundation, while avoiding those that drew too heavily on one I already had in my set (the Rent the Runway ladder is one that is regularly copied and altered a bit, for instance).

Categories for Position Definitions

After several takes, I've grouped these into 8 subjects:

• Supervision (Autonomy) Common level of supervision required and/or autonomy they should be able to handle
• Skill From basic skills to expertise in many areas
• Execution The level of work they can be assigned and can complete
• Design The level of system design they can perform in order to execute
• Work Standards To good standards and then developing standards
• Initiative The additional work or responsibilities we expect them to take on under their own initiative
• Learning/teaching Learning how to learn, learning, teaching
• Communication/Collaboration/Leadership Working with teammates to business stakeholders

One common category I left off can be summarized as "knowledge of codebase". I left this off because, (1) it is implicit in many of the other expectations, and (2) it's highly dependent on how long they have worked with the company as well as other organizational constraints (folks from Team A and Team B have different scopes).

Position Definitions

Using the 8 categories above, we can build some basic definitions for a ladder:

Entry Level (Intern/Junior): Intern, Associate, Junior
Interns or folks with a little schooling or self-learning experience

The expectations for this role are relatively simple:

• Skill: Has acquired some basic programming or CS skills, but still learning how to put them to use
• Learning/Teaching: Focused on learning how to be a developer at the Associate/Junior level

This role is typically about bridging a small amount of self-taught experience, partial college experience and/or code camp attendance with the ability to operate to Associate level expectations, below. (From a time perspective, this shouldn't be more than 6-12 months?)

Associate Level (Junior):

May enter at this level, depending on level of schooling, self-learning experience, etc.

• Supervision: Requires regular, day-to-day direct supervision to be effective
• Skill: Has acquired some basic programming or CS skills, but still learning how to put them to use
• Execution: Tightly scoped problems and likely will require active mentoring at a task level to execute well
• Design: Likely requires active mentoring from a more senior developer to plan small features
• Work Standards: Work requires thorough review, works often requires small to substantial changes to meet team or industry standards, little to no knowledge or experience working against team or industry standards
• Initiative: Ask for help when they're stuck, perform routine maintenance for systems
• Learning/Teaching: Developing skills necessary to write software in a business, focused on growing and expanding as a developer
• Comm/Coll/Leading: Learning how to communicate as a member of a team, receive feedback, and raise questions

Mid-Level:

• Supervision: Able to work independently on features and small projects (days to weeks)
• Skill: Solid understanding of core engineering concepts, capable of working in more than one domain (database, apps, APIs, web frontend, etc.), some skill in testing, security, one of OO/functional/procedural styles
• Execution: Breaks down features and small projects to execute on, consistently delivers features with significant value to customers and/or teams
• Design: Participates in design with more senior developers, learning how to prioritize work
• Work Standards: Delivers work that follows established patterns and helps improved internal guidelines, performs helpful code reviews
• Initiative: Asks for help when they're stuck, fixes faults based on team procedures, identifies quality and reliability issues in systems they maintain, proactive response to escalated customer issues
• Learning/Teaching: Self-directed learning, can help new hires and interns get up to speed quickly, mentors less experienced colleagues
• Comm/Coll/Leading: Works well with colleagues, seeks input from more others with greater experience or expertise, provides feedback to peers and manager, asks for clarification from peers or business stakeholders when requirements unclear

Senior (Career):

• Supervision: Requires very little oversight beyond high-level direction, trusted to deliver on large (weeks to months) multi-person projects
• Skill: Proficient in all relevant technical skills for their function and beginning to build expertise in one or more areas, aware of major industry trends in their area, appreciation of security, delivery, operations
• Execution: Capable of taking substantial features from concept to fully shipped, translates projects into tasks, responsibility on projects reaches beyond code deliverables
• Design: Creates solid technical solutions to ambiguous or open-ended problems, treats prototyping and design as a team activity, collaborates with others to review designs, cuts scope when necessary to hit deadlines or other constraints
• Work Standards: Contributes to codebases and common standards for teams, provides high-level feedback in reviews, code review feedback is respected and often sought after, received reviewed tend to focus on higher-level approach and less detailed feedback
• Initiative: Understands the business needs and trusted to prioritize work for the team, coaches others how to prioritize work against business needs to prevent feature creep, uses wider business and organization understanding to guide decisions on larger initiatives, identifies process optimization opportunities and contribute to implementation
• Learning/Teaching: Sought out as a technical resource, often teaches their strongest skills to others, consistently helps less experienced colleagues "level up", known outside their team as a technical leader
• Comm/Coll/Leading: Able to describe status and impact of large projects to mixed audiences, proactively reaches out to stakeholders with updates, communicates bad news clearly and quickly

Post-Senior Tracks #1 (Staff Engineer, Advanced, Lead Engineer, Architect, etc):
Note: this is a general definition, some items may be more or less relevant, or require greater emphasis, depending on whether you're targeting the Technical Expert, Internal Technical Lead/Architect, or External Technical Lead branches

• Supervision: Can own months-long initiatives from concept through delivery, can work completely autonomously without oversight
• Skill: Deep substantial experience in multiple programming environments. Mastery/expertise in several relevant technical skills, up to date on evolving standards, platform features, and community changes. Capable of executing across multiple domains (fullstack).
• Execution: Has owned and run entire sub-systems. Has led initiatives outside their area of expertise. Successfully plans and leads multiple developer projects to meet core goals.
• Design: Designs systems that balance functional and nonfunctional constraints to meet goals. Reviews designs of other.
• Work Standards: Helps set and maintain work standards for an entire organization. Provides technical leadership and mentoring to the team. Contributes to the community. Advises on the best ways to apply standards.
• Initiative: Sets vision for multi-month projects. Strategic impact over large team, long time horizon, or deep technical area.
  • (External Lead) May be wholly responsible for a service and meeting business goals/needs. Guides the way the team works.
  • (Internal Lead) Shepherds and aids in the development of new projects across the organization. Identifies key gaps in product offerings that will drive significant revenue + customer engagement.
  • (Expert) Identifies, locates, and competently fixes complex faults.
• Learning/Teaching: Provides considerable high-level technical guidance. Mentors colleagues. Constantly working to broaden the skillset of the team.
• Comm/Coll/Leading: Represents team when talking to external partners. Constantly goes above and beyond basic requirements to support their team. Strong ability to influence without requiring authority. May act as a team or technical lead. Capable of leading small teams for substantial projects.

Post-Senior Tracks #2 (Sr Architect, Principal Engineer, CTO, etc):
Note: this is a general definition, some items may be more or less relevant, or require greater emphasis, depending on whether you're targeting the Technical Expert, Internal Technical Lead/Architect, or External Technical Lead branches

• Supervision: Works autonomously to strategic goals. Manages service, initiatives, or business unit to ensure it meets business goals.
• Skill: Expert in multiple technical areas or specailist with deep knowledge in a particular area.
• Execution: Helps make critical product, architecture, and/or implementation decisions. Manages service or area to meet business performance targets.
• Design: Fully capable of building, designing and running entirely new, novel systems. Consistently able to reduce complexity of problems and achieve more effective results. Experienced in a variety of methods of prototyping. Engages and mentors others in design.
• Work Standards: Identify and champion the adoption of emerging technologies. (Internal Lead, External Lead). Identify and build standards for how product features and services are delivered throughout the company. (Expert, External Lead) Recognized widely in the domain for material contributions to the state of the art. (Expert, Internal Lead) Strong understanding and adoption of most relevant industry standards throughout the company.
• Initiative: Significant strategic vision.
  • (Internal Lead) Can take a 3-5 year business plan and translate into a strategic technical roadmap. Deeply technical savvy, focuses architecture and technical needs over the business horizon. Maintains a technical vision of the overall direction of the product lines
  • (External Lead) Identifies new features or entirely new product offerings based on combination of technical skills and business knowledge. Represents the technical side of the company to outside partners, investors, and prospects. Identifies opportunities in the intersection of long-term business and technology trends.
  • (Expert) Builds tools, frameworks, and guidance that improve productivity for many colleagues
• Learning/Teaching: Invents new concepts, pushed the whole organization forward regularly. Recognized by engineers in multiple functions as an expert mentor and teacher. Highly sought after.
• Comm/Coll/Leading: Capable of creating and running teams for large, long-running projects. Strong ability to influence without defined authority. Facilitate cross-team work and strongly influential beyond their team. (Internal Lead, External Lead) Works closely with engineering, product management, and sales to ensure close product/market fit. (Internal Lead, External Lead) Use technical and business knowledge to help multiple teams work together effectively. (Internal Lead, External Lead) Can set and direct an entire department.

Using this information

First: Don't copy and paste this into your organization. Besides the lack of specific technologies and values, you may find that some of these categories are more or less important in your organization. It's not unusual for one organization to require more advanced skills than average in one area, and less advanced skills in another. Your ladder should reflect what's important to your organization, while hopefully being able to use this as a starting point and way to compare to an average(ish) starting point.

Second: The levels above may not be the right number of levels for you. A number of companies have been gravitating towards Junior, Mid, Senior, Staff, Senior Staff, Principal lately. Others have numbered roles. Still others are standardizing on Entry, Developing, Career, Advanced, Expert, and Principal.

• Example: If your organization is remote-first, you might want to include additional detail on the communication front to dig deeper on asynchronous communication, proactivity, and so on.*

• Example: If you have a customer-facing developer team and a backend developer team, you might want to create two ladders or expand on skills with relevant examples for both teams, so folks will have good guidance for growth or identifying if another team is a better fit for their skills.*

• Example: If your company is focused on contract maintenance of an enterprise system, you may want to focus less heavily on initiative and design and more on execution, communication, and supervision/autonomy.*

References

Here are key ladders/frameworks that I think are useful to read, online material that I consider to be high leverage, and some great supporting books you should read.

Ladders/Frameworks

• Rent the Runway - Highly referenced ladder
• UK Gov - Interesting breadth of skill requirement. Linked to Junior Developer, others linked at bottom.
• Urban Airship - Well defined, succinct.
• Medium Growth Framework - Extensive (too much so IMO), but great content and the posts on how they communicate and work with it have a lot of great ideas
  • Engineering growth: assessing progress linked from above and useful to consider how and when you will assess folks against your ladder/framework

Online Posts

• Senior Engineer, John Allspaw
• Distinguished Engineer
• What a Senior Staff Software Engineer Actually Does

Online Resources

• https://www.levels.fyi/ - Compare levels across a number of (mostly large) companies
• https://www.progression.fyi/ - Links to other published ladders/frameworks

Books

• The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change
• Drive: The Surprising Truth About What Motivates Us
• Scaling Teams: Strategies for Building Successful Teams and Organizations

History

• 2019-07-10 - still trying to get the first draft done...
• 2019-09-15 - Initial posting
• 2021-02-23 - Light edits to the beginning, I kind of want to rewrite it all for tone and wordiness :P

As I continue to update the content, I'll note changes here with detail.