 We have Jason Yip from Spotify with us who is going to talk about BAPO model and its application in Spotify R&D. Jason, all yours. So as mentioned, my name is Jason Yip. I'm currently a senior Agile coach at Spotify, and I'm going to talk about something I tried within the Spotify Advertising R&D area, a model called BAPO, which is for organizational design. I'm going to try to go through all of this before taking questions, but feel free to add them. And if I see something quick, I might comment on it, but otherwise I'll try to get through it just so we can talk more at the end about what you think about this. I just want to first describe the problem context that we were dealing with and the reason why I was exploring this model. So I don't know how familiar you are with the Spotify in terms of business model and trends. This comes from the latest quarterly report, just showing the different levels of growth of advertising as well as the growth of the users on Spotify. MAU stands for monthly active users. Main idea here is really that advertising is growing in impact in size at Spotify. Growing percentage of revenue usually like growth comes from free users. Free users of advertising is just the importance of growing. Now, what that means effectively is that the influence in size of Spotify advertising will grow as well, which means that there will be pressures on structure. More specifically at the time that I was exploring this, we had just acquired Megaphone. Megaphone is a company that provides essentially a way for different publishers to advertise and we acquired them so that we could support our own efforts and associate that we were engaging in some more complex delivery. This has already been announced and launched, but at the time we were working on this thing called the Spotify Audience Network. Which is a much more complex delivery just because various different areas were working at the same time and we were working on some pre-existing collaboration issues. So just noticing that across different product areas we're having trouble working together effectively. So all these factors combined indicated that it might be time to revisit structure. These type of problems aren't always structural issues but at least indicated that there might be some mysteries with boundaries and how we work together across them. So the framing question, the question I was asking given this context was how might we approach org design in a more systemic logical way. Now some of this comes from a previous experience I had working with another area which was related to messaging marketing technology but with the advertising things it was a little bit larger scale but still the similar idea that I thought it would worth approaching this in a more systemic logical way. So the idea that I had to start was this concept, this phrase called structure follows strategy. It's a kind of a simple phrase originally from this guy named Alfred D. Chandler Jr. The actual original quote is unless structure follows strategy in efficiency results which I just normally just would express as structure should follow strategy. The BAPO model comes from someone called Jan Bosch. I kind of interpret as a expansion of fleshed out expression of structure follows strategy. This is actually a colleague appointed me to this and I thought okay this actually seems a much more interesting version of structure follows strategy and it's worth exploring as a way to think about this problem. As with all models this is not equivalent to reality but it's closer and possibly more useful. So we said okay let's let's take a look at this and see if this helps out. Now here I might as well define the term so I said BAPO what does it stand for? Essentially it's business architecture process and organization where business refers to at least I interpreted as product strategy, architecture is technical architecture, process also known as ways of working and then finally structure is organizational structure. So the idea is that the kind of primary driver is business then architecture then process and organization even though there are interrelationships between that that's how you want to primarily drive things rather than the opposite direction. So I was actually talking previously with some people about like people copying the Spotify model if you will and that tendency to start with structural things rather than strategy things is almost like a reflection of this kind of mistake of structure driving strategy rather than the opposite where it should be following strategy. So it should not be the first thing you look at. Okay so just to expand on each thing each item just to better understand it the if we look at business such a product strategy the idea here is really around different categories in the product life cycle so if you look at any product it does go through different stages. Initially it could be innovative as in you're exploring a potential new product you're not quite sure what'll work and you're running lots of experiments and how you even measure success is different because you're looking at how many experience you're running not everything actually is gets past that initial innovation then you'll get something that has traction and now you're trying to differentiate exploit this new product you have you're trying to maximize business value and eventually every product becomes commodity where it's no longer a differentiator you're not really improving business value you're really just focused on trying to minimize ownership. Each of these stages imply different success criteria as well as different ways of working so it's important to categorize what where a product is because then it affects how you do again all the subsequent steps. Typically when you look at this you're looking as well as product capabilities not like an overall product. The next stage is architecture architecture and this is really about decoupling and dependencies the general simple way of thinking about this is stable things should not depend on volatile things so you have this kind of one way dependency and you also want to decouple so something like let's say a service associated with a capability you don't want it to depend like one service supporting both a volatile and a stable capability because now you've coupled two things that should be isolated. Processes about ways of working again as mentioned depending on what stage the product is at or the product capability is that you want to work in different ways in innovation we may want to do lots of parallel experiments and differentiating what you do your kind of typical iterative incremental development and commodity you might outsource use third-party services etc just because the appropriate ways of working changes because you are trying to do different things and finally organization is about a staffing allocation and team structure the first the idea about staffing allocation is that for something that like product capabilities that are commodity as in you're no longer getting business value out of it it's no longer experimental and you're you're just trying to reduce costs so you don't really want to look at your staffing and saying most of your effort there you want to minimize how much effort you you allocate to this as much as possible after that between differentiating and innovation it's more of a judgment call so this is a kind of a decision based on your product strategy about how much allocation you want to have toward innovation experimental things versus differentiating this kind of if you think about it in terms of revenue you're not really making money off of innovation things yet they're really more for the future so depending on your situation how much you can afford to say hey we're planning for the future versus we need to kind of deal with what gives us benefit now that is a a call that needs to be made at a business department level about what is appropriate again this is why from the model the business strategy stuff comes first it determines how you think about things like this okay so the general idea I had so that that's the model but the general idea I had for what I was attempting to do with this was to had was two things one is to inject this idea of BAPO this model of starting from business to architecture process organization to inject this idea into the general narrative so when the larger like Spotify advertising r&d was was going through organizational design discussions and decisions people involved in that discussion would be aware of this model these concepts and that would influence how they would go about it and that that I was saying hey that's a minimum thing I just want the narrative to be out there so then people have these concepts and then they can think about it while they're they're deciding things the ideal though was to say hey I'll introduce BAPO and then it'll will directly create a target operating model to directly influence the org designs that was the the idea in order to go about this I had particular principles for how to do this change the first one starting where you are as in whatever I had control and influence over that's where I would start I wouldn't try to go somewhere where I didn't have capability use existing resources whatever assets or essentially people I already had influence over I'd start there person by person buy-in I also can be described as ground war or the Japanese term is nemawashi as in you're not trying to convince everyone at else you're actually everyone at once you are actually talking to each person and getting buy-in person by person in order to get the collective agreement which is a lot of work but tends to be more effective at getting overall buy-in and finally to frame as an experiment so using saying hey there's this thing I discovered it might be interesting I'm not saying it works just to make it more comfortable for people to engage with it because it's not lower pressure but also encourages more questions and exploration creates a particular mindset which I think is appropriate and useful for these type of changes so what actually happened right from the start when I was introducing this I didn't really have enough context in the business strategy to be able to say hey this is our current product strategy business strategy and therefore you know this is what architecture should look at and so on and so forth so I could only really use pre-existing artifacts which we didn't have anything pre-existing like in terms of a product capability map or anything like that but we did have existing high-level architecture diagrams if you're familiar with the C4 approach like Sam Brown talks about there's this idea of a high-level context diagram so it's almost like the interface between technical services and business concepts we did have stuff like that so I could use those to give and create an initial kind of straw diagram of high-level architecture which are were indicative even though they're not quite identical to product capabilities and use as an initial talking point so this is an example of starting where I was using whatever resource was available to get going knowing full well that I would iterate on this model so it wasn't necessary to start with a perfect expression of product strategy and architecture I could just start with an initial idea and then again framing as an experiment from an iteration be able to engage with people the next thing so the general idea is I'd have this straw man architecture thing start validating with people framing as an experiment migrate to more people as this thing started refining so I went from specifically I went from a senior engineer because it was starting kind of technical but this person had also quite a good familiarity with the business domain and then migrate to product leads and then finally to the broader leads of the overall mission overall mission just refers to the overall R&D area so create initial straw man use existing architectures a proxy validate with senior engineer fall by one on once with the product leads then finally the overall mission leads and this was the approach so just to be a little bit more concrete this is an example of the straw man I created the actual one is much more involved but and also if you're not that familiar with advertising concepts it's not relevant but just to give a sense of hey I have all these things grouping within those categories I mentioned before and Boppo and the product lifecycle so which are services that we kind of thought okay these are kind of commodity things they're not really differentiating no customer cares that we have them we just need to have them there differentiating things that are kind of known things that we know that if we get better at customers we'll pay more money for it so on and innovation things I wasn't quite sure what was it there so I just had this kind of question mark so I had this this is what I brought forward to a senior engineer and then from there talking to product leads we have this kind of more involved version again this is still simplified but gives a sense of how it evolved so one I guess first point here I put these things in red here some of the language started to change so and this is kind of thing also a useful thing I started translating the language both from the official language from the model to what was connecting better especially with the product leads so people were from more familiar with the Kano model if you're familiar with that just this idea of of hygiene I think differentiation in the lighting type things so some very similar concepts so when we say commodity saying oh no this is the hygiene what are hygiene product capabilities a one thing for sure is talking to product leads they were able to translate from the technical service to what how they would talk about product capabilities how customers would understand it which was able to introduce the split but then also this language from quantity to hygiene a clarify that differentiating meant that things that we know that if we do them they convert to money like it's relatively well known so we're relatively confident versus innovation capabilities which we're not sure that they work yet so we don't know that if we do this we don't know if customers care it's very experimental so that helped clarify okay where do the things go much better than the original language so and this is kind of think a good tactic to generally take what was useful at this point I think as well is that we could detect misalignment here quite quickly and which itself was useful even if this model didn't lead to anything at least it picked up misalignment issues while validating with product leads I also added current teams and allocations so hey how many people are associated with each category which then we can think about hey does this make strategic sense like should we we haven't took too many people working on particular things and finally I presented to the mission leads as a summary this is kind of this this blob it's kind of blurred out but this is actually more reflective of how the overall thing looked and then we kind of went from there now I'm going to talk about like how this worked out and I think what the lessons are so again back in the beginning I said to add a minimum I wanted to inject Bapo into the narrative as a minimum and then try to use this to directly influence the target offering model to directly influence org side I think I was able to achieve the first thing and I don't really think I was successful in the second thing so let's talk about lessons here I think Bapo is a useful model in general and that's why also why I'm talking about this because I think even for sharing this with you I think it's something that I would encourage you to take a look at it's a useful way to think about org design I also think the change tactics that I attempted starting where you are using existing resources person by person buying from this experiment were effective they got people engaged the failure I think I had was when I engage with the mission leads and I'm going to call this don't try to teach level three leaders to fish by level three I mean leaders of leaders of leaders and I think everyone's familiar with this phrase give someone a fish you feed them for a day teach them how to fish you feed them for a lifetime and I think with level three plus leaders they don't typically fish directly if you will if I'm going to follow that metaphor people at that level typically delegate fishing to other people and if you go in there trying to teach them how to fish where they typically delegate that you don't get much engagement nor a good response to some extent I'd say if you're engaging with a leader at that level just tell give them the fish and be prepared to explain how the fishing works only if they ask but for the most part I should have just said here's the conclusion what happened instead is that it was a bit of confusion and I don't think the message came across clearly so which is why I think it only ended up getting the narrative through there but didn't really directly influence how they were approaching things per se okay so this is a little bit more about what I did and some links more for the Bapu model I also wrote a blog post about this and there's also a newer version of Bapu called Esau that Jan Bosch came up with actually still like Bapu I think it's a simpler way to think about it but we're checking that out too but that's all I wanted to say and let's shift to questions thanks a lot Jason I think we just a little over time thanks a lot Jason it was a very insightful session