Improving engagement in your org that uses the Spotify model

Published on January 01, 2021

The “Spotify model” is an incredibly popular organizational methodology for managing work across teams. Personally it’s been present in some form in the last 4 places I’ve worked since 2014.

The Spotify model is a matrix organisational model that highly values team autonomy with servant leadership.

Now the critical thing is that you have to enable the team to be autonomous! You need to support the team members at their various levels of experience on how to be autonomous and effective. If you do this you will also get higher engagement in your culture and the actual work.

The Spotify Model

I’m going to assume you have heard about the model already. There are heaps of resources on google but I find that it’s critical to read the original whitepaper at

The core unit in the model is a “squad”. This is an autonomous, cross-discipline unit of 5-12 individuals that together own a product or product feature. There is no explicit leader of the unit. The product owner is responsible for prioritizing the work to be done by the team, but is not involved with how they do their work. The team must own their own processes. The process that the team uses to complete work should fit the team.

It’s interesting to note that the “model” was never intended to be a static model that could be transposed from Spotify on to your organization. In the original whitepaper it’s explicitly stated…

Disclaimer: We didn’t invent this model. Spotify is (like any good agile company) evolving fast. This article is only a snapshot of our current way of working - a journey in progress, not a journey completed. By the time you read this, things have already changed.

Copying the model is a starting point, but you should have a process in place to adjust the process or model as your organization and the projects you work on change shape.

You also need to understand what your organization’s culture is. You will need to explicitly provide the support for the individual trust and autonomy that the model demands if it is to be successful.

In other words you should be trying to get your teams and culture to a place where you can invent your own “spotify model” internally!


Daniel H. Pink wrote the book on autonomy in the workplace with his book “Drive”. He provides a generic audit for measuring autonomy in your organization at

This audit can be augmented for a specific product development team by working through the following with the team on a whiteboard or in some kind of facilitated discussion. These topics are fundamental to providing a supportive environment for autonomy and trust. You might be surprised that the individuals in the team have different answers than you or each other.

  1. Do you have a clear mission?
  2. What are the constraints and principles for your product and team?
  3. Explain how you receive support, organizational or technical?
  4. Do you feel fully trusted to do your work?

The responses to these questions can highlight gaps in your explicit support for autonomy. You can fix these AND improve engagement at the same time.

1. A clear mission

In order for the team to know that they are making the right decisions everyone has to be on the same page on what the mission is. This needs to be unambiguous and repeated regularity. It should be clear how the stories or problems to be solved will adance the mission. Everyone that’s on the team should care about the mission.

The mission will change as the team gets customers, solves problems and learns new things, but don’t assume that this shift is implicitly understood by all the team at the same time. Be explicit. An example might be moving from a temporal mission - we are optimizing to get this feature done by April, to a product market fit mission - ok we got that done, now we need to iterate on the feature and improve.

2. Constraints and principles

It should be explicit what the constraints are for a team in your organization. These constraints should be written down and understood by all the team members. This doesn’t have to be crazy, just list the really important things and the things that have caused wasted time previously.

e.g. we have to use AWS, we have to support GAMP, we use these languages or tools at our organization to keep costs down, this client of ours values predictability over scope or quality. These are things that some team members might be exposed to and have an implicit understanding of but others may not. Again it’s better to be explicit.

3. Learning and support

It’s important that the team members have access to support for organizational issues or technical issues. Is there a person they can present questions to about the Spotify model at your organization?

If you’re using scrum or kanban, has the team received explicit training about how those methodologies work, what they emphasize? Do they understand how to measure the success of each methodology?

If you have pick’n’mixed parts of each methodology, has the team explicitly understood the tradeoffs from losing parts of the methodology? Are they changing the methodology to solve a specific problem?

Being able to change the methodology being used confidently is a great way for the team to improve their autonomy and improve throughput by having a process that fits the team and the work!

4. Trust

Trusting the team means when you have the first three items above dialled in, you can just let them off without checking in every day. This can be difficult for organizations more used to top down management or close supervision. You have to know that almost everyone you work with is going to do their absolute best to solve problems they understand and care about. If you have done that bit then you don’t need to worry about engagement.

Issues usually arise from miscommunication. A common issues are that the team didn’t understand the mission or the constraints. You really need to spend the time to ensure these are communicated and understood well. Get the team to play them back to you in a facilitated way to verify.

Another common issue is that the team didn’t have the competence to solve a problem but the culture in the org didn’t allow them to ask for help, or they didn’t know where to ask for help. To have a successful Spotify model you should make sure there is always help available and it’s encouraged to learn from others and to share knowledge across teams (This is what the chapters and guilds are for).

Trusting the team also means supporting them through perceived failures. Make sure they are focusing on the lessons that were learned.

There will always be something to work on here but it will be specific to your team so I won’t talk about it too much. Always be trying to improve trust in the team.

Consider trust between team members and between your team and the other teams or stakeholders too!

Feedback and Autonomy

Ensure there’s a feedback mechanism so the team knows that they are on the right track! Have the team members provide feedback to each other too. So for example if you use strict Kanban, add a regular retrospective type meeting in there!

Darragh ORiordan

Hi! I'm Darragh ORiordan.

I live and work in Sydney, Australia building and supporting happy teams that create high quality software for the web.

I also make tools for busy developers! Do you have a new M1 Mac to setup? Have you ever spent a week getting your dev environment just right?

My Universal DevShell tooling will save you 30+ hours of configuring your Windows or Mac dev environment with all the best, modern shell and dev tools.

Get DevShell here: ✨

Read more articles like this one...

List of article summaries


Flexible work is here to stay but you should choose an emphasis

Note: This was written in August 2022 and I assume things will change quickly. It will be interesting to look back in a couple of years to see how much of this article is still relevant!

Most tech organisations were forced to change to remote during lockdown but haven’t explicitly changed their office attendance policy.


Hiring engineers in a candidate-driven marketplace

I’m writing this at the start of 2022 and it’s never been tougher to hire engineers. There is a very strong candidate market in software engineering at the moment.

There are roughly 1 million open software engineering roles in the USA and somewhere around 200,000 candidates. The rest of the world is having similar issues hiring engineers. Most people seem to think it will be this way for quite some time. There just aren’t enough engineers as software becomes more important to every industry.

When I started my career getting hired was skewed in favour of the hiring organisation. A candidate had to have a degree and there was no remote work so your choices for where to work were limited.

Now, in 2022 candidates with a couple of years of experience are in high demand and practises for hiring have changed significantly. You can work anywhere across a few time zones and university degrees thankfully aren’t necessary any more.

I’m mostly on the other side of interviews these days, so my are tips for other folks trying to hire engineers during these tricky times!


How engineers can help deliver software effectively

Delivery managers and team leads have the responsibility to deliver a software system via an engineering team.

Your customer wants every feature to work perfectly and they want it delivered yesterday. Your team wants to learn and grow.

It’s a tough role managing all the stakeholders and creators in a project.

Engineers can help drive great delivery by empathising with and supporting the delivery manager or leads in a project team.


Engineering systems for consistency and impact

Your most impactful engineering is done before you write any code.

It’s important to have some systems around how you approach problems to make sure you’re consistent every time.

These are some of the techniques I use to make sure I’m covering as many angles as possible when doing my pre-coding engineering.