Posted by acast on Mar 20, 2018 5:00 AM
At Acast we have grown from being a small startup with just a couple of engineers to being close to 30 now working with tech and product and we are on an accelerating curve. We outgrew our old way of being organised and have moved into a new structure that will scale better going forward. This blogpost outlines the beginning of this journey.
At Acast, within tech and product, we have always worked in functional teams that have been high performing, where all the necessary communication and synchronization between both individuals and teams happened organically. Very little process was needed, people were happy and we shipped features continuously. We are today the world’s leading technology platform for on-demand audio and podcasting with offices in Stockholm, London, New York, Los Angeles and Sydney. We have over 57M monthly listens today, and are growing rapidly. At the end of last year it started to become clear that adding more people to the existing structure in tech and product did not make us ship faster. Work started sitting and waiting in queues, communication required more effort and teams had competing priorities while depending on each other. We were outgrowing how we were organised and needed to tweak it in order to continue growing while staying fast.
We spent a few weeks talking to everyone working in tech and product as well as stakeholders outside, trying to identify what problems we had and what we wanted to optimise for. So far in Acast history people had organically executed on new features in projects outside their teams while taking care of maintenance within the functional teams. Growing beyond 20 people it became increasingly difficult to work this way without adding processes. Not surprisingly, everyone wanted all teams to output new features at high velocity while making sure all existing systems stayed stable. The big question was: How can we enable this at Acast while continuing to grow rapidly?
Autonomy and purpose are two core principles of intrinsic motivation for individuals and has proven to be effective for teams as well. Hence we knew that we wanted to have autonomous, purpose driven teams. At Acast we believe in Agile, but we don’t have strict Scrum teams or any other predefined setup. We identified two additional core principles that we find important for our agile teams regardless of process – we want all teams to continuously deliver and to continuously improve. So those were the only two expectations we made explicit in this change.
Figure 1: The four core principles when forming teams at Acast
After collecting data from lots of interviews and deciding on the core principles for creating teams, we started working with two of them, purpose and autonomy.
Purpose and Autonomy
Looking at purpose we saw four well contained purposes that we could organise around that supported the business in bringing the most value for Acast. We created a system diagram over every piece of software that is running at Acast to help identify possible autonomous teams based on the architecture. Since we have a microservice architecture deployed at Azure and AWS, it gave us a lot of freedom when carving out autonomous teams from a systems point of view. We also looked at company strategy and company objectives to identify the business areas we needed to support. When overlaying the business needs with our system architecture it quickly became clear which team purposes would enable high business value and high degree of autonomy.
Rather than having architects dictating how teams should design solutions and what tools to use, we have chosen to give the DevOps engineers that are on-call for all of Acast the mandate to set requirements on the systems to be accepted into the on-call rotation. That means that the teams are autonomous in everything they do up until the point where a system requires people to be available 24/7, then it has to adhere to a set of requirements. Each team has engineers that are part of the on-call rotation, so there is competence in each team to build it “the right way” from the beginning. It also enables us to have a healthy size on the on-call rotation which is at least 5 engineers. Product design and product analytics also happens across all teams to ensure consistency in the user experience.
Figure 2: Organisational design visualising our autonomous, purpose driven teams with a product owner and an engineering manager supporting each one of them.
Once we had our four core principles, the system diagram over all our running services, and a draft over the four teams’ purposes, it was time to start organising into the new teams. We had three criteria for self-organising teams
- Each team must have at least four engineers
- All teams must have the competence to execute on their purpose
- Every system must have a team owning it
People started with indicating interest in multiple teams and then, over the course of a week, converging into their final decision. In parallel with choosing what team to join, all systems were claimed by the new teams. At the end of the week we ran a final workshop where all remaining systems were picked up by a team and we together identified what knowledge dependencies we had and how to address needed knowledge transfers.
Overall this process took about 6-8 weeks and involved everyone working in tech and product. Engagement has been super high and we are positive that this will increase motivation, sense of ownership as well as quality and speed. Next step for all teams is to find their ways of working in order to meet Acast’s expectation of them to continuously deliver and continuously improve. If you are interested in being part of our journey, check out www.acast.com/jobs.