An integral part of Codemotion events is creating a space for CTOs, team leaders and managers to network, learning from each other and build connections.
As we’re unable to currently host our conferences in a physical format, we’ve hosted a series of panels to provide a space for critical discussion around themes of leadership and developer management.
The first was titled The Spotify model is dead – long live the Spotify model. The event was moderated by Piergiorgio Niero – Head of Engineering at SuperAwesome.
Our panelists:
- Kevin Goldsmith – CTO at Onfido (former Vice President Engineering, Consumer at Spotify)
- Daniel Gebler – CTO at Picnic
- Alesia Braga – CTO at SmartRecruiters
During the event, participants were able to ask questions directly of the speakers and vote upon the most popular via Mentimeter and also were polled on a range of topics being discussed by the panellists.
This article offers a discussion of some of the themes and conversation during the panel. You’ll want to watch the video below to fully experience the extensive discussion from our experts:
If you want to know more about how modern technologies and tools can support you for – and during – the organisation of a virtual event, don’t miss this article showcasing the best tools we used to host our online conferences since the COVID-19 outbreak.
What is the Spotify model?
Spotify launched in 2008 in Sweden, and has evolved to a music, podcast, and video streaming service, offfering free streaming of rights protected entertainment as well as addiutional paid features including inproved streaming ad-free and downloads to paid subscribers.
The Spotify model refers to a people-driven, autonomous approach for scaling agile that emphasizes the importance of culture and network. It was first documented in 2012 by Henrik Kniberg & Anders Ivarsson as Spotify rapidly scaled from a staff of 30 to 250.
It was a way of structuring scaling organisations that attracted significant attention by companies – particularly startups – as they scaled as companies were looked for best practices from those that went before them .
The Spotify model or something else?
Panelists were asked whether they incorporated the model into their own organisations. Attendees also answered the question in an accompanying poll:
Kevin detailed his experiences after Spotify, working at a company called Avvo :
“They were interested in the Spotify model. But one of the things I would say is, the Spotify model worked very well, at Spotify. Spotify has a very distinct and unique corporate culture that made that model work very, very well in that environment. When I’ve seen other companies adopt it wholesale, they try and bolt it onto a different kind of corporate culture”.
“And that usually doesn’t work very well, because the core of that Spotify model is team autonomy, which means you actually have to give the teams autonomy. If you are not willing to give that autonomy to your teams, and you try adopt the Spotify model, it’ll completely explode. It doesn’t work. Unless you as an organisation are willing to do that.”
Kevin notes that Avvo had a really good culture and “what we did is we took ideas from the Spotify model, certain things that work and kind of built our own thing. If you look actually, at the Spotify model, you’ll see that it’s really actually a collection of ideas from other places.
It’s taking its synthesising ideas that have been done in other places and combining them into something that was unique to Spotify. People at Spotify would not tell you to grab one idea completely implemented, they would say, take this idea from here, whatever makes sense.”
Daniel notes that as Picnic has grown to over 200 engineers:
“We went through quite a few phases, where we refuelled every 6 to 12 months. We have adopted some step by step elements from the Spotify model but certainly not used it as prescription”.
Picnic learned not to scale agile but the scale your organisation, “On the one hand, you’re looking at how do you scale? Or how do you build a scalable engineering team, but you need to pay attention to the rest of the organisation.”
Daniel shared that besides besides the organisation and process angle, “it’s very important that you think what is motivating most engineers as motivation is probably the most essential driver for productivity and autonomy and experimental culture. We learnt you should have an organisational model that is slightly disorganised in the sense that it’s malleable to change.”
Kevin asserts that the Spotify model has always been evolving from an organisation model to a framework or a set of organising principles.
He stressed “It was really just something that the company did. And thought it worked. Unlike people trying to sell you a particularly philopshy or school of thought. Spotify could care less whether you do whatever you do. And that’s a little bit different from the other kind of scale sand agile frameworks. And that’s also why I think it is actually much harder to adopt because it was never made for kind of other teams, other companies to use really it was just what we were doing and thought other people might be interested.”
When does at company break at scaling and how to monitor its health?
Daniel shares that when you grow fast “essentially in every three to six months, you need to reinvent yourself, you need to reorganise yourself you need to restructure yourself.”
He notes the importance of hiring the right people and that in many cases if you do really disruptive stuff, it’s much better to look for engineers that have a lot of potential instead of a lot of baggage from the perspective of experience.
“In regard to monitoring health, Picnic is monitoring health, the healthiness and the happiness of engineers on a sprint basis, where at the end of the sprint, we are looking at how the team is doing and then based on the results, we suggest organisational improvements. This means most of our structures actually emerge from the team itself instead of a top-down approach”.
Alesia suggests that what works for 10 engineers is not going to work for 40. The next breaking point that I saw was about 60 to 70 engineers, so you need a bit more complexity over there. Then about 120 and then I seen from 120 to 400.
You’re good to go above 400 If you need a bit more complexity, so that’s kind of like my rule of thumb in terms of numbers.” – she stresses that these numbers aren’t set in stone however.
She’s a big fan of objectives and key results (OKRs), a goal-setting framework for defining and tracking objectives and their outcomes.
“When you set up OKRs and use it properly, and then review your results, it’s pretty clear when you see which team is either underperforming or needs support”. She also notes that its often too late once people start showing their unhappiness in the workplace, so it’s critical to prevent that.
The Spotify Model: cognitive dissonance and diversity
Daniel suggests that you need to have a healthy notion of cognitive dissonance. “If you have a team, which is where everybody has come from the same school or has the same type of background that went through the same type of growing up through a similar type of organisation, then you will build a very one-dimensional product. And if you want to have a product that appears to a broader audience that has also the ability to attract new levels of customers, then you need to have some healthy level of cognitive dissonance.”
Kevin notes that diversity is also critical ” I feel strongly about diversity in the teams I build partially because I’ve seen diverse teams deliver better.”
Get ready for the Codemotion online tech conference
I hope you liked this article. If you did, and want to know more about the topic, don’t miss our next online conference! We’re covering an array of topics including serverless, cloud-native, big data, design/UX, IoT, team growth and careers in tech. Join a diverse gathering of tech professions to learn about the latest cutting-edge technologies as well as hands-on activities, best practices, and case studies.
