Squads, Tribes, Chapters and Guilds at Spotify. The origin story with Joakim Sundén, someone who was in the room when deciding the language.
It’s the Age of Digital and we’re all living in it. Sooner Safer Happier is a podcast orchestrated to help you on your unique journey to improving ways of working.
Hosted by Jon Smart, business agility practitioner, thought leader, coach, and author of Sooner Safer Happier. Jon is also the founder of the Enterprise Agility Leaders Network. Follow the podcast as Smart delves into conversation with business professionals and provides advice for a Ways of Working transformational journey.
Listen now to be at the front of change and ahead of the competition.
Transcript:
Jon Smart: Hi my name's Jon Smart welcome to the next Sooner Safer Happier podcast and I'm delighted to be joined by Joakim Sundén hi Joakim
Joakim Sundén: Hello hi I'm glad to be here thanks for inviting me
Jon Smart: Great to have you here. So Joakim was previously one of the first agile coaches at Spotify. Joakim and I have known each other for quite a while I was lucky enough to go and visit Spotify in New York in kind of the early days of squads, tribes, chapters, and guilds and Joakim was kind of fundamental to the construct of multidisciplinary teams, teams of teams, and the kind of the well publicised Spotify model so Joakim maybe you could introduce yourself you know say a bit about your background and then interested to hear more about your time at Spotify
Joakim Sundén: So from Sweden born and raised. My name's actually pronounced Joakim Sundén in Swedish but and I joined Spotify in 2011 I was already working as an agile coach with a background as a developer and an architect and then moved on to Agile coaching and I was employed as one of the first agile coaches when we were around eight to 10 teams and I went along for the journey until 2017 so six and a half years roughly or more than 200 teams at the end or squads as we would end up calling it. So mostly in Stockholm where the company's headquarters were are still are and also I lived in the US and worked in Boston and New York and also with the San Francisco teams for a while and now with Crisp a small boutique consultancy in Sweden doing more of that spreading the the gospel of great ways of working to other helping other companies and organisations
Jon Smart: So this topic of the Spotify model quite a lot of people have heard of the spot the so-called Spotify model and I know you've done conference talks and some of your colleagues have done conference talks about you know the Spotify model is not the Spotify model and don't just copy the Spotify model so and what I love about your experience is that you there you were in the room when the conversation was had around what language do we use and what do we call it so I am super grateful to have the opportunity to have this chat with you to kind of dig into the archaeology of you know the language and how you came to use these terms at Spotify and when I talk about the language and the terms I'm talking about squads, tribes, chapters, and guilds and so this is the move for from role-based silos, work passing, to multidisciplinary teams so Joakim if you could say a little bit about the background you know and at Spotify you know what was the what was the problem that was looking to be addressed and then how did you how did you come to be using these words yeah?
Joakim Sundén: So when it came to language and naming it squads and chapters in particular that was for very practical reasons early on we were growing like crazy and you know when when I met someone at the office I was wasn't sure are you a guest, a visitor, or is that someone new and you would ask so what what team are you on and they would say something like backend 2 or web 3 and that's the team they had been recruited into the functional team led by the manager and I was like no no no you're scrum team and they were like we don't work with scrum and well the team were you're oh that's bits or something like that so so so we said this doesn't cut it and then we basically just called a meeting some other coaches took the initiative we were we were maybe three at the time and just said we we want to come up with some more clear naming and we also had different names in different department department so there was still a division between technology and and operations and in one it was called team and in one it was actually called a guild what we later would be called chapters as it was confusion all around so we just wanted to settle for okay we need to be more clear on this and we had some suggestions and and people yeah some some some suggested the fire team you know work party or party maybe also from role playing that's part the party and I suggested crew or or work crew but then someone suggested squad mostly because of of you know hip hop connotations rather than than warfare or military and at the end of the day we just had a vote and and that's what won
Jon Smart: That's interesting I I didn't know I didn't know that I didn't know that the kind of the logic behind the word squad was from hip hop that's interesting so we get large traditional organisations adopting squads little do they know that has a hip-hop origin
Joakim Sundén: Yeah exactly the music context of course
Jon Smart: Nice and then and then what about some of the the origins of the word tribe you know what were the I'm interested what was the conversation in the room around landing on the word tribe where my understanding is a tribe is a collection of squads
Joakim Sundén: Yeah so when we knew that we were already seeing some some challenges with with growth so we started thinking about how can we actually grow in a way where we still can keep people yeah feeling that like they have access and that they are still part of establishing direction are empowered and trusted and and have a strong sense also of relatedness so we wanted these empowered or as we call it autonomous teams or autonomous squads at the time and we were concerned that we would lose that if we start adding hierarchy and so on so we looked at how can we basically mirroring the the concept of of autonomy and empowerment on the squad level okay when we grow we will probably be need more people involved in the same mission or or sub product as we sometimes call it so that's it came natural to then organise around these missions or or sub products also on the tribe level and we discussed things like the Dunbar’s number I studied social anthropology at the University and and also I think that that this was mentioned also in in Bas Vodde and Craig Larman’s books on scaling agile that we read as a book club basically that there's a limit to the amount of people that you can have meaningful social relationships to and before you start dividing into well subtribes as as you would call it and he studied of course nomadic tribes and and other tribes and and that's basically the the inspiration to the name we really wanted this relatedness and back to the the Golden Age of feeling you know oh I know who who to go to for help they will they will know who I am so they be gladly offer me help so so a strong focus on this sense of relatedness and and that's something I've seen also after Spotify when I've been working as a consultant there are many other skilled frameworks with agile release trains for example a popular one that doesn't really convey this feeling of unity and and relatedness and also when I typically look at these organisations they they don't even view it like that and they don't they missed out on the opportunity that that we invested a lot in which is building a sense of team in a team of teams or tribal unity so so I think that's that's what stood out about the name tribe
Jon Smart: I like that I like the unity angle that's that's really interesting and it's also interesting what you said you studied as well in terms of did you say you studied anthropology
Joakim Sundén: Yeah social anthropology
Jon Smart: Social anthropology yeah I think and that obviously helps on this topic that's that's really interesting the point around unity and I guess that's your identity your identity is if I if you ask someone where they work they'll say I work in this squad or I work in this tribe not you know I'm a software engineer or I'm a data engineer but rather I work on the the desktop front end tribe I imagine that's what you're striving for with that unity and identity
Joakim Sundén: Yeah exactly and I think that's also a big part of of Spotify's culture that we really well we tried to create and nurture as well that that this feeling of we're all in this together so really from the start never ever building silos and and saying that you know oh no that's not my job that's not my responsibility but really cultivating okay that I understand the problem that needs to be solved how can I contribute so so that's what we were for as well
Jon Smart: Yeah and on the topic of the language of tribes where you know when you were in the room talking about what words to use were there any other words that were being suggested being floated in the room?
Joakim Sundén: For tribe I think I don't really remember but I think that like product area or or even something more like subproduct was used we also talked about you know early on there was an idea that oh we talked about different layers so it would be the the infrastructure layer and the the product layer and the the service layer but you know pretty quickly we realised that that was not the right lines to to divide the organisation by and and not a good word to to use for that so it wasn't actually considered but but it was kind of used
Jon Smart: Yeah was there something about I seem to remember hearing something a story about motorcycle gangs or something was there something that sounded a bit too much like a motorcycle gang
Joakim Sundén: Yeah so so when we we I I mentioned squad but but we also discussed different words for chapters and guilds and so I remember Hell's Angels being floated as a as an example of of chapters I think it was an argument against chapters actually but but it won out in the end and and I think actually we we we we called it guilds what would later become a chapter and then we kind of when we grew we we inverted it so so the the smaller one be became a chapter. So it was a chapter of a guild basically so we would have a global backend guild and in the tribes we would have a local chapter of that global backend guild
Jon Smart: Yeah okay so there was some conversation around chapter might sound too much like a Hell's Angels chapter but nevertheless the word chapter continued
Joakim Sundén: Yeah I think it's those mediaeval or craftspersonship connotations around the guild so that's what a chapter of that guild where you would own your craft basically
Jon Smart: Makes sense
Joakim Sundén: The reason why we we also settled on on these words was that we we we really wanted to you know make it sure that that our culture is different we we wanted to broadcast that basically and we didn't want people to come with preconceived notions of oh yeah I know what a team is I know what a scrum team is we actually consciously chose different words to convey different meaning and use that to emphasise a shifting culture we are a special company it is different it's not your regular team and and strengthening the the identity like that and then we could also fill these terms that we came up with on our own with our meaning and what we wanted to to to emphasise and that's the of course the irony then of of people later copying those things that that irony wasn't lost on us and that's what you were talking about when we started saying don't copy the Spotify model and
Jon Smart: And and just on that point I guess that's your that would that be your advice would your advice be to not copy the Spotify model?
Joakim Sundén: Yeah so I went back and forth on on that over the years and I think that maybe you know we heard some horror stories early on that the people that just you know oh we're changing department to tribe and and team to squad and and you can now wear jeans on weekday it's like transformation done and yeah we were concerned that blindly copying and and that that would you know well reflect badly on on what we conveyed with it and and represent a misunderstanding of what we tried to do but also that you you know you would not get really good results but the more we started talking to people and used the Spotify model and also later in my consulting many tell you know great stories about how this you know transformations and change is a lot about communication and these names and and the the great videos and and the imaging around it it’s more well more approachable and and fun and engaging to a lot of engineers and and and people in the teams than oh say don't want to point out any other framework or or big consultancies but but that might not be as as as easily or or well received so so as long as you do it with a you know thinking deeply about what are we actually trying to achieve and what do we want to change and maybe define your own meaning or or project clearly what what do we mean by tribe what do we mean by squads and it could work
Jon Smart: Yeah that and that resonates with my experience as well which is start with the why as you said be very clear about why you're doing this what are you trying to achieve and I think there is a there is a human behaviour of you know the thing for the sake of the thing, agile for the sake of agile, squads and tribes for the sake of squads and tribes trendy words trendy terms let's copy and then done badly it's new labels on the same old behaviour. So I think it also has to come with a whole cultural element as well in my experience which I'd I'm going to come back to actually I'd love to ask you some questions about the culture at Spotify. So squads, multidisciplinary teams, tribes, team of teams aligned to an area of value is my understanding for a tribe and in the case of Spotify that might be kind of desktop client it might be iOS client it might be and I don't know the exact terms but I guess player different different different bounded context of value
Joakim Sundén: Sure we would more express it in terms of customer segment or or outcome so user engagement for instance or creator tribe and we would have squads that could either be well around the popular products such as the the Discover weekly Squad or the it could also be more about the functionality when it's more like a platform functionality that you offer internally but but also is an external one like playback the music with would be within the music player tribe but it could also be growth opportunities, bundling experience, partner partner integrations taste on boarding and things like that so
Jon Smart: And the reason for doing this is to one reason is to optimise for the flow of value so you've got multidisciplinary teams like playing rugby you're moving up and down the pitch together with the ball you're not playing a relay race you're not passing the baton and something you said earlier is we're all in this together you know everybody owns working together to get the good outcome. So once you once at Spotify once a tribe kind of a a a bounded context of value be it what you just said in terms of could be partners it could be discovery weekly once I had been identified I'm interested to understand how much ongoing flexibility there then was so you know there'll be impediments to the flow of value and that might involve changing the shape of that tribe we might be missing some skill sets it might not be quite the right boundary so I'm interested if you could talk through you know how you saw them evolve over time
Joakim Sundén: Oh yeah that's that's a big topic but I'll try and so the way I viewed it is that instead of having say a portfolio of projects or programs or initiatives Spotify basically had a portfolio of tribes so yeah we have creator, we have user engagement, we have platform, we have data infrastructure, and so on and so leadership would focus mainly on okay what are the what are what is the the mission of creator what what is what is that we're trying to achieve and then we would use metrics or or KPIs as as a corporate speak would be for okay we we we want to have bigger reach within artists now it's just this percent of of artists using the the artist app we want to increase that we want to increase NPS and so on and then the the squads and and the leadership of the tribe they would come up with ideas on on this is some features we want to build these are some things we want to try, experiments we want to run, and this is what we think we need and there would be a dialogue with leadership almost like a venture capitalist model of of of pitching your ideas and then we say oh great we'll give you more headcount and and maybe you guys will get a little less headcount but that doesn't mean that oh we've now promised a backlog of stuff that we're going to deliver no it's rather you know you would expect them to to to learn and pivot and and and then the next quarter or the next half year that would be the basis of the of the next conversation so within that bounded context they would be free to come up pretty much with any ways they they could they would be responsible for the business results these metrics and the outcomes rather than for for delivery of of specific features or projects or or initiatives so that also means that within the tribe you can organise in whatever way you want do you want to have you know a matrix model with chapters and squads and chapter leads or do you want more traditional one engineering manager for for the the squad how do you want to coordinate, what meetings do you want to have, that's you know whatever suits your context because it's going to be very different different from a growth marketing, hacking, trying lots of different ideas and experimenting to hardware partner integrations with with people who build speakers or cars then then you'd need much more predictability and and specifications and things like that so that's was also a design goal with the tribes this this high level of of autonomy and independence but what what also happened when we when we saw changes in in the organisational structure so we we we relied a lot a lot on on what was called self- selection or has been called self- selection we didn't have a name for it a couple of consultants with us called it Squadification and and later wrote a book where they called it self-selection so it could be when I was in Boston for instance we Alexa came came out the Amazon Echo thing which threatened to put you know oh now we have a a user interface voice controlled user interface between us and the listener that we can't control we need to double down on on voice it makes sense to have that in Boston so that's more of an external thing triggering okay how should we be organized assuming that we need to to to take on this other mission and we would typically then engage everyone in the tribe management leadership would do a little bit of prep okay we think it looks like this providing context detailed information and then the the teams and and all the team members would be invited to to share their views and give feedback we will start crystallizing okay what new missions, what what changes to the squads, what competences do we need, what systems need to shift ownership, what new do we see, what do we need, and basically co-creating the the organizational design or or the evolution of it sometimes more of a revolution it's like entirely new squads but more like evolution or or small changes and then once that's in place okay what Squad makes the most sense that you're now working on and many would probably stay in in the same or or the the the new similar Squad with the same people they've been working on but but others would move and it’s not remember it's not you know oh I do I'll do whatever I want and go to whatever Squad I want no it's we're all in this together, it's what's best for Spotify what makes the most sense so so taking that responsibility of of solving the problem rather than what do I want I don't know if that answered your question or
Jon Smart: Yeah it does yeah and that's that's yeah because what I'm hearing is I'm hearing agility when there is an external market event you mentioned Amazon Echo and what I'm also hearing loud and clear is the autonomy so there is a there's a very clear behavioural value in the company about autonomy and and I so that that's coming through loud and clear and most organisations in my experience don't have that much autonomy in that here's the pattern top down we've decided what it's going to look like and now we're going to roll out this pattern and you don't really have much of a choice and what I'm also hearing is alignment, you mentioned missions per tribe you said senior leaders will say right this is the rough direction now go figure and also what I heard you say is that people are not it's not a focus on the output like what features have you shipped it's a focus on the outcome which is amazing, fantastic, awesome, how it should be. So you've got high alignment which enables high autonomy because without the high alignment of the shared mission you can't have high autonomy because you'll just have Brownian motion laissez-faire some people go right some people go left so you've got the high alignment that's really good. A question on that high alignment in the missions, the mission rather per tribe or missions per tribe OKRs objectives and key results were were you using that language at the time?
Joakim Sundén: Yeah so so we we we started using OKRs I think in 2009 so that was even before I joined and so when I joined I had my individual OKRs as that I agreed on with my manager the tribe lead and we had on on all levels but individuals who were part of squads they didn't have objectives and key results they only had one for the squad so emphasising that it's a team effort but not individual ones and but later we replaced them with another thing for a couple of years but then OKRs came back and now I mean I haven't been at Spotify for a while but I regularly talk to a lot of people there and it's it's OKRs more than than ever so that's absolutely widely being used but no more now more on a tribe level that's how it was reintroduced but now also squads have started using it because once it's on the tribe level it's basically the squads contributing to creating the OKRs tribe level so then it becomes natural to also either some it would suffice to be guided by the tribes OKRs and in some instances you would probably come up with squad specific OKRs
Jon Smart: Yeah awesome amazing I really I really do think that is a success pattern when you've got OKRs, multidisciplinary teams, you've got high alignment, you can have high autonomy. In terms of the autonomy enabling different ways of working within the tribes and you gave some examples of you know one might be a bit more hardware focused one might be a bit less hardware focused so there wasn't prescription about how you organised or worked within the tribes was there a flip side to that flexibility was there a downside to that so if you did want to have any movement between squads between tribes did it mean that you've got to learn a different way of working or was was there was there any kind of like flip side to to that
Joakim Sundén: Not not not the one you're suggesting at least because I think that's always been in my experience over value that oh we need to have the same practices and then it will be easier for for people to move well I would say for one we don't want people to move unnecessarily so so more keep keep stable teams but also if if it's a problem that the way you're working is different in the in the other team than than what you're used with it's you probably rely too much on on heavyweight processes rather than you know collaborating to get the work done so I didn't see that that was a a big problem of course the problem becomes higher up in the organisation when you try to get create an overview understand what's going on but that's also a typical way that that Spotify will solve problems like that say that's what when we reintroduce the OKRs they say we all using different terminology some say we have these bets on the tribe some were using OKRs maybe that we need one consistent layer at least on on that obstruction to to figure out what's going on and to easy more easily coordinate so that's when the when when leadership decided everyone has to use OKRs and this is how we interpret OKRs there was a collaborative co-creation work defining that but then how do you actually establish your OKRs, how do you work with them, how do you follow up internally, you know we don't care that's you know what's going on in inside of your box we we we don't need to know. Another drawback though was that it sometimes to me felt like we were not giving enough guidance and basically you come up with it and then people would reinvent the wheel from scratch we wouldn't learn in a structured way not learn from what others were doing sometimes we would look oh you already figured out a good process for establishing OKRs let me copy that awesome and oh I just have to make these tweaks and these changes but but you know no structured sharing in in and learning it happened but it could have happened in a in a more structuring way
Jon Smart: In in your time there on that point when you were there was there a central PMO project management office or a VRO value realisation office to kind of help pull the details together and get the get the overall view
Joakim Sundén: No no it's it's we actually we actually were afraid of of project managers for quite a long time and I think we we went a little bit too far on on that scale and threw the baby out with the bath water but remember when when we introduced tribes this was 2012 there weren't a lot of people you know if if we tried to hire a senior experienced great project manager to a company like Spotify in 2012 you know that would have great experience of an agile way of of running that no that that it was very hard to find so so great project managers were you know attention to detail having a strong idea on how things should be done and we wouldn't more want more of a facilitating capability and so on so so so we didn't have that but once our culture became stronger and as we grew and and it was easier to get people with this experience and we had also so grown people internally Spotify actually after I left built up something that they called a project management office but but I used to say that it's not your mom and dad's PMO, it's very different it's it's a more you know making sure that the people are involved in in what we would call a Company Bet a bigger initiative that's that's cross functional that giving them a platform to meet making sure that that everyone understands what they need to do by talking to each other so creating platforms, communication channels, clarity, context while I would say a traditional PMO in my mind is more like I am the one running around getting the information being the spider in the net everything has to go through me I have I'm responsible for budgets and I call the decision and make the shots and the people who are actually depending on each other need to collaborate they might not even know of each other so that's not helping and building this sense of we're all in this together okay we need to figure out together how it's how it needs to be done
Jon Smart: I like that I like that turning it on its head and rather than pulling the information into one point getting pulling the people together to share the information together and you mentioned company bets and cross functional so would I be right in thinking that that's in the context of a company bet is where we want to do a piece of work which is going to touch multiple tribes is that the context?
Joakim Sundén: Yeah or it could even be you know other functions without R&D like like marketing or legal or customer support and so on but I would say that that most of the at least during my years and and what I know of after it would be mainly this portfolio model of investing in different tribes or or you know objectives and then increasing or decreasing capacity most in terms of headcount and you know changing the more or less challenging key results or object key results or metrics that would be steering the the day to day and that would be taken care of with within the tribes but then because we knew we we have good record track record of executing can we do it within one Squad excellent could we at least keep it in one tribe yeah pretty awesome but then you know as soon as more are involved and it's a little bit here and a little bit there and it's really important not so good so so that's why we introduced company bets to cover at least so these are the 10 most important things stack ranked so you knew that if someone on company bet one says we need your help and you're working a lot with company bet number three it's still a strong signal that you know we should probably see if we can help but it's still you're responsible to make that decision you have to weigh the pros and cons and and the the so with with the autonomy and empowerment of course the flip side is you have to take responsibility and you have to you can’t say well decide what which one these both are prioritized which one should I do well you need to figure out talk to people understand the pros and cons and so on
Jon Smart: Yeah I like the fact
Joakim Sundén: I think that's that's the problem in other organisations when you know we have 14 must wins so there's every everyone can connect what they're doing to one of these must- wins and and I'm when you say I need your help you know okay but I'm also working on the most important so there's no signalling strength in in what's supposed to be a strategy
Jon Smart: Yeah I like the fact that they are the 10 most important things stacked ranked that's very clear I also like the fact that it's only 10 as opposed to the top 237 priorities
Joakim Sundén: Well the as the story goes then the first time we we put this up and said okay what are these, we we define company bets and what are the ones going on now and and people identified on executive level 38 company bets and I said no no no that's not going to cut it let's say 30 and I what no never we can't get it down these are the 38 no 30 and once they did that sweaty conversations and okay now 20 I was like what and then 10 so so that was very difficult conversations and it was took quite some time for for for executives and and senior leaders to actually you know accept this and and start following suit but eventually it happened and then as the organisation grew with adding thousands and thousands of people when I visited the New York office a few years ago this right before the pandemic they had probably doubled in size since I was there and we had 10 company bets I said do you still have 10 company bets actually we only have four or five was the answer when the organization had grown a lot so
Jon Smart: Wow that's great that's really good so guilds and chapters so just we we've spoken a bit about squads we' spoken a bit about tribes I'm just I want to interested to touch on guilds and chapters so can you describe a little bit about you what what is a guild what is a chapter and also you know if there was any any history there around the terminology you've mentioned some of it already so bit yeah a bit of like what are they and a bit of the background
Joakim Sundén: Yeah so when when we had so we had clearly the the squad done that's where you do your work the the the scrum team or combo team or whatever we working you're using the the team that you're working with together daily to to deliver value and then you're also always every engineer or or every individual contributor in R&D will also be part of a chapter and that's a group with with people from the same functional group as you so it could be in the early days was backend, QA, web, mobile, as we grew mobile we added IOS and Android maybe and backend became machine learning and data and so on and the chapter was within the tribe but it was also 10 person or smaller so four to 10 people typically in that chapter and that meant that if you have like 20-25 backend developers in a tribe you would have two or three chapters so we we wanted to cap it at at a number and that was in part driven by you know we we wanted the chapter to be high quality conversations active so you can't have a big group of people then you you want to be able to have this active conversation about your practice, your craft, what does technical excellence look like within our field, what's what makes a great job or backend developer really work on your your craftsmanship and and personal skills and the other reason why we wanted it small was because one of the chapter lead one one of the chapter members was the chapter lead basically the manager for the others so someone who really knew that craft well and and could mentor and help and develop the people in their chapter and the idea was that we would work 50% time as as a manager and 50% time as an individual contributor on on on the squad that they were part of but some of you are because of it's a matrix model you would have some of your co-workers on other squads or most of them actually and then when we introduced the tribes and and had these chapters we we were concerned that well wait a minute we we still want to transfer knowledge and keep it together and have a community of interest if you will on on a global scale at Spotify so that's when we just said okay but all the backend chapters are then the backend guild, all the web chapters are the web guild, and so on so easy what do they do we don't know we'll see you know they will probably meet they'll have an email group and a Slack channel they figure it out so yeah and the first guild meeting to take place was a the web developer chapter leads who had agreed to to kick off the guild and we were we were also clear on on the guild coordinators that that we started it up with they should only bootstrap the guild it should feel like we own the guild together and everyone should take an initiative to isn't it shouldn't be meet again or shouldn't be do something so you weren't relying on on someone else having the passion or or the focus but but everyone should should own it and care about it but they said that we're we're bringing all the the web developers in from from the US to Sweden to have a crayfish party and socialise but we probably should do something more than that agile coaches can you help us and I've been running and some of us been participating in a popular Swedish conference called Agile Sweden we have lightning talks in the beginning of the day time box to 10 minutes a bell sounds and people applaud you have to get off and that's called unconference because it means that a lot of the participants are actually also speakers because with 10 minute talks you need a lot of them and it's easy and then in the afternoon we would have open space so the the lightning talks would act as as seeds to to these conversations so basically just a blank space of of time slots and rooms okay I want to talk about this thing that I heard a lightning talk about or I did a lightning talk about or it could be any topic and then people would just go together so and that became the de facto model then or standard for for how guilds were we're doing unconferences once or twice a year that's basically
Jon Smart: How often would the guilds meet how often would they get together people in the guilds and was it always in person or was it sometimes virtual?
Joakim Sundén: It was once or twice a year in person when when I was at Spotify. Spotify was very keen on collocation and would fly people over to to so that all web developers in the world could meet in one place and so on that of course has changed since so now it's it's a hybrid or or virtual or sometimes I know they they still collocated but it would be once or twice a year it came to the point at at some point in time it was like we had a problem with the challenge when the organisation grew that teams felt that they were almost never intacted it was always some guild or workshop or thing so we we actually started having offsite weeks so two weeks in the spring and two weeks in the in the fall so you had to coordinate so that was the time when everyone would do strategy days, product days, tribe offsites, guild offsites, hack week would be on such a week to make it easier to coordinate but chapters on the other hand that group would meet weekly maybe once or twice do a knowledge sharing, maybe watch a video, talk about what's what does good Java code look like or this is a cool new testing framework should we consolidate and and use the same or or is there no point and that's also an important point because the chapter wouldn't have a backlog of sorts they wouldn't have any time to spend on that so if you identify that we we should do some work together in the back end or we need to change this thing then you would have to go back to your squad and make the case that I need to spend time on on on doing this
Jon Smart: Yeah interesting and reporting lines so you said that for the chapters there's is a chapter lead and the chapter lead is mentoring and developing people within that chapter so that might be example you gave is web developers, it could be QA, it could be mobile, it could be machine learning, it could be data, so reporting lines can you talk a little bit about who reported to who and what that really meant because you know in the past traditional ways of working who you reported to was also where where the work came from as in you know you go back previous industrial revolutions that you know it was literally where your orders came from came from the person you reported to and here's your work here's your work order kind of thing so yeah could you talk a bit about kind of reporting lines what it really meant to to be the reporting line, the change in what it means to be a reporting line, and maybe talk a bit about incentivization as well well about you know how were people incentivized
Joakim Sundén: So so the chapter lead as I said was a 50% individual contributor and 50% manager and the and it was a matrix model and and the ideas that drove that was that well one you should really be able to develop your people and be a mentor to them that's your number one job is to grow people and we emphasised that a lot and we give gave the the chapter leads lots of training and support in in becoming better coaches teaching them professional coaching more or less how to set up one-on ones using the grow model and so on and we wanted everyone to have at least a weekly meeting with the people reporting to you focused on their development mainly and and that they're happy and and thrive at at Spotify so a lot of time went into that and very quickly chapter leads found that I don't have time to both be an individual contributor and a manager so that's one of the biggest misunderstandings of of how Spotify uses chapter is because that's in the white paper it's a 50% and and I see some organizations like oh excellent then we can save some money if if the the managers are also working and but but that never really worked for us so that changed quickly and when when I was at Spotify and left it was I don't know of any chapter lead that I work with that was a contributor no no one was forbidding them from it but but you know it was very hard to do that so some went back to be developers other kept you know oh I think there there's a good value and this is this is what I want to do and that also meant that we started hiring more when when we started hiring more people gradually we saw a shift on on more emphasis on the soft I don't call soft skills the people skills of of coaching and and and the helping people on their journey and so on and I know that the the the other thing we optimised for was that when you have with this matrix model it's clear that it's not like what you said that that the manager is the one assigning your work or or they don't have a bigger say in what we should be doing or how than anyone else because you know that you would probably have your manager in another team as an contributor or chapter lead and you could have two chapter leads you all have different managers so why would you listen to anyone in particular and we also said that they're not responsible for delivery at all but just growing skilled people so we really wanted to avoid micromanagement have the team self organised and so on and I think everything all of this succeeded eventually and and and we had a very strong focus on people development and then the the pendulum had swung kind of too far to towards that because we had a lot of people who were more coaching than actually actively mentoring and we had a little bit lost touch with you know you understand what's going on in the team so that you can be close and give active feedback because you have reports in lots of different things and you don't really know what what are they doing so so nowadays Spotify has switched it out so that the quality engineering managers even and you everyone in your team report to you regardless of of of whether you're back end or or anything like that and some people have suggested when I talk about this run courses or or the well that's not even Spotify is using the Spotify model as if you know what Spotify is doing now must be the latest and greatest so if we only copy that we don't have to skip through all the steps of but no of course it's you know we were optimising for one thing at one particular time point in time and and then we saw other challenges and now we're optimising for that and and that's so so often when I describe the the roles in use it's like what are you optimizing for what problem are you trying to solve and I think this is why chapter leads become so popular and why some big consultancies emphasise that, because in a transformation you know if you've outsourced a lot of your people and now you want to build a strong engineering or tech culture again it really makes sense to have someone who is a craftsperson themselves to kind of build this culture and and and so on but then the chapter leads in turn we're reporting to the technology tribe lead all the product owners or product managers as we would end up calling them the the product manager for the team the squad they would report to the product tribe and then we would have maybe designers and use the researchers reporting to the design tribe lead so we had this trio of product, design, and tech and now there's also inside tribe leads actually by and they would report to the CPO or the CTO for the director of design and then as we grew we would add add more layers but that's important thing that because everyone you know safe and other other frameworks sometimes sometimes talk about oh it's a it's a virtual organisation you don't have to change your your hierarchy and structure and so on well it's good because it offers you a transformation path that's a little bit easier to get started with but I think that if you're not in the end trying to change reporting lines that that it would be much harder because we we really had this we're all in this together, everyone is reporting to the same leadership and leadership team we're all if we want to say like oh we don't we want to sacrifice a front end developer to instead have a machine learning specialist or an agile coach or or you know we can make those choices we own it, we control it, we run it, and and that that did wonders for the we're all in this together related this culture
Jon Smart: I like it there's something I'm going to call out in what I heard you say which is something that I see as a repeating pattern for success you said that the there was a trio product, design, and tech was the trio that you said and you said that the you know from the product part of that trio the product managers reported to the product manager in a squad would report to the product manager in the tribe would report to the product manager keep going up whatever the tribe of tribes and then ultimately the tech lead reports to the CTO I guess the product lead ultimately I guest reports to the chief product owner of the company who might be the CEO depending on the company and the product so that is a that's a pattern for success that I have seen so it's good to hear you say that that kind of confirms my own observations and then that that trio and you said product design and tech that trio do they need to operate as peers and would I you know would you say that there needs to be a healthy amount of tension between them so that you can have a challenging conversation about hang on a minute we need to stop building new we need to slow down on the features and we need to do some tech debt remediation for example you know do you do you see that they need they need to be peers rather than being like a power gap where the product manager here's every here's like I'm going to dictate what we do is that something you've you you've observed
Joakim Sundén: Yeah so that was we we talked often about team at all levels of the organisation and we wanted this tribe lead trios to work as a team and be constantly aligned on what we should be doing and so on as actually we we when that was communicated from from leadership we took inspiration from the work that we were doing together Jon and the Steve Denning learning Consortium when we visited Riot Games (50:53) they have this phrase individual individual accountability collective responsibility that I picked up and wrote about in on my report where so the CTO and CPO was like and the design director of design were like this is spot on this is exactly describing it this is what we've been talking about but we didn't have it put in in such a great way so while the technology tribe lead was individually accountable for for you know tech health and so on and the the product for mission and outcomes and so on it was clear that it's a collective responsibility individual accountability means you're making sure that it happens but if you're the the person making the decisions you're doing it wrong because we're collectively responsible for making sure that it happens and that was key and we all they all even did what what we call the switcheroo so so they said that the product tribe lead is now individually accountable for organizational health and ways of working which has typically been the tech tribe and that didn't stop the tech tribe from from working as much on these issues as as they used to but it it meant that the product tribe lead now also needed to take an interest because they would be asked by their CPO how's ways of working, organizational health, and so going they couldn't ask you show before oh talk to the tech tribe lead they've got that covered no you have to you have to know you have to be on top of things so they meant that the collective responsibility and ownership increased and that's also a thing that I see with with clients that I work with it's it it's almost like we do these assessments and go in and help companies with with transformations or change journeys and it's like I can almost write it already before going into the assessment that you know aligning the leadership team because that seems to be something that's underinvested in and and people really missing out on that's getting this leadership together and alignment and feeling this we're all in this together we have a shared ownership of the success of this tribe or this company or whatever it is yeah and it goes back to Five Dysfunctions of Team by Patrick Lencioni and so on so so we've known this for decades at Spotify we've worked actively on it other companies not so much it seems
Jon Smart: Yeah so I really I really like the culture that's that's coming across here around autonomy, empowerment, experimentation, you know optimising the fact that the fact that even at a relatively early stage age there were coaches in the organisation coaching on the system of work and the culture so how people work together I like what you said about you know what do you want to optimise for I like I like that question it's like we can optimise for anything we choose to optimise for but actually you know what we're going to choose to optimise for something lots of companies don't choose to consciously optimise for anything and end up accidentally optimising for some things. So the culture culture at Spotify the values if you could maybe just say a little bit about that and you know what what were the values that were being driven from Daniel the founder what was the what was the principles and what were the leadership behaviours that were incentivized in the company?
Joakim Sundén: Yeah and I think that that Daniel and and the other founder Martin already from the get go they you know had this idea on let's hire the best engineers and and basically let them lose on on on this this problem that we need to solve so there was an idea of empowered engineers already from the start they are the ones that need to innovate they couldn't do it themselves they had an idea of a music player but how do we get it to be as fast and and play instantly and so on we don't know, they need to figure it out and and that was they they really had success with that and and tried to keep that culture as we grew and pretty early on recruited as CTO that had the same view and had successfully taken a startup to to to a bigger company using lean agile principles and ways of working and and he was he really came into the organisation called himself the first agile coach at Spotify because that was basically what he did this first year he started shaping up the organisation, he hired us as your coaches, he worked a lot with us so that's why we were involved in in the early stages of squads and chapters and tribes once once we got that going he was like okay great now we have this organisation now I'm going to focus on the architecture and and introduce microservices basically so so I think that great support and that they understood this and they believed in it and had seen seen it be successful and also that the founders were serial entrepreneurs who had seen it gone the other way as well how bureaucracy and and and so on had just slowed everything down to to a halt. So we had this idea of empower and trust the CTO Oskar Stål by the way he was very influenced by Dan Pink's Drive, autonomy, mastery, and purpose that would really motivate motivates us so already from the start when we we started building tribes and squads we had this concept of autonomous squad so so the picture he used was like it should be like a mini startup and everything else in the organisation should be designed to support that squad while in other organisation it feels like we're here to serve our our masters basically we we had to turn the pyramids upside down that every leader, everything, every policy, every process, it should be focused on on helping this one and then so so give them problems to solve and the space to solve it and great things will happen and if you look at the products coming out of Spotify like discover weekly, Spotify connect, and you know every great thing typically came out of a hack week or or a team or an individual engineer coming up with an idea and then being persistent in executing it even when getting bad feed negative feedback from manage oh that's it's too to hard, too difficult would just go on build it and hack week and then wow this is really cool we we should do it so so that's been reinforced and you can see if you go on LinkIn or Facebook and and watch what what Dan the founder and still the CEO is saying he's constantly praising hack week and and empowered engineers that's like what he what he communicates basically to the world so that was important and and really trusting people to make these choices and to that being safe to fail so we talked a lot about psychological safety before that became even before that became a term we expressed it in other ways and we we both on the culture side clearly emphasizing and we even recorded videos on Daniel and others, leaders, and the individual contributors describing this is a mistake I made a huge mistake, this is what I learned, this is how I try to fix it, to show that everyone is making mistakes we showed it in on boarding in town halls people started setting up these fail walls where they have wrote blog post about it and and but also at the same time working to have have ways of working that makes it low cost to fail so if we can constantly put out small things and do small experiments with small customers then we can fail early, fail often, and fail to to a very cheap price it's not about you know oh we make this big enormous project and we don't care if it fails that that would have never worked and building a technology, microservices, gradual rollout, continuous deployment, so so so to both the culture and and the way of working and the technology needs to be aligned on making it safe to fail and the last piece just shortly we already talked about it I would say we called it started talking more and more the bigger we grew and not just about autonomy but aligned autonomy we're all in this together shouldn't sub optimise you know don't look at what you can do for for your team but what what how can your team contribute to to the overall all of Spotify so this responsibility that comes with autonomy who do I need to collaborate with, is someone else working on this, is this conflicting with something else, is this going against our regulations, is is it not working with label licensing, you have to figure out you have to ask those questions no one will will serve them to you on on a page
Jon Smart: Yeah and and then my understanding is it then evolves over time as you continue to optimise for the outcomes you're going after so it's not a fire and forget it's a it's a here's what we're doing now and and then within all those values you said my understanding is it continues to evolve
Joakim Sundén: Oh yeah for sure and and we we often revisited our values and as I said we talked a lot about a autonomy that was hard to get to we were afraid of micromanagement and all of that thing but when our culture was very strong in that and we had a lot of autonomy we saw the other result was that we don't understand what's going on people are running in all sorts of directions and and you know a common reaction would then be okay we need to introduce more control but to us was no we need to introduce how can we introduce more clarity more guidance more context more information more support so that we don't stifle this autonomy and creativity but rather you know direct it in a way that where it becomes very useful the same problem and you have to have incentivized this and and it's I would say that one thing is that we had technology career steps it's been blogged about so you can can have a look at it Spotify blog but it's basically saying that mastery is one of five areas that's the basis of your career advancement and the salary the others are that you continue team you value team success over individual success, that you work on continuous improvement, that you care about business impact, and so on so so you actually had to be helping others, training others, having a huge impact, collaborating and to be able to to you know advance at this point to really put your money where your mouth is
Jon Smart: I love that I love that so the incentive is to help the team, help the organisation have business impact so you're incentivized to do the right thing the individual accountability collective responsibility quote that you you picked that we both heard at Riot games fantastic there are a lot of lessons in there that a lot of organisations can benefit from there are a lot of organisations who are I perceive going about this in a bit more of a top down type manner without so much collective input and shaping align to outcomes which is human nature to to try to copy something so what I'm what I'm picking up here is it's all about the values, it's all about the culture, be clear about what you want to optimise for and then pursue evolutionary or maybe sometimes revolutionary improvements and something I heard you say earlier is kind of make it your own as well don't just copy make it your own and that might mean your own language as well
Joakim Sundén: Yeah yeah and and I mean to me it's always been about you know applying the the Spotify model on a change or or a product mindset or a product model or agile way if you want it to be really clear what's the product vision, what's the change vision use that context and then do product discovery or change discovery and not just work in in big bank projects but rather incrementally, iteratively, small chunks engage teams we expect to introduce a ways of working with autonomous empowered teams guided by a vision and context then we should of course do that in the same way have a vision for what the change should be about, engage them, be stubborn on this vision but you know as Jeff Bezos right stubborn on vision but flexible on details if the teams have a better idea awesome present it if not you know here's a way you could do it that we believe will will reach the vision but as soon as you see is it not helping you know you can come up with something else I’ve actually been using your acronym their VOICE I think that that's spot on and exactly describes this you know clear on vision and principles and the outcomes and then lead with intent or context as I would say coach and support and and run experiments that's that's really what it's successful change is all about
Jon Smart: Awesome fantastic thank you very much Joakim really appreciate your time lots of learnings there which hopefully other organisations can benefit from and great to capture this ways of working moment in time you like kind of organisational archeology it's it's great to that you were in the room at the time the conversations are being had and you've been part of that journey so very grateful for you sharing your time, sharing your learnings, and your thoughts and your experience so thank you very much
Joakim Sundén: Yeah thank you it was a pleasure