What really happened at Spotify with Brendan Marsh

Join Murray Robinson and Shane Gibson as they converse with Brendan Marsh about his experience working at Spotify. Understand how Spotify’s agile methodologies aim to achieve speed to market and learning, which their leaders believe are crucial competitive advantages against larger, well-funded competitors.

Learn about:
🔸 The inner workings of the Spotify model
🔸 How the model has evolved over time
🔸 The focus on empowered teams
🔸 Constant experimentation with new ways of working and organising to enhance agility and efficiency

Tune in to gain valuable insights into Spotify’s unique approach to agile principles, team empowerment, and constant evolution in pursuit of increased speed and adaptability.

Read along you will

Murray: In this episode, we talked to Brendan marsh about what it’s like to work at Spotify. How Spotify’s agile ways of working are just a way to achieve the speed to market and speed to learning that their leaders feel are its key competitive advantage against bigger and better funded companies . How the Spotify model really works and how it’s changed over time. And how the model is all about empowered teams, constantly trying new ways of working and organizing themselves to find the best way to move faster. 

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson. 

Murray: and I’m Murray Robinson. 

Brendan: And I’m Brendan Marsh.

Murray: Hi Brendan. Thanks for coming on today. so we wanna talk to you mostly about your experiences at Spotify as an agile coach and product manager. And we’ll also touch on the crisp consulting model for your new venture. So why don’t you introduce yourself to start with and tell us a bit about your background and experience.

Brendan: Sure. I studied a Bachelor of Science in digital media which basically meant that I was a jack of all trades and master of absolutely none. I had a web development job and then realized that I wasn’t very good at it. So I ended up leaning into account management, project management. I dabbled with SEO for a while. And all these different experiences led me to a startup where I built a product that nobody wanted using project management methods; which was extremely formative in terms of learning about the lean startup and agile ways of working. 

Ended at an agency in Sydney as a product owner and then started teaching the rest of the company Agile ways of Working, which eventually landed me the job at Spotify as an agile coach, where I spent two years doing that. Everything from data infrastructure through to coaching discovery methods for features like Spotify running

And then I got the itch to get back into product and eventually became a product manager for Spotify’s desktop client, where I was responsible for the Mac and Windows application, which at the time had about a third of the company’s monthly active users which was about 40 million users .

So all in all, I was at Spotify for five years and then I left that joined a mental health nonprofit for a couple of years as head of product. Absolutely love that experience. That was a company called 29 K. And then I decided to move back to Australia and join this little boutique agency called Organa.

We are four consultants, two in Melbourne two in Sydney where I do everything from running courses coaching agile ways of working, helping with product and strategy, execution, coaching product managers. And we operate in our business like a nonprofit. We aren’t a nonprofit, but we operate like a nonprofit. 

Murray: So as you know, The big consulting company are going around town introducing the Spotify model and safe. And I was wondering if you could tell me how Spotify is actually organized.

Brendan: Sure. I suppose I should speak from the perspective of the time that I was there, cuz it’s likely reasonably different by now.

Murray: It was only a couple of years ago, wasn’t it?

Brendan: I left in 2018, so it’s been about five years now.

Murray: All right.

Brendan: But yeah, I remember the. Tribes and squads and chapters Paper came out in 2011. I think and I joined in 2013, and that was a big part of the inspiration for wanting to join that company. I moved my whole life from Sydney in Australia to Stockholm in Sweden to work for them. But I went there with a healthy degree of skepticism of I wonder if this is actually all true. I wonder if this is how they really do things and is this agile nirvana in some ways? And it really was. Obviously there were a lot of things that could be improved, but the culture of continuous improvement and this separation between the principles and values of agile and continuous improvement and the practices that you can choose to use in order to be that way was really clear.

When I joined squads were empowered product teams, as Marty Cagan calls it with a product owner, eventually we changed it to product managers as the title leading the team. Chapter leads being the line manager for people with different competencies. And then the squads were grouped into tribes. And tribes we viewed as incubators and support structures for squads to solve business problems. The tribe had a mission, a high level set of success metrics that they’re working towards, and the teams are pretty autonomous in trying to help achieve a particular mission for the business.

What wasn’t existing back then, for most of the time that I was there, was really heavy top-down planning processes. At best by the time I left, we had a portfolio kanban board at the company level called the Bets board. And at any given time there were 10 important strategic bets that the company was working on.

For example, launching on PlayStation was one of them. And then as an autonomous squad, you would look at that list every quarter and say, is there anything we can do to help the company achieve that bet. And the 10 were stack ranked. You’re expected to work on number one if you can.

And if you have to work on one and seven, you probably should focus on one first and then seven afterwards. There were some lightweight practices taken from safe, like, we eventually did big room planning to align teams and share any dependencies that we might have. We would bring a perspective of how much capacity we have to work on these things for the quarter and if we didn’t have enough capacity when that was a problem to solve for leadership. Guilds were absolutely a thing. Anyone could start a guild. Eventually they got a little bit outta control to a point where you’d wake up one day and go, we wait, where’s half of my team? Oh, so and so and so are over at the back end unconference, and some people are at the leadership unconference and so on. 

Murray: So a guild is like a special interest group. 

Brendan: That’s right. Yeah, anyone can join. So it’s not just the people that do that thing, but it’s the people that wanna learn how to do that thing too. 

Murray: And if they’re running conferences, they must have had some resources then. 

Brendan: Yeah, that’s right. Yep. Yeah, that was complicated in terms of which part of the business would pony up for those unconferences. It’s whichever tribe was the most related to the type of conference. Maybe they had the most amount of backend people in their tribe or something along those lines. 

Murray: A matrix model, so you’ve got your empowered product teams, people who used to be in a capability like UX design or something, would now have a UX design chapter lead, for example. What would they were responsible for as those capability manager?

Brendan: Actually you highlighted an interesting distinction here because design and product did not have chapter leads. So it was actually the tech organization that for the most part functioned in this way. But it still roughly looked like a matrix organization. It’s just that the leadership roles of the people that you report to, whether you’re in product or tech or even data would look a little bit different to what a chapter lead for a tech orientated part of the business would look like. 

Murray: Yeah. But the chapter leads wouldn’t assign you work, would they. 

Brendan: no, absolutely not. 

Murray: they would look after your development and, 

Brendan: That’s. 

Murray: Skills and so on. 

Brendan: They’re your line manager from a HR perspective, they set salaries, they hold development talks. They encourage you to get feedback from your peers. We had a 360 degree peer feedback system. They give salary increases, that kind of thing. But they also maintain the role of how do I grow people to become the best that they can be at the company, even if that means leaving the tribe and leaving your manager to go somewhere else, or even changing discipline. The nice thing about having that separation from the work be done is that it enables those sorts of things.

Murray: Yeah but Spotify was a really big organization with several thousand people. So there could have been thousands of people belonging to the development chapter, so they must have had some hierarchy within their chapter. 

Brendan: The way that chapters work were tribes were typically led by ahead of tech, ahead of product, and ahead of design, unless it was a heavily technical tribe. The head of product would have all of the product managers reporting to them. Eventually, as the company got like super big, you might have a, senior product manager that has product managers reporting to them, and then that one reports to the tribe lead. But on the tech side, you would have a tech tribe lead and that person would have all of the chapter leads reporting to them. Now, if they have backend engineers in the tribe, for example, then you would likely to be having say four or five backend chapter leads, reporting to the tribe lead, all doing the same thing just with different people in their chapter.

Murray: So who were the line managers for the head of tech? 

Brendan: So for a long time, that was the cto.

Murray: Okay. 

Brendan: The CTO would have the tribe leads report to him. One of the things I really appreciated about the CTO during that time was that he focused predominantly on growing great technical leaders and tending to the health of the organization, and how it works. I saw more of that from him than, here’s what our platform strategy is. Here’s, how we’re gonna solve these technical problems. And I think through the phase that Spotify was in, it worked really well.

Murray: Okay. So there weren’t very many levels in the hierarchy by the sound of it, 

Brendan: No,

Murray: for the size of the organization. 

Brendan: Yeah, I suppose so. Like the guiding principle was that any line manager at any part of the business tends to not have more than about 12 people report to them. Because anything more than that it becomes difficult to lean into those people and really guide and support them on top of any other strategic expectations or responsibilities that person might have. So eventually it got to a point where the CTO had too many chapter leads reporting to him, and that had to become a how do we solve that problem?

Murray: Okay. And would each line manager have a weekly one-on-one with each of the people who, reported to them? 

Brendan: That was the most common paradigm, I would say.

Murray: Yeah. Okay. And , so was it the same thing true for Agile in the area you were working?

Brendan: Yeah. So for the bigger tribes, so the tribe I started out in, when I joined the company was infrastructure and operations. So we used to call it the basement or the plumbing. The thing is tribes can also choose to do things in their own way. They also had that level of autonomy. So what we had was what we called the honchos. So we had a head of tech on the infrastructure side ahead of tech on the operations side, and we. The chapter lead of Agile coaches playing that tribe lead role as well, tending to how the organization works as a whole but was also the line manager for us Agile coaches. Now, I’d say that’s rare. At that time, most tribes, because they were smaller, the coaches would report to the tech tribe lead.

Murray: And was there a clear tribe led, cuz you talked about three people like a council. 

Brendan: Yeah. In the earlier days. Based on the director, vp assignments there were in many cases a clear tribe lead. Some would lean into the concept of shared leadership. A lot of the tribes worked in that way where they had to work together to make decisions. But I think eventually a Spotify grew and grew, and the reporting lines became more challenging. They ended up at the level above tribes called alliances, which is a concept of a clustering of tribes. They would have an alliance lead, and that was one person. And that was to simplify decision making and reporting lines. And that eventually coincided with the removal of the C t O role, the removal of the C P O role and the creation of the head of r and d, which encapsulated everything for tech, product and design and data.

Shane: So, You, You said that, there was a natural break at 12 in your organization where it is just too many lines of communication for us to increase the number of people that are talking to somebody in a leadership position.

And what a traditional organization would typically do is add in another level. But what I heard is that one of the default patterns was to move to a triad. So when the organization started to expand, and those lines of communications got too big, then you would naturally form a triad. And the example that I thought I heard you use was like head of tech, head of product, head of design and that idea of co-ownership, so we now have three people that are working together and, they’re making decisions together which is difficult, but if they have a relationship, will work. And that was one of the scaling patterns that seemed to permeate through the organization as they grew. Is that what I heard?

Brendan: Yeah. I think that concept was there from the beginning. And it makes so much sense when you think about it because, if you have one person deciding what the team does and works on all the time, then you’re limited to the creativity and intelligence of that one person. If you have one person leading an organization then you’re limited to that person’s intelligence and creativity. But if you’ve got three people leading an organization, then you’ve got counterbalances, you’ve got more ideas, you’ve got sanity checks that can come into play because, there’s an equal power footing. So that paradigm existed for quite some time. Even in terms of how we led the squads, we had this concept we called the potluck which was the po, the chapter lead, or in this case team lead and the Agile coach being the three people that more or less led each squad, and in some cases you might have, it gets messy. Where an agile coach is typically working with more than one squad. A chapter lead has people in more than one squad. So we have to figure out how to make that work. But we like the name potluck because it’s this concept of everyone brings a different dish to a dinner. And each of those perspectives means you get a better outcome. We called them honchos in, the infrastructure and operations tribe for a while. 

So we also experiment with names and we experiment with different leadership patterns. So that’s the thing, like the concept of this static model that companies are gonna go out and sell. For us Hendrick talks a lot about how the fact that the industry talked way more about the Spotify model than us working at Spotify would talk about it because we were just getting on with it and having this culture of continuous improvement. And while this doesn’t feel like it’s working so well anymore, how do we change that at almost every level of the company.

Murray: Yeah, I have seen a big consulting company roll out the Spotify model and SAFE at a big telco, and it was really rigid. It was a whole lot of playbooks. It was all done at the senior level with the executives in back rooms. And then the way it was rolled out was, this is the rule book. These are the new roles and responsibilities. You don’t have a job anymore, apply for this new job. And everything is very well defined and there’s no changes. So there was no concept of experimentation, of teams trying things for themselves or tribes saying, that didn’t work let’s try this. It was all just totally mandated. Top down, there’s now 50% less management jobs than there used to be. Go and apply for these new jobs,

Shane: Don’t forget, Murray there’s always a consultation phase right there. There’s always, once the immutable document’s been issued in pen and Inc, there’s always the consult. Where we pretend to listen to the people on the ground, give us feedback, we fixed the structure and it’s immutable. But don’t worry, we still want talk to you and see what your advice is. 

Murray: It’s often required by union agreements, so it means here it is and we’re not gonna change anything that’s consultation. That’s one of the big differences. I note between what you said and what the big consulting firms are doing, because you are talking about experimentation and change based on what was working and what wasn’t? That concept of empowered teams, empowered tribes, is totally missing from the way the big consulting organizations are implementing the Spotify model.

Brendan: Yeah, and there wasn’t really a, like a P m O office that’s trying to like, push towards some future state. Henrik used to love talking to people and trying to understand what’s the thing that’s slowing everyone down. The concept of speed, not just speed of delivering output, but speed of learning was such an important metric that we talk about. And I say metric maybe poorly because it’s not like it’s something that’s really easy to measure. One of the first blog articles I read when I joined the company was from the CTO saying that speed is extremely important.

And the reason for that was because it mapped back to our product strategy at the time, which was we know that Apple and Google and possibly Amazon are working on music streaming services. And when they release those services, they’re gonna commoditize the streaming market. and they’ve got hugely deep pockets. They’ve got control over the hardware that you’re using on your phones, iOS and Android. And they’ve got enough lawyers to get the licenses to the music. So what can we really compete with them on. Apple with the amount of money they have they could just come along and go we’re gonna halve the cost of premium.

And then all of a sudden, if you’re a Spotify customer, if you’ve got no real solid reason to stick around, hey, half the price, why not go to Apple? So the theory and our product strategy at the time was if we continuously build a better product than these competitors then we will keep giving customers a reason to stay with us, even if they price gouge us.

Murray: Yeah. And that’s turned out to be true. 

Brendan: Yeah. I mean it’s worked. And so how do you achieve that constant innovation while you create the conditions for people to experiment with new ideas. And to experiment with new ideas you might need new ways of working and so you can’t manufacture this process top down. It has to be give people the breathing room and the space, give them the strategy and the direction of where we want to go and access to all the data, but they need to, figure it out. 

Murray: But what’s the point of doing this? Surely Spotify’s goal wasn’t to do Agile better than anyone else, or was it 

Brendan: No. It was to execute on this strategy. It was to out-compete the people that are likely gonna come along and be extremely difficult to compete with. And the belief was that speed to market and speed of learning were gonna be the key factors that we can lean on because we did have the first market advantage. So let’s keep leveraging that. Let’s keep being first because what else do we have? They’ve got all these amazing competitive advantages that we don’t have and would be almost impossible to build. Spotify’s not gonna go and build a new phone that’s gonna take over the world. 

Murray: Yeah. Let’s look at things from a product point of view, because you also spent two years in product. How did you know what to build? 

Brendan: At any given time, a strategy team in the company has done a whole bunch of work to figure out what’s strategically important for the entire business and has managed to create 10 stack ranked bets.

So the first answer is, if there is something my team can contribute to on that stack ranked Bets list, which is a mix of O K R level messaging, but also sometimes it’s output driven. Classic example could be move Spotify away from bare metal to Google Cloud. That’s something that there’s a lot of strategic thought behind, but it’s not really that exciting to measure results towards that goal. Like you just know what you need to do and get on with it. First and foremost it’s can I contribute to anything on that list? And what is that and how do I help the company succeed with that?

The second thing is the tribe will also potentially have OKRs for the quarter and usually I’ve been a part of that conversation of coming up with them for the tribe or at least. Commenting on feedbacking on, if I’ve got a really good idea that I think is gonna move the needle on our tribe metrics I will contribute to that and therefore we’re then expected to focus on whatever the OKRs are for the tribe.

I should mention that if there is one of those company level bets that will cascade to the tribe level OKRs. So that gets first dibs on whatever the tribe has in mind. Actually, what really gets first dibs is keeping the lights on. So the expectation is if there is really painful tech debt , to pay down if part of your job in your team is to maintain a certain level of quality, release a product to the customer every two weeks, whatever that looks like, that actually is your P zero. Everything else is on top of that. And so many companies don’t do this. They don’t explicitly state that your first priority is not to go backwards. They talk so much about going forwards. They don’t talk about let’s make sure we don’t actually degrade the quality of our product, for example.

Murray: So you’d have an O K R and then some key result What would be an example and how would you be continually doing things to try and move the needle on that? Or were you doing a series of projects or what?

Brendan: Yeah. So the KR’s for the tribe are usually formed in a way that is measurable and depending on what it is, you’re either doing a whole bunch of discovery work to figure out what’s gonna move that needle. Whether that’s prototyping, user testing AB tests or the outcome is pretty clear. And you’re just executing on something that, we’ve done some discovery work and we know that it’s gonna have a certain impact. But it’s really up to the product managers to figure out what’s gonna have that impact. And then they do that with help from user research, data analysis, people in the team, stakeholder feedback.

I like to think of the product management role as making sense of internal and external complexity and using those signals to figure out what the right thing is to work on. 

Murray: Were you a product manager for a squad or a tribe, or where were you sitting there? 

Brendan: squad. 

Murray: Yeah. So you would’ve had what, 10 people? 

Brendan: Anywhere from about eight to 22. So when I was product manager for desktop for a while, that was 22 people. But we all acknowledged at the time that was unsustainable. We actually had to break up into small little mini teams to make that work. And then eventually I was product manager for two teams which is also a pretty common pattern there now.

Shane: So you mentioned that there was a bit of renaming there from product owner to product manager. What, drove that change in language? 

Brendan: Yeah, so I would say Spotify had a very myopic way of working when it came to product owners where most were looking at whats staring you in the face versus where do we want to go long term. Product ownership as a role has its roots in iterative, incremental delivery of value. And so the product owners became good at figuring out how to deliver what’s most valuable right now. What they weren’t so great at is what is our product strategy? How does that relate to everything else that’s going on in the business and the business’s strategy. What’s our longer term vision? How are we planning to get there? That more strategic piece was missing. So partly it was to signal, we actually expect you to do more of that work. The business has grown massively. We have bigger goals and ambitions, and some of those are more longer term. And your ability to make good tactical decisions needs to be influenced by a broader strategic understanding of what’s going on in the business. And we’re not seeing enough of that. This is basically the message from the then chief product officer at an event that we would go to once or twice every year or two called Product Days. The other reason for it was we wanna attract really great product managers. And it’s hard to do that when the role is called product owner

Murray: yeah, we’ve seen a, a big move in the industry to turn product owner into a more of a real product manager role, and that tends to mean that people are moving further away from the teams and spending a lot more time with customers and designers doing research. But then the teams start getting into trouble because they don’t have somebody to write the user stories. 

But seriously though with the product owner moving into more of a real product manager role and spending time on a lot more time on discovery what did you do about the business analysis type of stuff that the product owners used to do?

Brendan: So we experimented with a role for a while called technical Owner. And it was a mix of scrum master BA product owner someone that can help the team define the slice of value we’re trying to deliver and learn. I would say that by this stage, teams were mature enough that it’s not unreasonable to expect teams to write user stories. We have to remind ourselves, user stories are a tool to help us be more customer and value focused. Many teams just weren’t even using user stories because they had the conversations that were necessary to understand the problem that we were trying to solve for the customer. I know. Shock horror. No user stories.

One thing that I got to work on a bunch as well was test automation. And for a while, Spotify went all in with end-to-end tests and eventually realized that, you know how you see the the test pyramid. I used to call ours the test martini glass

There was so few unit tests, some integration tests and a but load of end-to-end tests. So that was a big initiative to try and change that over time to give teams lots of data to understand the state of quality. A fun fact about automation was before I took over desktop all the feature teams owned the different features on desktop.

And when I inherited all of those features in the desktop client, we quickly learned that there was probably about 10 or so different ways of writing unit tests in the client . So the thing about autonomy, is that it can lead to a lot of lack of standardization.

So we had to put some effort into standardizing on a particular tool and cleaning up a lot of tests and, but if you have lots of great tests then there is less need to do a lot of that work, I would say. And then you have to ask yourself do we need to add a new test to this? And to teams learn how to write tests at all levels and that more or less replaced the need for all of this manual test definition and stuff. But there were also QA helping teams figure out how to do this well. And you might have a card that isn’t written in a user story, but does have some test cases assigned to it or acceptance criteria.

Shane: So I’ve read that there was autonomy to make decisions around what tooling you use. If you want to use Jira, then you’d use Jira. If you wanted to use something like Trello, you could. And that over time there was a natural progression where teams would reuse what other teams use cuz it just made sense, but that was a choice. So how did you deal with standardization versus autonomy?

Brendan: In a whole bunch of different ways. I really like how Spotify came up with this idea of the Golden Path. And so teams that are building tooling for the rest of the organization to use, especially in infrastructure and operations, and one of the other tribes, which was called App Developer Productivity or design systems are a classic example of this too, where you make it so easy and helpful to use a particular tool or framework or component that. Why on earth would you bother using something else when Spotify’s done the hard thinking for you to make life really easy in your context? The concept of Golden Path was a really great way of saying you can still do what you want, but the easiest, blessed way of doing something is this.

We had a chief architect and the chief architect would very rarely make those strict calls to do things a particular way, but sometimes he did. So for example, you used to be able to write production backend services in Python or Java. And Java was chosen as the, if you are gonna write a backend service, it’s gonna hit all our customers or a lot of them. It’s gotta be in Java. Python you can still use it to experiment and test and learn. We’d never wanna stop you doing that. But if you wanna release something to all our customers, it’s gotta be Java. So occasionally there were those big decisions being made. The guilds also played an active role in figuring out how to standardize things. So people in a particular discipline, whether it’s the backend guild, front end Guild, might say, we are really struggling because when I want to go and work on this other code base I have to relearn javaScript frameworks . There’s seems to be one released every day and it makes life for developers difficult to have to keep learning new ones. Not to mention potentially any interoperability between them. But the guilds will get together and say, this is a problem.

Like, how do we solve this? And so the automated testing problem that I mentioned before, the unit test standardization came about from the Desktop Guild saying there’s too many, we can’t make sense of the data. If I join, go from one team to another, I’ve gotta learn a new framework. Let’s simplify this and we all want this. So it would either come organically, top down, or they’d have a golden path standard for how to do things.

Shane: And so the guilds more like a book club, where there’s a bunch of good ideas and we’re sharing, and if you think it’s a good idea, you’re gonna pick it up than a committee. Is that true?

Brendan: Yeah, I’d say that’s probably fairly accurate. Although the book club analogy does feel a little bit too non-action orientated I, I think out of these conferences, a lot of really good actions would come from them and people would run with something in order to make life better somehow. And committees would be formed at the conference, but they’re committees around a particular problem.

They’re not the guild committee, if that makes sense. Standardization of development tools on desktop was a committee where a more senior developer stepped up and said, Hey, this is really causing us lots of problems. We’ve talked about this. I wanna make a difference. I’m gonna put together a group of people from across the company in multiple time zones that represent different parts of the product that, of the desktop product in order to push for standardization. And he teamed up with one of the coaches to find some tools from Sociocracy in order to make that a real consent driven fast decision making process. So the coaches can actually be quite helpful in that scenario too.

Murray: I wanted to ask you what you think about the big management consulting companies going around implementing SpotaSAFE at the banks, telcos and mining companies. So imagine you’ve got a big hierarchical, traditional bureaucratic bank. Quite authoritarian, very centralized controls, very regulated. And the executives sit in an ivory tower in a wood paneled office with a secretary out in front. And then BCG or somebody comes in and sells them, the SpotaSAFE model. We’re going to help you cut your costs 20% by streamlining your bureaucracy liberating your people, and making you much more innovative and faster. They’ll talk to the executive team and they’ll come up with a new organizational structure, a new quarterly funding model, position descriptions, which they’ve used from some other client. And then they roll it out. Now the rolling out part is, an announcement, a consultation period. Here it is. Thanks for your feedback. No changes will result. And then you no longer have a job apply for a job in the new structure. I’ve seen it. And I’m wondering how you feel about that.

Brendan: Firstly it’s not really the Spotify model if it’s all about cost cutting. And it’s a big bang rollout of change. That’s so far from the environment that I was in within that model. So I what they’re really, I suppose taking is just the matrix structures. And perhaps that’s about it. It’s absolute madness. You could probably insert any other model in there and call it a cost cutting exercise, and it’s probably gonna achieve the same thing. And in fact, Spotify really was not that lean compared to a lot of other tech companies. We were lean in terms of how we worked, but we weren’t necessarily lean in terms of the ratio of like doers to non doers, engineers to design products, coaches, managers. Even just having a manager for every eight to 12 people alone is a heavy ish structure when you think about it. 

Murray: Not for a corporate 

Brendan: The cost cutting stuff, it’s hard to even comment on it because it’s not really what I know of as the Spotify model. But if we were to be kind and we were to say they actually have really good intentions, and it’s not about cost cutting, it’s actually about being lean, for example, and innovation and all those great things. To me, it’s like trying to sell a pathway to the modern era to an Amish community. The amount of shock to the system if you truly wanted to work the way Spotify works in a really top down ivory tower bureaucratic command and control bank , to be able to achieve that to me, it’s like electroconvulsive shock therapy to an organization. If you really wanted to go all in with that approach, and of course it implodes because using the Amish analogy again you’re bringing in things that they’re gonna have a visceral reaction to. Oh, so wait. My job as a manager is not to define everything. It’s not to have all the work that a team does be driven from the top down and specified by the time it gets there. I actually have to trust everyone. I have to give access to sensitive information to everyone. There’s so much baked into how Spotify made that model work that isn’t in that paper that I think is necessary for it to work in the way that it worked. 

Murray: I think there’s a philosophy underlying what you are saying about trust, empowerment. It’s not about cost cutting, it’s about believing you get the best out of people by getting really good people in, entrusting them. 

Brendan: yeah. And if I were to map Spotify’s model to one of the Agile principles, it was simplicity, the art of work not done is essential. that one is just so missed. And the trust point to me, all roads lead back to trust. I remember one of my first interactions when I got there was speaking to a VP of engineering and him gloating about the time he took down the spotify.com website accidentally, and what he learned from that. Another fun one was at some of our Christmas parties, we had a really talented piano musician that used to be in a well known Swedish band. They would set up a grand piano for him, and at the Christmas party he would play a song that he came up with that would absolutely roast the C-suite over the mistakes that they made in the past year. Absolutely. Completely and utterly obliterate them to the point where it’s almost uncomfortable. You’re like, oh my God. Is that even okay? But that was the culture , we don’t have time to let our ego get in the way of learning what the right thing is to do and pursuing whatever the right thing is to do.

Murray: It sounds like there was a lot of openness and honesty as well there, as opposed to the usual corporate thing of where, the manager’s job is to spin the message, like the watermelon project. One that’s read on the inside and green on the outside. So

Brendan: Love it. 

Murray: The team are all saying this is a disaster, everything’s on fire and it gets reported on the status reports using traffic lights, green, yellow, red, that it’s green and as it goes up what was shit at the team level turns into a powerful instrument for growth.

Brendan: Yeah. The majority of the time there was that real trust and openness and even just how planning worked, like people were expected to give a traffic light update on progress towards hitting a key result. And red was commonly used. We’re not gonna make it, . And that bubbled all the way up to the 10 company bets that, would have the CEO and a lot of the C-suite gather around and go how are we doing on these things? Daniel Eck, the ceo, would often get up at town halls and say, I want this company to make more mistakes than any other company in the world. Oh, and by the way, here’s a mistake I made recently. Like you’d actually embody these principles, which I think is sorely missing from a lot of these transformations because they don’t happen from the top. And even if they do, the person at the top is not embodying these principles.

Shane: Yeah, it’s one of the tests I ask is okay, so you’re going through a transformation. I’m using the air quotes there. So your exec are doing daily stands ups, and it’s open for anybody in the organization to come and listen. They’re not having conversations on the side and closed room boardrooms about the organization. And of course the answer is no. They’re not operating in an open and transparent and agile way that they’re asking everybody else to.

Murray: Let’s talk a little bit about what you’ve been doing since. So you went to 29 K, which is a mental health charity. How did you apply what you’d learned at Spotify there?

Brendan: When I got there, there was a lot of tail spinning, a lot of going around in circles trying to figure out what the right product is to develop. We were trying to do something really difficult, which is to try and, give the world free access to transformational growth tools. Where if people do the work on themselves for long enough in a group setting, we believe that we could move them through what we call Robert Keegan’s stages of adult psychological development. Which is an enormous undertaking. And we were basically working with psychologists to provide free interventions and courses and programs that people do in a group context.

What I tried to do when I got there was go, let’s stop talking about it and let’s try and put something out there and actually see if people want to use it. Let’s start validating our assumption. So a lot of what I did in the early days was product discovery, user testing. Will people be willing to be vulnerable in a virtual group of strangers? To me, that was the hard nut to crack. Will someone be able to talk about their childhood abuse with a bunch of strangers on what is effectively a zoom call

Murray: Yeah, 

Brendan: that’s really hard.

Murray: and were they 

Brendan: Yeah, we did manage to get some pretty powerful stories. We used to joke that our metric was tears per week. It was very challenging and a lot of the stakeholders were not accustomed to building tech products in a scrappy discovery orientated way.

And either they wanted the future vision of having a huge platform that we can use to do psychological research on and all that stuff. And it’s like we are so far away from that reality. We have to park that idea for quite some time. Cuz unless we can get people to use the app, we’re nowhere near close to that.

And then, you had people that have come from a psychology background or a neuroscience background that also don’t understand anything about building tech products. So yeah, it was really challenging.

Murray: But you were there for two years, so you must have built a few things 

Brendan: Yeah. We launched with a yoga influencer and we got the product out there. We got some people using it. We got some good feedback and the team have been iterating ever since. It’s a great tool.

Murray: And since then you’ve come back to Australia, you’ve joined a small consulting company called, ORgana. And you’re using the CRISP model now. I think it’d be quite interesting to hear how that crisp model works. What is it? 

Brendan: Yeah. So basically it’s a model for consultants to have a home, a community of people that can share costs, share work, learn from each other. It’s the best of both worlds, of either being a full-time employee versus going at it alone. So for me I’ve only done the whole consulting thing for a fairly short amount of time in the past, so I was pretty new to training and consulting. I did training stuff at Spotify, but doing it alone just felt too overwhelming to me, but also working full-time for a consulting agency also felt too constrictive, so this model really made a lot of sense. Cuz a lot of my interests are in the therapy side of the world. I volunteer at a personal growth retreat and they go for two weeks at a time. And I want to be able to go and do that volunteering. I’ve just started a master’s of counseling and the likelihood of a full-time position supporting me in all these endeavors is pretty low. So for me it’s a lot about freedom and autonomy. So our values are freedom and autonomy in, in return for transparency and accountability hearts over wallets. We care more about the happiness of ourselves, the purposefulness of what we’re doing over simply money. We care for the community over individual pursuits and continuous learning over a hundred percent billable work 

Murray: how does the financial side of it work though? 

Brendan: Sure. So we each pay a monthly fee back into the community, and that ensures that even if none of us are working, our month to month costs are being looked after. And we don’t have a lot of month to month costs. It’s like our Slack subscription and Gmail and all that stuff. And then 10% of everything we earn when we do work for clients, when we host training courses, 10% of that goes back into the business up to a certain amount. So , if we earn over $150,000 a year, we stop contributing into the business. And that’s to stop, if someone has an, a freaking amazing year, they’re not just bankrolling everyone else . But the minimum fee per month is also ensure that there is still a contribution coming in. And then we collectively decide how to spend that money. So part of that is for us to meet four times a year face-to-face. So it covers travel costs and the rest we decide.

Murray: And how do you get work then? 

Brendan: So the model only really works if you have a good enough network to find work yourself. So it’s not gonna be appealing to someone that is a junior consultant because they will struggle to find work and it’s not a given that we re gonna flood you with work opportunities. So we want every new person that joins could survive out on their own, is the expectation. 

Shane: So as a person who’s been a developer, then become a coach, and then a product manager, should agile coaches have always played on the field in the area they coach or not? What’s your view?

Brendan: I think it’s preferable from an empathy perspective to be able to empathize with the people that you’re coaching and helping. My entry to Scrum was literally reading the Wikipedia article about Scrum. I didn’t even do the course when I first started experimenting with it, I was like this is gonna help me solve a problem that I have and I’m gonna try it and see what happens. So I think just experience with trying agile ways of working and helping teams and leaders, 

Murray: This comes down to what you think the model of an agile coach is. I think of an agile coach as being like a sports coach, like being a coach of an AFL football team, whereas there are a lot of people out there at the moment who say, no, an Agile coach is a counselor. It’s the counseling model. In fact, if you try and get approved by IC Agile or ICF they will tell you that a coach does not provide any advice.

Brendan: Right.

Murray: All of that dev experience at Spotify. Don’t even talk about that. In fact, it’s probably a bad thing to have cuz you might inadvertently start offering people suggestions. Do you see what I mean? There’s a life coach model versus the sports coach model. I’m very much on the sports coach model side, but I’m wondering where you are? 

Brendan: I don’t think it has to be a dichotomy like that. I think the primary model is of a sports coach where you observe the team and you have tools and tactics to help them succeed. And you have advice to give and things to help them try. But I think of the ICF coaching, the one-on-one professional coaching stuff as a leadership stance you can take, or a skill you can use to help someone solve a problem. Because sometimes the transition people make when working in agile teams is overcoming this need that everyone else has the answers for them. And being able to coach someone through a problem to realize that they actually have all of the capabilities they need to solve that problem is also really beneficial. So when we used to talk about the agile coach role at Spotify, we used to use both of those analogies when describing our role.

Shane: Yeah, I think it’s about balance, you’re not there to say it depends to every question. But you are also not there to dictate what they should do next, you gotta find that balance to help the team be more effective at what they do and have more fun. And that’s your job, and you use the skills that you have. 

Murray: I like that you said it’s a stance. The counseling model is a tool in your toolbox. 

Brendan: Yep. 

Murray: It’s not everything.

Shane: Yeah. Sometimes you do take that stance because that’s the right stance to take. And sometimes you take a more directive stance where you go have you tried this? Have you tried this? because at the time of the context, you think that stance is the one that will help them the most, and then half the time you’re wrong and you learn and you go, not gonna do that again.

Brendan: In my first year of being a coach at Spotify, I did Lisa Atkins coaching Agile teams course with her, and she’s amazing. And I learned how to coach and I remember coming back and I started using it and I was like, wow, this is really powerful. And then I remember having a conversation with my manager where she’s I can see , you figured out this coaching stuff and that’s really great, but you also had really good advice and opinions and ideas and I think some of your teams are actually missing that right now because you’ve fallen in love with this coaching thing and maybe you need to figure out where the balance might be. And that was a really good feedback. 

Murray: Okay. All right. I think we should go to summaries. Shane, what do you reckon?

Shane: All right. I love the fact you started off talking about Spotify running. It just goes to show that we should do something, we should learn from it, and we should be willing to kill the babies. 

I love the fact you talk about separation of principles and patterns. You call ’em practices. I call ’em patterns. So this idea of here’s our core principles and everybody’s gonna be, held account to those principles, but the patterns you use to deliver to those principles is up to the team. 

I love the idea of a bets board. They’re all strategic bits and more importantly they are stacked rank. There is always one bet that’s at the top and you start from the top and work down. And you talked about the teams doing quarterly plans to say how can we help achieve bet one? How do we help chief Bet two? But later on, you talked about we have some other priorities as well, which we always forget about, which is keeping the lights on, paying down the technical debt, all those things that are just as important. And that balance is always hard, but the idea that there is a set of things that have been agreed are the big bets we’re gonna make. And teams know what it are and they can figure out how to contribute. 

I intrigued by this idea of the constant use of the triad. The head of technology, head of product, head of design, being a triad together to help balance out some decisions. So it’s not one person, but it’s not a committee that takes six months. and The product owner, the chapter lead, the agile coach forming that triad capability. 

We’ve had Jason Yip on here as well and he articulated it in a different way, but now I can see the alignment, which is we develop our ways of working because our product strategy was fast and agile. And therefore everything we did was directed towards it. It wasn’t that we were putting in an agile transformation or agile way of working. Our product strategy was if we didn’t work that way, we’d be dead. 

Brendan: Yeah when we looked into the data we saw that People were consuming music in different ways. They weren’t consuming albums and tracks and artists. They were actually going, oh, here’s a playlist around dinner parties. Here’s a playlist for my morning coffee. Here’s a playlist for these sorts of things. And so the strategy was the right music for every moment now to pursue what moments they are and what they should be, and how you can innovate around them requires that fast, autonomous, innovative way of working in order to pursue lots of ideas. It comes back to , what problem does the company have? What’s it trying to achieve and how does this help us achieve that? And often that gets missed.

Shane: Okay, so the big boys are gonna come after us and try and take out the segment. So we’ve gotta innovate faster, we’ve gotta learn faster, and we’ve gotta change faster. And that’s what we’re good at. And so if you apply that to a bank, if that’s not what you’re trying to do, if that’s not your company strategy, then the Spotify way, probably wouldn’t fit you.

I love the idea that, you moved from product owners, which were tactical to product managers, which were strategy focused. I’ve always loved the way Spotify described the golden path. The idea that if there is a good option, we can adopt easily and then go and solve another difficult problem. We’ll adopt the thing that just seems to make sense, and so that idea of using your design systems where why wouldn’t you use them, it’s a solved problem. Use them and then go find a problem that hasn’t been solved yet.

And most people will do the right thing. But if they don’t, you always need a rule maker, so you’re talking about the chief architect being the rule maker, and it takes a certain leader to be the rule maker who never makes rules. You only ever do them when there is no choice. You have no other way of influencing. And often the people in those roles are more managers than leaders, and therefore set rules all over the place. 

I like the definition of a guild that conversation we had around committees versus book clubs. There were still groups formed to fix problems but they were more transient. There’s this problem we’re gonna get together rather than a committee on the bench for the 12 months. They were, here’s the things we’ve learned, what are we gonna do about them? Take this action. 

So I’m writing a chapter in my book at the moment around team design. And so I’m focusing on patterns. And I had Spotify as a matrix pattern. But actually the more and more I think about it based on what you said, that’s not true. The pattern they followed was a self-organizing pattern. What happened was, it was just when it was published, it looked like a matrix because that was an easy diagram to draw. And so actually the pattern that they had was self-organization, self-empowerment, and then they just happened to use some matrix to form groups of people that could self-organize. So that for me has been a bit of a revelation and quite timely given what I’m writing right at the moment. So that was me. Murray, what do you got? 

Brendan: I would say it’s still, for the most part was a matrix organization. But I think that the key point is that we were never necessarily wedded to the, that having to be the way it is. So some teams actually said, screw it, we’re gonna have a line manager for all the people in a team and it’s not gonna be matrix. And that was an experimentation that actually eventually led to where they are now, which is that they don’t have chapter leads anymore. And they do have a line manager that has all the people in the team report to them.

Murray: Yeah. So what did I get out of this? There’s a very big difference between what people are doing in big organizations when they’re talking about the Spotify and Safe model and what Spotify was doing. I was really glad to hear that spotify really was a great company to work for that was doing things really well that really was empowered, that was living what they were talking about.

And they’ve been very effective in the market. They’ve really succeeded with their product strategy. They’ve been continuously innovative. They’ve been lots of clever things coming out. They’ve been mistakes, they’ve been disagreements. I’m thinking about Joe Rogan and all that stuff internally but that’s fine because as an organization they are driven by the values of empowerment, respect, trust, openness, honesty, low hierarchy. Things which are very much Scandinavian cultural values. And it’s that strategy and those values, which have led to the organizational structure, which was written down and that structure was constantly changing through experimentation anyway. So teams were empowered to say, no, I don’t wanna do that. I wanna do it differently. And it’s really that continuous learning. Continuous experimenting on the product, the way of working and the organizational structure, which led to, a very effective organization. And big consulting companies and executives who are going in and implementing the Spotify model are not implementing any of that. All they’re implementing is the matrix model and safe and some process changes, but they’re not implementing any of this empowered teams experimenting with things because that is extremely alien to their top-down hierarchical ways of working. 

We are actually very skeptical about whether organizations are benefiting much from what they’re doing with these big agile transformations. There’s a vested interest for people to say, yes, it is working. Is it, I don’t know. The thing I see is yes, there’s a big restructure. A lot of people lost their jobs. There’s new processes around safe, and there’s now quarterly budgeting, but everything else remains the same. All of their heavy bureaucracy, their rules, their processes. They still somehow expect that’s all gonna continue while they’re doing all this other stuff. Consultants I’ve spoken to say these organizations were a real mess internally.

I actually did coach a team in one of these organizations. I was trying to help a program manager, and we had this deep conversation about him being extremely authoritarian and he said you just can’t trust anybody and I don’t believe in this agile shit. Have you ever seen it work? I said, yes, in the past. It’s always worked well for me, but now I can see you having a few problems. God, that was hard. 

I think what I keep coming back to is that there’s something very real and very important and very valuable in all of this lean, agile, continuous delivery empowerment stuff that we are talking about. Spotify and organizations like that show can be done really well, but there’s also a tremendous amount of bullshit out there in the consulting world when people are going out and saying they’re implementing the Spotify model. So I suppose what you are showing us is the holy land is possible which is good news.

Brendan: That is the internal conflict I have so often seeing it out there. Even just in companies where they’ve just used the wording and that’s about it. And just going this could be so good, . Just it’s the hard stuff that they all miss. It’s the hard problems of, removing. Processes, removing bureaucracy, changing leadership styles. Even if these companies have the best of intentions, God is a must be a bloody hard thing to pull off, to really shift from such an enormously different way of working to something that is so dramatically different.

Murray: Well, And there’s a lot of very strong, vested interests of people who want to maintain their authority during all that as well. 

Brendan: Yeah. Either of you guys read The Sooner Safer, happier Book.

Murray: No, I’ve heard about it. 

Brendan: It’s the best book I’ve seen so far on transformation in a way where I could relate a lot of their principles back to what I saw at Spotify. And when I’ve read some of that book I’ve, looked at the way that they’ve thought about these things and go, oh yeah, that it’s like how we did this at Spotify. Ah, that was kinda like how we did that. I think that book is probably aimed at much larger organizations that want go on big transformation journeys. So worth checking that out.

Murray: Yeah. Alright. Let’s talk about how people can contact you and get some help from you if they need to. How do they do that?

Brendan: Sure. So, you can add me on LinkedIn if you like. Just Brendan Marsh, b r e n d a n. Or you can check out our website or Ghana O r g a n a.com au. We’d love to have a chat and I like meeting new people.

Murray: All right. That’s great. Hey, thanks for coming on, Brendan

Brendan: It’s been a blast. Thanks for having me.