Spotify - staying lean from small start-up through rapid growth

Editor's Notes

• #3: Spotify is a new way to listen to music. Millions of tracks, any time you like. Just search for it in Spotify, then play it. Just help yourself to whatever you want, whenever you want it. Launched October 28 2008. With Spotify, it ’s easy to find the right music for every moment – on your phone, your computer, your tablet and more. There are millions of tracks on Spotify. So whether you’re working out, partying or relaxing, the right music is always at your fingertips. Choose what you want to listen to, or let Spotify surprise you. You can also browse through the music collections of friends, artists and celebrities, or create a radio station and just sit back. Soundtrack your life with Spotify. Subscribe or listen for free.
• #4: Spotify is available in: 28 countries - USA, UK, Australia, New Zealand, Germany, Sweden, Finland, Norway, Denmark, France, Spain, Austria, Belgium, Switzerland, The Netherlands, Ireland, Luxembourg, Italy, Poland, Portugal, Mexico, Singapore, Hong Kong, Malaysia, Lithuania, Latvia, Estonia and Iceland. Subs: 3M June 2012, 5M Jan 2013, 6M March 2013
• #5: Three (four) development offices, ~300 engineers, ~40 teams. SF: http://www.flickr.com/photos/wallyg/3951912182/sizes/l/in/photostream/ Gothenburg: http://www.flickr.com/photos/andreas-pross/6210384973/sizes/m/in/photostream/ NYC: http://www.flickr.com/photos/19942094@N00/6358840971/sizes/m/in/photostream/
• #6: Tech in Jan 2011 – 60 persons, Jan 2013 - ~300 - 5x growth in 2 years, 10x in 3 yearsFrom 150 to >700 in 18 months. Why grow so fast? We grow to offer better products and solutions, to more users, in more markets, faster.
• #7: We need to improve our product at great speed, much faster than any competitor We need to prepare to scale, meaning that we must continue to move at a high speed while growing employees, users and devices We must continuously improve how we work and we must accelerate the rate at which we improve
• #8: We believe in autonomy. We want to hire great and passionate people and trust them to do the right thing. Best way to leverage their greatness. An organization that leverages everyone’s capacity for problem solving. We’re building an organization that can experiment and learn a lot and quickly respond to change. ----- Controlling management approaches assume people are passive and inert and require prodding.  Autonomy approaches assume people are active, looking for interesting work and curious and self-engaging.  Autonomous motivation has proven to promote greater conceptual understanding, result in better grades, enhance persistence at school and in sporting activities, generate higher productivity, less burnout, and greater levels of psychological well-being.
• #9: “ The most important feature of the organization is the autonomous squad. All other features are designed to support that mini-startup-like squad.” Small team, sharing the same mission and working on one product. Co-located. Cross-functional – everyone needed part of the squad. AC and PO part of squad. It should feel like working in a mini-start-up where Spotify is more of an incubator for start-ups.
• #10: Each squad has a mission and owns their “product” Playback Playlist/sCollection Radio What’s New iOS
• #11: Co-located. Squad room. Open yet closed off. Optimize for collaboration.
• #12: Lounge connected to every squad room, no need to book meeting rooms. Stand-ups, whiteboard sessions, … Quiet room, small meetings.
• #13: Lots of places to meet over coffee.
• #14: A big part of being an autonomous squad is that each squad decides on their own process – whatever suits the squad, their specific circumstances and context. Spotify used to be a company where every team was running Scrum, and we had synchronized 3-week sprints across the company. Today we have moved far away from this – more and more teams are using shorter sprints, Kanbanesque ways of working or a pure Kanban implementation focusing on flow. A quick poll before this conference told us that currently more than half of our teams are using Kanban or a Kanbanesque process and less than a third uses Scrum. This has been an evolutionary shift. It is quite common to see new teams starting with Scrum, especially when they start building a new product. We often see them shifting towards shorter sprints and then completely to focusing on flow as they move closer to getting their product live and then having it live and tweaking it.
• #15: We have a definition of what being an “autonomous squad” means. It lists seven areas that we feel are crucial for having autonomy.
• #16: We also measure, to see where a squad might need support.
• #17: Run survey with multiple squads – goal is to do it at least two times a year
• #18: And we are still all working on one product with a shared goal, so it’s not complete autonomy. Challenge is how to keep them together. We have divided the challenges with growing into two parts: How can do we STRUCTURE the company to effectively support the mini-startups without reducing their autonomy and avoid them getting lost in the big company. How can we learn from each other and leverages economy of scale and consolidation in tools, technical solutions and ways of working? How do we avoid local optimization that leads to global sub-optimization? 2. How can we best work to ALIGN the squads and foster collaboration to be able to build great things, without making them less autonomous This is what the rest of our talk is about.
• #19: Special Interest/Competence groups – web development chapter, backend development chapter, QA chapter, payment chapter, etc. Share knowledge, learn from each other, personal development together Identify common challenges Talk about good practices, decide on architecture, coding standards, etc. Learn technical skills – e.g. Test-driven development
• #20: Servant leadership Coaching, mentoring – your manager is an active engineer just like you 1:1 every week Usually 50/50 squad work/chapter lead Sometimes work in same squad, but not necessarily. Sometimes 2 chapter leads in the same squad. Good thing: harder to think of the chapter lead as a team/squad lead, because that’s not what he is.
• #21: Not typical management career path only, experimenting with “add-ons”, e.g., Expert, Teacher, Coach
• #22: Training, Lunch & learn, Tech talks, Webinars, Practices sharing, etc Management training, Leadership forum
• #23: Everyone working within software engineering is divided into a set of tribes containing 20-100 people each. Dunbar number - <150 people, so we recognize and know everyone Tribe structure is a support for squads and chapters. Focused on servant leadership. Tribe lead does not tell people what to do. The following applies to each tribe: Clear and defined mission High level of autonomy within each tribe Tribes are joined by a set of foundation principles that apply to all tribes Lead by a senior experienced leader (named tribe lead) responsible for all dimensions of the tribe (people, process, technology & culture) All skills necessary to produce live product features and code are present within the tribe, and thus the tribe can build cool stuff end to end A squad resides within one and only one tribe (people may be borrowed between tribes) Different experiments in different tribes: squad ops responsibility, architecture “Scrum of Scrums”, tech lead role, triumvirate, POTLAC
• #24: Tribe gatherings; demos, knowledge sharing
• #25: Avoid going “up-and-down the hierarchy” Squads always collaborate directly with each other Tribe borders are not hard – they are support function, not departments Creates a network organization Shifting fast since collaborations start and stop all the time
• #26: Started measuring after introducing tribes. Goal was to minimize dependencies between tribes. Lessons learned: Dependencies are not necessarily bad – often designed-in intra-tribe. “ Dependency” = not working, “Collaboration” = working well Different sorts of dependencies – technical, product, knowledge – different solutions New goal: Minimize number of blocking and slowing dependencies Product dependencies – closer sync, consider “projects”. Technical dependencies – automate, decouple, …. Knowledge dependencies – tech talks, blog posts, internal trainings, borrowing people, “internships” in other squads Dependencies between teams – technical dependencies, organizational dependencies (overlapping product, mission), knowledge dependencies Never let yourself be blocked. CTO says “Get shit done”, CEO says “When in doubt, do something” Important to understand dependencies – collect data Dependencies and collaborations – same thing. No problem – slowing – blocking – future
• #27: Lack of structure allows structure to happen. Individual autonomy and responsibility: “Make shit happen!” Trust people to do the right thing. Scrum-of-scrum common pattern – too static, our organization is changing all the time=>On-demand scrum-of-scrum when we have longer-lasting collaborations, e.g. projects involving multiple squads for several months. This example – spring 2012, big project (several squads, several months), scrum-of-scrum progress/blockers/dependencies
• #28: A Guild is an open community, so anyone can join any guild. Automatic membership if you are in that chapter – opt-out if you want to Opt-in for anyone else in company You can join multiple guilds, depending on your interest. All guild activities are optional by default. As guild member, you can choose how active or inactive you want to be in the guild. Each guild has a Guild Coordinator (or pair) who is main contact person for the guild, "bootstraps" the guild to enable self-organization, ideally trying to get rid of the need for a guild coordinator role.
• #29: Guild unconference about twice a year – a whole day of lightning talks and Open Space. Good format, very popular
• #30: A challenge with for any company is to create alignment within the organization. When every person and every part of the company is working towards the same goal, the effectiveness of the company will be much larger than if they were all working towards different goals. Sub-optimization and sometimes even conflicts between each others work is not uncommon. It seems to be a common notion that increasing autonomy leads to lower alignment, or that increasing alignment will lead to lower autonomy.
• #31: We believe that is a false dichotomy – autonomy and alignment are not opposed. They are in fact orthogonal – you can have an organization with high autonomy and high alignment. But you need to approach alignment in a different way from top-down control over what everyone is working on – which can sometimes be challenging and hard. Currently Spotify has a very high degree of autonomy, and we are increasing alignment. We are trying hard to increase the alignment without reducing the autonomy. So what do we do to achieve this?
• #32: The core of achieving alignment is to have a shared vision. We want everyone to understand the vision of Spotify – to really understand why we are here and what we are trying to achieve. This is a picture from a town hall where our CEO addresses the whole company. This usually happens every two weeks and usually focus on our vision, but also on what is currently happening in the company. Every town hall ends with a Q&A with top management, where any question can be asked. This is only one example of great transparency.
• #33: We also use OKRs – Objectives & Key Results – to align what everyone is working on. An OKR is a goal for the quarter, that is broken down into a few specific and measurable key results. Setting the OKRs for every quarter is an iterative process working both top-down and bottom-up at the same time. Every squad will think about what they want to achieve the next quarter and what will be needed in order to do that. At the same time there will be work on clarifying the overall company goals for the quarter. So things will bubble up from each squad, but they will also think about what they can do to support the overall goals. Before deciding OKRs squads also check that their OKRs does not conflict with other squad OKRs. Every Product Owner is part of the Product department – which is separate from Tech, but closely mirrors the tribe structure in Tech, but smaller. In a sense, Product is almost like a chapter and a guild cutting across all of Tech. This allows the product owners to sync their plans and goals with each other – so a lot of the discussions around goals happen here. This whole process makes sure squads are well-aligned in their goals going into every quarter.
• #34: Sometimes we also run projects as a way to closely align some squads working towards the same goal for a longer time. A typical project at Spotify usually has around 4-5 squads collaborating closely for a few months. This is a way to get a closer coordination between those squads. Note that projects at Spotify have little resemblance with ” traditional projects ” . We minimize project overhead, have no project budgets and usually don ’ t have a set deadline. How we work with product development: https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf Big retrospectives: http://joakimsunden.com/2013/01/running-big-retrospectives-at-spotify/
• #35: There was a lot of talk in the org that with the current size of the company we should be able to deliver more stuff faster. Challenge every squad: could you be faster? What is your cycle time? Can you measure it? How? How can you improve it? Is doubling the speed an appropriate challenge? If not, what is? If you think this is a challenge that would help you improve, what should your goal be and how can you reach it? Try to choose a challenge that is not impossible, but still not obvious how to reach (cf. Toyota Kata). Focus on sustainable improvement, don’t work harder, longer or take shortcuts/dirty hacks. Here are some ideas: it’s not necessarily you, maybe it’s waiting time, blockers and dependencies on other squads or departments? How can we minimize or eliminate these? Can you automate parts of your process? Remove tech debt? Limit WIP? Continuous delivery guild. Management “air cover”. Training and talks. Setting goals together with Product organization. Servant leadership: how can the organization support you in achieving these goals?
• #36: Structured work with improvements. Happens on many levels. Within squads – retrospectives and actions. Within tribes and organization – often structured, focused improvement work. Improvement is key in everything we do.