Sure, so for the last couple of years at Spotify since the concept of people operations was adopted, in many ways people operations was sort of like a local arm of HR within the tech and product group, and it was really charged with sort of greasing the wheels for incredibly fast paced growth. I don’t know the exact numbers, but I think Spotify went from something like two hundred to seven hundred people in product tech and design in under three years. That growth has stabilized, and simultaneously our larger global corporate HR function has really filled out and matured as well. So there is less of that need for that sort of local function. So my charge is to take this group, which I’ve just started working with just about a month ago and really refocus us on organizational effectiveness. So, how do we produce the best learning and the best results, with the people we have in the context that we have?
Yes, so I think a lot of it depends on what your definition of results are. We really try to build an environment where as long as a team is going about attacking an interesting problem, and they are being attentive to extracting valuable learning, I guess I’d say that our only concern isn’t that they build the next awesome feature or they build the next awesome product, or they get us into the next critical market, our underlying concern is really that we capture really valuable learning, and that that learning gets disseminated throughout the organization. Sometimes people talk about “celebrating failure” that’s actually not a framing that I love, I like talking about celebrating learning, and sometimes some of the richest learning comes out of failure modes, and that’s what we really want to be attentive to. So, a team is just as likely to get a great pat on the back for something that might look like a “failed experiment” when they’ve extracted some really valuable knowledge that we can apply in some other area of the business.
Harry: So, concepts like the Lean startup where they focus on failing fast, you would argue go ahead and fail fast if you can learn.
Absolutely. That’s really fundamental to our way of thinking. And it’s interesting in our organization we can get a little bit of clash of cultures between the need to fail fast on the one hand to discover what’s the next most interesting thing that we can be dedicating ourselves to, and on the other hand we have a really strong culture of engineering excellence. So there’s a lot to be done to bring those two cultures together, and to help for example engineers understand that maybe finding the lowest cost, lowest fidelity way to explore a problem space, is the right thing to do on a particular context, rather than making sure that we’ve developed a perfect production ready solution, to a problem that we are not sure yet that anyone wants us to solve.
3. Is the office or department of people operations deceptively technical and technological as well?
Actually the team that I am working with right now is largely non technical and one of the challenges that I’m going to have is to bring in some technical people to help fill that out.
4. Simon, could you tell us a little bit about your talk here at Qcon?
Sure, my talk was really centered around the idea of Spotify trying to grow up differently. There have been a million articles written about how mature companies need to learn how to be more like startups and that’s actually something that I am pretty skeptical about. The problems that a company like Spotify faces on a day-to-day basis trying to serve twenty million daily active users are just widely different from the problems that a startup trying to find its market faces. Our constraints are different, the boundaries of our work are different, the fact that in an early stage startup you just kind of know everybody and everybody does everything, that’s not really feasible in an organization the size that Spotify has gotten to be about fifteen hundred people now, seven hundred in tech product and design. So our approach is what futurist Warren Benes calls an ad-hocracy, which is an organization that is intentionally designed for flexibility and adaptation, and is maybe less concerned about extracting every last dollar of every activity that you engage in, and what this means is that we have as I talked about, a relatively high tolerance for failure. And we have a relatively high tolerance for inefficiency in the name of making sure that we are doing the right thing.
So we are generally a little bit less concerned of doing everything perfectly and a little bit more concerned of deploying our energy to making sure we are doing the right things. And that can mean that we can be subject to a lot of debate, we are very much a consensus culture, that probably comes from our Swedish roots, I got in an interesting conversation after my talk, from a fellow who said, you know, some of what you are describing I fell like I see in my organization where we are really a consensus based organization but what he said was that he doesn’t fell like they ever get to that sort of epiphany moment where everybody lines up behind an answer and I think that’s something that I’ve seen to be really different at Spotify. So we might debate and debate and debate for a long time, but generally we are moving towards consensus and I think that one of the great things about our culture is that when every possible stake holder has had the chance to have their say and all of these ideas have smashed into each other, by the time that we really need to make a decision, there tends to be really strong organic alignment behind wherever we end up. So, you might have a couple of people who might choose to dissent and commit, which is a concept that we are really fond of, but even those people are going to be bought in given that everyone around them really believes in this direction and then those people also can act as some protection in the organization, maybe they quietly maintain some of their skepticism and if they see something going off the rails they’d be pretty quick to speak up and people would listen to them because they’ve already sort of laid the ground work of concern.
Yes, another way that we talked about it is the tension between throughput and utilization – throughput we think of getting more of the right stuff done, versus utilization which is making sure everybody is engaged, and busy and we think that in a lot of traditional organization there is a heavy emphasis on utilization. At Spotify we are a little more comfortable with the concept that we and lots of others in the Agile and Lean communities call slack, which is sort of driven by the idea that if you got a pipeline and the bandwidth is fully utilized, nothing is getting through, no packets are getting through, another common example that we use is a roadway which has been a hundred percent utilized is a traffic jam, and it’s really easy to replicate those conditions in a workplace. So we intentionally built slack into our systems because we want to make sure that everyone is aligned at making sure that the right things are getting done. And that they are getting done quickly but we are more concerned with making sure that we are working on the right problems and we are working on those as effectively as possible.
I think that one of the keys to helping your organization understand why you are actually optimized for is finding ways to visualize it. This is a concept that I learned from the Kanban community, which is just finding ways to visualize your work would have a huge impact and it can start conversations that just wouldn’t happen otherwise, so there are lots of models for that. Some teams use Scrum boards, some teams use Kanban boards, more and more teams are adopting models like portfolio Kanban which are attempts to see across the organization, what kinds of things are happening, and also things like how quickly are those things moving? And at what stage of work are things running into bottlenecks? That can be a really powerful tool and it doesn’t really require you to stand up and make a huge case that something is going really wrong, it sort of can infuse the organization with much greater awareness to what’s actually happening, without you having to pull the red cord and say “Everything is on fire”.
Harry: And your goal would be to have your neighbor adopt that practice.
Yes, that’s actually a really interesting way of putting it, I find that visualizing your work actually catches on, so I’ve seen in lots of organizations actually that maybe someone would do something like a personal Kanban, which is just creating a system to visualize your own personal work and then people would be peeking over the desk and say “Hey, what’s that thing?” and they will learn about it and then the next thing you know there are four people with personal Kanbans and then the next thing you know they realize that they are actually a team, and we’ll make a team Kanban, doesn’t have to be a Kanban that’s just a common method for visualizing work, but the important thing is that you find some way to get that visualized.
7. And speaking of teams, what’s a good size for a team when it comes to technology?
That’s a really interesting question, there is the traditional answer which is like the two pizza team, and I would say that the average team at Spotify probably is somewhere between five and ten people. I am the interim tribe lead which is basically like a department head, for our team that works on social features. And our tribe is small, is about thirty people, the average tribe size at Spotify is closer to seventy to a hundred, and what we are doing is actually treating the tribe as one large pool. And some small group of people who are particularly well suited, or particularly interested in a problem, will form a very small team what we call a squad.
Sometimes as small as two or three people and they will work on the next stage of that problem, and then when they achieve what they sought to achieve they sort of go back into the pool and will look at what the next most interesting problems are and then will match the right people with the right problem. So we are using a concept called Dunbar’s numbers, which is essentially what researchers have suggested, is the actual number where people can actually have social relationships with each other and Dunbar’s number is like one forty nine or something.
We are well below that and our theory is that we actually will be able to develop a lot more robustness and resilience in an organization where we’ve got this pool of thirty or forty people who can reconstitute each other in small teams, for one thing they may get to tackle more interesting problems, they will get to tackle a more diverse set of problems, but this also means that these people sort of all have their fingers in each others code, and we think that this has the potential to unlock some better behavior, because if you know that it’s very likely that you are going to be picking up what that guy’s working on today, tomorrow, and vice versa then you are probably going to taka care to follow some best known practices, that you might otherwise not feel that you have to, sort of you own a little bundle of code and you think that you are going to be the only person working on it for a long time. This is an experiment that we are trying in my tribe, they are a couple of other tribes trying similar things, it runs sort of counter to the standard agile guidance, but so far I think we are pretty happy with the result.
Harry: Simon thanks a lot for coming here at Qcon, and have a great rest of the conference.
Great, thank you so much for having me.