Things We Learned Creating Technology Career Steps
Aloha Honua (“Hello World!” in Hawaiian)
It was great to meet a few of you at the LeadingEng conference! I think my talk went well; I got some great comments afterward. I especially enjoyed the talks from Neha Batra, Nivia Henry, Annyce Davis, and Ashley Miller, but all the talks and workshops were good. The slides from my talk are available here, and I plan to do a blog version when I can. Thanks to those who came to the book signing as well. It was outstanding to meet you. I must admit I still find signing books a bit weird, but I’m getting better at it.
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. Please check out the archives on Substack.
The Latest Podcast
The latest episode of the podcast is “Writing Useful Performance Reviews: Assembling the Data.” It is the first chapter in a four-chapter sequence on writing a performance review. While you might not be thinking about doing performance reviews yet, now is a great time to start collecting data, so you don’t need to scramble when review time comes.
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 third in a series about creating Spotify’s first Technology Career Path Framework. In this chapter, I share the lessons we learned along the way, especially the mistakes we made, the things that went well, and the things we should have done differently.
I learned so much about leading that effort in terms of how to do culture change and inclusively execute cross-team projects. Since writing this chapter, I have initiated similar career pathing exercises at Avvo, Anaconda, and DistroKid. While I’ve never done it exactly the same way, the lessons from Spotify were beneficial. If you ever have the opportunity to be part of creating a career ladder or pathing, hopefully, these chapters will be helpful to you as well.
This is chapter 34 of It Depends.
Things We Learned Creating Technology Career Steps
Originally published on February 22, 2016
The Launch to the Organization
We launched the request for comments (RFC) version of Career Steps at a special town hall for Spotify’s entire technology department in December 2014. Leading up to the town hall, we’d done several reviews of earlier iterations with increasingly larger groups from the organization, and we’d given training in Steps and conversations around Steps for every manager in Technology. We left plenty of time for questions in the presentation, which was good. We prompted people to read the document, ask questions in the document, via a mailing list or a Slack channel that we set up, or ask their manager. In retrospect, we should have followed up with some more opportunities to talk to our working group face-to-face. Most of the organization would have been reading the document for the first time after the town hall, and some had only read earlier drafts.
The Relationship between Steps and Compensation
One area was still incomplete when we launched Steps, and this incompleteness was an issue that challenged us for a long time. The vague area was the connection between your step and your salary. We had asserted that there was a connection, but when we launched the framework, our Compensation and Benefits team had not finished reviewing how this should work. We knew the generalities but not the details. This lack of clarity left us in a very challenging situation since we had given Steps a critical connection to the individuals in the organization, but we couldn’t yet explain it. We knew that there needed to be a connection between Steps and compensation. Suppose we were saying that Steps embodied what we valued from the members of our organization, but the salary of those members was determined entirely separately. In that case, we essentially contradicted ourselves and undercut the framework's effectiveness.
The lack of clarity around compensation created tension in adopting Steps with some individuals in the organization. Unfortunately, the connection between salary and step wasn’t resolved until nearly a year later. This meant that the first salary review after launching Steps couldn’t use the framework. This was a failure on one level, but it was also positive in some ways. Since Steps were very new, having people get a step and immediately have it affect their salary might have led to many bad feelings; by delaying the tie to compensation, people had time to adjust to the system and potentially change their step before their first salary review.
Our inability to talk concretely about Steps and salary also created misperceptions about how this would work. We had to spend much effort working through these only to have them reappear in mail threads and discussions repeatedly. The most persistent misperception was that the only way to change your salary was by changing your step. This naturally caused much concern that was difficult to dispel until the Compensation and Benefits team had completed their work. Our C&B team did a stellar job of creating a fair and very progressive system that allowed good overlap in salary ranges between the steps and a lot of headroom. Since that has been completed, we hopefully have put many of the concerns to rest, especially as we are now using Steps as part of our current salary review.
Behavior Versus Achievements
We made an explicit decision around Career Steps that your behaviors, not your achievements, characterized career growth. This is counter to the way career advancement works at many other companies. It was something that we not only felt strongly about; it was something that we were proud of. In a culture that encourages innovation, failure (and learning from failure) is a natural occurrence. If we only rewarded success, we were punishing failure and discouraging risk-taking. We also wanted to encourage real personal growth and not a culture of checking off achievements on a list and expecting a promotion. This naturally created some ambiguity around the requirements for each step. The working group embraced this ambiguity as a way of giving managers some room to make decisions and also to encourage discussion between the individual and their manager.
In retrospect, our approach was a bit naive in a few ways. While we, as an organization, are very comfortable with ambiguity in many areas, recognizing a person’s career advancement was personal and had personal consequences. Some individuals were very uncomfortable with this ambiguity and would have preferred more concrete requirements around promotion. Another group thought even the examples given were too much of a checklist. This is still something that we are working through.
We seek ways to support those in the organization who want more clarity without being too prescriptive. We have discussed creating lists of (anonymized) examples of the behaviors. The concern is that this would lead to people treating the examples as achievements to be checked off instead.
This has been a particularly thorny path to traverse with some very vocal minorities, but most of the organization seems to have understood the concept.
Having Greater Impact Means Not Working on a Team?
There was one aspect of the Steps Framework that we hadn’t anticipated being controversial and didn’t come up often in our earlier reviews of the document. This was the aspect of Steps being a reflection of your sphere of influence. The core idea around this was that as you increase your professional maturity, you will naturally become a resource for ever more extensive parts of the organization, either through your technical leadership, deep technical skills, or general problem-solving ability. This increasing sphere of influence brings new, broader responsibilities with it. This aligned well with our experiences in the working group at Spotify and other companies. For some individuals, the idea that they couldn’t move to a Tribe/Guild step without working outside their squads was a concern.
At Spotify, we point to the squad as the central place where work gets done. It is at the top of our inverted servant-leadership hierarchy. The question we repeatedly heard was: Why couldn’t someone just be better at what they do and get “promoted” for doing the same role if they were adding value to their team? I think this was a case where we could have presented the reasoning for this decision in a better way in the document.
Not Enough Chances for Advancement?
When deciding on the number of steps to create, we decided to keep the number relatively small. The thought was that it was easier to add more than it was to remove some. Four steps are not many changes in a potentially forty-plus-year career. The expectation was that people would potentially stay at a step for a very long time. This was very discouraging for some people who felt that they would never be “promoted” in their Spotify career.
Here, we missed the understanding that a segment of our organization wanted the opportunity for recognition of increasing advancement. We had not been doing this before in any respect, so we hadn’t considered that it was something that a group desired. We were wrong about that, and with Steps, we weren’t giving that group enough opportunity to get it. This problem was a significant oversight since we knew that part of what encouraged people to make career changes to management or the product team was this lack of recognition. As a result, recognition is an active discussion area for successive iterations of the framework.
Assigning Steps
After the town hall presentation introducing Steps, we gave people some time to respond to the RFC version of the document and feedback to the working group. In January, we started the process of making sure every individual contributor in the technology organization had a step. Initially, we left the process up to each tribe. This was a mistake. The tribes needed more guidance on how to make this process work. Luckily, at Spotify, we are quite good at figuring these things out and sharing good ideas. The Infrastructure and Operations Tribe came up with the suggestion that each individual should use the Steps document to make a self-assessment of which step they should be on, then have a discussion with their manager about where they agreed and disagreed. This was quickly adopted as a good process across most of the organization.
Once every chapter lead completed these discussions within each tribe, the tribe would meet to ensure that each manager was assigning steps to their employees similarly. Functional managers in different parts of the organization also met to do a similar exercise. These synchronizations helped ensure we were fair and consistent across the entire organization. Before the steps for individuals were finalized, the Tribe Leads and CTO met to go over all the recommendations for the Tribe/Guild and Tech/Company steps. This served two very valuable purposes. It assured consistency across the entire organization for the individuals on these steps. It also made the senior technical leadership aware of who these individuals were and what their managers thought they contributed to the organization.
The process of assigning steps to individuals was completed in March, but we also had a problem here. Adding steps into our HR systems was a more significant challenge than our HRIS team had anticipated. So, the steps were assigned in the spring but weren’t readily visible to employees, their managers, or HR until the fall. This also meant we had difficulties tracking which teams were behind in submitting steps for their employees. We couldn’t quickly run reports to see how steps were distributed as well.
Once we finally worked it out, we found we were missing a lot of data. Some employees had never been assigned a step. Some employees had transitioned between teams or roles, and their step hadn’t been communicated. Steps hadn’t been integrated into the onboarding process, so many new employees had never gotten their step. There were a bunch of other issues as well. These had to be rectified before we could do our salary review. The lack of visibility also contributed to an “out of sight, out of mind” issue where some people or managers didn’t do much with the framework after the initial discussion.
In retrospect, the working group should have taken ownership of this until the issues with the HR system were handled. Unfortunately, there was some poor communication around the timeline for the fixes, and we thought that the problem was solved.
Positive Results
Once the Steps Framework was launched, we started getting strong positive feedback from the organization in addition to the concerns noted above. Many of our line managers (Chapter Leads) were previously individual contributors; they especially appreciated having a structure to help frame personal development discussions. Also, many individuals told us how it was good to have some structure and understanding about how to grow at Spotify. The working group collected feedback in multiple ways, including interviewing employees in different offices.
We wanted to have some real data in addition to our anecdotal evidence to have greater confidence that we were adding value. Some robust supporting data came from our yearly Great Place to Work survey, where in the Technology Organization, the “Management makes its expectations clear” measurement increased by four percentage points year over year, and the “I am offered training or development to further myself professionally” measurement increased by six percentage points. Several things could have impacted these measurements, but we had a reasonable belief that Steps had a part in these increases.
While we had started our effort with the desire to be data-driven, as we went to measure our impact, it was clear that we were not as rigorous as we should have been. We should have started the entire effort with some qualitative numbers on how the organization felt about the support they had for personal development driven by a survey or poll. This would have given us better metrics to measure ourselves against and would help us guide future iterations. This is something that the working group is actively pursuing.
Loss of Focus
Once the steps were assigned, the working group started moving into a less active phase. There was a strong sense of accomplishment but also weariness. From meeting twice a week and working on the document in between the meetings, meeting with individuals and teams to discuss steps, training the managers, launching the effort, and supporting the initial rollout, there had been a tremendous amount of work done. However, this wasn’t anyone’s main job; we were all moonlighting to do this. Also, during this time, many of us were involved in a large project demanding our focus. It felt like we had completed our mission, and it was time to move on to new things. Unfortunately, we were wrong.
In this post-launch phase, we made some of our biggest mistakes. We’d launched the framework, but our support for it was largely put on hold. We hadn’t established the necessary structures to train new employees in Steps. We stopped sending updates and communicating about what was happening around Steps. This led to many questions and confusion in the organization around what was going on with the effort.
Eventually, we realized our error. At that point, we had to do some cleanup and rebuilding work to get the program back on track. Luckily, the HRIS team had done their thing during this time, as had Comp and Benefits. We also had our first Steps-enabled salary review to do. We were also very fortunate that parts of the organization had started to embrace Steps and were using it in several ways to support individual growth through structured training and formal or informal mentoring. These other efforts helped keep Steps from being forgotten by the technology team.
The working group had been inactive too long at this point. Most of the members had new commitments. For a time, we continued moving the effort forward with the participation we had, but it was clear that we needed to move into a new phase, which would require a new group.
Current Status
Currently, the Working Group is reforming with new members. The current members are engaged with our Human Resources team on training in Steps for Managers and Employees. We’ve also started working on the next iteration of Steps, addressing some lessons learned and feedback received now that Technology has been living with the framework for a while. The new group will have a few members from the first version, which will give some continuity to the effort and provide some history, but the rest of the group will be new, which should inject some new ideas and approaches to the work.
The leadership of the technology organization has been doing a lot to support the framework. We are actively giving more responsibility and opportunities to our Tribe/Guild step employees, and we are also looking to grow our Squad/Chapter step employees to the next step if that interests them.
We’ve had several promotions between steps during the year, which is a serious measure of validation. That would be a significant issue if people weren’t moving between steps.
Additionally, in my organization, two managers who were also highly skilled technologists moved back to being individual contributors. They were excited by the possibility of being technical leaders without being people managers.
Many tribes are now considering their Tribe/Guild step people as incremental members of their squads so that when they are helping outside their squad, they don’t adversely affect the ability of the squad to get its work done.
Lessons
We learned many lessons in the creation of Steps. If there was one thing that I think was paramount, it was that this ended up being a lot more like Culture Change than we expected it to be. We thought we were creating something to support and reinforce our company culture. In fact, we were specifying something where there had been only people’s conceptions before. So, while we feel that we did create something generally well-aligned and supportive of the Spotify culture, it was still a change for many individuals in the organization. If we had realized that, we would have treated the rollout more like a Culture Change effort and used more of those techniques in our rollout plans.
Another major lesson I didn’t capture above was that we didn’t have our long-term support plan in place. We did put together a plan around supporting the effort, but we created that plan after the launch of Steps. As mentioned above, the working group was tired from getting the framework to that point. It would have been much better to think through the long-term support needs of the work closer to the beginning of the effort and then adjust them later as we learned more.
I think that the process of using increasingly large groups to give feedback was quite good. It resulted in a much better outcome than if we had just generated the framework in a smaller, more isolated group. However, we primarily used the organization's managers and leadership to collect feedback. We would have benefited from including groups of individual contributors, especially if we could include the same people in multiple reviews of the document, just as we did with the coaches and leadership.
Once the Steps Framework was starting to solidify, we did a “simulation” to see what the potential distribution of steps in the organization might be once we rolled it out. The committee had what we thought was an ideal distribution based on Spotify’s hiring strategy and what would make sense for an organization of our size. We asked each manager to estimate (in a non-binding way) which step each of their employees was on. We then combined these to get a master histogram of what the distribution might be. Luckily, we got a distribution reasonably close to what we were hoping for. So, it was a good validation of the Framework at that point. This also had the effect of making each manager have to apply the Framework in a concrete way, which also generated more good feedback.
I want to reinforce the issues we encountered by underestimating the efforts required from Compensation and Benefits and our back-office systems to support this work. While we involved HR from the onset, we didn’t consider the timelines for the structural support to make the whole effort work. We should have involved those groups from the beginning, which would have avoided difficulties later.
Conclusions
I learned a tremendous amount in leading the effort around career pathing in the technology organization at Spotify. While I spent more time thinking about motivating and incentivizing employees than ever before, I also learned much more about my company and coworkers than I had expected. I was also reminded clearly how different my path had been from any of my fellow members of Technology. I had to put reasoning and explanation behind things I had learned experientially, which was incredibly valuable. Many of our employees had never previously worked at a company with career path support. Those with experience at other companies with career path frameworks had not seen anything similar to what the working group had created. As I talked with people individually and in small groups, I found better and better ways to articulate the reasoning behind the things that had just seemed obvious to us as we wrote the document. This process helped us immeasurably improve the document and hopefully helped clarify what I’ve written about in these chapters.
Creating this framework also raised some issues in the organization that we must address as a group. The Swedish word “lagom” characterizes the culture of Spotify. We try to see each other always as equals. We encourage people to challenge their leaders if they don’t think they are right. As the Steps document reflects, we put a higher value on strong teams than on strong individuals. We also imbue our teams and our individuals with autonomy in how they do their work. We tried to incorporate all of these ideas in our Career Steps. When people in the organization wish for more recognition and status to be reflected in our career pathing, is this counter to our culture, or is this indicative of the culture changing? What is the role of career pathing in enforcing a desired culture rather than supporting it? We’ll continue to look at these questions as we evolve Career Steps.
Spotify is a unique company with a singular culture. The specifics of what we created and the lessons that we learned may or may not apply to your company. In aggregate, hopefully, you will find our experiences and learnings valuable as you think through how you want to do similar programs at your company.
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