Key Takeaways
- Agile is not the goal - being responsive to change to support organizational objectives is
- You can't emulate someone else's culture by copying their organizational design
- The Spotify Model may be a good starting point, but you need to adapt it to suit your needs
- The Spotify Model assumes you have a modern, microservices based architecture to enable autonomous teams. If you don’t, it might not work for you
- Anticipate adaptation and plan an emergent approach to change
I joined MOO in April 2018, when it was in the process of adapting the organizational structure within Tech and Product based on the Spotify Model. Over the last year, we have started to evolve that initial design into something that meets our current needs.
MOO is an online print and design company, launched in 2006. MOO is passionate about great design and the difference it can make to the world. We help to make great design available to everyone, everywhere, focusing on helping customers create, share or promote their professional identity. Technology underpins EVERYTHING we do. It was vital that we organized ourselves effectively in order to support business aspirations.
Why MOO decided to implement the Spotify model
In 2015, MOO had plans to start growing and scaling the company, including the technology team. With a team of 50 in the Technology and Product already, we had to find a way to structure ourselves better, to ensure we could adapt to the company’s ever-changing needs. We were already using lean and agile practices in pockets, and wanted to work this way more to ensure we could stay flexible and change fast.
The team and wider company described the following problems when asked:
- “We aren’t staffed right”
- “Releases feel really painful”
- “Adding new physical products is hard”
- “Work across teams is difficult”
- “We’re not really doing agile”
- “Monolith to services is not always getting the priority it needs”
- “We’re worried about infrastructure & network & security”
The Spotify Model approach was introduced by our CTO at the time, who had first-hand experience of the model, and knew Agile coaches who worked at Spotify. At the time, it was considered the “new normal,” and the aspirational approach to aim towards and it appeared to align well with our culture, values, and principles. We wanted multi-disciplinary product teams that were able to:
- be fairly autonomous
- release frequently and safely
- do research AND “learn from life”
- take ownership of their products in production
- continue to inspect and improve their ways of working
- build products that can scale fast
- build services and tools that enabled us to go from idea to MVP in days/weeks rather than months
So, it seemed like a good match!
The goal and results that we aimed at
The goal was to ensure the Technology and Product teams could work with the wider company to meet the strategic objectives of MOO, introducing new features and services to launch new products. Technology underpins everything we do at MOO, from our e-commerce experience to printing and fulfillment of orders. Being able to quickly adapt our technology to suit the needs of the business is vital to MOO’s success. Agile was not the goal.
How we implemented the Spotify model
We started off by organizing ourselves into the Tribes, Squads, Chapters and Guilds model described by Spotify, to inspire our organizational design and ways of working within Technology and Product.
We reorganized ourselves into four distinct Tribes, that owned an integrated set of products and services. Each Tribe has two-four multidisciplinary crews (we chose not to change the name of our teams from crews to Squads!), that were stable and organized around ownership of integrated products and services, including support from an Agile delivery coach, a product manager, and experience design. Chapter leads provide line management for each discipline with various Guilds created around topics that teams and individuals self identify with.
Staff It Right
We wanted each crew to be multidisciplinary and to have all the skills they needed to be autonomous and function independently. As well as introducing the concept of stable teams, this meant introducing new roles and career paths, as well as beefing up some of our existing functions
- Introducing the technical product owner as a role & career path. Some of our crews primarily provide very technical services internally. We felt we needed someone with a technical background to be a product manager in these places
- Staffing up test engineering and making test automation a thing within our crews
- Ops Engineering - establishing a Platform team. Not quite DevOps or SRE, but a much more modern variant of a Sys Admin to look after all of our infrastructures and a first step towards removing the wall between engineers and the production environment.
- Staffing up user research & user experience design
Last, but by no means least, we Introduced Agile coaching as a role and as a career path. The Agile Coaching Chapter is there to support and enable MOO to sustain healthy and happy teams that continuously deliver valuable outcomes. We now have a thriving Chapter of in-house, permanent Agile coaches at MOO. What is great about the Chapter now, is that we are starting to broaden wider than the tech and product team, and consider enterprise agility across the whole company.
From Squads to Quads
One of our own takes on the Spotify Model was introducing the concept of a Quad made up of the product manager, Agile delivery coach, tech lead and experience designer. Each Tribe (and crew) would have a Quad that collaboratively agreed what is possible for a crew or Tribe, and the best course of action based on current knowledge from each discipline.
This Quad of roles was envisioned to ensure a healthy tension across each Crew and ensure each perspective and discipline was equality considered. No point doing something technically amazing if there is no customer value, or the reverse, constantly hacking and building tech debt to chase revenue!
The idea was that responsibilities would be discussed and aligned based on the current context, with each role bringing a unique perspective. You could also alternate or add the specific roles depending on the context. Each discipline has certain ‘pull factors’ that will attract certain types of work and responsibilities, creating an alternative approach to a traditional RACI.
How we evolved the Spotify Model at MOO over time
The first iteration was implemented two years ago. We are now at the stage where it needs a refresh, now that we have learned what works well and what doesn't.
There are definitely some aspects which are great. We are much better organized around products, rather than projects and temporary teams. We have more end-to-end ownership of services and stability in teams that don't change so frequently.
Tech and product grew significantly in 2016 and 2017, and being organized as product teams and Tribes helped with end-to-end ownership. As new people joined, they had an obvious home and sense of belonging, helping people settle in better.
There were elements that didn't work so well though.The Spotify model is theirs and it works for them. It's not a magical recipe for anyone to follow.
Over the last six months, we have been making a series of smaller tweaks and enhancements to what we implemented - evolution, not revolution. We don't want nor need an agile transformation. However, that doesn't mean there isn't room for improvement! We have made changes and enhanced:
- Tribe & Crew Leadership
- To ensure more local decision making, we have put more emphasis on the product and engineering directors being ultimate decision makers
- Quads - In smaller teams, a quad isn't viable. In a stereotypical 7-9 person team, half the people were in the Quad, creating an artificial split and hierarchy. Considering all four perspectives is still very important to us - calling that concept a Quad isn't
- Engineering Manager role
- Evolved their job description to ensure they are considered part of the team, and not just focussing on individual people management and using their experience to support and advise the team
- Agile Delivery Coach role
- Making clearer the coaching and delivery aspects of the role and how they are complementary to engineering managers and product managers within their crews and where coaches can bring unique value
- Career Paths
- Evolving all of our job families to ensure they have clear career progression and align with the MOO Core Capabilities model
The Spotify model has been a great starting point for MOO, but now we need to tailor our organizational design for our own needs and culture.
What we learned from our agile journey
Although similar, MOO's organizational culture wasn't an exact replica of Spotify's, which meant some of the ways of working they use just didn't gel for us.
The Quad concept that we were so proud of has ended up feeling a little hierarchical. Many members of the Quad wanted hard drawn responsibilities, so they understood what they had to do. The concept of shared accountability was alien. This meant a lot of decision making by committee or seeking permission or approval centrally for every little detail.
The other main learning is related to the technical enablers to make the Spotify Model viable in the first place.
There are lots of training and case studies out there on how to transform from waterfall to agile. Most of these recommend using scaling frameworks or org designs similar to the Spotify model, organizing teams around end-to-end value streams. The Spotify Model assumes a loosely coupled, modern architecture with Microservices owned end-to-end by Squads in their model - as that is what Spotify does! This is a fundamental enabler.
In reality, many companies have legacy software, monoliths and tech debt that create significant dependencies between teams, that makes this type of organizational design impossible in practice. Until you decouple thee dependencies, it's extremely hard for teams to be truly autonomous. Conway's Lawwas proving true and we had built systems that represented our organizational structure at the time.
MOO as a company is 12 years old and has grown quickly. This means the tech stack has evolved quickly with it. We don't have the ideal architecture (yet!), and have monolithic applications to contend with. This makes it hard to organize ourselves in Tribes and Squads that own end-to-end services, as there are still so many dependencies as we unpick our monolith and build new services in parallel - all whilst continuing to grow as a business!
The next steps
MOO is in the process of making the changes described in an incremental way. We have a great team of experienced agile coaches and technology leaders who are comfortable choosing the right concepts and methods from their agile and lean toolboxes to help MOO evolve. We won't be sticking religiously to the Spotify model or rolling out a scaling framework out-of-the-box. What we do here at MOO isn't cookie cutter and we challenge ourselves and get excited by the process of trying to find the answers that work for us. Although we will continue to be inspired by industry trends.
We are currently assessing our tech strategy and looking more at how our current architecture and legacy software is constraining us and assessing different ways to make progress. This will help with cross crew and cross tribe dependencies and significantly reduce the effort of multiple teams to launch new products.
To fulfill our purpose, we will continue to find and retain top talent, balance our team skill set and seniority, and create an environment that allows distributed working.
The Spotify Model won't help with any of that!
About the Author
Claire Donald is the Engineering Director of Platform & Agile Coaching at MOO. She has over 20 years of experience leading technology teams in both the private and public sector