Category: Spotify

Things We Learned Creating Technology Career Steps

This is a repost from: https://labs.spotify.com/2016/02/22/things-we-learned-creating-technology-career-steps/

This is part three of a three-part series on how we created a career path framework for the individual contributors at Spotify. Part one discussed the process we used to formulate the framework. Part two contained version 1.0 of our framework. In this segment, I’ll talk about the lessons we learned rolling out the framework to the technology organization. If you haven’t read the first two parts, I suggest that you read those first before proceeding with this one.

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 trainings in Steps and conversations around Steps for every manager in Technology. In the presentation, we left plenty of time for questions, 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 to 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

There was one area that was still incomplete when we launched Steps, and this turned out to be an issue that challenged us for a long time. This was the connection between your step and your salary. We had asserted that there was a connection, but at the point that we launched the framework, our Compensation and Benefits team had not finished their review of how this should work. We knew the generalities, but not the details. This 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. If we were saying that Steps embodied what we valued from the members of our organization, but the salary of those members was determined in a completely separate way; we were essentially contradicting ourselves and undercutting the effectiveness of the framework.

The lack of clarity around compensation created some tension in the adoption of 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 wasn’t able to use the framework. On one level this was a failure, but in some ways this was also positive. Since Steps were very new, having people get a step and then immediately have it affect their salary might have lead to a lot 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 around how this would work. We had to spend a lot of effort working through these only to have them re-appear in mail threads and discussions again and again. 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 on 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 now using Steps as part of our current salary review.

Behavior Versus Achievements

We made an explicit decision around Career Steps that career growth was characterized by your behaviors and not by your achievements. 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, then we were consequently 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, this was something that was personal, and had personal consequences. Some individuals were very uncomfortable with this ambiguity, and would have preferred more concrete requirements around advancement. There was another group that thought even the examples given were too much of a checklist. This is still something that we are working through.

We are looking for ways to support those in the organization who would like 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 the majority 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 naturally will become a resource for ever larger parts of the organization; either through your technical leadership, your deep technical skills, or your general problem solving ability. This increasing sphere of influence brings new, broader, responsibilities with it. This was well aligned with our own personal 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 that work gets done, it is the top of our inverted servant-leadership hierarchy. The question we heard repeatedly was: why couldn’t someone just be better at what they do and get “promoted” for doing the exact same role if they were adding value to their team? I think that this was a case where the we could have presented the reasoning of this decision in a better way in the document.

Not Enough Chances For Advancement?

When deciding on the number of steps to create, we had decided to keep the number relatively small. The thought being that it was easier to add more than it was to remove some. Four steps is 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 turned out to be 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 had been wanting the opportunity for recognition on increasing advancement. We had not been doing this before in any respect, so we hadn’t considered that it was something that a group really felt the absence of. It turns out that we were wrong about that and with Steps we weren’t giving that group enough opportunity to get it. This was a big oversight since we knew that part of what had been encouraging people to make career changes to management or product was this lack of recognition. This is an active area of discussion for next 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 definite mistake. The tribes needed some more guidance on a good way 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: 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 these discussions were completed in each tribe, the tribe would meet to make sure that each manager was assigning steps to their employees in a similar way. Additionally, functional managers in different parts of the organization also met to do a similar exercise. These synchronizations helped make sure that we were being 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 ended up serving two very valuable purposes: it assured consistency across the entire organization for the individuals who were on these steps, and it made the senior technical leadership aware of who these individuals were and what their manager thought they contributed to the organization.

The process of assigning steps to individuals completed in March, but here we also had a problem. The effort of adding steps into our HR systems ended up being a bigger challenge than our HRIS team had anticipated. So, the steps were assigned in the spring, but weren’t easily 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 easily run reports to see how steps were distributed as well.

Once this was finally worked out, we found that 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. All of 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 were always thinking that the issue was nearly 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 doing interviews with employees in different offices.

We had wanted to have some real data in addition to our anecdotal evidence to have greater confidence we were actually adding value. Some strong 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 4 percentage points year over year, and the “I am offered training or development to further myself professionally” measurement increased by 6 percentage points. There were several things that could have impacted these measurements, but we had reasonable belief that Steps had a part in these increases.

While we had started our effort with the desire of being 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 to guide future iterations as well. This is something that the working group is actively pursuing.

Loss of Focus

Once the steps had been 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 that also was demanding our focus. It felt like we had completed our mission and that it was time to move onto new things. Unfortunately, we were wrong.

In this post-launch phase is where 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 put the necessary structures in place to make sure that new employees were being trained in Steps. We stopped sending updates and communicating about what was happening around Steps. This lead to a lot of 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 during this time, the HRIS team had done their thing, 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 really started to embrace Steps and were using it in several ways to support individual growth through structured trainings and formal or informal mentoring. Having these efforts emerge helped keep Steps from completely being forgotten in 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’re also starting working on the next iteration of Steps addressing some of the lessons learned and feedback 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 is what they are interested in.

We’ve had several promotions between steps during the year; which is a serious measure of validation. If people weren’t moving between steps that would be a major issue.

Additionally, in my own organization, two managers who were also extremely skilled technologists moved back to being individual contributors. They were excited by the possibility of being able to be technical leaders without being people managers.

Many tribes are now starting to consider 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 for 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 would be. Our view was that we were creating something that would support and reinforce our company culture. In fact, we were specifying something where there had been only people’s own 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 much more like a Culture Change effort, and used more of those techniques in our rollout plans.

Another major lesson that I didn’t capture above was that we didn’t really have our long term support plan in place. We did put together a plan around supporting the effort, but that plan was created after the launch of Steps. As I mentioned above, the working group was pretty tired from the effort of 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 definitely resulted in a much better result than if we had just generated the framework in a smaller, more isolated, group. We primarily used the managers and leadership of the organization to collect feedback though. We would have benefited from including groups of individual contributors as well, especially if we could include the same people in multiple reviews of the document, just as we did with the coaches and leadership.

There was something that I neglected to mention in the first post that I thought was quite valuable. Once the Steps Framework was starting to solidify, we did a “simulation” to see what a potential distribution of steps was 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 for us, we got a distribution fairly 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.

In addition to the lessons in the rest of this document, I want to reinforce the issues we encountered by underestimating the efforts required from Compensation and Benefits as well as our back-office systems to support this work. While HR was involved from the onset, we didn’t really take into account 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

In the process of leading the effort around career pathing in the technology organization at Spotify, I learned a tremendous amount. While I obviously spent more time thinking about how to motivate and incentivize employees than I ever had before, I also learned a lot more about my company and my coworkers than I had expected to. I was also reminded clearly how different my path had been than any of my fellow members of Technology. Things that I had learned experientially, I had to put reasoning and explanation behind and that was incredibly valuable. Many of our employees had never been at a company with career path support at all before. Those with experience at other companies that had career path frameworks, had not seen anything like 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 helped us improve the document immeasurably and hopefully also has helped clarify the things that I’ve written about in these posts.

The effort of creating this framework also raised some issues in the organization that we’ll need to address as a group. The culture of Spotify is characterized by the Swedish word “lagom.” 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 is reflected in the Steps document, we put 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? These are questions we’ll continue to look at 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 own company.

Spotify Technology Career Steps

This is a repost from: https://labs.spotify.com/2016/02/15/spotify-technology-career-steps/

This is part two of a three part series on how we created a technical career path for individuals at Spotify and what we learned in the process. This post contains the actual version one of our Technical Career Steps. This is the complete document, so it is a bit long. In the next and final post, I will talk about the mistakes we made along the way and the good and bad lessons we learned. If you haven’t read the first segment, you should start with that.

Table of Contents

  1. Motivation behind the Steps Framework
  2. Career Steps for Tech employees
  3. FAQ

Motivation behind the Steps Framework

As Technology within Spotify has grown over the years we have learned that people striving to increase their impact often wanted to become a Chapter Lead or Product Owner even if they might have preferred the role of an individual contributor engineer. Everyone in Spotify Tech should have a way to grow their careers and expand the impact of their -work no matter what role they play. A shift into a Chapter Lead or PO position is not necessary.

The Steps Framework provides a way to do this.

The Steps Framework

As your career evolves within Spotify, you will likely take on a variety of roles, in a variety of contexts. You will work with multiple teams, on multiple projects, perhaps in very different domains or perhaps in a smaller area of specialty. You will build capabilities and mastery. Your impact on Spotify will grow, and so likely will your sphere of influence.

Your career development within Technology will therefore be a journey — sometimes sideways, sometimes forwards, and always flexible. There are some common patterns in the series of roles people decide to take on, and in which disciplines and expertise areas they focus, but this is not rigidly defined. It is up to you, with the help of your manager, to choose a path that aligns your interests and the company’s, and that helps you develop, grow, and meet your own unique personal goals.

Throughout this journey, as you gain experience and develop your skills, you will have greater and greater impact. In other words, the degree to which you contribute to the success of Spotify — its team and its mission — will grow over time.

The Steps Framework  is designed to provide you with:

  • The opportunity to explore new roles, skills, contexts and disciplines over time, avoiding a specific, rigidly-defined “track”
  • A way to understand your progression toward greater and greater impact, independent of specific role or discipline
  • A set of well-defined expectations corresponding to defined points in this progression

In practice: Disciplines, Roles & Steps

In practical terms, supporting this development journey requires a more complex framework than a typical vertically-oriented hierarchy or “career ladder”. There are three key elements in the Steps Framework:

  • A Discipline is a domain of expertise and impact. Examples include:
    • coaching
    • software development
    • testing
    • project management
  • A Role is a way in which you engage with a team, a project, or a discipline. They are not all formally defined, but there are some common ones. Examples include:
    • software engineer
    • tester
    • road manager
    • technical product owner
    • chapter lead
    • agile coach
  • A Step is the combination of a well-defined set of expectations and behaviors associated with a particular degree of impact on Spotify. As you take Steps on your career path, your impact grows.

In the end, your path will involve taking Steps forward, growing your impact and broadening your influence while you evolve through specific Roles in various Disciplines. Your compensation is influenced by your Step, aligning your performance to the positive impact you are able to have on your team, your product, and Spotify as a whole.

Moving to a new Step in a given domain represents both an acknowledgement of what you have done and a commitment from your manager that you will get bigger challenges in the future.

Your Step is a measure of your personal growth and is intended for use in discussions about career development between you and your manager. Your Step is private: only you and your manager can see your Step.  But we believe in transparency, and so will re-evaluate whether everyone’s Step should be public in some form after we have lived with the framework for a while.  It is much easier to share this information later than to un-share it if it becomes problematic.

Behaviors and our expectations at different Steps

We have identified five sets of behaviors that  provide a framework for understanding and talking about the expectations on all of us, at different levels of impact. They are:

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

The greater the impact, the more we expect in each of these areas.  A “senior” technologist who’s helping to set company-wide strategy will need to make these values manifest in different (and more sophisticated) ways than a fresh-out-of-school member of a squad.

The path

There is no one path through this framework. It is up to you and your manager to navigate the set of roles and the contexts in which those roles can be played, finding good ways to align your interests and your organization’s needs. Through this process, you will always learn and grow, increasing your impact on the company, and thus moving to different Steps. There is no expected amount of time that you will spend on each Step. Some people will move through them faster, and some will go slower. Some will reach a Step and choose not push towards the next Step, instead growing in other ways. The steps themselves are a measure of professional maturity and are therefore cumulative. A Tribe/Guild-step contributor shows all the behaviors of the Individual-, Squad/Chapter- and Tribe/Guild-steps.

Career Steps for Tech employees

There are five characteristics that every individual in Tech should develop as part of their professional growth at Spotify:

  • Values team success over individual success: We are a team and not a collection of unaffiliated individuals. You may be part of several teams: your squad, your chapter, your guild(s), your tribe. Contributing to the success of each of these groups is more beneficial to the company, the product, and our customers than chasing your own success at the cost of your teams.
  • Continuously improves (self and team): Spotify believes in never settling for the status quo. We are always focused on learning and growing.
  • Holds themselves and others accountable: As a company we value transparency and autonomy. These values must be coupled with accountability if we are to succeed. Taking responsibility for your own actions and the actions of the team and holding others to this standard is critical for us to be able to trust and work with each other.
  • Thinks about business impact: Spotify is a business. If we wish to keep working within this culture that we’ve built, we need to make sure that we are aligned with that business. Understanding how the choices you make affect the company is important for your growth as a professional.
  • Mastery: While the other characteristics talk about expectations and behaviors that are independent of your domain or role, mastery is specifically about becoming a better software engineer, agile coach, technical product owner, QE, QA or TA. There are items marked for each of these disciplines. Anything that isn’t marked is expected of all roles.

We have also identified four Steps in your career path at Spotify. Each Step is marked not only by increased responsibility, but also by your increased impact within tech.

  • Individual Step. At this step, you are focused primarily on being a useful contributor, gaining experience and learning how to be effective on their team. It is not expected that a member of technology would remain at this step during their entire time at Spotify. At this step, your focus should be on growing so that you can support your team. This is the only step where there is an expectation that all members of technology should move toward the next step.
  • Squad/Chapter Step. At this step, you are a resource for your chapter or your squad, either as a domain specialist for your team, or as a generalist/problem solver for them. You should be able to lead smaller efforts coordinating with other members of your team and drive them to completion and/or dig into tough problems and solve them independently taking in feedback from your peers and focusing on the outcome.
  • Tribe/Guild Step. At this step, you have an impact across squads or chapters. You are a resource for a larger group as a domain expert or generalist. You will lead cross-team (squad/tribe/chapter) efforts involving more people and drive them to completion and/or you will take on large challenges, working with diverse stakeholders in multiple teams to solve a problem that affects your larger organization.
  • Technology/Company Step. At this step, your focus is significantly on supporting Tech-wide or company-wide initiatives. You will Road Manage projects that span tribes and be responsible for solving Tech-wide problems, and/or you will also represent Tech in company and/or industry forums, and/or you will be a go-to person across the company to solve very complex problems

On recognition and promotions

When you are consistently demonstrating the behaviors and sustained impact of someone at a wider Step, your manager should recommend you for an official promotion (as long as you are willing to accept the increased expectations going forward).

The process for promotion depends on the Step involved:

  • A chapter lead can promote one of their individual step employees to squad/chapter step without outside approval, though the chapter lead will make this decision in part based on feedback from that employee’s peers in the squad and chapter.
  • Promotions from squad/chapter step to tribe/guild step must be approved by the relevant tribe lead, after consultation with tribe-level leadership.
  • Promotions to technology/company step must be approved by the CTO, after consultation with technical leadership, including people currently at the technology/company step.

Since we place so much value at Spotify on being an effective member of a team; promotion to the next step, at all levels, should involve consultation with a varied group of the person’s peers. This can be done using the loops tool in addition to direct conversation, for example.

Formal promotion to a new Step will normally come with an immediate compensation increase, as well as an immediately increased scope of responsibilities. The promotion represents a commitment from both sides: you will keep executing at the more advanced level, and your manager will continue to provide opportunities to have broader impact.

Examples of broader responsibilities as part of being at a more senior step for a developer could include things like:

  • driving the technical implementation of a new feature for a squad at the squad/chapter step
  • figuring out how a tribe should adapt their systems for anonymization at the tribe/guild step
  • leading the CDN technology strategy for content delivery, including technical feasibility, cost/benefit analysis, and vendor selection at the technology/company step

Public recognition will frequently be decoupled from formal promotion. We believe it’s more effective to recognize people for successful completion of important projects than for reaching a (somewhat rare) career milestone.  So we expect to see more announcements like “Please join me in congratulating Jane Jones, who drove this project to completion over the last few months” and fewer announcements like “Please join me in congratulating Jane Jones, who has officially been promoted to the Tribe/Guild Step”.

On Setting the Step for a New Employee

It can be hard to tell what step a new employee is on based solely on their interviews. To give the employee time to acclimate to Spotify and their role, their official step will not be determined until their six-month review. During that review, the step is set through a discussion between the new employee and their manager.

The new employee should do a self-evaluation with the framework to see how much they believe each behavior represents them. The manager should talk to the peers of the employee and use their own knowledge and experience from working with the employee to do an initial evaluation of how the different behaviors in the framework describe the employee. A discussion between the manager and the employee will show where they agree and where they differ, and allow them to reach a decision on which behaviors describe the employee today. This also sets the context of areas to focus on in the near future for growth.

On Compensation

Your compensation as a Spotify Employee within Technology is influenced by the Steps Framework: having a bigger impact on the company should lead to higher pay in a straightforward and transparent way.

We want to make sure Spotify salaries are following the market. Therefore we get salary benchmarks from specialised suppliers and industry leaders in this area. Since the salary benchmarks are used as a recommendation and not as strict guidelines when setting salaries we will not share them internally. We’ve always used market data to help guide our pay principles. Since H2 of 2015 we are matching them to work within our steps framework.

The salary benchmarks for Steps overlap each other. This means that a person at the Individual Step can earn as much as someone at the Squad/Chapter Step and vice versa.

On Titles

Steps do not map to titles. We approach titles differently depending on whether we’re talking about internal or external use.

Internally:

  • Scopes of impact have defined names — the Individual Step -> Technology/Company Step.
  • Roles have defined names — some more formally defined than others.
  • Roles are typically more useful for internal communications than anything else.

Externally:

  • Employees have a tremendous amount of flexibility regarding how they represent themselves externally.
  • They can use their roles, they can use more standard titles that they feel are more communicable.
  • We may in the future provide examples of external titles that commonly map to our internal role names to facilitate this.
  • We expect employees and their managers to work together to come up with appropriate external title usage.

Expectations for each Step

On Requirements vs. Examples

A few questions are common around the examples provided in the framework: are the behaviors in the bubble diagrams hard requirements?  How many of behaviors must someone be demonstrating, and how consistently, and for how long *must they be demonstrating them before they are considered to be at a particular step?

The most important point is that managerial judgment is always required: this framework provides a structure for fostering conversation between managers and employees, but it cannot ever provide a detailed recipe for how to handle any particular situation.  So the answers are intentionally not black-and-white.

The intention of the Steps Framework is to describe what it looks like for an individual to have increasing levels of impact on the Spotify tech organization.  But the truth is that there are lots of ways to have big impact, and we want to support all of them.  Someone might be moving the whole company forward through their deep expertise in a particular technology, and by putting on their headphones in a corner and singlehandedly writing a huge and critical piece of infrastructure that accelerates the work of hundreds of other people.  Someone else might move the the whole company forward by spending lots of time in meetings, driving consensus and resolving conflict as the company does something new.  These, and lots of variants in between, are all valuable.

So the answer is that the behaviors in the bubbles are mostly examples: many of the bubbles describe a specific activity more than a general behavior. These “activities” are mostly meant as examples of step-appropriate behaviors, as opposed to specific activities required to demonstrate that behavior. In aggregate, they paint a picture of what we mean when we say “tribe and guild impact”, “squad and chapter impact”, etc.  But they should be treated as triggers for discussion rather than a checklist.  Are you doing this thing?  Would your work have more impact if you did?  In general, we think these are all valuable things that people in tech should do.  But it’s not about seeing a behavior once and checking it off, or seeing a behavior consistently and checking it off, or about checking off 80% of the bubbles at some level or 100% of the bubbles.  It’s about the impact that your work has over time, and these bubbles are a loose proxy.

FAQ

What about my special situation?

These guidelines should never trump common sense. People are complicated, and there may be some special cases that this framework does not address well. Managerial judgement will always be needed, in all cases.

I do not see myself as a developer, QA, TPO or a coach. My discipline is not mentioned in the framework, what expectations are set on me?

The framework provides examples for four of the most common disciplines within tech, but there are others. It would not be possible to define good examples for all possible disciplines or combinations of these. The existing examples should inspire and help you and your manager to set the expectations for you even if the names of the disciplines are not a perfect match. If a tribe after evaluating the framework later comes to the conclusion that the present disciplines are not helpful enough and need arises to define new examples for other disciplines they can introduce new ones.

Is there a set of formally-defined roles?

No. As context and ways of working differ across Technology, formal, pre-defined roles would not fit into a lot of squads. We do have disciplines (e.g. coaching, software development, toolsmithing, quality assisting, …) to guide skill sets and expectations, but as an individual contributor at Tech we do not forcefully limit our work to one of these.

What is the connection between Roles and Steps? Do I have to be at a specific Step to take on certain Roles?

Not for most roles – but some. Examples: You won’t be a good chapter lead if your sphere of influence is Individual, hence being squad/chapter step or above is needed. To be a Chief Architect your sphere of influence needs to be on a company level.

Is this a reporting hierarchy?

Reporting is based on your Role and Discipline, and not your Step. Based on their role, a Software engineer of any step can still report to a Chapter Lead.

Are Steps like “Senior”/etc. designations?  

Steps are a tool to facilitate career development and do not confer any title.

Do I have to demonstrate the behaviors in all value areas to be considered for a wider Step?

As a rule, yes. Steps are intended to reflect growing spheres of influence and impact. We believe all the competencies listed are necessary for someone to really have the increased level of impact that a new Step represents.  However, people are complicated, and there may be cases where someone’s strength in one area compensates for a weakness in another.

Do I need to continuously move through steps during my career at Spotify?

This is something to discuss with your manager. While we expect engineers to continuously improve their skills there is no rule that one must also continuously increase their sphere of influence. Individual step is considered an introductory step for an inexperienced contributor. We do expect that employees will move from the individual step as they become contributing members of their squad.

What happens if I want to move to a step with less impact?

You may choose to embrace a new discipline where you have a significantly lower level of mastery. There may be other situations that lead you toward this choice. Again people are complicated and we neither can or should try to anticipate every situation. If you decide that you want to make this kind of change, discuss it with your manager. Note that your compensation is tied with your Step.

How does this relate to loops?

Loops is a tool focused on performance development that puts employees in the driving seat. It can be very useful for your career evolution. Promotions are a separate process from Loops.

How does this relate to Priorities and Achievements?

Priorities and Achievements are a way for you to make commitments to goals and measure your performance against them. This can help determine your salary adjustments within your range year to year, but it is not tied to your step which will determine your salary range itself. As you increase your impact by moving to wider steps, your priorities and achievements should reflect that.

When can I get promoted?

When you and your manager agree that you are consistently operating at the next Step. Specifically, promotions do not need to be tied to the annual salary review cycle. See “On Recognitions and Promotions” for the details on how the promotion process works.

To what extent is this a tool, guidance, or a formal policy?

This framework is intended to provide a concrete toolset for employees and their managers. It is the model all of Technology is using. While deviations may make sense and be needed in some cases, that is the exception and is something that should be discussed at the tribe leadership level.

How does my Career Step affect my salary?

Your career step is used to determine a range of pay based on people at a similar sphere of impact in similar disciplines. This pay range gives guidance to managers on competitive rates of pay in the industry. It does not set your salary from year to year. Your pay change set in your yearly salary review is based on your performance based on expectations during the previous year.

Do I need to be promoted to increase my salary?

No. You can stay at a step and continue to increase your salary year over year. The salary ranges from step to step overlap significantly and they track the market (which is evaluated every year). Your salary increase is based on your performance, your behaviors, and the market.

How do I as an introvert fulfill the expectations on communication and networking in this framework? It seems to be tailored for more extroverted people.

The important thing is to make a positive impact. Given that, you have to find your own way, something that you feel comfortable with. Some people prefer the written language, others the vocal one. Some people share their ideas right away, others prefer to take time to think and elaborate. You just need to make sure you are communicating in an effective and constructive manner.

Building a technical career path at Spotify

This is a repost from: https://labs.spotify.com/2016/02/08/technical-career-path/

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.

This will be a three part series. In this, the first part, I will talk about how we created our framework. In the second segment, I will talk about the framework itself. I will talk about the hard lessons learned in rolling out this kind of program in the third part.

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 part 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 saw a YouTube video of a panel on career pathing for tech startups at some point. One of the speakers made the argument 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 very good advice for a few reasons. A career path framework is unnecessary in the early days of a company and creates unnecessary 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 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 what their future at the company looks like or how they can take on more responsibility.  When this shifts from an occasional idle question to a more of a groundswell, then you know that it is truly 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 a need. Honestly, this was likely too long to wait, and some of the issues we had when we rolled it out were presumably due to the fact that we hadn’t done it sooner.

There were a few things that 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 and be driven by the human resources organization. Within the technology organization at Spotify though, we tend to take a more direct responsibility for the things that impact our culture. We feel strongly that our culture is an important advantage in the effort to build 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, would work for employees from a diversity of backgrounds, in the US and Sweden, at all levels of experience, and in many different (some unique) roles. It was clear that this would require a team that could represent, as much as possible, the whole organization.

Build 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 a diversity of 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 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 RFC. 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 definitely 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 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.

Part two: the result of the process

In the next post, I will share the framework itself that was the end result of this process.

Innovation, Autonomy and Accountability: my talk to the UK Department of Media, Culture and Sport

I was asked to speak at the UK Department of Media, Culture and Sport in January. One thing that often comes up when you talk to people about autonomous organizations is the subject of accountability. This is something that we even discuss within Spotify, from time to time.

When talking to a government organization, especially one who is responsible for distributing funding for programs, like the DCMS, the concern around accountability is paramount. At the same time, governmental organizations are also looking to innovate to provide better services to their constituents.

My goal with this talk was to present the idea of how a governmental organization could innovate by using autonomous teams while maintaining accountability by picking good metrics to measure success of programs and measuring those metrics on an ongoing basis. This would allow the programs to have autonomous control of their work and innovate, while having a objective measurement of the value that they were returning.

The Spotify Tribe: My talk from Spark The Change last week

The organizers of Spark the Change in London asked me to speak about the Spotify matrix model. I was only too happy to comply. It was a great conference, and I met a ton of good people. As usual, I tend to talk to my slides, as opposed to putting a ton of text on them. Hopefully, you can still get something useful from it.

The Spotify model: how to create, dissolve, and remix teams to be more dynamic and more innovative

One of the most challenging parts of managing a traditional, hierarchical, organization is being responsive to new opportunities; especially those that require leveraging skillsets outside your own team. At Spotify, our organizational model allows us to create, dissolve, and remix teams with a minimal disruption to individuals or managers. This gives us tremendous abilities to address both temporary and long term opportunities.

This post was originally written by request and posted on popforms.com. Special thanks to Kate Stull for requesting the article, and helping me with editing.

 

One of the most challenging parts of managing a traditional, hierarchical, organization is being responsive to new opportunities; especially those that require leveraging skillsets outside your own team. At Spotify, our organizational model allows us to create, dissolve, and remix teams with a minimal disruption to individuals or managers. This gives us tremendous abilities to address both temporary and long term opportunities.

How it used to be

As a manager at Microsoft and Adobe, I was always challenged when there was a problem or opportunity that required repurposing a team or adding on additional scope to an existing team.

This kind of thing comes up all the time: a business development opportunity, or integration with another product. Often, this would require small efforts from multiple specialized teams.

It would cause disruption as those teams had to change their current plans and had to coordinate around a new challenge while still making progress towards their existing goals. Given that people and resources were managed within the team, and managers were still responsible for delivery of their existing commitments, often it would be hard to motivate them towards supporting this new effort.

Creating a new “tiger” team is often the solution in these situations, but that isn’t always an adequate solution for long-term or permanent projects since it essentially punishes the managers of the existing teams and requires finding a new temporary manager for the new team.

Another problem in existing organizations is figuring out what to do with a team whose project has been cancelled.

If the team is a high-performing team you may try to turn the team onto a new problem, which may or may not be a good fit for their skills and experience. You may instead dissolve the team, assigning the members to new teams based on the needs of those teams rather than the preferences of the individuals. You may leave it up to the individuals to find new roles in the company or face layoffs if they are unsuccessful.

These solutions end up punishing both the individuals on the teams and their managers, often for reasons beyond their control. In an organization seeking to innovate (which requires some amount of failure), it sends a counter message to one of experimenting and taking chances.

How we remix teams at Spotify

At Spotify, we wanted to create an organization that allowed us to be dynamic around our staffing, and adaptable in our teams.

We embrace failure as being important to learning and innovation, so we didn’t want dissolving a team to be a punishment. We put this new organizational model into effect over two years ago and have been working with it since. In that time, the technical organization has grown from 250 to over 600 people. We went from having three engineering offices to five, and from having 30 teams to over 70.

We focused on building full-stack, autonomous teams, built around a single, clear, mission. The expectation is that once the team’s mission has been fulfilled that it will dissolve.

To this end, new teams are constantly being created and old teams dissolving, with their members building new teams or moving into existing teams if they need additional staffing. Rather than create a formal manager role for these teams, we decided instead to make the teams collectively responsible for fulfilling their mission.

With this model, changing teams does not mean changing your manager, and dissolving a team doesn’t leave a manager looking for a new role.

We do have a strong belief in role of the manager as mentor to their reports, so we have a strong managerial culture; it just is manifested in a matrix, rather than hierarchical model.

Why Chapter Leads work better than traditional managers

Our technical managers are called Chapter Leads. They are usually responsible for managing a narrow range of developer disciplines within their larger organizations, for example: mobile developers, or backend developers. A Chapter Lead usually has direct reports in multiple teams in the organization.

For an individual, it is common to change teams, but it is less common to change managers. As each team is responsible for their full stack and all platforms, a team may include members from several chapters.

An example is the search team in my organization. Its members come from five different chapters: the backend chapter, the mobile chapter, the keyboard and mouse (desktop and web) chapter, the agile coach chapter, and the test chapter. Additionally, there is a product owner and a UX designer, both of whom are part of the product organization (which is organized more traditionally).

The Chapter Leads are not responsible for deliverables directly. Instead, the Chapter Leads are responsible for staffing the teams appropriately; for working with the individuals in the team to help them grow; and for working with the Product Owner and the Agile Coach to make sure that the team is performing well together.

Since the Chapter Lead has visibility into multiple teams, they can often identify short or long-term skill set needs and are empowered to resolve them.

Sometimes, this means switching two developers in two teams temporarily for a skill set need. Sometimes this means moving a developer into a different team to address a short term staffing need. This also means that if there is a new mission to be addressed, the chapter leads can work together to staff a new team to address that mission out of the existing teams in the organization.

A benefit of this model for an individual is that there are many opportunities for them to work on new projects or develop new skillsets since there are new projects spinning up on a regular clip.

When and how we remix and dissolve teams

This remixing is not constant throughout the technology team. We do have several very long-lived teams that are focused on features in the product, but even those teams will shift people between each other based on short or long-term needs. In some parts of the organization, specifically the infrastructure teams, they tend to be focused on short-term projects and are creating new teams more often. Those teams dissolve when they have completed their project.

We will also dissolve teams if we believe that their mission is no longer necessary. Usually this is the result of the team invalidating their mission themselves. We celebrate these conclusions just as much as the successful completion of the project, since we value the lessons from a “failed” project. Celebrating your failures as valuable lessons encourages risk taking, experimentation and innovation.

By striving towards a model that gives the individual consistency (their manager, and their Chapter) while still giving the organization fluidity and adaptability, we’ve found a happy balance that lets us extend our agile-first values beyond the work that a team performs to the organization as a whole. This has allowed us to focus on innovation and leverage opportunities that slower-moving organizations would have difficulty addressing.

Several companies have attempted to adapt our model but there is something critical to understand. Our organization model itself is fluid and continues to change and evolve to support the needs of the organization. The specifics of our implementation are less important than the underlying values and ideals that created it.

If you want the benefits of a dynamic organization, you will need to build something that is suited to the values of your own organization. I would argue that a central requirement is endowing teams with autonomy and decision-making authority. If you cannot support this, then you should look instead to adapt your existing model to remove impediments and bottlenecks instead.

Slides from the Godel talk in September

Was delighted to be invited by Godel Technologies to kick off their IT Breakfast series in London. Stuart Hughes, the CTO of LateRooms, also gave a great talk on the culture that they have built. What they have done sounds really great, very similar in feeling to what we’ve built at Spotify. It was a wonderful morning.

I realized that it has been two years since the Scaling Agile @ Spotify whitepaper was published, so I decided to focus on what we’ve kept and what we’ve changed since then. I also spent a bit of time talking about how we hire, as this also fit into the theme of the morning.

Here are my slides:

Product Tank Stockholm video

The video from my August talk at ProductTank Stockholm has been posted. I get started around 18:08, but the other talks were pretty good too, so you should watch them all if you can.

ProductTank Sthlm – August from MindTheProduct on Vimeo.

ProductTank Sthlm August was all about “Creating drive in product development”. It featured three great speakers:

Siavash Ghorbani (@siavashq), CTO & Co Founder of Tictail, talked about Building a Product Driven Organisation:

“I’m planning to talk about the different phases we as an organisation went through as we grew from 4 to 30 over the past two years and how we’ve recruited and structured our organization for high throughput without penalizing creativity.”

Kevin Goldsmith (@KevinGoldsmith), Director of Engineering at Spotify, talked about Autonomous Teams:

“Spotify has made a central bet that we can move faster, be happier and be more effective with autonomous, full-stack teams. We’ve had some great success with this approach, but it hasn’t been without some tweaking and adjustments. I’ll talk about what is critical to think about if you want to try this with your product. ”

Tuva Palm (@tuvapalm), Group Product Manager Platform at Klarna, talked about Growing from 1 Customer to 3.5 Billion:

“I will talk about how the PM role changes when you grow and what critical ingredients remain the same no matter the size.”

Drinks and a light snack were be provided by Logi Analytics, fueling the energy behind these talks and the great conversations throughout the evening.

My slides from ProductTank Sthlm

I was asked to speak about how we align around the product while we maintain autonomous teams. Given that this was a talk to product people rather than engineers or coaches, I tried to keep it focused around product definition and prioritization. As usual, I don’t like to put many words in the slides, so hopefully you get the gist. There is a recording being made, so hopefully that will get posted and then I will link to it here.