Maintaining The Speed Of Scaling: Startups To Enterprise
Checking session availability…
Hang tight while we load the latest updates.
As a product leader, it can be tough to navigate working in different team structures, processes or with the constraints of a small (or large) team.
This interview will take on key learnings from Flavia on how to balance trade offs of moving like a startup with a lot of weight. How do you create things like goals, communication and build autonomy within a team.
Maintaining The Speed Of Scaling: Startups To Enterprise
Flavia Neves, Rory Madden at UXDX EMEA. Video: https://youtu.be/lPe9bTuO3BY
Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.
From startups to Spotify
[00:00:00] Rory: As Snjana [?] just mentioned, we'll be looking at scaling from startups to enterprises. Can we just start with a quick background on yourself and where your experience fits in with that startup-to-scale-up position?
[00:00:17] Flavia: Sure. I started my career in a startup, which was actually a spin-off, so that was my first introduction to startup life: one person in a 20-person team, just doing it all as an intern. Then I had multiple jobs throughout my career, primarily in startups, but I also had some more corporate experiences and some slightly bigger companies. So I have experienced the very small-scale startup all the way up to now Spotify, with almost 9,000 people.
[00:00:58] Rory: So definitely in the enterprise space now.
[00:01:01] Flavia: Definitely, but it still feels like it has the good parts of a startup.
[00:01:09] Rory: Excellent. I guess your background is more product management. Would that be correct?
[00:01:15] Flavia: Yes and no. I had multiple roles in my career. I actually started in a more traditional marketing function, then very quickly moved to product growth, and then finally to what's traditionally called a more core product role.
Product philosophy and three pillars
[00:01:35] Rory: Great. I didn't actually know about the marketing background, but that's on me. On the product side, we've chatted before about Marty Cagan, Teresa Torres, all those kinds of things. Can you explain, because I think it's going to be relevant as we go through, what your philosophy on product is, and has that changed at all as you've gone from a startup to a scale-up to an enterprise?
[00:02:01] Flavia: Oh, it changed so much. I've been at Spotify for six months now. If you had asked me eight to twelve months ago, it would probably be a different answer. You know me, we've talked in the past, so you've heard me talk about what I was doing in my previous jobs and what I was pushing for. A lot has changed throughout. I think I was very fortunate to have all of these experiences, to face very different problems, and that shaped my product philosophy, the things that I believe in and the things that I push in my own teams.
[00:02:41] Flavia: I could talk for the whole session about all of those experiences and what was special about all of them. But I think the most important thing is how flexible I became throughout the years by having such different teams and structures and problems. All of these things shape the way that I think about product, and I learned that there is no playbook that can guarantee success. It's all about being very flexible and adapting to the circumstances.
[00:03:13] Flavia: Of course, if you ask me whether I have principles that I've maintained throughout my experiences, I sure do. There are three main pillars that I fundamentally believe in, and I believe that no matter the structure, no matter the problems, they're still the ones that guide me. One is caring about the team. That's a very big priority for me, probably the number one priority. Without a team we can't do anything. So making sure that they are okay, that I'm investing in their growth, that I am supporting them mentally, at the job and outside of the job, is something that is very critical for me.
[00:03:58] Flavia: The second one is making sure that there is a strategy, that there are clear goals that everybody can rally around. I think that without the strategy, without some sort of north star, it's very difficult for teams to operate. And finally, it's giving them what they need, which some people call empowering teams, but it's actually giving them the support they need to deliver against the goals. People talk about having these very clear goals but then don't provide the teams what they need to actually achieve them, and there's no point in that. So I always make sure that these three things are at the top of my priority list and that I act on them regardless of the company I'm part of.
Flexibility: empowering teams versus following direction
[00:04:45] Rory: Excellent. It's great to have guiding principles. Can I dive in a little bit before we get to your Spotify experience? You mentioned flexibility and that things have changed. Can you give an example of something that works well in a startup and then maybe in a more traditional organization, one or two examples of how you use that flexibility but guided by those principles?
[00:05:12] Flavia: That's such a good question. I'll give you two examples. One of them is really interesting about Spotify, because everybody talks about Spotify. But let me give you another example first, of things that I was very keen on doing in my previous job where I'm now almost doing the opposite. For people that know me, it's like, "What are you talking about? Are you ignoring all the things that you've always preached?" It's part of having that flexibility that I was talking about.
[00:05:44] Flavia: In my previous role, for me it was all about empowering teams, allowing them to shape the work and drive the direction of the company. The reason I was doing this was because they knew a lot about the users. They knew more than anybody else in that company about the users, their needs, what was driving them, everything about users. So they were in a very privileged position to drive the right investments. It was also a company that was very much about optimization and about giving users a better service, rather than massive innovation. There was no one better positioned to drive those things than the teams, so a good chunk of my work was making sure that they had a voice and that they were actually driving the priorities.
[00:06:38] Flavia: Whereas at Spotify, I am actually trying to convince the teams that, hey, there is a very good, ambitious direction, so we don't have to be influencing it or be part of every single decision that is made in the company. The team, the structure and the leadership, not just the style but the actual outcomes of the leadership team, shaped how I am approaching product management. In some situations I'm more, "Hey, you should be driving this. I want these teams to drive this." In other circumstances there is good direction, so our role as a team is actually different. We need to provide a different input.
The Spotify model at scale
[00:07:22] Flavia: The thing I thought I would share with you about Spotify is that when Spotify was a small startup, everybody knows the Spotify model: tribes, squads, everything. It worked really, really well for Spotify. It allowed them to move really fast. Teams were empowered and fully autonomous. They could push whatever they thought was the right thing to push and move really, really fast. I'm speaking for myself, not on behalf of Spotify, but I think this was a very important part of Spotify's success: hiring really good people, giving them the conditions and then letting them run autonomously, having this structure that had everybody in the room who was required to accomplish the goals.
[00:08:14] Flavia: Right now at Spotify we are actually dealing with the consequences of doing this. We are a much larger organization, and this no longer works, because we're huge. We have big ambitions. We have to align 8,000, 9,000 people. So it's impossible to have every single squad operating almost isolated in its own world, pushing the things they want to push without aligning with everybody else. You might end up with 5 or 20 squads working on the same thing because, hey, it's super important for the business. You might end up duplicating efforts. You might end up doing things that might not be the right thing to do. So for a lot of reasons, including our structure, it's not possible to work this autonomously without alignment.
[00:09:05] Flavia: If you don't put boundaries around this autonomy... and by boundaries I mean simple things. When you start and you have a small group of people working on your startup, you have a small runway, so you have to make do. That's the life of a startup. You want to move really fast. But if you don't create some small boundaries, nothing very complex, simple things like "Can we all use the same language? Can we all use the same type of stack?", then if you are successful and you end up growing to the size of Spotify, or you don't even have to get to the size of Spotify, you might end up in the situation I'm facing now.
[00:09:48] Flavia: I have squads with completely different stacks. I have to work with them on the languages to bring everybody to the same page, because otherwise it's very complicated, within the mobile app, which is where I'm working, to actually move forward, because everything is a blocker, et cetera. So there are things that we do as a startup that we have to adjust slightly when we are a bigger company: boundaries, making sure we are doing the right things and preparing for scaling.
[00:10:24] Flavia: At the same time, you also need to adjust your mindset. As a startup you need to move fast when the runway is really small, so you just have to get things done, experiment a lot, take bigger risks. When you're a bigger organization you have more money, you have other problems, you have other limitations. It changes based on where you are. Did I answer your question?
One product manager per squad
[00:10:51] Rory: Yes. I think you gave a good answer, but I have about ten new questions now from what you were saying. We actually had an audience forum discussion yesterday that touched on one of the topics I think you mentioned there. What I've seen with some large companies is they go, "Okay, we're going to roll out agile and we'll do Scrum, so now we need a product owner, so every BA is now a product owner." So now you've got 80 teams, 120 teams, and 120 product managers. The challenge there sounds similar to what you're saying: everybody's trying to set their own vision and their own direction. How are you structured, if we take Spotify? Does every team have a separate product manager, or does product management sit above a number of different teams?
[00:11:44] Flavia: Every squad has a product manager. We work like the four friends, not the trio. We operate with insights, which is data, qual and quant; product; engineering; and design. But we have one product manager per squad. And I'm guessing this is your question, or at least it will help shed some light on how we do things: I am facing challenges with product managers saying, "I need to have my own thing to run. I need to know what my mission is, what my area is." It's probably the biggest concern that I hear on a weekly basis: "I love all of this, this all makes sense, but what is my mission? Please can you give me something that I can act on?"
[00:12:39] Flavia: Again, we go back to how we are organized, what the setup is. For me, the way of solving this, and I'll come back in a year's time to tell you how it went, is about working on the mindset rather than fulfilling what everybody wants. I have squads that have very specific missions.
[00:13:08] Flavia: Let me very quickly tell you where I work. We are organized in business units. We have several business units: freemium, marketplace, consumer, et cetera. I am part of consumer, and then we are subdivided. There is an area called Core Experience, CoreX, that handles the whole mobile experience, and I'm in this area, because we are primarily a mobile-first company. This team proves or disproves new value propositions. If we want to do something new in the company, either we are responsible for it or we support it. It always comes to us to a certain extent.
Bet squads and baseline squads
[00:13:51] Flavia: So I have two different setups. One is a bets-driven system, where essentially the company works with bets. When we are innovating, and again, because we are a mobile-first company, innovation primarily involves us, we have a lot of investments that are very long term. We could realize the full value of some of these things in two years' time. But at the same time, we still have to maintain the experience and make sure that everything is working well and that we are adapting to what the market is saying.
[00:14:34] Flavia: So I have two different types of squads. I have the squads that are working on the bets. They don't own the bet end to end, but they do have an overview of the whole end-to-end process. And then I have squads that are focusing on the baseline experience: what does home look like, what does search look like, and at the same time, how do all of these things come together?
[00:15:03] Flavia: For me it's about finding the right people for the right role. There are product managers who are very optimization driven. They're all about, "Give me a north star, give me a metric. I'll go my way and I'll find a way of squeezing out that last 0.5%." There are product managers who say, "I don't care about that. All I want is to rethink the experience. I want to reimagine the experience. I want to find the new things that nobody's thinking about." So it's about finding the right person for the right role, and then also working with the squads to show them the value they're bringing regardless of what they're working on. Even if they don't have a very defined mission that they can own end to end, they know that their part of the puzzle is very critical for the business, and they understand how it fits into the whole structure of, for example, an event [?].
[00:16:04] Rory: I love that. The analogy I'm thinking of, and I can't remember who came up with it, is the explorers versus the town planners. It's that different style, but everybody is important.
[00:16:20] Flavia: Everybody's important. And when I say they're taking care of the baseline experience, it's actually interesting, because when I was rethinking the organization and talking to people, I always thought, "Oh, everybody's going to want to work on the bets, because this is the future of Spotify. All eyes are on this. This is thinking about Gen Z [?] users, it's about thinking about this and that and all the things we don't have today." And I was very surprised that every single person wanted to work on the baseline. Not because they wanted to improve the metrics, but because there is a strategy, there is a vision that I created when I joined Spotify, to rethink the whole experience.
[00:17:01] Flavia: It's not a bet in the sense that it's specific to one objective, but it is actually redesigning the experience and transforming it to make it better for users. It's been great until now, and it's still great, but the industry is evolving, so we can build different things, and they're really interested in that. That's why I was saying it's all about finding the right people, but also not having boring support functions. They are needed, it is what it is, but you can always find a way of making the work really interesting for everybody.
What a bet means at Spotify
[00:17:43] Rory: Great. You've mentioned bets a few times now. Just to give context to people who might not know, can you explain what you mean when you say bets?
[00:17:54] Flavia: There are company initiatives and then there are company bets. We have all of the things we need to support, like any other company. We have the mobile app. We have the integrations with other products like Google Home, PlayStation, et cetera. We have an area fully dedicated to growth and making sure that our free and premium products make sense. We have teams that are fully dedicated to our licensing world, which is a world in itself. So we have individual investments to maintain certain things and to keep the business evolving. And then we have these bets or initiatives. Some things are initiatives, some things are bets, where we push the boundaries of Spotify.
[00:18:47] Flavia: I cannot disclose that much. No, actually, I can give you an example. Many years ago podcasts were a bet. Now podcasts are out, and they're part of the Spotify ecosystem. Back in the day it was, "We are a music company. We don't have talk formats. We should make a bet on this new vertical and either prove or disprove our hypothesis that our users want this." We have several of those things going on, and when we're talking about bigger investments that are a little bit outside of the ecosystem, we refer to them as bets.
[00:19:29] Flavia: I'm sure other people from Spotify will say, "That's not it, it's something a bit different." This is my interpretation of our bets. And then we have mountain bets, which are bets that involve the entire company. They're really big. They're going to get us far, far from where we are today. Did I answer your question? Is this good enough?
Why autonomy starts to break down
[00:19:50] Rory: To me, yes, it explains it. If anybody has any questions, there is the chat, so do post, and I'm seeing some come in. On that, I'll move back to the focus of this question. I'm going to ask a preliminary one and then I'll ask the audience question. People are interested because I guess it's a controversial take: the autonomy, letting teams run on their own, worked and was an integral part of getting to the scale where you are now, but you're saying there are issues with it coming in now. Why do you think that is a problem? I'll just use the example you gave of different technologies. If each team owns and is responsible for its own area, why does it matter if they're using Ruby and somebody else is using Go and somebody else is using some other language?
[00:20:51] Flavia: I'll give you my best non-engineer answer for this. There are a couple of problems with this that I see. I'll talk about these two, and I'm sure you'll have more questions. One is the fact that only you can touch that one thing that you own. We're talking about something the size of Spotify. Just so you have an idea, I don't want to lie about the number, so I'll go with percentages: we are involved in 90 to 95% of the company's bets, and we're talking about way more than 20 bets. So there are lots of requests coming through.
[00:21:41] Flavia: If you don't use the same language, if you don't have the right setup from an engineering perspective, you'll end up having to deliver everything that everybody's asking of you. Not in the sense that everything that comes through has to be delivered, but for anything that makes sense for the business, nobody else can help you do it, because it's your own stack and nobody else works there or understands what you have there. That's the first problem we see. If you're the only person who knows the code, if you're the only person who can touch the code, then you're the only person who's going to have to deliver everything. There's no collaboration in that sense.
[00:22:23] Flavia: The other problem that I see is that sometimes we have incompatibilities. Engineers, don't kill me, maybe this is not the real problem, but this is what I'm getting right now: "Oh, we cannot move faster because we have this and that and they don't match. We have this microservice here, we have this stack over here that could solve the problem you have, but it's going to take us two months to build an API that can link things together." So it slows you down and forces you to constantly build something, and then another something, and then another something. Again, my non-tech view is that the more services you put in between other services, the higher the complexity, the more support you need, the more maintenance, et cetera. So these are the primary problems.
[00:23:21] Flavia: Let me just say something, because I don't want to be misinterpreted or mis-explain myself. When I say that the autonomous model worked really well in the beginning and now it no longer works, that's not quite what I'm saying. It worked really well, and that model was just perfect for Spotify, and for any other company in my opinion. It doesn't mean that now the teams are not autonomous or that they cannot drive the things they think are most impactful. It just means there's a little bit more effort put into the alignment of everybody.
[00:24:02] Flavia: You can't just run and then, at the end of the process, say, "Hey, look at this beautiful thing I have here." You have to do a little bit of work beforehand to make sure that nobody else is working on the same thing, or if they are, that we might collaborate rather than just build our own thing. We might want to make sure that it's not going to impact a company bet that is about to explode. We're doing these experiments with ads: does that fit into the whole Spotify strategy and vision for the future, or can we just go ahead and move this quickly?
[00:24:40] Flavia: The reason this isn't as much required when you're smaller is simply because you're smaller. You know what the vision is; everybody's in the same room. So it's not really taking ownership away from squads in that sense. It's more that we need a little bit more structure for teams to achieve what they want. Sometimes, yes, we need adjustments, but it doesn't mean that they get a prescription: "Now you go and build this one thing." Not at all.
Making implicit constraints explicit
[00:25:13] Rory: That actually makes a lot of sense to me, because the way I think about it is that there isn't real autonomy. Nobody is autonomous, because you always have some constraints, and they're either explicit or implicit. To your point, in startups you just implicitly know certain things because people are saying them. But from what I'm gathering, it's, "Okay, now we have to be a little bit more explicit, because we can't rely on people just implicitly picking up all of the boundaries that should be in place."
[00:25:45] Flavia: Exactly. Last year, when we were together at UXDX, you probably heard me talk about how teams need to be driving, because they are the ones who know everything. We need to be empowering teams. I still fundamentally believe in that. But right now I'm very happy with the direction that I'm being given. First, because it makes a lot of sense. I trust the leadership team. I think what they're driving makes a ton of sense, so it's very easy for me to say, "That sounds amazing. I'm excited about this. Let's make this happen, and let me put my own spin on this," because of course I will, and so should the teams. But I can stand behind this. It's something that I believe in. And the second thing is that it's very well communicated.
[00:26:46] Flavia: Whereas in previous experiences I had, there was no direction, or the direction did not make sense to me personally or to the people around me. So there was this constant battle of, "You don't know what you're doing, so I should be driving this, or my team should be driving this. So step back, relax, do your own things, but let the ones who know how to do this do their job." Whereas here it's almost like I'm okay being told what to do, which, you know me personally, so you know that's far from the truth. But it does make sense. Even the things that I don't see the same way, where I'm like, "I'm not sure if we should make this investment now," the whole context makes sense.
[00:27:36] Flavia: There's also a leap of faith when you trust the people who are driving the company. Sometimes you have to take a leap of faith and say, "Okay, I don't see it now. I'm going to trust that you're right, and even if you're wrong, we'll learn from it, because it's a small portion of what we're trying to achieve here."
Direction is not a feature spec
[00:27:55] Rory: We've spoken about this before, and one thing I don't know has come across clearly here: when you say you're getting direction from the top down, I have experience of companies that just tell me, "Go build this feature. Here's the requirements document, just go build it." I don't think you're talking about that level of build. So can you explain what kind of direction you're getting, and how much leeway the team still has to figure out what's the right thing to do?
[00:28:29] Flavia: I think one of the primary problems of leadership in general is this misunderstanding of what it means to give direction. Direction is not saying, "I want this feature built tomorrow, and here are the specs, and here's a mock-up that the CPO sketched very quickly because the CPO is also a great designer." That's not at all what leadership, in my opinion, needs to do. What leadership needs to do is set direction.
[00:28:58] Flavia: What I find great about Spotify and how we operate is that leadership actually looks at the market, the industry, the evolution, and then doesn't just spit it out and say, "Hey, these are all the nuggets of information we have to share with you." They actually digest it and communicate it in a way that allows us to understand why we're moving in a certain direction and what that direction is for Spotify. The direction they give is more in terms of: here's how the market is evolving, here are the constraints we have, here's what we believe right now, and here's what we want to invest in at a very high level. These are the top five areas that we think we need to tackle to achieve the goals we set for ourselves.
[00:29:55] Flavia: And those goals are explained by all of this information about the market, about what we want to be as Spotify: what we are now, what we want to be in the future, what we need to do to go from now to then. They give us this perspective of, "We've done all of this research. We talked to a bunch of people in the industry, to who we think are the gurus. We've learned this, this and this. We reflected on our previous goals. These are the things we want to achieve next, and these are the four or five fundamental areas where we feel the biggest investment should go." Which doesn't mean nothing else should get investment. It's just that these four or five things are the priority.
[00:30:50] Flavia: When we get that, all layers of the organization, all the way down to the squad level, actually have a say in what we're doing. For example, the bets are not generated by leadership. What we call the leadership team, which is Daniel Ek's team, is not the one prescribing the bets or writing the bet and then sending it over to a manager who sends it to another manager. It's none of that. It's, "Here are the areas we need to invest in." Of course Daniel has ideas. Of course Gustav, our R&D person, has ideas. All of us have ideas. But a lot of the bets come from something a squad was doing that unveiled something important, which was then pitched and became important for the company, to the point that it became a bet for an investment.
[00:31:47] Flavia: This happens in different ways, but there is no, "Here you go, we have prescribed this to you, now you're going to go and execute it." Of course we have constraints. Of course we are big. Of course we sometimes need to make decisions about whether one squad takes this or another squad takes that, because of how big we are. But there is no prescription of "This is what we're going to work on, this is what it's going to look like, and this is how you're going to execute it." It's not that at all. It's more strategic direction, and then at each level there is a definition of, "Okay, what does this mean for us in CoreX?" That defines the CoreX investments. Then, what does this mean for the areas within CoreX? And the same process over and over again, all the way down to the squads. But it's not "Here's a feature, go build it."
[00:32:43] Flavia: That's why I really like this model, and that's why I completely changed my mind. Well, I didn't change my mind; I just adapted to a new circumstance where I actually believe in leadership. I believe in what they're saying and the investments they're making. So it's more, "Okay, how do we put a spin on this? How do we make sure it gets executed the best way possible, bringing the user experience know-how, bringing all of the things that leadership doesn't have at that very nitty-gritty level?" So it's top-down, but it's also bottom-up, if that makes sense. It's like a cycle.
[00:33:23] Rory: That makes a lot of sense. The way I'm interpreting it is that, in my experience, leadership often tells you to do something but without the context, and as you were saying, their context is huge: the research into the market and all that. The other bit I found frustrated teams was the lack of agency. They might have ideas but no way of getting those ideas up. It sounds like you've managed to get both: leadership giving the context of why they're asking for certain things, not just "do this," as well as allowing the agency to bubble up and come through.
[00:34:04] Flavia: Right. It's not perfect. I'm making it sound perfect; it's not. We have a long way to go. If you talk to people at Spotify, Spotify is very different depending on who you talk to. Even the way we build products is fundamentally different from mission to mission, unit to unit. There are lots of things we need to work on, and there are processes that need to be adjusted. But in general there is a good structure, and there is this feedback loop of, okay, we're feeding up, and then up feeds down. It's this circle of feedback loops, I guess.
When to add structure
[00:34:44] Rory: Great. One question from the audience: when would you say pure autonomy starts to break down, and when do you need to start looking at making those implicit boundaries a bit more explicit because of your scale, making sure you have cross-compatibility, alignment, avoiding duplication, et cetera?
[00:35:09] Flavia: That's such a good question. There are things that I think should be intentionally done early on without hindering progress, like those stack decisions. It doesn't mean you should do everything by the book and take longer because now you have these rules. Honestly, you might not live long enough to actually need those rules. But just some little things in the beginning, such as, "Hey, when we start growing... we have to build these things bearing in mind that if we succeed and we grow, we will have these growing pains. So in the process, can we minimize this a little bit? Yes or no?" And then make that decision. If the cost of implementing those things is much higher than the risk of not doing them, just go ahead, because you have to make your startup work. So some of those things should be done in the beginning.
[00:36:15] Flavia: Another thing I found, especially now at Spotify, that I would do if I went back to a startup, is the mindset: setting the right expectations. Letting people know, as you were saying earlier, Rory, that you are getting direction; you just don't realize you're getting direction. Direction is needed, and it's needed for a reason. You're still the expert. You're still the person, or the squad, the team, that will probably make the best decisions about certain things. But just because you're in the same room with everybody, and you hear things here and there and connect the dots and suddenly it makes sense to you, doesn't mean you're actually working that autonomously. You're not. You're working with your squad, you're working with your counterparts, you're working with your leadership team, you're pressured by runway. So you are pressured, you have constraints.
[00:37:15] Flavia: Raising this awareness early on, that this is happening already, will help later on, when we have to start talking about, "Hey, we need to do more alignment, we need to do more of this." There isn't that shock of, "Wait a second, I was working autonomously, and now I have to justify to people that I need to do this and that." You always had to; you just had fewer constraints. And now we're growing, and with that growth come really good things, and then things that are not as pleasant.
[00:37:46] Flavia: To answer that question directly: these things come very early on. I think when you start seeing, or even before you start seeing, that there could be overlaps, that's probably a good sign that you need to put in some structure. You have a clear vision, you have clear goals that everybody needs to achieve, but when you start sensing that not everybody interprets them the same way, that there start to be, "Oh no, I understood this, not that," and then people are working on different things in parallel and they don't match. When you start to notice that there are overlaps in the work, that the squads are not communicating, so there's no longer that startup feel of everybody knowing everything, and you start to see, "Wait a second, I didn't know you guys were working on that," that's the moment when you go, "Wait a second, we need to find a forum."
[00:38:38] Flavia: And please don't go overboard. I hate processes. I suck at them. It's probably the worst thing that I do. If I could not do planning, I wouldn't do planning. This is awful to admit, but I hate these processes. But they're very much needed. So just start really small. When you start seeing signs that, hey, we're growing, we're starting to lose track of what's going on, that's probably the moment when you start creating small forums to align everybody, to make sure everybody's running in the same direction and that everybody understands their role.
[00:39:12] Flavia: That's so important, because when you are in a startup in the early stages, you wear many hats. You do it all. You work on this today, and then you're fine working on that tomorrow. There's a point beyond which you will see squads saying, "Wait a second, that's not mine. That's not my thing to do." By then you've already passed the stage where you needed to put some structure around it. So make sure that everybody understands their new role, moving from everybody doing everything and trying to achieve something, to, "Okay, now I have something that I'm responsible and accountable for, and that fits into a bigger structure." You need to do this at that point.
[00:39:58] Flavia: Sorry, I haven't thought about when the right moment is until now. I guess there isn't a right moment. You almost anticipate the growing pains, and you work with the squads, you work with your system, you make sure that the strategy is always very clear, et cetera. And then you deal with the growing pains, because no matter how prepared you are and no matter how much structure you put around your company, you're going to have growing pains. You will never find that sweet spot of growing just enough to do what we want to do, but not so much that you end up with problems. We could talk about it for another hour.
Tech debt, product debt and process debt
[00:40:42] Rory: The analogy, and Kevin Ruth [?] said it, was that when you have a startup you're going to build tech debt, because you don't know what works. You're going to go down dead ends and wrong avenues, and you just have to acknowledge that and move quick. If you survive to the next phase, then you can invest in paying down that tech debt. But I always think there's a corollary to tech debt. There's also product debt, where you have to kill off features that didn't work. There's design debt, where you have to redesign things. And there's process debt. When you hit certain stages, you have to be continuously thinking, "When do I pay this down?" Because if I don't pay it down, everything's just going to start slowing down to a crawl.
[00:41:27] Flavia: That's so true. I was thinking about what you were saying about when we pay it. There's always a reluctance to pay. This is anecdotal, I've only worked in ten companies so far, but what I've noticed is that we end up spending an awful lot of time doing processes. OKRs, oh my God, the time we spend moving the whole organization, especially if we're talking about a thousand-plus-person organization, aligning everybody on OKRs. Just take 10% of that time and invest it in your debt across the organization.
[00:42:09] Flavia: The same thing with features. Don't just build more and more and more features. Spend some time killing them, assessing what makes sense and what doesn't. What I often hear is, "Oh yeah, it's not giving us much, but it's also not doing any harm." It's doing a lot of harm, because you still have to do maintenance and support. It's still going to break. You're going to have to invest in it. It's going to hinder you later on and prevent you from doing things. Performance-wise, you might not see a drop, because that thing is over there, but it does have real costs. So investing some time in that debt is 100% worth it. And if companies say they don't have time to do it, it's a lie. They do. We spend an awful lot of time on things that are, frankly, useless most of the time.
Shifting the mindset
[00:43:02] Rory: I think Stephen said yesterday that he allocates 40% of team time to tech debt and maintenance, and then in the rest he tries to squeeze in his new features. We're very tight on time, but I just want to touch on one last question, which is the mindset shift, because you said you would work on the mindset. As we've said, it's not that you're imposing new boundaries; you're just making the implicit ones explicit. How has that been for you, and for the individuals perceiving their autonomy?
[00:43:44] Flavia: It's a challenge. As a leader, you have to be willing to be the common enemy for a while. I think I'm lucky in the sense that I have very tight relationships with the people I manage and with the teams in general. I've managed engineering before, but I've also not managed engineering and treated them as my own team, because they are my team: engineering, design, insights, et cetera. I'm fortunate that I build these strong relationships with people, so they give me the benefit of the doubt even when they don't see eye to eye with me, when they're like, "What the hell are you trying to do? This goes against everything that we want." They still say, "Okay, we like you. We know you've done this in the past."
[00:44:40] Flavia: Especially when I've been longer in an organization than I've been at Spotify, they've seen me operate, and they remember, "Oh, we also thought this, and then we saw the light at the end of the tunnel." So they trust me. But it's a painful process, because you have to go against everything that people want, their own personal drivers in their professional lives. Some people are easier than others to convince about this path, and it's just about having a simple conversation: "Hey, this is where your role fits, this is what we expect, and this is how much I need you to achieve this goal."
[00:45:22] Flavia: It's always about reminding people how important they are. I think the majority of companies forget that each individual person, of course we have low performers and people who are problematic, but in general every person we hire has a very important place in the organization, and without them we're not going to achieve anything. That's why my number one pillar is supporting people, caring about the team, nurturing them, growing them, reminding them of these things: this is where you fit in the organization, this is how important you are for the business, this is what you have brought before, and this is what I want you to do going forward.
[00:46:00] Flavia: With other people it's more painful. I've had situations where I had three-hour-long conversations with people crying and my heart completely broken, because it was visibly upsetting, and people were completely lost because of what I was saying. It's not that they disagreed. It's almost like you pull the rug from under their feet. Everything they believed in suddenly gets questioned, and it kind of makes sense, so it's even more, "What is going on here? What she's saying makes sense, but this goes against everything I believe in."
[00:46:43] Flavia: Those people, believe it or not, the ones you have three-hour crying conversations with about "this is what the future is going to look like and this is how it's going to affect you," became my best leaders, because they adjusted. It was a shock, and then they adjusted to this new reality and understood what it means to work in a different way.
[00:47:06] Flavia: Just a final thing, I promise I will wrap up now: showing them the future. If you find a way of showing them that there is a better world, that you're not taking anything from them, you're evolving the organization, and in the majority of cases you're actually making their jobs much better, even though it doesn't seem like it, then when people buy into that vision, the process just goes smoothly. It's so much easier, even with the crying sessions.
[00:47:44] Rory: Brilliant.

