Shared resources in the Spotify model

Question

A company is trying to adopt the Spotify model, with tribes, squads, chapters etc. They came up with around 6-7 tribes. However they have a part of it, UX/UI that is needed on an ad-hoc basis from each tribe's squads i.e. they so some work for them, and then go away. These guys are regarded as a shared resource. It's been said that there would not be enough work for them if they decided to put the people in the UI/UX team to tribes.

Do you agree with this approach of the "shared resource"? Any lessons learned from using the same pattern? Or reasons to avoid it?

Answer 1

There are a few things I see here to consider.

1) Is the problem that you don't have enough people or that they are too narrowly skilled? Both result in the "shared resource" problem, but require very different solutions. For example, not having enough people can be solved by either hiring more people, cross-training many of the basic skills in that discipline, and providing coaching and mentoring from the expert (the designer). On the other hand, if the problem is that all they are capable of doing is a narrow set of design tasks then they may need some cross-training to be able to effectively integrate into the team.

2) Why don't you want "shared resources"? This isn't the end of the world. If you have it for a while, that may just be life, but it can create problems so you don't want to force this or let it linger too long. There are two main problems with "shared resources". The first is that these skills are usually important and you lose a lot of time to overhead with this model, so you get less and less of an important skill as you spread them across more squads. Second, what happens the when two squads need the same person's time to move forward? Now someone has to lose. This will probably result in holding up a whole squad or making them work on something less valuable while they wait. In the worst-case scenarios, I've seen this result in critical missed deadlines that cost hundreds of thousands of dollars. Those circumstances aren't common, so don't panic, but that's why you don't let it linger.

3) Do you need extreme depth in this skill. Are you doing something bleeding edge in the industry. Companies like Tesla or Boston Dynamics (electric self-driving cars and walking autonomous robots respectively) need people who are very narrowly focused in their skillset because they need all of their time dedicated to a deep understanding of a specific skill. 99.9% of companies don't need that. If you're in that 0.1%, the value added by narrow, deep skills is way more than the value lost or risk added by the "resource sharing" model.

4) Where are you at now? There's a big difference between acknowledging that this is where you are at now and deciding to stay there. If having shared UI/UX designers is where you are at, don't beat yourself up over it. If it's not where you want to be in a year, talk about your plan to grow on to a different circumstance.

Hope this helps - this is really a situation best suiting to coaching and I tried to turn a coaching conversation into a post, which is always messy at best. At the very least, I tried to give you some angles to look at your situation from to make the most effective decision.

Answer 2

Even if there is not enough work "on average" to have a UX resource in every team/tribe/whatever, there will always come a point when the shared resource is required by more than one team at the same time, and the shared resource can't meet every team's needs in a timely fashion.

Good communication and oversight can help (i.e. before teams embark on a UX-heavy feature, collaborate with other teams and the UX-resource to manage time allocation), but fundamentally any time a "team" is dependent on an "external" resource, there is scope for work to be blocked.

Ideally you would have UX-skills within the team - and you don't necessarily need a dedicated UX professional to do this.

Answer 3

So, there's a few things in this question. First, the use of shared resources and secondly, the Spotify "model". Let's take the second one first since it's going to be a lot shorter: There is no Spotify model. The Spotify model is a place in time where Spotify was some 5-6 years ago. They got there by doing their own thinking on how to structure their organisation and if you want to be as good as Spotify you really need to do your own thinking as well.

Alright, onto the actual question: Used of shared "resources". My firm belief is that using shared "resources" is a bad idea. And let's drop the resources work altogether, let's talk about shared people.

Why don't I like people working in several teams at the same time? (because that is what the shared resource situation is like) Mostly because it will drive up your lead and cycle time, ie. how long it takes to get stuff done. It also creates a lot of context switching which again drives cycle times and focus down.

With shared team members sooner or later you will run into a situation where their expertise is needed but they're not available. This can have catastrophic consequences. Also, they actual people suffer from the situation as well: They might not have clear priorities, they do not have a community (team) around them that they can jell with (except the UX/UI community which is not getting enough cross pollination from other communities) etc.

So, in short: Even though from a traditional resource utilisation viewpoint shared resources are a good idea in the real world they're a bad idea because a) people are not machines b) resource utilisation is not a useful thing, lead and cycle times are.

Answer 4

The 'Spotify Model' is not like Scrum, Kanban, Safe etc. It's a methodology that Spotify created for their specific situation. It may or may not have worked, we have no idea of knowing for sure unless we spoke to many employees and stakeholders at Spotify.

I would recommend that you look at something which is proven to have worked at many different organisations e.g. Enterprise Kanban.