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?

  • 3
    I always call people out for this..but I am going to swerve the question (really sorry) and say; there is no such thing as "the Spotify model". It is not a thing. The author of the white paper you are referring to (Kniberg) has even tried to distance himself and Spotify from it since they have progressed far beyond that. This doesn't answer your qiestion but for your own professional development it is important to understand that the Spotify model is not a model, it is, quite simply "Spotify in 2012". And, it was a best endeavour with mixed results. – Venture2099 Oct 18 at 13:39
  • Yes, I agree. It's just a trendy name, and because it's become viral nowadays, people will understand when we're referring to the "Spotify model". Usually it's the description of clustering an organization. Perhaps even for the same reasons, as in, why do you call an aubergine "eggplant"? It's not an egg... – dqm Oct 18 at 13:43
  • 2
    That is not quite the point I, or even Spotify are making. It is...the music company built their organisation organically in the image they wanted to serve their customers their particular product. It is not a model. If Henrik Kniberg was at IKEA or Chase Bank he would have invented a different organisational pattern. There is no model. The model is...design your own model. Does that makes sense? They started with engineering and worked forwards to a structure that suited engineering goals. Most companies are ramming the engineers into a model...they learned from a PDF at Spotify. – Venture2099 Oct 18 at 17:21
  • As the guys have said, I think you should just be careful about adopting a model which was designed for a specific point in time for a specific company. Also the company was also in a very unique situation as well. – user32613 Oct 22 at 15:08

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.

  • Love this response. Conversational. Adult. Common sense. Fantastic answer. – Venture2099 Oct 18 at 17:24

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.

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.

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.