The Platform PM role at Spotify

Abi: Nils, thank you so much for coming on the show today. Really excited to chat with you.

Nils: Thank you for having me. I’m super excited too.

Abi: So you’re the second platform PM we’ve had on the show and I’m really excited because as we’ve talked about before, platform product management is a bit of a murky role. And so I want to start the conversation here. You’ve been a platform PM since '2015, so just over eight years now. It’s quite a bit of time. So first I want to ask you, how did you actually fall into this role?

Nils: Just by accident, on a banana shell, if you will. And I suspect many platform PMs go to it that way. I was in one of the platform teams at Spotify dealing specifically with the infrastructure and developer experience for the iOS app. And one day my department lead was going on parental leave, so my product manager interimed for that product lead and then there was a product manager-shaped hole and I thought, “Hey, I could do this. I’m a bit of a generalist. I don’t know what PMing is in general or what platform PMing specifically is, but I bet I’ll find out along the way.”

Abi: This is 2015 long before I feel like platform engineering, all this stuff was trendy. At the time, was it typical at Spotify for there to be a platform PM within all the platform engineering teams?

Nils: Yes. That was a pretty solid pattern at that time. Mobile development of Spotify grew organically together with the rise of mobile in general. And that was just before this time where you saw people adopting mobile more and more instead of say desktop applications, stuff like that. So pretty early. Spotify started with one mobile team and that was the mobile team and then it split into two mobile teams, one for iOS, and one for Android, and that was the time where I started in those teams and I was a PM and then it just grew and grew and grew and the expectations of what a platform is or how to do quality assurance or quality management for apps just grew. So at some time, it was definitely not trendy and it was the slush team that did everything and we did the releasing, we did performance, we did well mostly releasing but also developer experience in theory. But that was before we at least, Spotify invented the term developer experience.

We didn’t think of it in terms like that. We just say, “Hey, the app needs to work, people need to be able to work in the app, we need to release to app stores, can this team handle that?” And then on little by little we just realized that well performance is something we should do full-time because that’s very important. Let’s make a specific team and then lift that from those proto-platform teams. And then we did the same with releasing, so we have specific release teams, and then just more and more things grew from there.

Abi: I joked about how your role and experience in 2015 preceded the trend of platform engineering and you just joked about how this even preceded the term developer experience industry-wide, but even at Spotify, which I feel like was one of the first. In your observation, when did the term developer experience emerge within Spotify and how did that happen?

Nils: So this is a while back, so I hope nobody can contradict me and dig up some old documents, but in my mind, we were through and through a platform team and just had a functional, like these are our responsibilities, but more and more talking to customers and figuring out what does product management actually mean? And we weren’t product managers at the time. We were called product owners and basically managed backlogs and stuff like that. And that was a change in and of itself.

But the more we thought about product management, like what do our customers want and how can we go from just making sure we release every week to people having a nice time in the app? And I think at that time, the person I was interning for now, the product lead of our department asked me, “Hey, can you write some memo about starting perhaps some DX team?” And I think I wrote a memo on that and then it turned out that we grew and grew and eventually, divided into our studio or department. We call it studio internally in Spotify for fun’s sake. And then we divided that into separate product areas. One of the product areas is specifically developer experience, now consists of five teams. Five or six teams.

Abi: So let’s fast-forward to today. We talked about how you got into the role initially, but what exactly is your role today and then what is your broader department or organization’s mission?

Nils: That’s great. I wonder if we should start at the department and then boil down to where I live in it. So there’s some context. In the wider department or R&D studio as we call it. It’s called Client Platform. We care about everything that makes our customers – feature developers – be able to have an idea and then ship that to customers within a few days. That’s the wider goal and we want to remove every obstacle in there. And that studio is divided into three distinct product areas. One of them is developer experience where we care about things like build times and being able to start your ID and stuff like that. And we have building blocks, which is architectural components and SDKs and how one can compose a feature from specific blocks and be able to do that efficiently.

Then we have quality platform, which is how do we make sure that we have a high quality for the end user from the app, from an infrastructure perspective. So how do we make sure that we keep app size down? How do we make sure that the app starts pretty quickly and when you load new views that’s quick in the app and how do you do instrumentation? So the teams that implements the features can own their own quality and see the effects their changes have upon the wider app.

And within the product area developer experience where I work, there’s another subdivision called Pillars where there’s a local developer experience, which is pretty much build systems and IDs. There’s a CI developer experience pillar, which is how do we make sure that pull request reviews are quick and tests. We test the right things in the right amount of time in order to guarantee quality, but make sure that pull request still are quick. And then there’s a unified platform pillar where I work currently and have for a year and our remit is to make sure that how can we reuse stuff we build primarily for the mobile app because Spotify is a mobile-first company into other apps that Spotify maintain, like the desktop app and the watches and the game consoles and the TV apps and stuff like that. How to make sure that everything we build has a benefit for all apps. So ideally someone could move from being a developer in one app on one platform to another app and still retain knowledge and not have to relearn stuff from scratch.

Abi: And I’m sorry if you already brought this up, but what is the umbrella organization then for all of these different organizations you’ve described?

Nils: We have the Pillar where I work, to the product area, which is a developer experience, to the studio or department, which is called Client Platform that cares all about the clients and then there are departments further up. We have a mission called the Platform Mission and that is divided into some studios caring about backend developer experience and stuff like that and infrastructure and data and ML and stuff like that. And it all leads up to a consumer business unit, which is basically how do we serve the consumer and end-user customer best so they get nice features and a nice working app. So that’s the organizational tree.

Abi: I want to give listeners a little bit of a teaser to put a pin in this part of the conversation because later on, we’re going to be talking about how your organization reorganized around focusing on journeys and domains rather than specific technologies. So really, really interesting journey that I’m excited to get to. But before that, I want to talk about the murkiness of the platform PM role, which I know is something you have a lot of thoughts on. In our previous discussions you’ve brought up that there are some unique challenges to being a platform PM and what I thought was really interesting that you mentioned was just the difficulty of defining what your product is. So can you share more about what you mean by this?

Nils: Yeah. So in my imagination, I’ve always been a platform PM. So whenever I think about end user-facing PMs, it’s a bit of a fantasy land where the grass is always green so you’d have to take my fantasy with a grain of salt, I guess. But what I imagine is that you have some nice package that you deliver to an end user customers and you sell it and you get like, oh, people bought my package, but they also had a choice because they could have bought another thing, another chair or whatchamacallit. But as a platform PM, what is your product exactly? If our mission is to make sure that someone has an idea and are able to deliver it and we take care of the rest, we’re not necessarily saying to a new employee, “Hey, here’s our product offering, you can choose these tools or you can’t,” because I guess you might say that we have a captive audience where it’s like well we provide this excellent build system for you and a build experience and can’t really choose another one, to be honest.

So what is the product? The product is not a package, it’s a capability. Product is an idea that you’re supposed to be able to do something like a jobs-to-be-done type of thing. But the jobs to be done is wildly different because what is between an ID and ship can be anything depending on what that ID is. So our scope is really, really big is our client platform and it shows by the number of people we are and the different product areas we have, but it’s hard for someone joining us as a new PM for instance, and they’ll ask, “Well, so what’s the offering? Where can I read about it?” And we’re like, it’s an abstract idea more and a sense of giving customer, well, capabilities that are within some certain timeframes that we define as a good developer experience.

Abi: That’s very interesting.

Nils: But then we do have specific tools and SDKs that people can use at certain points in their developer user journey. But are those individual different products? Internally for us, they have different product managers for sure because we have the developer journey, we’ve piece mealed it up and we have the individual PMs caring about build graphs and stuff like that just to be able to have a good building experience. But it’s an incremental build, a product. It’s very hard to have that conversation, especially when you talk to other people in the area, not necessarily PMs but engineers or user researchers and they say, “Well who’s your ideal customer for this ID?” It’s like, well all developers. How do you segment that because…

I think in at least some platform PMs I know, I think there’s a lot of imposter syndrome going around because you’re like, oh, stuff isn’t working here, we’d better put something on the roadmap to fix that or on the backlog and we seem to have high build times over here, let’s see what we can do to fix that. And that’s I think, is the murkiness and the experience when I started just going into the hole, I think it showed because there was no, this is how you do platform PMing, this is what’s expected of you. It was more or less here’s your team, solve the problems, find out what the problems are and make sure that they go away.

Abi: Really interesting. The point about your captive customer base, i.e all developers and how that makes it difficult to think about defining what is and isn’t your product or whether you even have a product. Your perspectives are really interesting. How have you practically solved this and what’s your current approach? How do you define your immediate team’s charter or mission or scope or actually what do you put forth currently?

Nils: So a lot of it is breaking down in jobs to be done and I think at some point, we’re struggling because a lot of the frameworks in product world is not necessarily designed for platform PMs but we have make do to have these conversations with other people that we’re working with. But a lot of it, we do actually internal, is we have one place where we can see all our customers’ activity and that’s the repositories. Our customers are people working with code so we can see where are they working and then we can use all data we can get from the code versioning systems like Git, so where do people work, how do people work, how can we construct a customer journey just from the signals we get from build systems or from check-ins? But also, you can also divide it into different platforms or different levels of applications. For instance, we have some UI layers where we see some customers or teams operate. We have some super base SDK C++ level where we see some people operate and those usually have very different environments where they’re working.

So you can categorize them that way like an SDK developer, people working in deep frameworks or UI developer having an ID and just want to use UI components that we build and those might be the same people, just at different times. So this ties into a jobs-to-be-done type of framework or a customer segmentation persona type framework.

Abi: You’ve mentioned that another challenge with platform product management is how to not leak your internal org chart. This is a problem that sometimes, regular product managers and product organizations have, but how have you seen this manifest itself at Spotify specifically?

Nils: Well as I said, we tend to think of the overall studio-level mission from idea to ship and it’s very easy to segment that into, well I have an idea, so I start an ID and that’s one team and then I build something either locally or over the network and that’s another team and another department. And when you do that, it’s very easy for it to… You pigeonhole problems into different teams, but there might be spaces in between where a customer is like what do I do when I get here? And there’s nobody really to talk to and you’ll see customers always ending up, especially people who’ve worked for a long time, and you have an intuition on, I know this person is very smart, that person can always tell me who to talk to and how to solve problems regardless of if it’s that person’s job.

So what you see is typically, regardless of where the problem is, you speak to a specific person, and they pinpoint a team, but that team might feel like, well, this is not really in our realm anymore because we might have changed missions suddenly. So they will point and ping pong the customer to another team who’s like, well, we actually have something figured out here yet. We’re going to build it soon, but you can talk to this third team. And this is how you shape your org chart. If you don’t have a very clear point of contact for all problems, then it’s the very risk of making the customer have to know about your internal organization in order for them to know, who should I talk to about this specific problem?

And it’s super challenging. We’ve done some work in unifying our support channels and making sure that we have representatives from all teams looking in that very support channel. But in a 200-team world, that’s a challenge, especially when people are located all over the world and making sure that someone has nice everywhere or at any time.

Abi: The point about how you’ve approached support channels, it’s a good tie into what I wanted to ask you next, which is, how you stay close to the customer. You mentioned some of the challenges with the fragmentation of different responsibilities amongst platform teams being a challenge for customers to know who to talk to. And I also funny enough, feel like connecting and staying close to the customer is sometimes a challenge for platform PMs. I’m not sure you would agree in your case, but what has been your experience, and what are some of the approaches you use to stay close to customers?

Nils: So when I talked about the challenge or non-challenge, I agree that it’s always a challenge regardless of how you work. I think one of the few boons or benefits I personally see with Platform PM is that you’re close to the customer. You can just switch floors and there’s your customers, you can say, “Hey, I’m going to sit down by you and see how you do work and talk to them and having a bit of a close relationship.” So I think that’s where it actually is a benefit to be a platform PM.

That said, I think it is a challenge. It’s always a challenge when you know people and their inside orgs to make sure that you get voices heard from anywhere and you’re just not reactively listening to the person who might just be the loudest rather than the most representative case or tying to your strategy or the problem you’re trying to solve at the moment. That’s never going to stop being a challenge.

It’s even more of a challenge the last years after the pandemic, which I have a feeling it was yesterday, was actually further and further away in time, because I think we were very used to just living together in an office and that’s my go-to example is just switching floors because it used to be that and we all sat together in one building or another. There’s a few buildings across the world but still, it’s localized and more and more sitting just alone in your own apartment for one and a half years nurturing an ever-growing list of Slack channels of people, you’re either pinging directly or just lurk and try to find out what’s going on. People come and go in all companies and that’s a good thing, but if you’re too reliant on just having these contacts, then those people go away, then you need to struggle to get the new context that you need to have. And that can be a super big challenge, especially if Slack and email is how you interact with other people in the company.

Abi: Is that today your primary channel? What do you do today? Is it primarily the support channels? Are you having coffee with customers, developers? Or what are the specific methods you use?

Nils: I’ll speak personally and then I put that against the official answer of what people should be doing. I tend to rely a lot, and this is because I’ve been probably in this company for a long time, rely on just lurking on Slack and see how people talk and who they talk to and what they talk about and the urgency in their voices. And we have a bunch of Spotify-wide service that we put to develop and see how they work and we have metrics to see how things are going. We do structured user research-led interviews to see how people work and map out user journeys. And just regular interviews with people and our customers to see how they’re feeling at the moment. But personally, I lean a lot on just being in conversations or near conversation and seeing the problems people express and see patterns in that.

And I think we also have in Spotify a writing culture, ish, where we especially in the pandemic or the post pandemic world, express our thoughts through long documents on, these are ideas we want to explore and these are strategies we’ll want to pursue. Reading those documents is vital also to see where are we going, where’s the company going, where’s the company’s strategy leading, where are our customers? Just specific internal customers, what are the strategies they want to pursue and how can we help them pursue their goals? And I think that’s one important thing on platform PMing, how can we, instead of just looking at our infrastructure and the tools we happen to build and think about this and plus one and instead, go to think, what do our customers actually want to achieve? How’s their world changing right now? What’s their strategy take and how can we make them do that? Where do we need to go in order to enable that?

Abi: I want to shift topics a little bit, talk about just the platform PM role, generally speaking. I know you come from an engineering background as you mentioned. What are the backgrounds of other platform PMs at Spotify and what do you think, you’ve been doing this eight years, what do you see as the optimal profile or backgrounds, balance of technical, non-technical for someone in this role?

Nils: That’s a super interesting, very pertinent question because those are conversations that always goes around what makes a successful and effective platform PM. Wish I knew. And I think there are two ways into becoming platform PM. Either you might be some engineer who just saw like, well this seems like a fun new challenge and I want to take the team or something in a certain direction and just go into it and are amazed on what being a PM even means. That’s how I did and this is my personal journey. But we also hire people who are just well-established PMs, product people and then we’re internally onboarding them into the domain that we’re working in. What does mobile development mean? There are certainly challenges and pros and cons for each direction. I think of it in terms of a spectrum coming from those different backgrounds and the challenge from being an engineer first before you’re getting into platform PM is, how do I understand what the different frameworks we might use as how can I be effective in doing decisions?

How can I structure my product thinking or customer awareness, rather than just being, this is my favorite piece in the roadmap. And the challenge coming from a pure PM background from perhaps some other company or some other parts of the same companies. How can I get onboarded into the technical domain which we are in as a platform PMs, to know what… If we’re weighing two options against each other, what do they actually mean? What is the team capability and how fast is an idea realizable? And how do I know if an engineer says that, “Oh, it’s a piece of cake.” How do I know when to push back and how do I know when to trust that?

But being from a more PM background, having a much sure-structured way of working with product. At the end of the day, I think for an organization, I think that’s not a personal question on what’s an optimal background. I think it’s an organizational question, how can you make your organizational make these kinds of backgrounds help and nurture each other because I think there’s, as platform PMs, a lot to learn from the different respective backgrounds and how to make sure from a product to foster that. And I don’t have the answer on how to do that, but I know that’s actually the question to be able to answer.

And I think you can draw definite parallels between these questions of engineering management, it’s exactly the same for a better engineering manager if you’re coming from an engineering background or general manager background, very hard to say. You need to help each other to get information from both. But some of these specific examples can be controversial to discuss, but I always think of it in terms of technical writers because as a technical writer, you’re successful if you’re a good writer and well, a good technician, and you need a little bit of both. And not every writer is a good technical writer and not all engineers will be good technical writing and you need to be able to learn from both sides. And it’s the same for platform PM and engineering management, I think.

Abi: Well, having done this for so long, I’m sure you’ve seen many people succeed and struggle in this role and I’m sure you’ve seen many dynamics of people first entering into this role and leaving the role. Someone I previously had on the show Will Larsson, he’s written a couple books on staff engineering, engineering management. One thing he’s brought up with me in the past is that it can be potentially challenging to attract people into the platform PM role as opposed to a more traditional PM role because there’s potentially less visible impact. Meaning it may be harder to get bonuses, get promoted, grow your career as a PM if you’re doing something internally facing. What’s your perspective and experience with that?

Nils: I recently had a talk with my manager and she dropped the term, delayed gratification and I think as a platform PM you have to be comfortable with that delayed or never appearing gratification. I think that’s key. And the only way to do that I think, is to be genuinely interested in the subject matter. You don’t even need the technical knowledge, but just to be interested in this domain, interested in helping customers achieve what they want to do instead of just seeing it as a stepping stone either in your career or to some other role or to some other department. You have to be in it for the long haul, at least. For a little bit. And I’m very biased because I’ve been here for so long, so of course, I would say that, that would make sense to me and people are super successful in their careers moving around. I don’t want to throw shade on that, but I think to be a successful platform PM I think you have to be interested in what you’re trying to achieve at the end of the day.

Abi: Do you think platform PMs are at a disadvantage in terms of typical company compensation, promotion ladders? You’ve been doing this a long time. Do you think if you wanted to increase your salary, do you feel that being a platform PM it puts you at a disadvantage versus being the PM of the Spotify iPhone app or something like that?

Nils: I think the key to a good successful career is always to be able to demonstrate, well, your impact. What have you been able to achieve? What have you been able to drive? I think for any type of PM that can be a little bit abstract because at the end of the day, you’re a PM for a team and the team does stuff. What was my role exactly in doing this and I sat in those promo packages. What was my role in achieving this big thing? And then the imposter syndrome sticks. I’m going to imagine that’s not very different for any PM.

But that said, yes, I think it’s easy to demonstrate value the more you can tie your impact to dollar signs and that might be easier if you are part of a customer facing thing that increased the user engagement by X percent, for sure. But in general, that is not necessarily at Spotify, but I think to be able to drive a successful platform org, you as leadership, need to be able to recognize impact and argue for your organization even when that’s not necessarily easy to demonstrate. And I think this also ties together to how we as the industry think about quality metrics versus quantity metrics. And I think it’s much easier to discuss stuff in quantity metrics and put dollar signs and stuff. But a lot of the things, especially in developer experience is hard to quantify.

You can talk about developer satisfaction scores and we have a ENPS on seven, but if you make an organization more effective, you can try to just say, “Well, you can ship stuff 20% faster and you can calculate that to engineering hours somehow.” But it’s all never exactly capturing the full picture, what it means when you can put your customers inside some flow state where they’re just… We talk a lot about, it sounds a bit silly and abstract, but we talk about how we can unlock the creativity of our customers and put them in a flow state. And that’s not necessarily a quantifiable thing, but it’s just a feeling that they get when they’re able to have these ideas and effectively work towards them. And I think for an organizational, that’s super valuable to be able to bring about. But then leadership of those organizations need to be able to say, “This is valuable beyond these hours saved. This is valuable because we’re able to at some point ship user impact.”

So again, I’d like to put that on the organization rather than the individual level, but if you’re at a place in any company where you’re not able to argue that, then you’re definitely at a disadvantage.

Abi: Yeah. What you’re saying here, really resonates. The challenge and the fuzziness, the futility of trying to translate everything into dollars, which is a lot of-

Nils: Soul sucking type of document to write sometimes.

Abi: Yeah. And the difference it makes when an organization just has a cultural belief or principle around why this thing matters. You’ve been at Spotify for a while, what do you think is the difference? Why does leadership at Spotify, why do they get it? Why do they invest in this, whereas at so many other organizations don’t?

Nils: That’s a good question. And bearing in mind that I haven’t been in many other companies and so it’s hard to compare when you haven’t seen a lot of companies from the inside. But I think one of the things that makes Spotify successful in that department is that it’s pretty engineering driven. I think it has a good mix of engineering product driven versus necessarily, a top down profit focus. The belief has always been there in Spotify that if we build the right experience, we will get the customers and then we focus on building the right experience. And when we do that, we also focus on how can we measure that their experience is the right experience and how can we implement it fast? I think internally, we say that Spotify’s competitive advantage is the speed of how we can ship ideas and learn new stuff, and the key of learning fast is implementing fast and then measuring a lot, then changing fast.

Abi: I love that. Well, we could talk about this all day. As an outsider, I am very inspired by Spotify’s investment and upholding of the importance of developer experience. And so, so many leaders, developers I talk to at different companies are seeking to bring this culture into their own organization. So I think how to do that is still quite elusive, but hearing your perspectives on it I think, are really helpful and inspiring for listeners. I want to shift into now, some of the recent projects you’ve worked on, which are really, really interesting. Starting with, and I’ll have you describe it in your own words because I’m going to butcher it, but you talked about a recent shift, a reorg if you will, where you shifted from having your different platform teams organized by a specific language or technology and shifted to the teams instead owning journeys. And again, I probably butchered that. So first in your own words, could you describe to listeners what the shift or change was?

Nils: Sure. So moving back to the org chart I was describing earlier where one of the product areas we have, which is comprised about six teams, that’s the developer experience product area where I work. Traditionally, we come from a background where everything was one mobile app and then when they split into two mobile apps. And that meant that we had teams owning those apps, effectively being platform teams. So we had the iOS team, iOS infrastructure team that owns the iOS app and did everything with it and similar Android one. And as more apps came about, we will have a platform teams for them as well. So a web platform team. But we’re solving the same thing. The customer needs the same thing. And our customers teams, the feature engineers, they’re cross-platform, they own a feature, they don’t own a platform, so they will implement something like your library across all apps, but we didn’t work that way.

But solving the same thing per platform led to a lot of redundancy in re-implementation. And my favorite go-to example, I hope I won’t get punished for this by the teams I worked with, but my favorite go-to example is the translation pipeline or translation tools we built and I was the PM for both the iOS and Android team and I knew that we have duplicated implementations of this and sometimes, people in the tech industry can become, building their identity with a certain technology or a certain platform. And I know that we have hired a bunch of iOS engineers who are super passionate about iOS stuff and that’s the core of their being. Sometimes, of course, when they build stuff with iOS app, you do the best available tooling for that and that’s your world. Then we have an Android team who’s exactly the same, passionate Android engineers.

Then as a PM you’re like, well, isn’t this platform independent tooling that we could share implementations? And you’ll see, sure, they can use ours or something like that. And as I was the PM for those teams, I think I was able to identify a few opportunities like maybe we should join forces somehow and don’t do this re-implementation. But it’s difficult because the apps worked differently and they lived in different parts in the Gits repositories. So it’s hard and we had to figure out a good way to put stuff closer together in order to make that happen. That’s a surprisingly long journey, but at the end of the day, it made more sense to own a piece of the journey, a piece of where people are on an idea to ship scale. So people own domains.

That’s how I think about it and domain corresponds to a job to be done or something like that. So instead of an iOS team, we have the build team that owns the build system and the infrastructure around that for all of the apps or primarily mobile apps. And then we have the local developer experience teams who make sure that people can be effective in their ideas, both Android Studio and Xcode, which are the primarily tools people use to do coding and make sure that we have the same instrumentation of all of them so we know how people are working and are able to do effective plugins in those ideas to do smart stuff. Basically owning those type of journeys throughout.

And I will say that this sounds like a slam dunk we did a long time ago, but it’s actually quite recently. And orgs, orgs are always difficult and the changing in org is always tricky because people have affinity for working with a certain thing and every change is scary. And as someone who tries to design org change, you’re always like, what are the most optimal thing we can achieve? And you think of it as something that will live on forever and ever, and that’s never the case. I think a healthy organization do change every couple of years because the nature of where you work will change and then you might be more permissible to, this is good enough, we can change for the better and that’s good enough. But everything comes with a cost.

Abi: The pros of what you described I think are pretty clear, less duplication of efforts across solving similar problems and different technologies or platforms, more holistic thinking about these jobs to be done. So what were the trade-offs? What were some of the cons of switching to this approach?

Nils: I think first and foremost con of change is that it’s change. And I read a fun tech blog where it’s like change always starts as -10 points and it’s always more stable to keep things the way they are because at the end of the day, change can be scary. You’re changing people’s closest friend group with their team and changing that, you shouldn’t take that likely. So you need to make an effort to know that first, we have a good idea in our heads and then we float that idea around all the different people and that takes time. So we’re starting with one idea and the needs change over time and this always moving target and it preoccupies a lot of minds even before and during the change. Like how are things going to be? Is this a good setup? Is this a team where the team has a future? Is this team integral to the strategy of what we’re trying to achieve or is it one of those other less important teams and stuff like that?

And really, when you talk to people, you can see a lot of these ideas float around them. You can be the one on a whiteboard just drawing lines and that’s fairly simple. And then you’re actually changing people’s day to day friend group, which you shouldn’t take that too lightly. That’s the biggest con. The other biggest con is probably ownership, because ownership is tricky and hard, especially in this macroeconomic climate where it’s hard to hire people for every company. So when you have some set of ownership and you’re changing the teams radically, not just shifting them slightly, but turning them 90 degrees, there’s a lot of ownership pieces to figure out and ownership discussions in my experience, is one of the most tricky thing you can do in an organization. And that takes a lot of time.

So you’re faced with either, we go ahead with this reorg and we figure out the ownership later, but then you have the risk of things falling between the chairs and nobody really being super psyched to take on the most tricky sandwiches or you’re faced with figuring out all beforehand, but then they always going to take three years and it’s going to be irrelevant by the time it comes about.

Abi: Yeah. While we’re on the topic of org design and team structures and change, Spotify is, in addition to being known for its focus on developer experience, also known for a big emphasis on highly autonomous product teams. That almost contradicts some of the work you do in terms of standardization of tools and captive audiences or a customer base as we’ve talked. So, what does that look like? Do you find that challenging to work in an environment where the culture for teams is to be highly autonomous? Do you feel like your work is in conflict with that or in harmony with that?

Nils: I think it’s super, super challenging and I think we see that across the whole company. And as you say, I think Spotify is known outwardly as being comprised of highly autonomous teams. And I think there’s also this concept of a Spotify model that’s become this trend of other companies want to absorb and be like, “Yes, we want to be Spotify. That’s successful. How does this work in a bank setting?” And then you’re confused and especially from within inside Spotify. But I think it’s worth knowing that, at least in my mind, that has always, even when we try to do the Spotify model internally, an idealized situation. But still, the concept lives on in people’s minds, especially people who worked here for a long time and people who are new join in just like, I’m super psyched to be a self-sufficient product team, or we can just have an idea and we can put it in there and we can do whatever. Just have the ideas. And that’s not the reality. That’s not the reality at all.

Most of the projects we’re trying to do either inside Spotify, just the business priorities or the sweeping infrastructure we change in my department in client platform, multi-year efforts with a lot of coordinations between 10 plus teams. Then you can’t have team autonomy in all levels. So it’s definitely a clash where in order to combine the two worlds of autonomous versus big project led, we as many other companies I believe, use OKRs a lot objective and key results. And that’s become the harness of how we reign that in, where it’s like, well, you can’t be autonomous with what to do or why to do stuff, but you can be autonomous with how to come up with these solutions. And that’s what we’re trying to strive for. Where you need to have on some centralized level of ideas on where do we want to go, what’s the company strategy and how can we tie into that? And we codify that almost either in objectives or in strategy documents or in long-term roadmaps.

And then we start with a goal that’s far away a few years and then we need to work with teams to say, “Hey, so this goal I just made up as a PM, how do we count backwards and see what we need to build in terms that?” And that’s where the autonomy piece kicks in, where it’s like, how can we creatively solve for, we are here, we need to get to here, and what’s the road we take? What are the dependencies and what do we need to solve?

Abi: Yeah. I feel like the tension between company initiatives, standardization, shared resources and team autonomy, such a universal challenge for platform infrastructure engineering in particular. So really interesting to hear where you’ve landed in terms of how Spotify approaches a company that’s famous for its focus on team autonomy. I want to shift gears again and now talk about another project that you’ve recently worked on, which is helping people onboard as mobile engineers. Maybe start with the impetus of this project. What sparked it? Was there a burning fire? Were you hiring a bunch of people? What caused this to even be something you guys wanted to invest in?

Nils: Yes and yes. So I think the background of the burning fire is how to do development at Spotify, especially when I started a long time ago, was, to put it nicely, organically grown. So it started with just something and it was relatively easy, but then scaled into 300+ people working in the same repository, in the same app, trying to do their own personal or their teams’ mission somewhere. And it’s very hard to process-wise, get that to scale when it’s just, oh, something’s broken here, well, let’s fix it here. So it was almost unknown how to do development for any discipline. I speak primarily about the mobile development because that’s where I come from, but it was same for backend development and machine learning or AI. Super similar. Someone got started and it was like a labyrinth. You’re a new engineer and you’re expected to do something, you pick up a simple ticket and it’s like, “How do I do this?”

And you had to find out someone in your team, is like, okay, how do I check out the code? Oh, you go there and you do this. Oh, you can’t check out the code because you don’t have the right access to the LDAP groups. And who do I talk to? Oh, you need to go to it and you need to be added there and oh, you need to actually create a set of keys in order to be access to network. Oh, right? But now you’re still not in the right group, so you can’t actually do client development or whatever. It just became this multi, multi journey for a new developer just being bounced around different people that probably knew something or had worked with how to set up Python environments before and just were the Python person that you talked to.

And then someone had the smart idea of like, well, we hire a bunch of people. So it’s just getting more and more murky on the people who are in the know that you can talk to and more harder and harder to find and more and more pressure and things are changing so much so they’re not even knowing. So someone had the great idea to create what we called a golden path, which is going from zero to your first pull request. What are the actual steps, one by one? And that was a technical writer. So I think that person just sat down next to various fierce engineers like now you’re going to pretend that I’m a new joiner and you’re going to tell me step by step what I should do and I’m going to do those things and until it works, we’re going to sit here.

And I think that took weeks. I think probably both of them thought like we’re going to hash this out in the afternoon and that’s going to be it, but it took literally weeks because there’s so many like, oh, if this happens, you need to set up your bash environment like this and have the right environment variables and stuff like that. So onboarding was hard. Very hard to measure also. But we created these guides one for each discipline on going from zero, talking to IT, shaking out the code, also codifying how does one do feature development for mobile? Here are the tools and that’s the case and the architecture components one should use. Here’s the instrumentation you need, here’s the logging you will need to set up.

Just going through that and creating a dummy feature. Actually going the full way of checking it into the app and then as the last step, removing yourself from it. And that was a project I led as a PM for mobile development. It took a couple of months and I, as I always do, estimated, I said, “Well, we’re we going to be done in the afternoon.” And I saw that again, we were different platform teams, so people working on it from different teams and the documents diverged more and more and I had to put my foot down and say, “Hey, we’re going to sit in the same room from all the platforms when we work on this document together. It’s going to be one document for all mobile development and it’s going to contain the same things.” To be sure that we not only document, but also standardize as much as possible.

And the first idea was, we’re just going to list all the steps and we know that the steps is going to be too much. And then when we see the steps, we can cut them down because we’ll see patterns and like well, this is probably not going. So we from a developer experience perspective can automate this and this and these steps. Sp basically, the golden path is our backlog of things we need to fix in order to just be successful in day one. I think we had grand ideas on, well, you’re going to just get your laptop from IT. It’s going to be shipped with all the tools installed and then it’s going to have all the source code on it, and it’s just going to be pre-steps being done. So you can just run a script, check it in and you’re done.

And then I learned one of my first PM lessons, that’s not how new employees want to work even. Where I think I told this to my boss, people are going to be up and running in like a day. But talking to new hires, I was quickly disabused because what they wanted to do was something completely different. They’ve been hired into this fire hose of information, just blasted at you, trying to hit the ground running and be effective and introduced to a new team, but also go into these onboarding courses and social events. And what they all usually want is a quiet day with the laptop to set things up just right with your own personal window manager or specific tool sets or your Emacs versus Vim and didn’t want at all to just get things pre-installed because then there’s no downtown, there’s no shielding, which is again, very hard to quantify because how do you make sure a new employee is secure and able to take things in their own pace.

Abi: Well, perfect transition to my final question for you. And as you were describing this Golden Paths project, and you mentioned that measuring onboarding is challenging. So I want to ask you, and you’ve mentioned to me before, you’ve gone through a few iterations of how your team, maybe just Spotify broadly, measures onboarding experience, onboarding time. So take us through the different things you’ve tried and where you’ve landed on today.

Nils: Yeah. It’s an interesting subject. Again, we’re hamstrung by the fact that we have quantitative metrics to work with, but we want the qualitative people feeling well and learning fast. But some of the first things we tried was time to your first pull request, which we quickly reduced very quickly because we have a golden path that leads you through it. So now we’re done. But that’s not it because the person won’t feel onboarded and then we go into the territory, how does one feel onboarded? What’s the goal state? Is it when the person feel they’re done? Is it when the manager feels they’re done? Is it when the teams feel they’re done? The next thing we tried was a very small iteration of this not actually capturing any mental state at all, but just, well, the first pull request is for free. How about the 10th pull request?

Then quickly realized, well, pretty good. We don’t get an individual score of how people are onboarding, but we do get some quantitative score of the complexity of development, which that’s actually how I think of the onboarding metrics or how complex is development, and the more we can reduce the complexity, then the faster onboarding will take. And that was okay, but we wanted to capture this sense of being effective inside the team. So we’ve discussed things like, this veers into the sometimes controversial topic of how do you measure productivity at all and do you measure how many pull requests per day engineers do? Because if we want to measure onboarding as productivity compared to the team which we was looking at, we can say, “Well, we’re going to measure pull requests per day per developer for new joiners, and then we can compare them to the same level in the team and wait for when those converge.”

But that’s very complex and perhaps, can feel not so nice for people to just be measured individually. So we landed on something akin to time to to a meaningful pull request where we do some thinking and heuristics around what’s a meaningful pull quest is. So it’s not like a one line doc change or something like that, but more the first change that looks like a change would do for a person in the team, which they onboarded and also compared with people starting in the same cohort at the same time. So some level of first complex enough representative pull request, but it’s super tricky and at the end of the day, we’re measuring more the environment they are in more than how people feel, which well, can be sad.

Abi: Yeah. Well, one follow-up. Can you share more about the heuristics for how you define meaningful or complex enough? Is it just the dif size or what do you look at?

Nils: I can’t because I don’t actually know, and I’ve since transitioned from working with onboarding, and that has passed through some teams. So right now, I can’t, but as I understand it, it’s some level of complexity. Then I will imagine it’s either touching some systems or being actual code versus docs and probably a dif size lines of code or something like that, make that comparable.

Abi: Super interesting. Well, Nils, this was a really, really fascinating conversation. I enjoyed it very much. Your insights on the murkiness of the platform PM role, your own experiences navigating different challenges at Spotify, and these recent projects you’ve taken us through have been I think, really interesting and will be really valuable to the listeners. So thanks so much for your time. Thanks so much for being on the show today.

Nils: Cool, cool, cool. Thanks for having me. Super interesting. Awesome.