Medium's domain: Engineering
Medium's Growth Framework is a little different from how many companies approach development, recognition and leveling. This document describes its structure and some of the reasoning behind it.
Goals
We are attempting to solve a number of problems with this framework, and avoid others that we recognised in other systems. At a high level, we are trying to achieve multiple goals:
- Allowing engineers to develop in multiple ways, rather than artificially reducing them to "engineer" or "manager".
 - Recognising that roles are not static, and that people will evolve over time.
 - Codifying what is expected of engineers.
 - Recognising contributions that are typically undervalued or ignored in traditional engineering ladders.
 - Providing multiple ways for people to be recognised for leading within the organisation.
 - Giving recognition and rewarding professional development.
 - Ensuring fair and equitable compensation.
 - Avoiding the development of a homogenous team, where everyone does the same kind of work.
 - Connecting hiring and progression to our company values, so we hire, incentivise, and reward what we value.
 
Overall, the main goal we are trying to achieve is helping engineers answer the question "How do I progress?"
Overview
We recognise that all engineers are different and that each applies a unique combination of skills in their work. We understand that there are many paths to a successful career, and support and encourage the growth of different shapes of engineers that together create a robust and flexible team. We know that there are particular kinds of work that is often overlooked, which is nevertheless very important.
Tracks
To recognise these contributions, we define 16 tracks along which engineers are incentivised to develop and progress. Each of these tracks represents a discipline that adds value to the organization and helps Medium achieve its goals. These tracks are grouped into 4 categories:
Building
Mobile, Web Client, Foundations, and Servers
Executing
Project Management, Communication, Craft, and Initiative
Supporting
Career Development, Org Design, Wellbeing, Accomplishment
Strengthening
Mentorship, Evangelism, Recruiting, Community
Each category has a list of hiring indicators from the hiring rubric, which hint at the kind of qualities useful for progress along these tracks, but they are intended to be more informational than prescriptive.
Each track is weighted equally. We have deliberately tried to define tracks that add concrete value to the organisation, and hold appeal to all kinds of engineering personalities.
Engineers may attempt to progress down any combination of tracks, though realistically, they will only be able to focus on a few at a time, and organisational needs may mean that they are strongly encouraged to focus on certain areas.
Milestones
Each track has 5 milestones, which get progressively harder to achieve. It is much harder, for example, to move from milestone 4 to milestone 5 than from milestone 1 to milestone 2. Track milestones typically range from simple individual contribution to major organisational impact. Each milestone is intended to be approximately as difficult to achieve as the same milestone in every other track for a motivated individual, assuming a start from scratch. Given the wide range of tracks, and people's experience or natural capabilities, every engineer will find some tracks easier or harder than others.
Each milestone has a description, which provides a high-level overview of the milestone, and 6 example behaviours and tasks. These examples are descriptive, not prescriptive. They are designed to be read together with the milestone description to paint a picture of the kind of person we would expect to see at that milestone.

Milestones 1 and 2 of the Craft Track
Points
Each milestone achieved earns points. Because successive milestones are harder to achieve, they are worth more points. The chosen point progression slightly favours specialisation over generalisation. Organisationally, it is important that people develop and are rewarded for mastery of certain skills so we have the ability to innovate at the leading edge. However, we recognise that strong generalists provide great flexibility and are foundational to a robust and antifragile team.

Milestone points progression
Points at a given milestone replace points earned at an earlier milestone. For example, moving from milestone 3 to milestone 4 earns an additional 6 points, not an additional 12 points.
With 16 tracks, each having 5 milestones, there are a total of 320 points available. We do not expect anyone to come close to achieving that number.
Levels
Every point earned contributes to an engineer's overall level. There are 5 overall levels, each divided into 3 sub levels. Successive levels require more points and are harder to achieve.

Level progression
The entire point progression is defined in the rubric and in the interactive tool.
We may add more levels over time as we grow as an organisation. The highest level is currently defined at 135 points out of a possible 320, which gives us plenty of room to grow should it be necessary.
Salary
We care very much about fairness and recognising equal contribution with equal compensation.
Level-based salary and equity is the same for all engineers at the same overall level. There may be rare occasions where this is not the case due to external factors or exceptional extenuating circumstances, such as acquisitions.
Medium offers equity refreshes based on tenure, so it is not necessarily the case that everyone at the same overall level will have the same equity.
Medium may also offer one-time signing bonuses where there is a compelling business need, such as a role that is particularly hard to hire for, or where we need to incentivise someone to move their home. Taking this into account, annualised compensation may differ between people at the same level.
Although we reserve the right to retain this flexibility, we work very hard to ensure that people performing at the same level are compensated equally, regardless of gender, race, or any other unimportant factor.
Titles
Titles typically serve three purposes --- helping people understand that they are progressing, vesting authority in those people who might not automatically receive it, and communicating an expected competency level to the outside world.
The first two needs are met by the level number itself, and so internally, to the extent that we refer to them at all, we will use the level numbers to communicate seniority and capability.
In standard industry parlance the 5 major levels are broadly comparable to Engineer I, Engineer II, Senior Engineer, Staff Engineer, and Principal Engineer, but externally the levels don't mean much without context. Therefore, we allow people to choose a title from a restricted set at each overall level, for external use on their resume, bio, or LinkedIn profile. For example, an engineer focusing primarily on Supporting tracks at Level 3.3 might choose Engineering Manager, while an engineer focusing on Building tracks at the same overall level might choose Senior Engineer.
Positions
• Positionsare simply the titles, which represent the expected reach (team, department, company, etc) each employee is expected to have at Medium.These are critical to ensure consistent and therefore fair pay (each position should have a small salaray range in which everyone is paid within)• Assignmentsare a collection of responsibilities needed for Medium teams. What outcomes and impacts your teammates can expect from you• Abilitiesare the tools we value/recognize at Medium. They are the tools you need to complete those role responsiblities... HOW you do it• Valuesare the aspirations we strive for at Medium
More details about positionsOurGruuv::Expect is built on the aspiration of equal pay for the same job.
Which is why we encourage companies to do away with arbitrary and unavoidably biased raises.
The better way is to have multiple levels within a single title and tie tight compensation ranges to these levels.
For instance, let's imagine that you have a growth framework where juniors are 1.*, mids are 2.*, seniors are 3.*, etc.
A 3.2 and a 3.3 within the domain of engineering would have the title of Senior Software Engineer. However, they would be paid differently becuase they've reached a different sub-level within the journey of being a senior.
This style of growth framework promotes actionable feedback based on the abilities Medium values.
- More opportunity for recognition (and promotion)
 
 ... and less ambiguity, burnout, and questioning "what do I have to do to be promoted/recognized"- More fairness and consistency.
 Possible because the system is designed to base recognized growth on a predefined and agreed-upon system of cumulative achievement (fair for specialists and generalists alike).
 ... and less chance of bias or stress related to ensuring an equitable system for compensation-impacting recognition- More conversations about the things that matter (growth, performance, and the impact each teammate is having on each other and the mission)
 
 ... and fewer "who likes whom" or "who is the best raise/compensation negotiator" gamesUnstated expectations are resentments waiting to happen.
Therefore, OG strives forClear Expectationswhich leads to great habits, which leads to the team flow state, which leads to theMedium Gruuv!
0 inherited Positions within the 1 parent domain.
24 nested Positions within the 4 nested domains.
- Engineer - 1.1w/in:Building
 - Engineer - 1.2w/in:Building
 - Engineer - 1.3w/in:Building
 - Engineer - 2.1w/in:Building
 - Engineer - 2.2w/in:Building
 - Engineer - 2.3w/in:Building
 - Engineer - 3.1w/in:Building
 - Engineer - 3.2w/in:Building
 - Engineer - 3.3w/in:Building
 - Engineer - 4.1w/in:Building
 - Engineer - 4.2w/in:Building
 - Engineer - 4.3w/in:Building
 - Engineer - 5.1w/in:Building
 - Engineer - 5.2w/in:Building
 - Engineer - 5.3w/in:Building
 - Engineering Director - 5.1w/in:Supporting
 - Engineering Director - 5.2w/in:Supporting
 - Engineering Director - 5.3w/in:Supporting
 - Group Lead - 3.1w/in:Supporting
 - Group Lead - 3.2w/in:Supporting
 - Group Lead - 3.3w/in:Supporting
 - Group Lead - 4.1w/in:Supporting
 - Group Lead - 4.2w/in:Supporting
 - Group Lead - 4.3w/in:Supporting
 
Values
• Positionsare simply the titles, which represent the expected reach (team, department, company, etc) each employee is expected to have at Medium.These are critical to ensure consistent and therefore fair pay (each position should have a small salaray range in which everyone is paid within)• Assignmentsare a collection of responsibilities needed for Medium teams. What outcomes and impacts your teammates can expect from you• Abilitiesare the tools we value/recognize at Medium. They are the tools you need to complete those role responsiblities... HOW you do it• Valuesare the aspirations we strive for at MediumUnstated expectations are resentments waiting to happen.
Therefore, OG strives forClear Expectationswhich leads to great habits, which leads to the team flow state, which leads to theMedium Gruuv!
0 inherited Values within the 1 parent domain.
0 nested Values within the 4 nested domains.
Assignments
• Positionsare simply the titles, which represent the expected reach (team, department, company, etc) each employee is expected to have at Medium.These are critical to ensure consistent and therefore fair pay (each position should have a small salaray range in which everyone is paid within)• Assignmentsare a collection of responsibilities needed for Medium teams. What outcomes and impacts your teammates can expect from you• Abilitiesare the tools we value/recognize at Medium. They are the tools you need to complete those role responsiblities... HOW you do it• Valuesare the aspirations we strive for at Medium
More details about Assignments, including tips on how to organize themMany organizations do not delineate between an employee's Position, and the Assignments they take on.
OG believes that even though this standardization / uniformity might seem simple and harmless, it is actually devestating to clarity.
This is true for one simple reason... no two people are the same! So we should stop trying to drive more and more uniformity onto our workforce... we should lean into an individual's strengths and helpt them self-organize to form unbeatable teams!
However, this does not mean we have pure chaos. It means that if we break down the work that needs to be done into collections of responsibility, we can sanely and simultaneously give employees a unique-to-them job description and have a well-oiled team with no responsiblities falling through the cracks.
This is what Assignments are; hats you wear that represent the expectations or the specific set of responsibilities to a project, squad, team, department, or Medium as a whole.
Another downfall that organizations who do not distinguish between a person's standardized set of responsibilities (one role = your position) suffer from is that this rigidness doesn't take into account the fact that your responsiblities shift and morph over time.
Sometimes an engineer will play part of a product owner role. Sometimes a technical product manager will take on a role that is usually completed by an engineer. This is the key to clarity!
Assignments should be building blocks of clarity, that can be expertly combined to put folks in a position where they can utilize their strengths every day.
So when should you separate out a Assignment?
- Is this collection of responibilities always done by a single person? It likely should be one role.
 - Is there a realistic situation where it would be played by two separate people? It likely should be split!
 - As a manager, do you have folks that do excellent on a few of the responsiblities, but need improvement on others? Consider splitting so that you can be clear in your feedback!
 Unstated expectations are resentments waiting to happen.
Therefore, OG strives forClear Expectationswhich leads to great habits, which leads to the team flow state, which leads to theMedium Gruuv!
0 inherited Assignments within the 1 parent domain.
4 nested Assignments within the 4 nested domains.
- Builderw/in:Building
 - Executorw/in:Executing
 - Strengthenerw/in:Strengthening
 - Supporterw/in:Supporting
 
Abilities
• Positionsare simply the titles, which represent the expected reach (team, department, company, etc) each employee is expected to have at Medium.These are critical to ensure consistent and therefore fair pay (each position should have a small salaray range in which everyone is paid within)• Assignmentsare a collection of responsibilities needed for Medium teams. What outcomes and impacts your teammates can expect from you• Abilitiesare the tools we value/recognize at Medium. They are the tools you need to complete those role responsiblities... HOW you do it• Valuesare the aspirations we strive for at Medium
More details about abilitiesAbilities are be defined as the behaviors, skills, or knowledge that Medium values. These are observable, tierable, and able to be practiced deliberately given the opportunity and intention (by executing the responsiblities of different roles)
Abilities are how you do what you do, and are the key ingredient to the role and position eligibility journey you are on while at Medium.
If abilities sound like competencies from a traditional HRIS-style compentency model, it is because OG believes our take on this far exceeds what they are intended to do, and seeks to replace them.
Competency models are far less than ideal when trying to drive clairty, consistency, and fairness into a growth framework. The difference is that Abilities in this framework are observable, tierable (in that there are milestones that are used to indicate when your manager is willing to put you in situations of greater and greater impact), and awarding of the next milestone should only be done when there are clear signals that the person in question has been performing at that level for a period of time.
No treating subjectivity as a bug and trying to remove all of the subjectivity out of the process (this is impossible)... instead OurGruuv:Expect seeks to make the subjectivity the feature, especially when paired with OurGruuv:Observe. Consistent observations that help us express the one true piece of data we have... our experiences. Matched with a tool that drives clairty between you and your manager as to where you stand with your manager... not specifically what YOU are, but a way to track your perception as measured by what situations your manager would place you in.Unstated expectations are resentments waiting to happen.
Therefore, OG strives forClear Expectationswhich leads to great habits, which leads to the team flow state, which leads to theMedium Gruuv!
0 inherited Abilities within the 1 parent domain.
16 nested Abilities within the 4 nested domains.
- Accomplishmentw/in:Supporting
 - Caerer Developmentw/in:Supporting
 - Communicationw/in:Executing
 - Communityw/in:Strengthening
 - Craftw/in:Executing
 - Evangelismw/in:Strengthening
 - Foundationsw/in:Building
 - Initiativew/in:Executing
 - Mentorshipw/in:Strengthening
 - Mobilew/in:Building
 - Org Designw/in:Supporting
 - Project Managementw/in:Executing
 - Recruitingw/in:Strengthening
 - Serversw/in:Building
 - Web Clientw/in:Building
 - Wellbeingw/in:Supporting
 
Domain Hierarchy
Domains are simple. They exist to group a common set of Roles, Abilities, and/or Values.
They are usually departments, disciplines (such as design or engineering), or even teams.
Their hierarchical structure exists to help you visualize the organization of your growth framework.Unstated expectations are resentments waiting to happen.
Therefore, we believe thatClear Expectationsleads to great habits, which leads to the team flow state. Do this continuously and your team has found it'sGruuv!