Spotify's domain: Spotify

Some guiding principles

The working group began as you might expect, talking about the aspirations for the effort and comparing our own past experiences with career ladders at other companies. We talked about which of those elements made sense in Spotify's culture. Quickly, we realized that the simple career ladder proposed by the tech leadership group wouldn't make sense. Within the first or second meeting, that proposal was officially dead, and we started from scratch.

We agreed on a few principles early on:

  • This would not be a "ladder", with an up-or-out mentality. We wanted to support people who wished to maintain their current level of responsibility.
  • The basis for advancement was a demonstration of behaviors and not achievements. We wanted our framework to be a true model of professional development. It should be about who you are, and not about what you've done. In a failure-safe environment like Spotify, we didn't want to penalize people for taking big chances.
  • We wanted to support the changing of roles without punishing people for developing themselves. In other career ladders we'd seen, the role becomes a silo. Switching roles could mean a literal demotion since the requirements of a level are  tied to specific areas of achievement in a specific role.
  • We wanted this framework to reflect our team-oriented and autonomy-driven culture. Teamwork is critical to our way of working and we wanted to make sure that this was part of personal development.
  • We wanted to support both generalists and specialists. Many folks at Spotify move around the organization to develop a breadth of skills, while others like to get especially deep in specific technology areas. We wanted to support both of these types of people.
  • We believed that career progression is marked by the impact you have on progressively larger areas of the organization, your sphere of influence.

We shunned the word ladder from the start, influenced in part by our career ladder skeptics and our desire to support multiple ways of development. Struggling for a way to describe our model of career pathing, we eventually came upon the word "steps" thinking more about rocks in a stream than a staircase. The rocks would let you move side to side, or even backwards in order to eventually move forward. The framework was named Spotify Career Steps.

A set of five characteristics

We were able to build on some of the efforts that had come before in the technology organization. Specifically, the Agile Coaches guild had spent time developing a common set of core capabilities they thought each Spotify developer should have. This became the basis for the areas of development of our framework. We then added two additional areas to reflect professional development within our culture.

The five characteristics of Spotify employees that we identified were:

  • Values team success over individual success
  • Continuously improves themselves and their team
  • Holds themselves and others accountable
  • Thinks about the business impact of their work
  • Demonstrates mastery of their discipline

I will go further into these characteristics in the next part of the series.

A set of four steps

There was some discussion around the number of "levels" to have. We decided that it was easier to add more levels later than to remove them if we created too many. Given that we had decided that being more senior meant being a resource for larger and larger parts of the organization, mapping "levels" to our levels of organization seemed like a reasonable first approach.

The four steps of career development at Spotify that we decided on were:

  • Individual -- at this level, you are new to working and are figuring out how to be productive and contributing member of the company.
  • Squad / Chapter (these are the teams that people primarily belong to) -- you are now a contributing member of a team and are a resource for the people you work with every day.
  • Tribe / Guild (these are the larger teams organizationally or functionality that people are part of) -- now you are a resource beyond your immediate team. Either because you have depth in a technology (and help others or other teams around that technology); because you are skilled at solving difficult problems that span teams; or because you can be counted on to lead other developers in your tribe to solve large cross-squad problems.
  • Technology / Company (the highest levels of the organization) -- The developers at this level are resources for the entire company based on their technical and leadership skills and are expected to spend a significant amount of their time working across the organization.

A map of career growth at Spotify

The five characteristics and four steps created a map of professional development at Spotify. We then spent significant amounts of time defining each of the characteristics for each step.

One decision we made that I think was especially good was that mastery was only one of the five characteristics. That is the only area where we differentiate based on role (since mastery as a coach is significantly different than mastery as a mobile developer). This also helped reinforce that switching roles didn't necessarily mean moving backwards in your career development as most of the characteristics were universal.

Much of the focus of the feedback we got was on the content of this map. This makes sense because this was essentially where the model got concrete for people. We were defining would be expected of employees in technology, after all.

A group editing process

We settled into a rhythm of working in a shared google document, mob editing. Non-pair changes followed our code review guidelines: an edit was made in the doc as a suggestion, and two separate approval comments to the suggestion were needed to accept the change.

The current version of the document (we would "fork" or create a new copy of the document on a regular basis) was then shared with progressively larger groups of managers and employees to get their feedback. Their comments and suggestions were then incorporated, after which a new version would be shared.

The rounds of feedback and tweaking were extremely valuable. We realized that we weren't doing enough to support introverts in the initial versions, for example, and had to go back and make significant changes.

After several months of revisions and sharing to larger and larger groups, we finally created an official RFC version, which was then shared with the entire organization for comments, and suggestions.

This particular collaborative editing and progressive review process ended up working quite well. There were some improvements that I will recommend in the third part of this series.

At this time, I want to recognize the initial working group that was instrumental in the creation of the process and the document. We worked so well as a group that in retrospect it is hard to remember whose ideas were whose. Any idea that any of us had was definitely improved by the others involved. While I am writing about what we did, the work itself was a true collective effort by Chris Angove, Daniel Prata, David Poblador I Garcia, Eli Daniel, Henrique Imbertti, Jessica Joelsson, Kevin Goldsmith, Kinshuk Mishra, Olof Svedström, and Will Meyer.

-- Pulled from this article explaining Spotify Career Steps

  Positions 

• Positionsare simply the titles, which represent the expected reach (team, department, company, etc) each employee is expected to have at Spotify.
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 Spotify teams. What outcomes and impacts your teammates can expect from you
• Abilitiesare the tools we value/recognize at Spotify. They are the tools you need to complete those role responsiblities... HOW you do it
• Valuesare the aspirations we strive for at Spotify

OurGruuv::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 Spotify 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" games
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 theSpotify Gruuv!
0 Positions directly associated with this domain.
    0 inherited Positions within the 0 parent domains.
      7 nested Positions within the 6 nested domains.

        Values 

      • Positionsare simply the titles, which represent the expected reach (team, department, company, etc) each employee is expected to have at Spotify.
      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 Spotify teams. What outcomes and impacts your teammates can expect from you
      • Abilitiesare the tools we value/recognize at Spotify. They are the tools you need to complete those role responsiblities... HOW you do it
      • Valuesare the aspirations we strive for at Spotify
      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 theSpotify Gruuv!
      0 Values directly associated with this domain.
        0 inherited Values within the 0 parent domains.
          0 nested Values within the 6 nested domains.

              Assignments 

            • Positionsare simply the titles, which represent the expected reach (team, department, company, etc) each employee is expected to have at Spotify.
            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 Spotify teams. What outcomes and impacts your teammates can expect from you
            • Abilitiesare the tools we value/recognize at Spotify. They are the tools you need to complete those role responsiblities... HOW you do it
            • Valuesare the aspirations we strive for at Spotify

            Many 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 Spotify 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 theSpotify Gruuv!
            0 Assignments directly associated with this domain.
              0 inherited Assignments within the 0 parent domains.
                5 nested Assignments within the 6 nested domains.

                  Abilities 

                • Positionsare simply the titles, which represent the expected reach (team, department, company, etc) each employee is expected to have at Spotify.
                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 Spotify teams. What outcomes and impacts your teammates can expect from you
                • Abilitiesare the tools we value/recognize at Spotify. They are the tools you need to complete those role responsiblities... HOW you do it
                • Valuesare the aspirations we strive for at Spotify

                Abilities are be defined as the behaviors, skills, or knowledge that Spotify 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 Spotify.

                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 theSpotify Gruuv!
                0 Abilities directly associated with this domain.
                  0 inherited Abilities within the 0 parent domains.
                    9 nested Abilities within the 6 nested domains.

                      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!
                    All Parents:
                      All Children: