#032 - Jason Yip - Agile @ Spotify

Foreign.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

And I'm Jason Yip.

Hey Jason, thanks for coming on. We're really interested to explore what's going on with Spotify engineering and agile these days. A lot of us have seen the videos from Henrik Nyberg about the Spotify engineering culture, so we're keen to explore that and all the experiments you've done since then. Let's start by getting you to tell us a bit about your background and your experience.

Sure. I first got involved in extreme programming back in 1999 when I was grad school and a colleague pointed me to Ron Jeffries Extreme programming, which I started getting into, started engaging with people on Usenet software engineering and then really got into the extreme programming space. My advisor helped organize the first extreme programming conference in Sardinia. So I was there as well. And then before I graduated, I joined ThoughtWorks in around 2001 and then stayed at ThoughtWorks for quite a while, eventually moved and worked mostly out of ThoughtWorks Australia until around 2015, in which case I joined Spotify in New York City. So I've been kind of involved in this for quite a while.

So how long have you been doing agile coaching for?

I never had an agile coach title until I joined Spotify, because in ThoughtWorks you're a consultant. So if we go with that, then it is since I've been at Spotify, which is 6ish years now. But I guess I approach coaching similar to how I approach consulting. It's more like general problem solving, helping people out, doing whatever.

So Spotify is famous because of the video Henrik Nyberg talked about with squads and tribes and chapters and guilds. And I was just watching his video again on the Spotify Engineering Cult show, and it's a great video, people should go and watch it. And it's interesting that that organ structure is just actually a small part the whole video. And yet it's the thing that everybody focuses on the big consulting companies going around to all of the big corporates and saying, we're going to transform you into an agile organization by implementing the Spotify model and safe.

Oh really?

And as a result of that, we're going to be able to cut out a lot of management waste. They go in with a target of firing 15% of people because that's apparently what the Spotify model is all about, being more efficient in your management. So I was wondering what you thought about that.

Yeah, I know, like there's a lot of people who are quite Annoyed with the Spotify model phenomena. The phrase was never used in the videos or the blog posts or anything like that. It was more just, this is how Spotify builds products. And I think that behavior is useful. If more places would just share, then you can learn from each other and it's a useful activity. The problem, I think, is when people aren't engaging in the spirit of, let's share what we're all doing and then we can learn from each other. And it's more, I'm just going to copy what you're doing, but I have no reflection. But what I'm doing, which is not really learning anything at that point, that's the problem. So there's a lot of blowback where people just don't even want to talk about it anymore. And I think that's. Unfortunately, it is useful to share what you're up to so we can all learn from each other. It doesn't even matter whether you're a tech company or not. Every problem solved is interesting when you're saying, hey, what's an effective product development culture? Org structure is the last thing that you need to be worried about. Most places that are having trouble, it's probably starting with a strategy gap before we even talk about org structure.

Well, what's the first thing you need to worry about then?

Oh, product strategy, business strategy. Both. Both having something that's coherent and two, that it's communicated broadly so that people know how to line up to it.

So first of all, thank you to the Spotify team for sharing so much. What was shared and the way it was shared was awesome. Disappointed what the market did with that work that's caused Spotify to be less willing to share. But I can understand why that's happened from the Spotify side of things. So one of the things that most people pick up in is the way you documented a matrix model with squads and tribes and chapters and guilds.

Right.

It was a really nice way of articulating one technique you can use when you want to scale your teams. And scaling is hard. But what I think I heard you just say was, actually, you didn't plan to create an organizational structure. What you did was said, well, here's our goal, let's go and see what we'll end up with. Is that what happened or was it a little bit more formed?

All the things were in response to particular problems. I wouldn't say that there isn't or wasn't a org structure problem. There was. And any place that grows beyond, hey, everyone can sit in one room is going to encounter that it's inevitable. That shouldn't be surprising. Once you get large enough, there are particular stages. You're going to start going, hey, my structure doesn't work. And it just becomes very difficult. And then you have to say, okay, what can we do to structure this such that we work more effectively? But along with that, scale isn't just, hey, the structure is wrong, but there's also, how do I ensure people are aligned to a common goal, that they're able to operate independently, that you can change things independently and not have the end product look like it's completely disconnected. And then you get into the specifics of how you should be structured and allocation, responsibility and even design of architecture. But just to the original point, I want to apply this structure and there's no context for it. That doesn't make any sense. It's like a solution looking for a problem. You need to understand the problem first and then you design something for it.

Yeah, well, the problem is I'm getting hammered by shareholders because my company's not making enough profit because we're an old dinosaur and the big consulting company promised me that they could fire a lot of people using the Spotify model and then my profit goes through the roof and I keep my job.

Yeah. And that's a misdiagnosis. If you say, hey, we are no longer competitive in the market. That's a business strategy, product strategy question. That's not an org structure question. Even if I'm going to magically reduce costs by 25%, that still doesn't make you competitive. That's nothing. It doesn't matter if you're saying, I'm no longer competitive, I'm going to just reduce costs. So, so what, people just stop buying your stuff and it's over? It doesn't make any difference. It's still a strategy problem. Cost cutting is when you're looking at something that's a commodity capability and I don't really care about it and I just want to reduce cost of ownership. Cool. But that only applies to commodity capabilities. It doesn't apply to strategic capabilities. It doesn't even make any sense to talk about it that way.

Well, that's what companies are doing. They are applying this to their core strategic capabilities, their core engineering innovation. It's happening right now.

If you said, hey, here are strategic capabilities and we're not getting any traction, we're not approaching it correctly, I don't have a problem with saying, okay, this is what's going on and we need to be more nimble or effective at approaching these capabilities so that they're more valuable. That's cool. But then you don't talk about it as, I want to reduce the number of people on it. That isn't a relevant point. That might be a side effect.

So what do you need to do to make a great product development organization?

The long list here, and I split it into three things. There's some kind of core belief, there's some principle stuff, and then there's key practices. A lot of the key practices are your stereotypical extreme programming stuff, which is continuous delivery, various technical practices, and there's an underlying assumption there that we're all in it together. I don't know how many people pick up on that. It's not even said because it's just assumed that we're all in it together. So therefore you do certain things, but then you go somewhere else. They don't have that assumption and nothing works. And I go, yeah, that's because you're all trying to beat each other down. That's why nothing you're trying is working. There's no collaborative we're in it together mindset.

We just had a great discussion with Steve tendon from TameFlow, and he says that it's about unity of purpose, which is similar to what you're saying, but the reason you don't have unity of purpose is because of cost accounting models. So you take an organization, you break it up into its parts, and you give each one a KPI, and then each one acts selfishly to achieve its KPI, even if it damages the others.

I would call that strategic incoherence or lack of a business strategy. If you say our strategy is to reduce costs across the board, that's not a strategy. That's incoherent. If it was a commodity thing, I might say, yeah, sure, reduce how much we're spending on this because we don't care about this capability. But that's within a larger strategic context of within our position in the market. This is the stuff that's going to allow us to win. These are the things we're going to play with. And this is in the I don't care, make it as cheap as possible pile. The issue is not that you do cost optimization, is that you're doing it on the wrong thing because you have no coherent strategy.

So the first thing you said to be successful is you need to be all in this together, which Steve calls unity of purpose. What else do you need to be a great product development organization?

Ah, assumption that people are trustworthy. So this is the classic theory X versus theory Y thing. If you think people are not trustworthy, there's a whole slew of behaviors and systems and practices that will come into play that will just make things ineffective and really difficult to scale. If you can say, hey, I generally believe people are trustworthy, but they might lack knowledge. So we have to make sure we communicate things clearly. They might lack skills. We have to make sure there's support to develop it. They might lack tooling structures, whatever. So we have to set those up. And then you'll start actively designing that system to be effective. If you don't trust people, you'll just run around telling everyone what to do, which just doesn't scale.

Yeah, I agree. I mean, it's probably the case that there are a small number of people that are untrustworthy. But if you design your organization, assuming that everybody's untrustworthy, you have this awful organization. So that, by the way, is Steve Tendon's second point. I'm wondering what the third most important thing is then.

I call it a playful growth mindset. Spotify has this value called playfulness. From the perspective of what makes it efficient to learn something, it's usually when you're playing with it. So it's not like work. It's more like you're just messing around with something you kind of enjoy. And you can sustain the hours necessary to get good at something or to learn about it. Playfulness is more for that. So that you have this growth mindset. You want to learn, you believe that you can learn as well as you approach in a playful way.

So with some organizations, we see play days, lots of different names for the idea that a team can stop doing their core work and go and play with something new. Are you saying that actually you're trying to get that philosophy in everything you do, that it is around experimentation and playing with things, with the idea of getting growth, of improving something. And that we don't just keep it to every third Friday.

Yes, that's definitely it. I'm not saying that you wouldn't necessarily also have a break thing, but I treat that more as trying out very different things. So exploring a bit. Because even if we get very good at something, sometimes you just don't try stuff. Cause they're just way off sometimes. So you want to sometimes create space for that. If you look at product life cycles, everything eventually becomes commodity. It doesn't matter how fantastic it was originally. And you need to discover the next thing eventually.

I've Just watched Peter Jackson's documentary on the Beatles called Get Back, which was from their filming sessions for the album Let It Be. And the Beatles are incredibly creative, and you get to see them writing new songs and creating new songs in these sessions, and it's all play, it's all playfulness. They get stuck and they go and play some R and B and they mash things up together and they're just playing with things all the time. And then they find something that's good and they improve it until they get these amazing songs.

Yeah. People have been looking at, how do you develop expertise? And they talk about how many hours it takes and deliberate practice and all that. And I think there's sometimes an assumption that that practice is a lot of hard work. But I think playfulness is a much more reliable way to get that sustained effort on something than just saying, hey, I want to be super disciplined and we're going to focus on this thing. Most people can't sustain that. If you're looking at the level of an organization, you go, okay, well, most people can't sustain that. I can't approach it like that because I'm only going to give a handful of people who are able to sustain, and everyone else is just going to burn out.

So how does Spotify encourage this playful growth?

So as part of hiring criteria, you're looking at particular behaviors, and if everyone around you has that, then it's a little bit of role modeling osmosis.

Do you think in the early days that whole idea of playful growth mindset was in place at Spotify? Or do you think it's something that tends to be able to be bought into an organization as it scales and as it's successful?

I assume that it was originally part of the initial company. One thing that happens in a hypergrowth company is that all these things don't naturally continue. So you have to be quite deliberate about it. Maintaining it is actually not straightforward when you grow that quickly because you're outnumbered by new people when you grow very quickly.

I wanted to ask you about the people that you're bringing in, because what I see a lot of these days with engineering companies is that they're trying to solve their problems with growth by hiring really large numbers of people in developing countries to work with them. And I've heard a lot of people have trouble with this. You know, some people have said to me, look, you need three or four people offshore for every person you have onshore, because the level of skill is so different. And there's all sorts of Cultural barriers. Some people say it works, some people say it doesn't. I'm wondering what Spotify's view on that is.

Spotify doesn't do outsourcing or offshore stuff per se. We did start introducing something called work from anywhere. There's a time zone preference. So you want to stay in either the European time zone or North American American time zone because it simplified coordination. Back when I was consulting, a lot of the people that I've met in different countries were good. Like the individuals were fine. The main issues, if I'm blunt, were their managers were not fine. Their skill level, their intelligence was no different. Their management was not that great. It actually created a hamper on their ability to engage effectively.

But doesn't it come back to one of those things you talked about, which is core belief, core principles and values, core goals? Those organizations that you're outsourcing to, their strategy and their goals are not yours. They're there to make money by helping with development. They're not there to actually invest in the product you're building. So is that one of the problems is we're bringing other organizations, other people with different strategies and different goals and trying to get them to work on the same thing?

So if you're a company and you're hiring another company to do something for you, I think there's responsibility on you to establish what you expect from a supplier.

I agree. You can't outsource your responsibility for something important to a supplier. You and the supplier together have to take joint responsibility for it. I want to ask you about this again because I see so many people doing it. They're outsourcing their core engineering capability to China because a developer locally costs $200,000 and a developer in China costs $20,000. So look at that. Fantastic cost saving.

So, two thoughts there. One, you might have to do that. This market is very hot right now, so the price difference is significant. You might just say, I can't get anybody. Nobody wants to work for us. Okay, what are you going to do then? You're going to have this kind of strategic partnership. You don't have a choice. I get that. Because this market is crazy right now. Two, normally I would just say don't outsource strategic capabilities. The cost saving is irrelevant because this is a high leverage capability that if you're successful, the return is very, very high. So what does it matter that you save a little money on the developer side? Who cares? It doesn't matter. If that's not the case, you really have to say Is that really a strategic capability? Because, like, there's no leverage here. If something is commodity, where you go, hey, whether we do really well on it or not doesn't matter so much. It just has to just sort of work. Yeah, it may be worth saying, should I outsource this? Or these days be more, can I just buy this? Is there a service I can rent? But anything that's strategic, it doesn't make any sense that you would be worried about the cost of it as opposed to worrying about maximizing the opportunity.

All right, so your strategy then is about hiring great people locally or now a bit more remotely with virtual things. But you're not too worried about cost.

I wouldn't say you're not worried about cost because it can at a point where you do have to worry about that generally. I would say if you understand your product strategy, like what it's worth, it already sets where you care or not about how much something costs. If the return on something is high enough, your care about how much it costs just reduces because it's a ratio here. If the numerator is high enough, who cares what the denominator is? You just don't care as much.

All right, but putting aside costs for the moment, what sort of people are you trying to hire?

Simon Worley had this thing with pioneers, settlers and town planners. So depending on where a product capability is in the product life cycle, so if it's kind of innovation, experimental thing, versus just iterating on something that's already has traction, you just need to iterate on it and you're very confident that I'll have a return versus things that are commodity. And those activities are actually quite different. And you may select people differently because they're more keen to do the different types of work.

So one of the things I picked up was this idea of as you scale the product teams, you try and create boundaries that make sense between the teams so they're not colliding with each other. One of the things Spotify was particularly good is taking their monolithic app and breaking it down into small widgets. So, you know, here's the recommendation widget, here's the widget, lets you play the song. And so each group of people was then responsible, but still aligned with the greater goal. So how does it work as your product gets more mature?

This is very difficult. It's very easy to say, okay, I'm just going to modify this architecture to make it easy to decouple teams. That is very difficult. And yet that is very important to do to work out how to deal with that. If you don't adjust your architecture to allow for adaptation, flexibility, isolation, everything else is pretend. Places do org structure changes and they just pretend that I'm going to have some teams and they're all autonomous and they didn't modify the technology. So it's fantasy. So you go, oh yeah, no, we're all autonomous because the org structure says so. Except we all touch the same thing. Well, why did you bother pretending you're going to be forced to coordinate anyway? There's actually a few tactics here, like one where you're moving interfaces about. It's hard sometimes to work out where should that boundary be and what if it moves? What if you have something that you thought was stable and then you go, wait a minute, there's an opportunity here and then your architecture's not designed for that. So what do you do here? Because maybe it doesn't work either. So do you really want to modify to allow you to experiment there. There's something as well where you say, forget it, we're not going to try to modify interface. I'm just going to duplicate everything, Just duplicate it, see if it works. And then if it works, then we'll worry about cleaning it up later. Anything that's experimental, you should expect to throw 90% of it out. So you don't want to get ahead of yourself.

That reminds me of the XP principle of you ain't going to need it and the rule of three, it's all based around the idea that you can actually refactor and that you're good at refactoring and you do it consistently because otherwise you're going to build up a huge amount of tech debt, aren't you?

Yeah, and usually in the XP days we were talking more about single code base, just the scale was different and the same problem is in play, except the context is way more complicated but you're still trying to create the same effect. I don't think the principle is wrong, it's just the execution is harder.

The feeling I got from the original stuff that was published was actually empowering teams to do what they think's best is a good way of starting. But over time people will tend to reuse work other people have done because it makes sense. So if everybody else is using Jira, then actually if we don't really care, we'll just use Jira because there's knowledge, there's support. Is that still happening?

Yeah, there was enough cross pollination that you get that natural consistency because people are lazy they go, oh, you're doing this, I'll just do the same thing. I don't want to have to think about it. And you'll get this clustering. Now, with larger scale, even that gets difficult. If you get large enough, the cross pollination is not necessarily as reliable. So you'll get this drift happening, which maybe that's not so useful. So there's more deliberate things happening. We have something called golden path for particular technologies. They'll be like, hey, here's the supported everything's in place way to do something and you can follow a guide and whatever frameworks and libraries for it, and that's the supported way. You can still do your own thing sometimes, but usually someone will check in and saying, hey, are you sure you want to do that? Because at larger scale you really have to check on is this variation useful or is it just going to add to the mess that we're dealing with?

So as you scale, we have to be more deliberate about what is shared to provide more guidance but still leave them to make the choice about whether that's the path they want to follow.

Yeah, you want to have encouragement for things that seem to work, but the mechanism might not be the same. A lot of mechanisms start to adjust as it gets larger. This is the same thing. If you're designing a technical system, the architectural principle might still hold, but the way you're able to accomplish that might have to change because scale does change things. You start going beyond human cognitive capability.

So how do you design your architecture so that you can scale and have focused autonomous team?

I don't know if there's a clear answer for this because I've seen two styles out there. Spotify is more of a services thing. You have services and they're smallish and you can reason about them and then some of the complexity is in the coordination of those services. It's a hard thing to work out what's correct. And I know some people back in ThoughtWorks mode, maybe you want them less small and a little bit more coarse because you're trying to simplify the interactions. There's this inevitable trade off. You either have more elements that are simple, but then the coordination is more complex, or you have less things and each individual thing is more complex, but the interaction's a little bit easier. If we humans had a bigger brain capacity, I don't think our systems would look the same. Whatever approach you take, my tendency is just to be aggressive about keeping things simple. I might be wrong though. There's a point where you're going, okay, we kind of cross the boundary of human comprehension now and we have to take a different approach. I don't know, it's tough and people are trying different things.

I tend to either look at the number of lines on the diagrams or I listen to the number of words that have to be used to describe the thing we're talking about. And at some stage there becomes almost an unconscious limit where you go, okay, that was too many words and too long, or that diagram has too many nodes and links. We need to break it apart, simplify it, and then deal with the complexity that we now have. Two things that have to talk together in an agreed way.

So I think the system that you design to be built and maintained by a small team doesn't look the same as a system designed to be built and maintained by multiple teams. Because part of the architecture is to enable particular ways of working. And if you say, hey, I want to have something that allows me to have thousands of people working on it, I'm going to design that differently than if I only want one team working on it. And that's where something that you might say, hey, this is simpler all of a sudden gets like, hey, this is kind of crazy. But necessary.

So what does Spotify scaling structure look like now? Is it still tribes and squads and chapters and guild? Surely you've moved on from that. So what's working now?

Marty Kagan has this term called empowered product Team. It's just our old school cross functional team. All the skills necessary to work autonomously is on the team. But empowered product team is probably the trendy term for that now. If you're in a platform team versus so that's squad and that's still in play. Chapters in the sense of do people of a particular technical discipline get together and then meet and talk about stuff? Yes, that still occurs. So you know, chapters guild type stuff. Probably more guildish now than chapters where you had the line manager being the chapter lead. That is mostly not the case anymore. Mostly it's associated with the team. So they're essentially lean the matrix back to more delivery focused. I know some people who were around during the chapter lead days found it difficult to engage with people because they couldn't stay up with what was going on in each team. So the preference just shifted.

When I'm working with a new organization or a new team, they often struggle with the difference between the person that's in charge of guiding the work to be done and the person is in charge of the pastoral care of the team making sure. That people are getting career progression, that they're having fun, that when they have problems in their life, they have somebody to talk to. What have you done within Spotify? Have you solved that problem of the difference between people directing the work to be done and the people that are helping make sure that people are safe and getting what they need out of their role in the organization?

We kind of went back and forth like, nominally, it is the direct managers who take care of the development of people we also played around with. The product managers would be responsible for the outcomes as well as the health of the team, even though they didn't have direct reporting. And I would say it depends on each area how effective that is. Usually I would say the engineering managers and the product managers, being nominally the lead of a product team, would be paying attention to that. I've also seen too, if you have more senior people on a team, they'll just do that as well. Oddly enough, agile coaches, just because of scale, don't spend that much time on individual teams. So it'll be helping someone else to deal with that more than directly doing it myself. For the most part, it's the people that are directly in that circle will handle it.

There's plenty of research around that says that the majority of the features we build are hardly ever used by the users that we're building them for. So that seems like the biggest source of waste in any of these product development teams. So how do we make sure that we. Where you're building the right thing upfront?

You are actually very explicit about what effect you're trying to create with this feature or product that you're introducing and you're tracking it. So we typically have product insights, people who will set those things up, because you have to set up the infrastructure to be able to measure these things and then you watch some of them take a while, though. You could say, I think it works, but you have to wait because not everything is an instantaneous response. You're effectively running an experiment. And sometimes those experiments take a while to be able to say, does it have traction? I'm not sure. Does it have traction? I'm not sure. And then you'll go, okay, no, we're pretty sure we've run this long enough. It's going nowhere. Maybe it could go somewhere, but we just need to tweak how it was implemented. So you're playing around a little bit with that. You need to be clear upfront what effect you're trying to do. And then you work through it. You launch something you release it and then let's say the first few people like it. Does that really mean like depending on what kind of product, if, because we do a mass consumer product, if even the B2B stuff, like you're not quite sure if you had a single customer and they like it or not, and that's immediate, great, you can tell right away. But for these other things, it's just complicated, you can't really tell and it just takes a while to assess.

How are you incorporating user experience, research and design into your product development teams? Or is that a separate function or do you use the dual track model?

Yeah, we do have user research. I think for internal products we do encourage team members to attend user research sessions to at least observe it. I think for internal tools it is useful to have people talk directly, I think even if it's mediated, facilitated by designers, user researchers, just so that people have direct connection. That's a little difficult with mass consumer side of things. Just because you can't talk to everyone. You'd have to directly talk to a million people, which you can't do.

But you could talk to a sample of people every week though.

Yeah, which is what ongoing user research do. So ongoing user research do, and then people might attend some of those sessions so they get a sense of it. But you always have to be careful how that's interpreted because it's not just respond to what a handful of people say because they might not actually reflect the larger population. So it has to be shaped or framed in a particular way. So we say, okay, that seems reasonable, what we're seeing and how to interpret it.

So this sounds like a bit of a funnel where there's user research and product research going on for a while before things get to the engineering teams.

It's more like it's happening in parallel continuously.

Okay, it's a bit more like dual track. But then how does it feed in?

They're sharing it all the time, they'll be doing sessions and then that gets continuously fed into the teams. It's not like continuous as on a schedule. It's more like, okay, this seems like a relevant thing. It seems real and it drops in. That's ideal. It doesn't always work that way, but that's the ideal.

So is that idea of continuous research and then dropping that information into the engineering team an organic process that's just part of the corporate culture, or is it more a practice that is taught.

When people come in from a broader product strategy? There's still going to be key questions. We want to understand or key things we want to understand. So it isn't just, I'm just going to look randomly at this thing because that doesn't usually work. You're still, hey, here's a thing we're trying to do. Here are key questions and let's look into that. But there's also an area, we're not even sure what question to ask. So we do some kind of discovery, exploratory type stuff. And then you go, okay, these seem to be the most important things. And sometimes you also have very directed things, as in, I would need to know what the answer to this question is and then do that. And that takes time, so there might be a bit of a delay. You also need to be able to operate. Even when you don't have full answer, you still take a shot. But you use whatever you can, though. But more insight is better than none.

So it seems like Spotify is pretty advanced in doing a lot of the modern practices in product development and agile and software development.

So I'm curious then, what are the challenges? What are the main issues you are dealing with now?

I still think aligned autonomy, as in, I have autonomous teams working in a coherent fashion toward a common goal. That is hard. It never gets easy. The larger you get, the harder it gets. That theme hasn't changed since I started working there, and I think that's still a problem. As things evolve, having to adjust the architecture, you could say, hey, this is how we should operate. But then the technology starts fighting you because it's not set up that way. Responding to that and adjusting it and having a technical strategy that supports the product strategy, that is still tough. It's still tough. There are some commodity things that you have to maintain yourself. You can't outsource it because data protection, or there's no one to outsource to, or there's nothing you can buy because no one handles the scale, then you go, okay, you're doing it yourself. So having to juggle the different stages, that's complicated. It's tough. These days we're trying this work from anywhere thing, maintaining the we're all in it together, shared identity. That's tough. It's tough. Kind of had this phenomena that people would only really interact with their team and the people they directly work with and they started getting distance between everyone else. Because you stopped bumping into each other at lunch, you stopped standing in the elevator together, all these kind of random things, and you go, oh, okay. This is becoming a systemic problem. I deliberately introduced bumping into the elevator and deliberately introduce bumping into each other at lunch. All those things are in play. I don't think they're fancy, it's just, they're just ongoing.

So how do the executive and the leadership of Spotify deal with this? Are they doing Agile at the top level?

When I think Agile, a large portion of that is about product development. And what you're dealing with at the top level of a company is not necessarily, necessarily what I would call product development. There are some other things there. I know some people expand the agile definition to umbrella everything, which I'm a little reluctant to go to. You have an overall business strategy, how to make that coherent, how to convey that across a very large organization, ensure those people can operate independently, but also dealing with various other dynamics, politics. As long as people have different interests and they're not cloned, you're going to be dealing with politics. And the larger the scale, the more complicated that gets. That's not agile stuff, that's people stuff.

But Agile has gone pretty heavily into this area with business agility, Agile leadership, executive scrum.

Yeah, leadership teams rather than individual leaders. I wouldn't call that agile stuff. There is good strategy, bad strategy stuff. There's a book by Richard Rummel how to think about strategy, how to convey that. I wouldn't call that agile stuff. That's something else altogether. If people are talking about enterprise Scrum in the sense of I have connecting team things, I don't even know if that really works that well because of scaling issues. If you think how many meetings could you attend and if you're large enough the numbers don't work because you'd have people that all they do is attend another coordination meeting. You need to actually think about this differently.

I think there's an Agile methodology that has got a really good A3 diagram of how you make that happen.

Holacracy has all of its circles and its hundreds of meetings.

Some people were playing around with it, looking at it, I was thinking this is way over specified. This is very similar to a specification for a really complex system. You're dreaming. This is going to be way messier and more dynamic.

So I primarily work in the data and analytics space and what we're seeing in the last year or two is this idea of hyper specialization. And so the idea is no longer having cross skilled teams. We now have hyper specialization and handoffs. So back to a factory model, a flow model. So everything I've read about Spotify in the past has always talked about a group of cross skilled people. That work together on that goal. So is that still the way you work?

Generally, most teams are cross disciplinary. We are seeing some stuff like that where the depth required on that particular skillset for that particular product capability is actually quite deep. Obviously, if you can have the cross functional thing, there are advantages of that. But the first thing is you actually need to solve a problem and you need a certain level of thing and whatever is necessary, that's what you have to have.

So let's maybe go to summaries. Shane Indeed.

So I think the first thing you talked about is it's a strategy problem, not an organizational structure problem. So I think in the market, we saw the Spotify model give us a great org structure that was visual and easy to understand. And so people tried to apply that org structure. They didn't think about the product strategy and the organization strategy. So I think that's the first thing is worry about your strategy problem first, and then the organization will sit around it if you get it right. The second thing I picked up is this idea of core belief, core principles, core values, and core practices. Get those right because without those things being aligned, you've got a bunch of people that are pulling in different directions. Does your organization think people are trustworthy? Because if they don't, you've got a massive problem, especially with remote working, where we can't actually see people and what they're doing anymore. And we shouldn't care. If the work's getting done and it's getting done to the quality that the team's agreed to, then we're all good. Do you trust your people or not? Because solve that problem, the idea of playful growth. We should have fun at what we do. We should be able to experiment within reason because we're trying to solve a problem. And if we can have fun and solve that problem, then why wouldn't we? You use the word deliberate a lot, and I like that. So as you scale things that naturally happen, you have to be more deliberate about enabling those things to carry on, because the new people outweigh the old people. So that culture, that way of working, gets lost unless you're deliberate about retaining it. And if your architecture doesn't support decentralization and scaling, then your organizational reshuffle is irrelevant. People cannot work in the way you've designed the org chart because your technology, your tools, your architecture doesn't support it. So that is going to have to work the old way and pretend that the new org is in place. And as you scale, you get to a size where cross Pollination doesn't happen. There's just too many people and therefore there will become gaps. So as you scale to that size, you need to think about how you're going to maintain that cross pollination or how are you going to come up with another way of working that doesn't need it. So I thought that was interesting. And then four golden paths. So think about the guardrails that are really, really important that you encourage everybody to follow to make them clear. These are the ones that we want everybody to use across the organization because it makes sense. But as you said, you still let the teams go off and do what they need to be successful. So if they don't want to use the golden path, then it's up to them. And then it's about being coherent, not coordinated. It's the idea of everybody working together. But we don't need those command and control structures to make it happen.

I think it's very interesting that organizations have picked up that structure model and then run with it. It's real cargo culting. They've taken a solution to a problem that you had at that time and then just applying it everywhere. And maybe that's what big consulting firms do all the time. We talk a lot about the need to tailor your ways of working for your situation based on patterns, knowing what the patterns are out there. And you talked quite a lot about team topologies, which is good because I really like those patterns as well. And we'll be exploring that further. I thought it was interesting that you talked about some of the same things as Steve Tendon in Theory of Constraints. So unity, purpose and trust in people are absolutely core principles. I loved what you're saying about play and I urge people to go and watch the Beatles documentary because you're going to see it at work. I also really liked what you had to say about don't outsource your strategic capabilities. You need to be investing and building those internally. And yet so many organizations I see are trying to outsource their strategic capabilities to a low cost developing country which doesn't make sense is always very problematic for many reasons, often because of their management rather than the individuals. But it is about things like levels of experience. And if you have 10 people who've got two years experience, that's not going to replace one person with 10 years experience.

So in source, not outsource, hire great people, hire strong people, hire people who are able to explore the area and engage in play, to create and learn. And then I find it interesting that the structure model that was around eight years ago, actually. Still mostly works. But the change is that you've moved the people management more inside the product teams and product groups. I think that's pretty obvious that that was going to need to happen. It seems like a transitional step with people management still strongly outside. And the big issues you're still facing is how do we organize our architecture to enable autonomous teams and how do we align those teams so that they're focused on the organizational objectives and everybody's working together with one purpose and that's the key to it. And you're still very much a product centered organization, which is great.

We started to explore agile leadership and you were saying that you don't really think that that's a thing or very relevant or you don't really believe in it and that interesting.

It's kind of scope creep in my opinion. It's important to understand how to do effective leadership, but I wouldn't say, oh, that's an agile thing. There's a lot of different sources there that aren't just agile things.

Yeah, there's people bringing in a whole lot of good practices and calling it agile leadership. And maybe the thing is that it's all aligning with the agile values. Well, we'll see. We'll talk to experts in that field and see what they have to say. Maybe we'll all learn a bit more. So how can people find you? Jason? I know you have a blog on Medium. Is that the main way people get in touch with you?

Yeah, my handle on Twitter is JCHYIP and that's also the ID I use on Medium. LinkedIn uses my full name, so just chase me up on LinkedIn. But Twitter and Medium are probably the best spots and from there you can find me.

All right, great to have you on. Very interesting conversation. What do you think, Shane?

Yep, that's awesome. And thank you to you and the team that are there now. And the team in the past have been so generous at sharing what you've learned and experimented it at an organization that has a scale.

Yeah. Well, really appreciate it. Thanks Jason.

Catch you later.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help with Agile, contact murrayvolve. Co. That's evolve with a zero. Thanks for listening.

Sam.