Spotify nie używa modelu Spotify. Twoja firma też nie powinna?
Zwinne Organizacje | Podcast o agile | odc. 25
W kwietniu 2020 w sieci pojawił się artykuł „Failed Squad Goals”, który wstrząsnął agile coachami na całym świecie, bo mówił o tym, że Spotify Model nie działa w praktyce.
W dwudziestym piątym odcinku podcastu „Zwinne organizacje” Paweł Tomkiel rozmawia z jednym z autorów artykułu - Jeremiah Lee. Zapraszamy do słuchania.
Paweł: Cześć, nazywam się Paweł Tomkiel i jestem agile coachem w Deloitte Digital.
Zanim przejdziemy do wywiadu, chciałbym powiedzieć, że słowo „failed” w kontekście „failed model”, „Failed Squad Goals”, tak jak jest zatytułowany ten artykuł, wydaje się być bardzo mocne. Warto, żebym powiedział, że uwielbiam Spotify, ich produkty są świetne i właściwie nie będziemy rozmawiać o firmie Spotify, tylko o Spotify Model. Czyli o modelu operacyjnym Spotify, który jest nazwany Spotify Model. Został on opisany i opublikowany przez agile coachów Spotify w 2012 roku. Jak podkreślali autorzy, już wtedy ten model był tylko po części rzeczywistym stanem rzeczy w firmie Spotify, a po części był wyobrażeniem, taką Gwiazdą Północną, do której chcieli dążyć. Było to dobre parę lat temu, a jednak model ten jest powielany przez kolejne organizacje, mimo, że Spotify zmieniało go i ciągle się zmienia jako organizacja, która nie przestaje rosnąć. I właśnie o tym rozmawiamy z Jeremiah Lee. Zapraszam serdecznie do rozmowy.
Paweł: In today's episode of the agile organisation podcast, I'm interviewing Jeremiah Lee. Jeremiah, as you describe yourself, you're a Californian living in Stockholm, living in Sweden. The list of companies you have worked for is impressive because we have Fitbit, Disney, Apple, we have several start-ups, and you currently work for InVision. I believe we are using InVision in Deloitte Digital right now in Poland so thank you for your work.
However, we are meeting because you work for one of the most known company in the agile world - Spotify. Spotify introduced Spotify Model, and you wrote an article in 2020 called "Failed Squad Goals", where you described why the Spotify Model was not working for Spotify even. A lot of companies implemented it since then, so maybe we would start with your introduction. Who are you, and what you do for leaving right now?
Jeremiah: Hi, I'm Jeremiah Lee. I am a Californian living in Stockholm, an engineering manager, specialising in APIs and platform products and a founder. I'm currently an engineering manager at InVision, a platform for design product in engineering collaboration. For Spotify, I was the product manager for its embedded as DK, which is seen as DK that takes Spotify experience and put into all sorts of embedded devices, like smartwatches and smart speakers and game consoles, TVs and just all over a place.
Paweł: Maybe to lay some foundation for our listeners, how would you describe the Spotify model and we're getting in it.
Jeremiah: Yeah, so in 2012 Spotify published a blog post and video about its way of working, and those are what became known as the Spotify Model, but to be clear, Spotify's never called that. At the time, Spotify was continuously evolving its way of working, and for a moment, the company did something remarkable. It chose to build out in the open. Only had some point the company stopped looking out in the open and forgot to tell anyone, so everyone assumed that Spotify published that point in time must have been the magical combination to maintain the speed and numbness of a small team and as a group. The Spotify model is two ideas that we would call today to streamline teems and Matrix management, but Raptors ideas up and away. So summarised it, Spotify had teams called Squads and organised a group of teams into a department called Tribe, and a business unit called a Mission. Each team supposed to be many autonomous start-ups with the product manager acting as many CEOs for each area. It seems they had designers and engineers with a wide range of specialisations. The intent was that team should have every skill necessary on it without having to rely on another team to succeed, so this is not a new idea. The idea of four stack multi-discipline product engineering teams was more commonly for two as an agile feature team in the two thousand arts. Anything more common for today might be a streamlined team or even a scrum team. So the other central element of the Spotify model was major management, so its engineers were called Chapter Leeds. They manage software engineers that specialise in a specific type of software development and cross the department. For example, all software engineers who might come back and apply across all department teams would have one manager and all of the injury. I was immobile engineers, and the department there has a different manager. It was to allow engineers to move between teams within the department to best meet the needs of the business without people having changed managers now. It was well-intentioned. Still, the drawbacks far exceeded that one benefit.
Paweł: To clarify, one thing here: chapters work like just a function of people, so just functional cross-organisational team that align and try to enforce consistency and enforce some structure for back an API for front and user experience and so one, is that correct?
Jeremiah: That's right. Those of its intensity, because if you have no one team producing feature inside and ended up at the end of the day, saw the ship a single binary already Google, so it had to get everyone's code to come together. So everyone in all the hundred engineers are talking with all the other hundred engineers, and they should be approaching their work and a summer manner because it does have to go out as a single thing in the end. It doesn't apply so much to back on APIs like we generally give microservices. It is also the idea of microfinance. Maybe that benefit is a little less applicable today, but that was the idea.
Paweł: And isn't that your first point in your article where you said the Matrix management solved the wrong problem, so what problem did Spotify tried to solve that and what was a conclusion?
Jeremiah: The notion of Matrix management would have a bunch of self-organising teams and be constantly reorganising. The work with us will be so dynamic that the people composing the team would be in constant flux. Honestly don't think that's a good way of managing teams. Put it into a more significant issue here that, like engineering management has a function, so engineering management in the model had little responsibility beyond the career development of the people they managed. One of the things I have learned about great managers is that they understand the dynamics of the individuals on a team. If a manager doesn't interact with the entire team, they can't solve some of the interpersonal in-collaborations problems within the group. The other aspect of this is that managers themselves are accountable for anything related to the delivery business value. They're career coaches for the engineers, and for me, this is a very dismissive view of the value of engineering management. I think the engineering manager should be accountable for the team's performance as a unit. Others should be like you can use this analogy of any CEO inside of team like there should be equivalent CTO on the team. That's what you get used to metrics management because a manager spread across many teams and then only managing one or maybe people on a team. Spotify eventually learned that these drawbacks also learn that moving people between teams breaks up the team and that assembling a unit in itself takes time. I don't think there was a belief that offer engineers were gears that could replace machine were the same but like we set to remember the importance of the team in which they're working, so individual matter but that he matters more. A team should be more than some of its parts, and that's what an engineering manager should be doing.
Paweł: If we can give an example, let's say I'm a developer on Spotify, how often would I change the teams, how many managers I would have above me, how many people would manage my work?
Jeremiah: The answer to that is - it depends. Spotify is a company that has never stopped growing. It's been increasing since we started it, so we are adding more people. The composition of the teams is going to change. How frequently you changed teams, it's going to be unique to every individual experience. When we up seeing that people didn't change, teams are often. Still, there were discussions about the engineers and betting on other teams. Often from multiple quarters, which just further added to the problem of the value of that team being like a composed unit is functioning as a team like if I'm working with another team for two or three quarters, I'm part of the team that borrowed me.
Paweł: And now moving to the second point, which is a fixation on team autonomy, why did Spotify want teams maximum independence in the first place?
Jeremiah: Something I love about Swedish society is how aggressively egalitarian it is. I think Swedish society hierarchies are questioned with suspicion and personally given the inequality and inequity in the world. I think that's a great starting point. In other cultures, you can see how strict hierarchies are reinforced like you dare question the establishment, which seems antithetical to innovation trying to disrupt something established. Autonomy is not wrong, and I think autonomy is a requirement for individual happiness in general. You want to be able to control your life in your destiny. There is the spectrum where one side is absolute control where few people in a company dictate what many people must do. People do to work have a minor impact that's not an environment for fostering innovation. You have like a genius savant charge or something, but even then, a genius savant will miss signals that people doing the work would pick up. The other that spectrum is where individuals have absolute autonomy, and they can do whatever they want. Still, the situation that ignores the collective good and we need something in the middle, probably leaning slightly towards the side of autonomy where leaders responsible for business outcomes can direct effort but don't you to be the details of every team's execution.
Paweł: That sounds like to be in line with old agile values. When you give this autonomy to the team and foster innovation, why didn't it work?
Jeremiah: I think you have to go back to why Spotify emphasise a time so much in the first place. I believe our people there had an initial none of success the company was growing. They felt like the company was slowing down. The comparison no just how fast they used to feel when they were a smaller company. A cult of the illusion of early-stage speed, there's a feeling that things think fast with your early in a start-up, but that speed is entirely a mirage. Things feel fast because you don't have to worry about the scale of support of customers yet, and you're also doing the easiest things first because you want to minimise investment improving at an idea just a case that idea doesn't work out. But as you get more successful, you have to start building for scale from the start. As you get competitors, the competition can also quickly do things that you did quickly. They can only do them now faster because I can look at what you have already proven out, don't have to do the other experiments, and copy that point. So, good look at what works for you and billions that, and then the next set of product differentiation typically comes from features that are just more difficult to build. So now you need more people to support everything you've already constructed well while you're also making new things. Things start to feel slower because it's not that it's more challenging to create. It's because you have to create more difficult things both in the grander ambition of the features and account for scale from the onset of anything. Spotify completely missed this point. They didn't understand that they thought things are going slower because they had to coordinate too much with other teams. Hence, they prioritised individual autonomy over everything else, and I think it resulted in a fair amount of chaos.
Teams were rebuilding the same features that other team said already built. Teams are choosing multiple tools to solve the same problems. Collaboration just got squashed because no one wanted a dependency on another team, but the reality is like that dependency is for anyway. At the end of the day should be like a single area of all the team's work. Spotify didn't focus enough on alignment and accountability desert just as crucial as autonomy and are under one of the others of the original Spotify blog post even gods to me like they're supposed to follow-ups for house Spotify was going to implement those. Still, he had never finished bed that resulted in a fixation on autonomy that might speed up an individual team that you make the company overall slower, and that's what happened as Spotify grew. In the article, I wrote that the company with small teams has a wide range of work to deliver and frequently shift initiatives. But as a company grows, should reduce the duplication of effort by shifting those duplicate functions to new teams dedicated to taking care of component. When you do that enough, then team's benefit from having compositional tools they can realise, and then they can think we're deeply among term about the problems are being asked to solve. Differentiate them in the marketplace, but to do that, someone has to be thinking strategically about that team competition. Teams have to be OK with a little less autonomy in dependency on another team that provides a component. I just something spot by the fiver down that balance at the point which you wrote those articles and video.
Paweł: Basically, from what you are saying, I understand that autonomy helps to increase agility, increase speed in the start-up face of any company. However, later on, you need to set some dependence management processes, some resource management for you create this value as a whole company, not each team individually.
Jeremiah: Looking at an example of this was like one point Spotify rolled out of the Facebook workplace. It's like Facebook for companies. It's a pretty cool product, but I also have luck and compliance. And good box and box and quickly so many of a place but possibly put information as I'd like Google groups and email listen. Your question came up which tool should we use to announce something cool that our team has done. Do I have to send it now email to an email list, publish on multiple channels, post the page on confluence, and post the post to the Facebook workplace? So they can give some guidance on how we should do internal communication, which tool we should use to share that information. One of the happenings have conversations about what we announce into the company. There are many places where you place it. People participate in one area of discussion, like not being seen in a conversation on the Facebook workplace. It is one of the single areas we will reduce the man of autonomy you have regarding internal communication to create inefficiency. So that we know you don't have to check five different places, you get an understanding of what's going on in the company or be part of the conversation happening around something.
Paweł: Exactly, and access management now it's much easier to manage multiple people's access in one to tens of them. The third point in your article was that collaboration was an assumed competency, and I believe that's connected to the usage of tools and how you communicate with the rest of the company. So what processes were lacking and needed one to structure those collaborations? If it was an assumed competency, what would help?
Jeremiah: As I mentioned in the article, many people didn't have a basic understanding of agile practices, but they were responsible for their teams for figuring it out. So you don't bother to learn about a subject by studying what came before. You are going to take a long time to become proficient in that subject. Learning from first principles can be good, but just what is happening is that people thought that trying something different was because they could sense that their practices inside the team were not working. They try other things hoping that you don't have somehow by generating through all these variations as they would finally figure out of the network for them I have a word for that. I call that should provide a rating, and that's when you're mindlessly narrating through something instead of forming a hypothesis about the thing that is changing and measuring the outcome. I think it was a lot of that Spotify regarding essential team planning, which I don't think is the best use of engineer's time, so that's a lot away all. I haven't worked there for three years. I still have friends there, and I know things. I've heard things have improved, which is great to hear.
Paweł: My question to that collaboration, to that process in the organisation, would be: where did you have any PMO unit, some central unit for organising processes and for managing work for dependency management, for resource planning?
Jeremiah: When I worked in Spotify four years ago, it did not have a PMO but did have this process called the Bet process. It was a ranked list of all the company's priorities to get any level of cross-organisation prioritisation. It had an executive to make your initiative bet. It would be all the most important going on inside the company for a quarter more. It was a fairly terrible way of getting across a moment in the organisation because it required going to the highest level of the organisation to get authority to tell another tribe that my work matters and you need to prioritise this. There is no defined practice, and the company forgetting work prioritises across business units and departments. I think Spotify just told teams to look starting at the very base. We don't care if you use on banners scrum, we're going to use dirt track overwork, and we're going to teach you to write user stories and fine epics on track dependency to create good work definition. And this is our standard way of proposing work to another team and how you can track it. We will give you project program managers to help coordinate some other more significant initiatives. By the way, they're also monitoring work and status and a standard way so that anyone says the organisation can figure out our project. I think we've done amazing things for the individual team's proactivity, and then we can focus on the opposition line and practices. I don't think you need the PMO. Still, like there are things you can do to improve design practices, here are the essential metrics to the business, and everyone should connect their work to them. We should be able to answer many prioritisation questions by evaluating our proposed efforts against those outcomes. There's an idea of tight - loose- tight. Where it has to be tight on setting expectations and precisely what you want people to do. They need to be loose in giving people freedom and empowerment to figure out the best way to meet those targets. But the need to be tight again on the follow-up, so people are accountable.
Paweł: That's what you described team autonomy, however, with set up dependency management and communication processes.
Jeremiah: Yeah, it is basically how can we create smart defaults inside of the organisation so that when people like how do I do X inside the company, OK I know how to do X, now I don't have to think about that. It might not be the best process in the world, but it is a divine process that I can engage with. It will allow me not to think deeply about a process or practice and go back to focusing on something that I wanted to open to somehow against the business.
Paweł: Case of giving people checklists for what could be wrapped up in the process, great.
I believe now we can move onto the last point in your article, which was that mythology became challenging to change. From this point, I understood that Spotify Model was nothing more than just renaming business units, department teams, and manager. Is the correct assumption here? Is it true?
Jeremiah: Well, I think we break down the ideas behind Spotify Model what we get our streamlined teams in Matrix management, and both of those ideas predate Spotify, and we didn't need weird words to talk about those ideas and at the start so we can use clear language without mystique. We also know that matrix management was a terrible idea that even Spotify been in, so you left with our streamlined teams called squads for no apparent reason.
Paweł: My question is why the world is adopting Spotify Model? Everyone speaking about Spotify Model wanted to implement, adapt, introduce chapters, and raise tribes and squats, so is it just because it sounds cool? What's the reason for that?
Jeremiah: I think companies, especially those established industries that may be undergoing a digital transformation and feeling those competitive threats from digital natives, feel threatened in looking for quick fixes, and the Spotify Model is deceptively simple. It also didn't work, so it fools people twice. It seems like a quick fix to what is fundamentally very difficult as orders humanity and how people work together efficiently.
Paweł: A lot of great thoughts. We had many episodes when we say the word tribe when we say the word scrum what we even implemented squads in one of the organisations that we worked with, so now hearing that from you is making the feeling worse.
Jeremiah: But we shouldn't feel bad. It is a complicated problem. It's good to try to solve the problem, and being an excellent agile company, you should be able to try something experiment value to see if it served at school and change and evolve if it didn't. It's not a terrible starting point. Fundamentally, agile practices help any business that is now having to use and engage with software in engineering design collaboration to keep their business relevant.
Paweł: How did the Spotify model worked at different points in time and when it started to struggle, and when it was working?
Jeremiah: One of the most exciting things about the original Spotify blog post and video they feel often gets ignored. The paper explicitly said Spotify, like any good agile company, is evolving fast. This article only a snapshot of a currently working I love is a journey in progress, not a journey completed by reading. These things will have already changed from the very beginning at the moment it was published. It was a plan that was never fully realised. A program that ended up changing without an equal amount of fanfare that's not adding about Spotify, against Spotify, struggling as a natural part of any growth, and Spotify is a unique unfortunate company and has never stopped increasing in size. So it never stops working with how to organise efforts arguably never got good at it but was also never so bad that it was harming the marketplace because of it. I honestly in the company could be even more successful if it stops throwing money at its inefficiency problems with none of the hiring, but now I'm an executive there.
Paweł: Now closing, Jeremiah, if our listeners want to find out more about your work, where they should start?
Jeremiah: First of all, thank you for the conversation. You can find me at JeremiahLee.com, and I am active on Twitter on LinkedIn as Jeremiah Lee.
Paweł: Thank you for taking your time. Thank you for all those insights. I believe that's pretty valuable to all our listeners interested in increasing agility in their organisations. So thank you, Jeremiah, and I hope to speak soon.
Dziękuję również współautorom artykułu "Faild Squad Goals": Rolandowi Siebelink oraz Jasononowi Harmon.