Prawie połowa spośród prawie 8 tys. osób zatrudnionych przez giganta rynku internetowych usług strumieniowania multimediów zajmuje się wytwarzaniem oprogramowania. Model funkcjonowania, kultura i organizacja firmy na przestrzeni lat ewoluowały tak, by możliwie najlepiej wykorzystywać posiadany kapitał ludzki.

Spotify to założony w 2006 r. przez Daniela Eka serwis udostępniający treści cyfrowe, również w formie aplikacji mobilnej. Na świecie funkcjonuje pięć dużych, deweloperskich biur firmy (w Sztokholmie, Goteborgu, Londynie, Nowym Jorku i Bostonie) a jej usługi dostępne są w ponad 180 krajach. Liczba aktywnych miesięcznych użytkowników Spotify w czwartym kwartale 2021 r. przekroczyła 400 mln, z czego 180 mln to właściciele płatnych subskrypcji. Firma osiągnęła w tym okresie przychody w wysokości prawie 2,7 mld euro.

Organizacyjna układanka

W Spotify nie istnieje dziś centralna organizacja R&D, firma nie zatrudnia też nikogo na stanowisku Chief Technology Officer. Podstawową jednostką organizacyjną rozwijającą oprogramowanie Spotify jest tzw. squad – interdyscyplinarny zespół, zajmujący się tworzeniem aplikacji i usług. Obecnie w firmie funkcjonuje ok. 400 takich zespołów, a do każdego z nich przypisani są Product Manager i Engineering Manager.

• liczebność zespołu to zwykle od 4 do 12 osób,
• zespół ponosi pełną odpowiedzialność za tworzone systemy: od koncepcji, przez opracowanie i wdrożenie, po aspekty operacyjne i utrzymaniowe,
• każdy zespół działa autonomicznie, dobiera optymalny dla siebie sposób funkcjonowania.

Pojedyncze, powiązane ze sobą zespoły, skupione są w „plemionach”, tribes. To środowisko zapewnia wsparcie liderów i trenerów Agile, nieprzypisanych do żadnego konkretnego zespołu. Na najwyższym poziomie w Spotify działa obecnie sześć jednostek biznesowych, w obrębie których formowane są zespoły i Tribe'y.

„W Spotify nie ma centralnej organizacji R&D, bo ten model nie sprawdzał się – zaczął się tworzyć pewien silos R&D. Wszystko odbywa się w ramach zespołów, czasem na poziomie Tribes, czasem Squads Niektóre zespoły w ramach dużych Business Units są jednostkami R&D, inne nie, ale wszystkie są przemieszane, by lepiej ze sobą współpracować.”

Marcin Floryan, Technology Operations Lead, Spotify 

Oprócz tego w organizacji funkcjonują „gildie”, nieformalne, organizowane oddolnie wspólnoty praktyków, skupiające na przykład programistów C++, ale i pasjonatów fotografii. Funkcjonują one głównie w sferze wirtualnej ale wiele z nich organizuje także lokalne spotkania co pewien czas. Guilds pełnią ważną funkcję w kształtowaniu poczucia przynależności pracowników i stanowią platformę wymiany opinii, rozwiązywania problemów i tworzenia rekomendacji technologicznych – wchodząc niejako w rolę architektów IT.

Zarządzanie 

Na najwyższym szczeblu zarządczym strategiczne decyzje podejmuje tzw. „D Team”, znany też jako „Daniel’s Team” – menedżerowie skupieni wokół CEO, 

Na poziomie zespołu stery dzierży Engineering Manager we współpracy z Product Managerem. W idealnej sytuacji jeden EM powinien zarządza jednym zespołem; w praktyce liczebność personelu przypadającego na jednego EM-a ograniczana jest do 8-12 osób, co czasem przekłada się na jeden zespół, innym razem – na trzy.

• zakres obowiązków menedżera określa jego umiejscowienie w organizacji (jednostce biznesowej) oraz bieżące potrzeby,
• do obowiązków ogólnych należy zapewnianie współpracy między inżynierami, dbałość o dobre praktyki inżynierskie i poprawność tworzonej architektury, wsparcie i rozwój zawodowy pracowników, wsparcie procesów planowania, organizowanie pracy,
• członkowie danego zespołu mogą migrować do innych składów – a nawet powinni. Już na etapie rekrutacji pracownikom sygnalizuje się oczekiwanie, że po dwóch latach należy próbować znaleźć nową pozycję w firmie, 
• za pośrednictwem odpowiednich systemów wewnętrznych pracownicy może zgłaszać chęć przejścia do innego zespołu, a menedżerowie – zgłaszać zapotrzebowanie na dodatkowe kompetencje przy swoich projektach swoich zespołów.

Wdrażanie i integracja funkcjonalności

• każda nowa funkcja usługi, tworzona w zespołach R&D, przechodzi szereg testów automatycznych w ramach procesów CI/CD,
• mechanizm „cannary release” zapewnia inicjalne wprowadzanie zmian w małym zakresie i ich weryfikację w oparciu o metryki i automatyczne testy,
• w obszarze back-endu zmiany, po zatwierdzeniu, wchodzą w życie w przeciągu kilku minut – dzięki architekturze mikroserwisowej,
• w obszarze aplikacji mobilnej codziennie powstaje nowa wersja aplikacji, instalowana na urządzeniach przenośnych wszystkich pracowników, co stanowi komplementarną formę testów obok testów automatycznych, 
• nowe wersje aplikacji trafiają do sklepów mobilnych w cyklu 1–2-tygodniowym

Zespoły nie mają jasnego podziału zakresu odpowiedzialności, co może powodować pewne problemy, na przykład gdy kilka zespołów pracuje nad zbliżonymi rozwiązaniami. 

„W pierwszych latach istnienia firmy bardzo celowo mówiliśmy, że powielanie pomysłów jest akceptowalne, ponieważ koszt koordynacji jest większy niż dublowania rozwiązań. Jednak im większą firmą się stajemy, tym trzeba aktywniej znajdować ten balans. Jednym ze sposobów zmagania się z tym problemem jest tworzenie jak najbardziej rozległej sieci nieformalnych znajomości. Tam, gdzie zależności istnieją, polegamy na naszych inżynierach i nieformalnych negocjacjach między zespołami.”

Marcin Floryan, Technology Operations Lead, Spotify

Pomocnym mechanizmem jest podejście „inner source” – gdy dany zespół chce zmienić komponent czy system, którego nie jest właścicielem, bierze wdrożenie zmiany na siebie, ale kieruje do właściciela prośbę o weryfikację lub akceptację zmiany. 

„Kultura Spotify”

Sposób funkcjonowania firmy obrazują wypowiedzi jej liderów. Daniel Ek, założyciel i CEO, deklaruje: „Chcemy popełniać błędy szybciej niż ktokolwiek inny”. Z kolei Katarina Berg, dyrektorka działu HR, zachęca kandydatów do pracy w Spotify słowami „Witajcie w kontrolowanym chaosie”.

„Nie mamy pojęcia, co powinniśmy robić. Realizacja pomysłów, strategii, celów musi być oparta na realiach rynku i na tym, czego dowiadujemy się od klientów, więc musi podlegać ciągłej weryfikacji. To, co robimy, w większości przypadków jest pewnym eksperymentem. Skoro tak, nie jesteśmy w stanie z góry przewidzieć, czy się powiedzie. Im więcej eksperymentów, tym więcej możemy dowiedzieć się i nauczyć, a więc lepiej rozwijać. Jest przyzwolenie, a wręcz oczekiwanie, by te błędy popełniać.”

Marcin Floryan, Technology Operations Lead, Spotify

Jak rozpoznać potrzebę zmian?

• dwa razy w roku do wszystkich pracowników wysyłany jest kwestionariusz; zawierający pytania dotyczące na przykład satysfakcji z pracy, poczucia przynależności, itp. – na tej podstawie analizowane są trendy i tendencje, szczególnie te negatywne,
• Quarterly Business Review – na wszystkich poziomach firmy tworzone są podsumowania ostatniego kwartału, dotyczące zarówno kwestii biznesowych (metryki produktu) ale i sposobu funkcjonowania firmy; są to informacje dostępne dla wszystkich pracowników.

Przykładem konieczności wprowadzenia zmian w organizacji była ewolucja strukturalna. Do pewnego momentu spółka działała w oparciu o tzw. rozdziały (chapters). W takim domenowym podejściu odpowiedzialność poszczególnych menedżerów rozkładała się obszarowo, np. web, mobile, itp. Miało to swoje zalety – kierownik danego obszaru pozostawał czynnym programistą, był w stanie zrozumieć problemy i realia innych inżynierów, a jednocześnie wykorzystać swoją wiedzę i umiejętności, by pomóc rozwiązać ich problemy. 

Model stracił jednak efektywność w miarę rozwoju firmy. Im więcej inżynierów zatrudniał      Spotify, tym bardziej rosła liczebność zespołów zarządzanych przez menedżerów, 

„Przesunęliśmy odpowiedzialność, skąd inżynierowie będą czerpać wiedzę – już nie od menedżerów, ale innych inżynierów. Mamy cały szereg szkoleń prowadzonych przez inżynierów, wspierających rozwój umiejętności technologicznych. Dzięki temu EM może skupić się na celach zespołu. Dziś inżynierowie są sami bardziej odpowiedzialni za swój rozwój, a ich EM jest po to tylko, żeby im w tym pomagać, motywować i stawiać wyzwania.”

Marcin Floryan, Technology Operations Lead, Spotify