Co zrobić, gdy przybywa projektów, zespoły się rozrastają i zaczynają przekraczać granicę możliwości ogarniania team leadera? W pewnym momencie po prostu jest za dużo ludzi i ciężko się dogadać.
Nikt nie lubi zmian, zwłaszcza takich, które zmieniają nasze środowisko pracy, oddzielają nas od ludzi, z którymi się lubimy i pracujemy na co dzień. Czasem również możemy dostać innego szefa, lub zupełnie inny projekt.
Niemniej jednak organizacje muszą rosnąć, cele biznesowe muszą być realizowane, więc skalowanie zespołów, zmiany organizacyjne są koniecznością. Jak do tego podejść rozsądnie, transparentnie i w taki sposób, żeby wszyscy szybko nabrali efektywności w nowym układzie?
Z tego odcinka dowiesz się:
- Co robić, gdy zespoły rosną?
- Jaka jest maksymalna liczba osób w zespole?
- Jak podzielić ludzi na nowe zespoły?
- Jak wybrać managera nowego zespołu?
- Co to jest wymyślona przez Krzysztofa happiness matrix i w jaki sposób sprawiła, że każdy w nowym zespole pracuje z tym, z kim chciałby najbardziej?
- Jak sobie poradzić z konfliktami?
- Jak komunikować zmianę?
- Co Krzysztof – z perspektywy dwóch lat – uważa, że mógł zrobić lepiej?
i wiele więcej 🙂
Agenda
00:00 – Intro
01:00 – Wprowadzenie
01:48 – Jak podejść do tematu skalowania zespołów?
03:30 – Kiedy należy dzielić zespoły?
04:36 – Jak dobrze podzielić zespoły, by wszyscy byli zadowoleni?
06:54 – Czego nie wzięliśmy pod uwagę, dzieląc zespoły?
08:22 – Jak ustalić skład nowych zespołów?
10:11 – Jak przydzielić ludzi do nowych zespołów?
11:45 – Co to jest Happiness Matrix?
13:11 – Kryteria przydziały ludzi do zespołów
14:05 – Co zrobić z konfliktami w zespole?
16:26 – Jak podzielić projekty między nowo tworzone zespoły?
17:22 – Jak wyłonić liderów w nowym zespole?
18:38 – Co się dzieje kiedy jeden lider ma ogarniać kilka zespołów?
19:57 – Jak z dobrego specjalisty nie zrobić beznadziejnego lidera?
21:13 – Co zrobić kiedy nikt w zespole nie chce być liderem?
21:38 – Jak komunikować zmiany w zespole?
24:24 – Jaki był feedback od ludzi po zmianach?
26:28 – Co mogliśmy zrobić lepiej?
27:01 – Podsumowanie
Wersja do słuchania
Linki
Happiness Matrix
Przykładowy plik Excel (oczywiście – z losowo wygenerowanymi danymi;) do ściągnięcia stąd.
Transkrypcja odcinka
[00:01:00.960] – Paweł
Cześć, witajcie w Nerd Management, z tej strony Paweł Rekowski…
[00:01:04.140] – Krzysztof
…i Krzysztof Rakowski.
[00:01:05.910] – Paweł
W dzisiejszym odcinku porozmawiamy o tym, jak skalować zespoły, czyli kiedy mamy sytuację, kiedy rośniemy, kiedy jest więcej ludzi i zespół dochodzi do sytuacji, kiedy zrobi się wielki. Kiedy to według Ciebie jest sensowny czas, żeby zacząć dzielić ludzi?
[00:01:24.540] – Krzysztof
Tak pomiędzy 5-9 osób to jest taka strefa, w której powinniśmy się zastanawiać już nad tym, jaka będzie przyszłość naszego zespołu.
[00:01:32.160] – Paweł
Jeżeli macie w tym momencie 10, 12, 15, a słyszałem o zespołach po 30 osób, to zdecydowanie ten odcinek jest dla Was. I co ważne porozmawiamy o tym, co my tutaj zrobiliśmy, a dokładnie co ty zrobiłeś. Pochwal się jak w ogóle podszedłeś do tematu dzielenia się zespołów.
[00:01:48.810] – Krzysztof
Na samym początku zaznaczę, ze nie ja zrobiłem tylko zrobiliśmy to w całym naszym zespole z naszymi team liderami, z naszymi członkami zespołów. I ten odcinek nazwaliśmy „Jak skalować zespoły. Część pierwsza” bo co jest ważne to to, że ten proces przeprowadziliśmy dwa lata temu. Wyciągnęliśmy pewne wnioski, już wiemy, co moglibyśmy zrobić lepiej. Ale teraz właśnie tymi wnioskami, tym, co zrobiliśmy i tymi wnioskami się z wami podzielimy.
[00:02:16.110] – Krzysztof
Jak wyglądała u nas sytuacja? Mieliśmy dwa zespoły, które pracowały nad konkretnym zakresem projektów z jednej dziedziny i mieliśmy tam 4 aplikacje: dwie nowe aplikacje, każdy z zespołów miał swoją nową aplikację + 3 wspólne aplikacje legacy. Więzy między członkami tych zespołów były mocne, czyli byli ludzie dobrze zakumplowani i pracujący z sobą już od dłuższego czasu. Te zespoły miały 5-letnią historię, więc to nie były takie ad hoc zespoły, tylko jednak długo trwały.
[00:02:46.620] – Krzysztof
I doszliśmy do momentu, kiedy każdy z tych zespołów miał dziewięciu pracowników. No to już byliśmy na naprawdę, na szczycie naszych możliwości. Trochę, trochę już było późno na to, żeby pomyśleć nad jakimiś zmianami, ale to wynikało z różnych procesów, które się działy, że mogliśmy dopiero wtedy do tego podejść.
[00:03:05.880] – Krzysztof
Każdy z zespołów oczywiście miał swojego team leadera. Jedna z tym liderek była na macierzyńskim, więc tutaj też mieliśmy taką dodatkową sytuację, że tam była zastępowana przez kogoś.
[00:03:16.740] – Krzysztof
No i stanęliśmy przed tym wyzwaniem, że mamy 2 zespoły po 9 osób. Mamy w sumie 5 aplikacji i musimy z tym zrobić.
[00:03:27.270] – Paweł
Gdzie pojawiły się te pierwsze sygnały, że trzeba to wszystko podzielić.
[00:03:30.240] – Krzysztof
Było kilka takich sygnałów, które spowodowały, że stwierdziliśmy, że musimy coś zrobić. Pierwsze mocno teoretyczne: czyli pracujemy w Scrumie i Scrum przewiduje pewne ramy. 9 osób to jest już absolutne maksimum. Team Liderzy też zaczęli dostrzegać, że im ciężej się pracuje z większą liczbą osób, no bo jednak team leader musi mieć taką relację 1:1 z każdym pracownikiem. Mówiliśmy o tym już wielokrotnie. I jeżeli mamy 9 osób, no to naprawdę ciężko mieć taką relację z każdym. Mieliśmy świadomość pewnych sympatii czy antypatii między ludźmi w zespołach i to też jest.. może to nie był jakiś czynnik motywujący nas do zmiany, ale coś, o czym wiedzieliśmy, że niektórym się lepiej pracuje, niektórym ze sobą gorzej. Ale przede wszystkim to była ta liczba ludzi. To był sygnał, że musimy coś zrobić. Za duże są te zespoły.
[00:04:29.100] – Paweł
No dobra, i jak do tego podeszliście? Bo z tego, co ja wiem, to nie było, że wzięliście siekierę, ciach na pół, tylko jednak podeszliście do tego dużo sprytniej.
[00:04:36.900] – Krzysztof
Oczywiście jesteśmy bardzo dużą firmą i w korporacjach czasem tak się dzieje, że niektórzy narzekają: w przeciągu 5 lat miałem dziesięciu szefów. I zawsze to przychodzi gdzieś tam z góry informacja: dobra, od jutra jesteś w innym zespole i gdzieś tam cię gdzie indziej przesuwamy. Często to są jakieś operacje na excelach, które gdzieś tam kierownicy wyższego szczebla podejmują.
[00:05:01.650] – Krzysztof
U nas nie chcieliśmy, żeby to tak wyglądało. Staramy się podejmować decyzje w zespołach wspólnie. Więc przygotowując się do tego, oczywiście rozmawialiśmy o tym w gronie team liderów, łącznie z product ownerem, ale przyjęliśmy kilka założeń. Pierwsze założenie, które przyjęliśmy, to że trzeba rozdzielić odpowiedzialność za aplikację, ownership, właścicielstwo, odpowiedzialność za aplikację. To jest coś bardzo ważnego, żeby każda aplikacja miała swojego właściciela, kogoś, kto czuje się za nią odpowiedzialny. Priorytetem było dla nas to oczywiście, żeby te zespoły zmniejszyć do takiej liczby, która jest ogarnialna, która będzie ze sobą w łatwy sposób pracować, czyli do takich 5-6 osób. Oczywiście musimy mieć jakieś role w zespole, które są, które muszą tam być, czyli musimy mieć team lidera, senior developera, akurat tak się złożyło, że wtedy mieliśmy trzech seniorów. Musimy mieć oczywiście developerów, musimy mieć testerów, w związku z tym musi być jakiś skład tego zespołu.
[00:06:01.470] – Krzysztof
Mieliśmy również kwestię team leaderów, czyli zespół musi mieć team leadera. Mieliśmy tutaj trochę utrudnioną sytuację z koleżanką, która była na macierzyńskim. Utrudnioną w tym sensie, że musieliśmy się zastanowić co zrobić do momentu, kiedy ona wróci.
[00:06:15.450] – Paweł
Mówisz, że to był problem odnośnie team lidera, ale czy to nie było tak, że na to zastępstwo ktoś musiał być głową tego zespołu przez ten czas? To chyba też było ułatwienie, bo później naturalnie mieliście trzech liderów po jednym na zespół.
[00:06:29.670] – Krzysztof
Tak, zdecydowanie. Tutaj byliśmy w świetnej sytuacji, że nie musieliśmy zrobić czegoś, o czym mówiliśmy w naszym pierwszym odcinku, czyli ze świetnego specjalisty zrobić słabego, beznadziejnego lidera. Mieliśmy osobę, o której wiedzieliśmy, że ma w sobie taki pierwiastek lidera, więc to nam znacznie ułatwiło, chociaż również popełniliśmy tu pewne błędy. Będę o tym zaraz mówił.
[00:06:54.120] – Paweł
No dobra, to czego nie wzięliście pod uwagę przy tych przygotowaniach?
[00:06:56.970] – Krzysztof
Pierwsza rzecz, którą teraz oczywiście, z perspektywy czasu wiemy, że może dobrze by było, żebyśmy wzięli pod uwagę, ale wtedy nie wzięliśmy. To chociażby takie frameworki związane z architekturą zespołów, chociażby team topologies, ale wtedy dopiero się tego uczyliśmy i jeszcze nie czuliśmy się na siłach na tyle, żeby to wziąć pod uwagę. Nie wzięliśmy też pod uwagę prawa Conwaya, czyli tej zasady, która mówi o tym, że aplikacje, systemy, które budujemy, kształtują się na wzór zespołów, które powołamy. To wynika z tego, że nie za bardzo mieliśmy luksus, żeby tworzyć coś od nowa, od zera, tylko mieliśmy jakąś aplikację i musieliśmy raczej kształtować zespoły dookoła tych aplikacji. Chociaż oczywiście fajnie było mieć taką mniejszą wersję i bardziej rozszerzoną, żebyśmy w to weszli głębiej.
[00:07:47.790] – Krzysztof
Nie wzięliśmy też pod uwagę testów profilowych, pewnie ze smutkiem się do tego odniesiesz. Wynikało to z tego, że musieliśmy po pierwsze szybko działać, po drugie nie mieliśmy wszystkich osób przetestowanych, a po drugie już tak bardzo pragmatycznie, w tamtym momencie akurat zrezygnowaliśmy z jednego dostawcy tych rozwiązań związanych z testami profilowymi i już nie mogliśmy przetestować tych osób, które były nie przetestowane tymi testami, które mieliśmy przetestowane. To spowodowało dużą trudność w tym, żeby przetestować wszystkich i jakoś ich dobierać. Więc tego też nie wzięliśmy pod uwagę.
[00:08:22.590] – Paweł
No to w takim razie jak układaliście te zespoły, żeby to miało sens? Bo jaki był wkład tego, że dana osoba będzie pracować w zespole A, B, a nie C?
[00:08:32.970] – Krzysztof
No właśnie, to teraz możemy przejść do tego elementu. Czyli jak w ogóle to zrealizowaliśmy? Pierwsza rzecz, którą w ogóle braliśmy pod uwagę, to to, czy rozbijemy sobie tę całą grupę osób, te dwa zespoły na 3 czy na 4 nowe zespoły. To był taki start, który braliśmy pod uwagę. No i tutaj patrzyliśmy na to, jakie role mamy wymagane w każdym zespole, czyli mieliśmy takie minimum, że w każdym zespole chcielibyśmy mieć seniora i lidera oczywiście, oraz testera.
[00:09:03.330] – Krzysztof
Plus projekty. No i skoro mieliśmy dwa takie corowe projekty wydevelopowane od zera i trzy projekty legacy, plus mieliśmy trzech seniorów i potencjalnie trzech team liderów. Więc tutaj dosyć szybko odrzuciliśmy tę opcję z czterema zespołami stwierdziliśmy, że to za bardzo rozbuduje naszą organizację.
[00:09:26.490] – Krzysztof
Mieliśmy też kwestię Product Ownera i analityka biznesowego, czyli, że jest jakiś próg skalowania w takim typowym wymiarze organizacyjnym. Czyli jeżeli chcemy, żeby Product Owner był obecny w zespole, żeby chodził na wszystkie wydarzenia, żeby był na bieżąco. U nas stawiamy na politykę, że Product Owner i analityk biznesowy pracują bardzo blisko z zespołem, bardzo mocno, to nie są jakieś osoby, które siedzą na innym piętrze i się widują z zespołem raz na dwa tygodnie przy Sprint Review. Tylko są na bieżąco. No to była kwestia kalendarza. Więc szybko doszliśmy do wniosku, że trzy zespoły to jest takie idealne rozwiązanie. Wtedy mielibyśmy te trzy zespoły po około 6 osób.
[00:10:11.670] – Paweł
Super. No to wiem, wybraliście już liczbę, wybraliście skład, no i teraz jak poprzydzielać tych ludzi? No bo wiemy, że mamy trzy worki. Ale jak mówiłeś, gdzieś tam niektórzy nie za bardzo lubili siebie, albo nie lubili ze sobą pracować, albo były jakieś tarcia. No to co z tym zrobiliście? Bo to chyba jest naturalne w każdej firmie, nie każdy lubi się z każdym. I co z tym zrobić?
[00:10:33.540] – Krzysztof
Pierwsze ćwiczenie, które sobie zrobiliśmy tak na naszym poziomie team liderów i menedżerów, to przygotowaliśmy kilka takich hipotetycznych zestawień, jak te zespoły mogłyby wyglądać. Pierwsza wersja to w ogóle ja sobie sam zrobiłem, bawiłem się w miro. Tam można łatwo sobie te klocki przesuwać. Potem zaangażowałem w to liderów i też robiliśmy sobie jakieś wersje. I mieliśmy jakieś wersje, pomysły, jak to może wyglądać. Ale, jak już wspomniałem wcześniej, nie chcieliśmy zakomunikować ludziom: dobra, to jest finalna wersja. I tak będzie, bo po pierwsze to byłoby przeciwne takim naszym wartościom, że powinniśmy to wspólnie decydować na ten temat, że powinniśmy być transparentni, a po drugie pewne decyzje… nie musimy, jak wspominaliśmy o tym wielokrotnie, nie musimy trzymać się kurczowo tego, że ci menedżerowie podejmują pewne decyzje.
[00:11:25.620] – Krzysztof
I zaczęliśmy bardzo wcześnie być bardzo transparentni. To znaczy komunikowaliśmy zespołom już w ogóle od samego początku, że musimy podjąć jakieś działania, bo mamy za dużo ludzi w zespole. Potem było: rozważamy takie, a nie inne opcje, więc cały czas otwarcie komunikowaliśmy, żeby ludzie wiedzieli, że coś się dzieje i gdzie jesteśmy w tym procesie.
[00:11:45.750] – Krzysztof
Potem wymyśliłem coś takiego, co sobie nazwałem „Happiness Matrix”. I to polegało na tym, że poprosiłem liderów, żeby wysondowali, dowiadywali się od ludzi na rozmowach 1:1, z kim chcieliby pracować, z kim nie chcieliby pracować, jakby widzieli ten podział zespołów, jakie mają pomysły. Czyli po pierwsze zbieraliśmy te pomysły, a po drugie na podstawie wszystkich tych informacji, które otrzymaliśmy, przygotowałem taką macierz, gdzie była informacja, kto z kim chce pracować, i to był jeden albo kto z kim nie chce pracować, to wartość minus jeden. Oczywiście te relacje były w dwie strony, czyli ktoś mógł z kimś chcieć pracować, a ta druga osoba np. mogła nie chcieć albo być obojętna.
[00:12:28.720] – Krzysztof
Więc przygotowaliśmy taką macierz, gdzie te preferencje miały wartość numeryczną. I to dostarczyło nam dużej liczby informacji, gdzie widzieliśmy pewne konflikty, widzieliśmy osoby, które są… niezbyt dobrze się z nimi współpracuje. Widzieliśmy osoby, z którymi wszyscy chcą współpracować. I to nie było coś, co byliśmy, czym byliśmy zaskoczeni, bo przez te rozmowy 1:1, ogólnie rzecz biorąc, świadomość tego, co się dzieje w zespole, dużo z tych rzeczy wiedzieliśmy. Niemniej jednak to nam pomogło to zwizualizować.
[00:13:00.400] – Krzysztof
I gdy wprowadziliśmy to do Excela, zrobiliśmy taką tabelę, to potem co chciałem zrobić, to podzielić osoby na zespoły, przyjmując konkretne kryteria. Chciałem po pierwsze, żeby żadna osoba nie pracowała z jakąś osobą, z którą nie chce pracować. Czyli powiedziałeś, że nie chcesz pracować z Kowalskim, to nie będziesz pracował z Kowalskim. Druga rzecz, chciałem, żeby zmaksymalizować coś, co nazwałem happiness factor każdej osoby, czyli żeby ta osoba pracowała z jak największą liczbą osób, z którymi chciałaby pracować. I trzeci punkt: chciałem też zmaksymalizować happiness factor zespołu, czyli żeby ta wartość tych wyborów ludzi sumarycznie w każdym zespole była jak największa, czyli żeby nie było zespołu, gdzie np. są same osoby, które obojętnie pracują z takimi osobami, co im wszystko jedno czy by pracowały czy nie. A jest inny zespół, gdzie jest na maksa wszystkich osób są te połączenia takie pozytywne. Chciałem, żeby to było mniej więcej na równym poziomie. I to była kwestia przydzielenia osób do zespołów.
[00:14:02.320] – Paweł
Ludzie ze sobą chcieli współpracować. A załóżmy, że co by się stało, gdyby ci ludzie nie chcieli ze sobą współpracować, jak do tego podejść? Bo zakładam, że nasi widzowie mogą mieć sytuację, że albo będzie pozytywnie, albo będą, na przykład, będzie więcej tych zgrzytów, niż u nas. I co w takiej sytuacji zrobić? Jakieś scenariusze w głowie tam wtedy mieliście, budując tę matrycę?
[00:14:24.250] – Krzysztof
Tak, to jest dobre pytanie. Przede wszystkim byliśmy świadomi wcześniej np. były konflikty, jakieś konkretne. Osoba A nie chce współpracować z osobą B – i z wzajemnością. Byliśmy tego świadomi i oczywiście pracowaliśmy nad tymi konfliktami. Wcześniej stosowaliśmy różne sposoby rozwiązywania tych konfliktów. Ale bez dużego zaskoczenia zobaczyliśmy, że te osoby jednak zasygnalizowały, że nie chciałyby pracować z tą drugą osobą. Nie było dużo przypadków, pojedyncze. I mieliśmy takie szczęście, że nam się udało te osoby rozdzielić.
[00:14:56.650] – Krzysztof
Druga kwestia była taka osoba, z którą sporo osób nie chciało pracować zdecydowanie. I tu mieliśmy duży zgryz, co z tym zrobić. Przydzieliliśmy tę osobę faktycznie do zespołu, gdzie nikt nie zaznaczył, że nie chciałby z nią pracować, ale też nikt nie zaznaczył, że chciałby z nią pracować. Była taka duża obojętność w tym zakresie. I to jest faktycznie coś, nad czym trzeba się zastanowić bardzo uważnie i spędziliśmy bardzo dużo czasu, często rozmawiając. Czy ta osoba może być w tym zespole, czy nie będzie? Jakie będą konsekwencje? Potem musieliśmy rozważyć te konkretne relacje z osobą A, z osobą B, z osobą C i tak dalej, dwustronne. Jak to będzie wyglądać? Obawialiśmy się, jaka będzie reakcja, jak ludzie będą współpracować.
[00:15:41.680] – Krzysztof
Sytuacja jakoś się rozwiązała, też w sposób powiedzmy dosyć niefortunny, bo zaraz po tym, jak ogłosiliśmy nowy podział, do czego jeszcze wrócimy, w jaki sposób to opublikowaliśmy, to akurat ta osoba powiedziała, że chciałaby od nas odejść, ale poczekała do ogłoszenia nowych zespołów, żeby nam nie psuć tego eventu związanego z ogłoszeniem nowych zespołów. Więc abstrahując od tego, czy to faktycznie nam coś zepsuło czy nie, bo problem się sam rozwiązał. Ale dostaliśmy kolejne problemy, no bo to nam popsuło trochę strukturę tego i wymagało dużo takich zakulisowych negocjacji, żeby jakoś zapełnić dziurę po tej osobie. Ale dzięki temu, że mieliśmy jakiś schemat, mieliśmy zasady, mieliśmy taki framework, to dało się to zrobić.
[00:16:26.610] – Paweł
No to super, A co z projektami? Jak je podzieliliście?
[00:16:29.560] – Krzysztof
No właśnie, to jest coś, co było bardzo ważne, bo nie tylko ludzie, ale też projekty nad którymi pracujemy. I przez to, że te zespoły mieliśmy podzielone tak, że wyszło nam, że w dwóch zespołach mieliśmy akurat, powiedzmy, takie duże grupy ludzi, które pracowały nad tymi naszymi projektami, takimi których ownership był per zespół, nowymi, naszymi corowymi projektami, to dosyć łatwo można było przydzielić te projekty do określonych zespołów. Dla trzeciego zespołu wycięliśmy z tej aplikacji legacy też taką bardzo ważną część, która jest kluczowa. I ten zespół przejął ownership tej dużej części. Natomiast niedobitki tych trzech aplikacji legacy – zostawiliśmy współdzielony ownership pomiędzy tymi trzema zespołami. Zresztą we wnioskach trochę jeszcze o tym powiem czy to był dobry pomysł, czy zły.
[00:17:22.560] – Paweł
No dobra, a jak w tych zespołach rozwiązać kwestię lidera? Czy to faktycznie wyszło tak, że wróciła osoba z urlopu i super, i mamy trzy zespoły, trzech liderów, czy może tam był jakiś problem? Jak też pracowaliście w trakcie tego urlopu? Bo wtedy jeden lider dwa zespoły musi ogarnąć, jak to działało?
[00:17:42.820] – Krzysztof
Mieliśmy teraz taką sytuację, że mieliśmy trzy zespoły, jednego lidera, takiego full time, jedną osobę, która zastępowała tę liderkę na macierzyńskim i się pojawił trzeci zespół, który trzeba ogarnąć. Więc mieliśmy pewien zgryz, pewien problem, zwłaszcza taki duży, przejściowy okres, powiedzmy, dosyć ważny. To, co zrobiliśmy, to pierwszy z zespołów otrzymał tego lidera, takiego etatowego. W drugim zespole ten sam lider był takim liderem tymczasowym, który powiedzmy, trzymał to miejsce dla tej koleżanki, która miała wrócić. Natomiast w trzecim zespole awansowaliśmy tego seniora właśnie, który zastępował liderkę, awansowaliśmy na stanowisko team liderskie, żeby już z pełną mocą i z pełnym umocowaniem ta osoba kierowała zespołem.
[00:18:38.200] – Krzysztof
I z perspektywy czasu mamy kilka takich obserwacji związanych z tą sytuacją team leaderską, chociaż nie wiem czy mogliśmy to lepiej rozwiązać. Ten team leader pracujący z dwoma zespołami, z perspektywy czasu, zresztą dosyć szybko zauważyliśmy, że to nie był dobry pomysł, no bo ten team leader nie mógł poświęcić każdemu z zespołów 100% uwagi. Już prawie absolutnie w ogóle nie mógł poświęcić czasu na kwestie techniczne, a to jak wiemy w naszej branży jest demotywujące bardzo nawet dla team liderów, którzy lubią pobrudzić sobie palce w kodzie i w projektach.
[00:19:09.430] – Krzysztof
No i zespoły to zauważyły, wskaźniki zaczęły spadać – eNPS, Feedback 360. Ewidentnie to nie było idealne rozwiązanie i to nie była wina tego team leadera, tylko to była wina kwestii obiektywnych, czyli ile mamy godzin w dniu. I de facto wzrosła tej osobie liczba członków zespołu z 9 do 11-12. Więc to był problem.
[00:19:33.820] – Krzysztof
Druga kwestia to promocja właśnie tego seniora na team leadera. Ta osoba się świetnie sprawdziła i z perspektywy czasu stwierdzam, że szkoda, że w ogóle już wcześniej tej osoby nie promowaliśmy na team lidera zespołu, ale nie wiedzieliśmy, że będziemy mieli takie przekształcenie. Ale ta osoba sobie świetnie poradziła, jeżeli by była promowana jeszcze wcześniej, to by to przeszło. To jeszcze bardziej gładko.
[00:19:57.550] – Paweł
Awansowaliście seniora na lidera, czyli mieliście właśnie to kluczowe ryzyko, że mamy dobrego specjalistę, ryzyko beznadziejnego lidera. I to była sytuacja, że ta osoba sama chciała? Czy pytaliście się wtedy w tym zespole, czy być może ktoś chce, czy ktoś inny może nadawał? Czy były jakieś tarcia, gra o tron czy coś takiego?
[00:20:19.450] – Krzysztof
Tutaj mieliśmy typową, bardzo dobrą sytuację, czyli tę osobę już wcześniej widzieliśmy, że to jest po pierwsze świetny specjalista, a po drugie osoba, która ma ten potencjał liderski, która wychodzi do przodu, która pokazuje inicjatywę. Czyli w tym momencie ze świetnego specjalisty zrobiliśmy… Ta osoba zrobiła, siebie zmieniła w świetnego specjalistę/świetnego lidera, oczywiście, który się uczy, który się wdraża swoją rolę, ale jednak sobie dobrze radzi.
[00:20:45.440] – Krzysztof
I to była jedyna taka osoba w zespole, więc po pierwsze nie mieliśmy tej walki na noże, na śmierć i życie, nie było konkurencji do tego tronu. Ta osoba wymagała dostrzeżenia, motywacji i pokazania jej, że dasz sobie radę, że jesteś świetna w tym, co robisz. To była pewnego rodzaju komfortowa sytuacja.
[00:21:06.010] – Krzysztof
Gorzej jest, jeżeli na przykład mamy dwie osoby aspirujące do tego tronu, albo gdy nie mamy nikogo. I co wtedy? Ja w takiej sytuacji uważam, że warto szukać na zewnątrz i rekrutować team leadera z zewnątrz, niż zepsuć dobrego specjalistę, żeby był słabym, miernym liderem.
[00:21:22.150] – Paweł
Tak, zdecydowanie potwierdzam to samo, że lepiej znaleźć kogoś, kto jest świadomy tej roli, niż szukać w środku na siłę, bo to jest to, od czego wszystko się w Nerd Management zaczęło, kiedy widzieliśmy takich przypadków za dużo i to niestety zawsze kończyło się źle.
[00:21:38.350] – Paweł
Jak komunikowaliście tę całą zmianę? Bo mówisz, że już od początku to było takie przezroczyste, no ale jednak były te wszystkie tarcia, ustawiania tej szachownicy, raczej się działo za kulisami. Jak w ogóle to wyglądało? Jak komunikowaliście to ludziom?
[00:21:51.610] – Krzysztof
Bardzo ważne dla mnie jest i dla naszego zespołu teamliderskiego było to, żeby być transparentnym. Czyli komunikowaliśmy cały czas, jakie są kolejne etapy, co robimy, jakie mamy pomysły. Czasami nie wchodziliśmy szczegółowo w takie rozważania, co robimy z konkretnymi osobami, co myślimy, no bo wiadomo, że pewne rzeczy powinny zostać gdzieś tam za zamkniętymi drzwiami, ale ten taki framework – dzieliliśmy się tym frameworkiem.
[00:22:16.300] – Krzysztof
I kolejna ważna rzecz, że informowaliśmy biznes z wyprzedzeniem, że po tej zmianie będziemy mieli czas, kiedy zespoły będą się zgrywać, kiedy będą się wdrażać, kiedy będą się docierać. My będziemy mieli obniżoną wydajność i to było ustalone z biznesem. Product Owner brał udział w wielu tych ustaleniach, też był informowany na bieżąco. Właściwie wszyscy interesariusze byli informowani o tym, co się dzieje.
[00:22:41.890] – Krzysztof
I gdy już doszliśmy do finalnej formuły tego, jak to będzie wyglądać – spotkaliśmy się wszyscy we wszystkich zespołach. Przedstawiłem wtedy kolegom i koleżankom tę naszą Happiness Matrix, wyjaśniłem, jak to wszystko działało. Oczywiście nie pokazywaliśmy nazwisk, tylko ogólne informacje, bo też nie chodziło o to, żeby tutaj ludzie nad tym się jakoś drążyli temat. Ważne, żeby mieli zaufanie do team liderów, że podeszliśmy do tego w sposób solidny i rzetelny.
[00:23:11.080] – Krzysztof
No i ogłosiliśmy tę informację. Następnie team liderzy pracowali ze swoimi zespołami, żeby zespoły się uformowały, żeby wymyślić nazwę, żeby wymyślić jakieś zasady współpracy. Tutaj też było ważne, żeby zespoły potem miały taki czas, kiedy nie pracowały zbyt dużo nad projektami, tylko właśnie formowali, ustalali zasady, mieli czas dla siebie. No i wtedy oczywiście zgodnie z teorią zespołów, nawet jeżeli ci ludzie się znali, pracowali ze sobą, to jednak to wszystko był nowy zespół. Więc wtedy każdy lider stanął przed wyzwaniem tych takich pierwszych 90 dni lidera, żeby ustalić, co będzie dla mnie ważne jako team leader, jakie są oczekiwania, ale też bardzo dużo przykładali wagi do tego, że nawet jeżeli na przykład w jednym zespole było dużo osób z jakiegoś starego zespołu, to żeby te stare zespoły uśmiercić, tamte zespoły nie istnieją. To jest historia, którą wspominamy, oczywiście, ale nie ma tak, że to jest np. zespół Dexter plus dwie nowe osoby, tylko to jest zupełnie nowy zespół. I to było bardzo ważne i to bardzo pomogło takiemu właśnie zgraniu się.
[00:24:23.640] – Paweł
Super. To jaki był feedback od ludzi, gdy już to wszystko się ułożyło, każdy o tym wie, zaczyna się praca. Może bardziej dostają informacje: dobra, to te zespoły już faktycznie wyglądają tak jak wyglądają i jaka była reakcja?
[00:24:36.680] – Krzysztof
Moim zdaniem przez to, że byliśmy dosyć transparentni, ludzie do tego podeszli z zadowoleniem. Nie mieliśmy wielu uwag negatywnych, że komuś się coś nie podoba. Raczej ludzie widzieli uzasadnienie i wiedzieli co mają dalej robić, jak to będzie wyglądać, więc byli z tego zadowoleni. Zespoły się szybko zintegrowali, mimo że były to znaczące zmiany jednak.
[00:24:59.210] – Krzysztof
Mamy takie wnioski, już przechodząc do wniosków, że pojawiły się osoby, którym nie poświęciliśmy wystarczająco dużo czasu, chociażby ze względu na podszlifowanie ich soft skilli, takich miękkich umiejętności, zwłaszcza jeżeli te osoby dostawały trochę więcej odpowiedzialności, czy jeżeli z takiego dużego zespołu robiliśmy mniejsze, no to wiadomo, że na każdego członka zespołu przypada trochę większa widoczność w tym zespole. Muszą w jakiś sposób sobie te stosunki zmienić. To był taki nasz wniosek, że moglibyśmy niektórym osobom więcej czasu poświęcić, ale szybko to zauważyliśmy i potem to naprawiliśmy.
[00:25:37.910] – Krzysztof
Kolejna kwestia to projekty. Dosyć szybko zauważyliśmy, że brak tego ownershipu przy tych wspólnych projektach to był problem, że niepotrzebnie to odkładaliśmy na później i że mogliśmy to jednak szybciej załatwić, szybciej to uporządkować. To też w przeciągu tych dwóch lat to zauważyliśmy i poprawiliśmy.
[00:25:59.570] – Krzysztof
Mówiłem o tej ważnej części, którą wykroiliśmy z legacy dla jednego z zespołów. Tutaj też się okazało, że mocno dociążyliśmy ten zespół, bo to jest projekt, który jest ważny w przypadku Black Friday, taki dosyć kluczowy. Tam jest pewne obciążenie, zwłaszcza w listopadzie. To była duża odpowiedzialność dla tego zespołu, ale tutaj sobie radziliśmy, chociażby nadal organizując pomoc innych zespołów, żeby te osoby nie czuły się pozostawione samym sobie. Natomiast to było dobre, że każdy z zespołów miał swój ownership.
[00:26:28.730] – Krzysztof
Z takich jeszcze wniosków, co mogliśmy robić lepiej, to wracając do tego, co mówiłem na samym początku, żałuję, że nie weszliśmy mocniej w takie frameworki, które są znane, lubiane i teraz do nich wracamy typu Team Topologies, prawo Conwaya, architektura organizacji. Ale to jest coś, czego się cały czas uczymy i pewnie jeszcze nam trochę czasu zajmie, żeby wrócić do tego i w jakiś sposób to wdrożyć. Dlatego też o tym będziemy mówili na pewno w części drugiej tego odcinka, który nagramy za rok czy dwa.
[00:27:01.910] – Krzysztof
Ale podsumowując to była pozytywna zmiana. Te metody, które zastosowaliśmy dobrze zagrały. Moim zdaniem ten Happiness Matrix to było dobre podejście, bo właściwie nie mieliśmy dużych konfliktów w zespołach i jednak widzimy, że te zespoły dobrze działają, fajnie są zintegrowane, dobrze się ludziom współpracuje, więc to było dobre.
[00:27:24.950] – Paweł
Super. Bardzo solidną garść informacji na temat skalowania zespołów. Dorzucimy w notatkach do tego odcinka taką przykładowo matrycę, żebyście zobaczyli jak to wygląda, w jaki sposób to było realizowane. Wszystkie linki również znajdziecie na stronie odcinka, do książek polecanych, do materiałów, o których opowiemy na pewno jeszcze w kolejnych odcinkach.
[00:27:46.760] – Paweł
Jeżeli macie pytania o to, jak skalować lepiej zespoły, jak sobie radzić w takich sytuacjach lub czegoś byśmy nie powiedzieli, to koniecznie napiszcie w komentarzu, dajcie lajka, zasubskrybujcie ten kanał.
[00:27:57.320] – Krzysztof
To zdecydowanie jest coś, czego cały czas uczymy się, zastanawiamy się jak to zrobić lepiej. Jeżeli uważacie, że coś co zrobiliśmy jest bez sensu, albo chcielibyście się skonsultować, albo chcielibyście dorzucić coś mądrego, o czym możemy powiedzieć w części drugiej, to dawajcie znać. Jestem bardzo, bardzo chętny do tego, żeby usłyszeć coś od Was.
[00:28:17.270] – Paweł
I też podzielcie się swoimi doświadczeniami. Jeżeli mieliście okazję podzielić zespół 2 na 3 albo i więcej. A wiem, że niektórzy z Was, którzy piszecie takie sytuacje mieli, więc tym bardziej jestem ciekawy i na jakim etapie jesteście teraz, gdzie to wszystko Was zaprowadziło? No i też chętnie się nauczymy od Was jak można to zrobić lepiej.
[00:28:39.400] – Krzysztof
Dziękujemy, że obejrzeliście ten odcinek. Do zobaczenia za tydzień we wtorek o ósmej. Żebyście nie przegapili następnego odcinka, zapiszcie się na naszego newslettera, zasubskrybujcie nas na YouTube, na linkedinie, na Facebooku, na Instagramie. I do zobaczenia za tydzień!