Building a technical career path at Spotify
你好世界 (Hello World in Chinese)
Hello everyone! I hope your summers are going well. We’ve got full-on Olympic Fever in my house. It is amazing to see people who have worked and trained for years or decades compete on the world stage. While you love seeing people win, I’m always amazed by the joy often displayed by the folks who don’t make it to the podium. To me, that is a lesson in itself to take pride in your accomplishments even if you do not achieve your goal.
If you are new to the newsletter, please check out the archives on Substack. Of course, you can always buy the book.
New Blog Post
Creating the newsletter or podcast every week and promoting the book has seriously impacted my blogging frequency, but I published a new blog post this week: “You should give that talk or write that blog.” It answers the questions I get quite often from folks considering launching a blog or speaking at a conference.
About this newsletter
If you are new to this newsletter, here’s what makes it unique. Every two weeks, I share a chapter from my book It Depends: Writing on Technology Leadership 2012-2022, which Unit Circle Press released in March. These chapters are not in sequential order, but each one is a standalone piece. In addition, a podcast serializes the audiobook in order, released in the alternate weeks from this newsletter.
The Latest Podcast
The latest episode of the podcast is “Addressing the challenges of partially distributed engineering teams.” Partially distributed engineering teams are teams where some people are working together in an office and others are working remotely (or in a different office). These days, this might also include teams where people are in an office some days each week and working from home on the other days. The difficulties these teams face are quite different to the issues that fully distributed or fully co-located teams face.
You can get the episode at Apple Podcasts, Spotify, YouTube, directly via the RSS Feed, or wherever you get your podcasts (see pod.link for a more extensive list).
Drop me a line
I’m always eager to hear from you. If you have questions, want a signed copy, or simply want to say ‘hi!’, please email me at contact@itdependsbook.net. You can also share your thoughts on Substack or the various podcast platforms. Your feedback is invaluable, and I look forward to hearing from you.
About this week’s chapter
This week’s chapter is the first of three about my experience leading the effort to create Spotify’s first engineering career path when I was a Director of Engineering and VP there.
The three chapters were originally presented sequentially as articles on Spotify’s Engineering Blog, and they are still there if you want to see the originals. From the process, I learned an amazing amount about how to lead an inclusive company-culture-aligned culture-change effort. Those lessons still inform my approach to leadership today.
Would I suggest that every change you want to make in your organization undergo such an exhaustive process? Decidedly not. Spotify's situation was unique; we had a well-defined engineering culture with hundreds of engineers who had been at the company for multiple years. The original HR approach to this (and, in fact, what they used for other departments) was a copy-and-paste effort that was counter to the existing culture. We knew that unless we wanted to drastically change who we were (almost nothing can impact a company culture more than a career ladder), we had to take the reins and make something ourselves, and that was what we did.
Would this be a good way for you to build a career pathing framework at your company? As always, It Depends on your existing company culture, size, and age. Do I think there are techniques here that you may want to use for change within your company? Absolutely.
This is chapter 32 of It Depends.
Building a technical career path at Spotify
Originally published on February 8, 2016
Spotify launched a career path framework for individuals last year. Since then, I’ve spoken to leaders at several other companies about it. This seems to be a bit of a hot topic, so I’ve decided to write about our model and how we arrived at it. Hopefully, this may be useful to your company.
The road is more important than the destination
If you are trying to figure out how to approach career paths in your company, it will be tempting to take ours (or someone else’s) and just use that, cargo-cult style. I would highly recommend against this though. How a person matures within your company is a critical element of your company’s culture. As I’ve written before, your culture is unique; a career path framework from another company will not build on or reinforce the values that make your company great.
When should you create a career path framework?
I watched a panel on career pathing for tech startups a few years ago. One of the speakers argued that you should create a career ladder later than you think you need it, a little bit after it is really necessary. I think this is excellent advice for a few reasons. A career pathing framework is unnecessary in the early days of a company and creates a superfluous process that can be as much of a distraction as a benefit. One of the great things about the early stages of a company is that the roles people have are constantly evolving. Formalizing them too early can stunt the natural development of the organization and the individuals within it.
Eventually, as a leader, you will start hearing about people wanting to know their future at the company or how they can take on more responsibility. When this shifts from an occasional idle question to more of a groundswell, you know it is time to create something more formal.
At Spotify, we’d waited almost eight years before deciding that it was time to create a career pathing framework. The company’s anti-hierarchical culture probably was a large part of the reason for not seeing this as needed. Some of the issues we had when we rolled it out were likely because we waited too long.
A few things made it clear that it was now past time to do this. There was no formal way to acknowledge career growth (via title, salary, or responsibility increases) in the individual contributor role. There was a strong belief within the organization that the way to be “promoted” was to become a Chapter Lead (line manager) or a product owner. In fact, switching to these roles at Spotify is more akin to a career change (to management or product) than it is to developing as an individual contributor.
In the spring of 2014, at a technology leadership offsite, we decided to create a “career ladder” for Spotify and quickly drew up something simple to start with. I was made the Road Manager (driver/leader) of the effort to flesh it out and then roll it out to our large organization. It seemed like a straightforward task at the time. That assumption turned out to be very naïve.
Defining technical career progression, the Spotify way
At other companies, especially companies the size of Spotify, creating a career ladder would be something that would probably originate from the human resources organization. However, within the technology organization at Spotify, we tend to take more direct responsibility for the things that impact our culture. We feel strongly that our culture is an essential advantage in building our product. So, in Spotify Tech, we take these kinds of projects very seriously and are vocal and involved partners with our HR peers, even to the extent of driving some of these programs ourselves in partnership with HR instead of the other way around.
The goal was to create a framework that would make sense with our culture and work for employees from diverse backgrounds, in the US and Sweden, at all levels of experience, and in many different (some unique) roles. Clearly, this would require a team that could represent, as much as possible, the whole organization.
Building a working group that is representative of the organization
I put out a call to the technology organization for people who were interested in solving this challenge and who were also willing to commit the time to do it right. From the responses I received, I selected the group based on location (to maximize the number of offices represented) and on the role of the volunteer (to have a good cross-section of technology).
I also tried to get diverse opinions on the concept of career development. We had a few people who had been vocal in their skepticism of career ladders in general. I wanted to make sure that those voices were present as well.
We were lucky enough to have our Chief Human Resources Officer (CHRO) join for several of the early meetings. Naturally, our HR Business Partners for technology were also involved. Their domain expertise was critical throughout the process.
Doing it right takes a lot longer than you’d expect
At first, I thought that a few months of twice-a-week meetings would be sufficient to conceive and launch the program. That turned out to be ridiculously optimistic. We were able to largely define the framework in a few months, but to create something like this, in an organic, bottom-up manner, for a large organization, requires many cycles of feedback gathering and incorporation. In the end, it took nearly six months from the beginning of the working group to the official Request For Comment (RFC) document. It is now over 18 months since that initial working group meeting, and it still feels like we’re getting used to having the program in place, even as we prepare for the second iteration. We have spent a lot of the last year supporting the rollout and adoption of the framework.
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 changing 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 ensure 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 your impact 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 to describe our career pathing model, 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 backward, to move forward eventually. 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 chapter.
A set of four steps
There was some discussion around the number of “levels” to have. We decided it was easier to add more levels later than remove them if we created too many. Given that we had already 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 a 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), you are skilled at solving difficult problems that span teams, or 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. They 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 step's characteristics.
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 backward 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 where the model became concrete for people. We were defining what 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 proposal were needed to accept the change.
The current version of the document (we would “fork” or create a new copy regularly) 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 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 with progressively 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 creating the process and the document. We worked so well as a group that, in retrospect, it was hard to remember whose ideas were whose. Any suggestion that any of us had was improved by the others involved. While I am writing about what we did, the work itself was a truly 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.
Upcoming talk
I’m giving a talk, “The path from Director to CTO: How to follow it, or how to mentor it,” at the LeadingEng conference in New York City in September. You can use the code “DISTROKID” to save 10% on your registration! More information and registration: https://leaddev.com/leadingeng-new-york
Thanks again for reading! If you find it helpful, please share it with your friends.
Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores