Daj każdemu zespołowi własny cel i własną metrykę. Tak brzmi pierwsza lekcja zarządzania przez cele i tak wyglądają OKR-y w większości firm produktowych, które znam. Zespół Activation odpowiada za konwersję z rejestracji, zespół Engagement ma DAU, zespół Retention ma churn. Każdy wie, za co odpowiada, każdy ma swój kluczowy wskaźnik i swój cel do dowiezienia, wszystko wygląda profesjonalnie.
Ale... zanim tak samo przypiszesz cele swoim zespołom, otwórz ze mną restaurację :)
Otwierasz restaurację i ponieważ masz spory personel, chcesz go sensownie zorganizować. Myślisz sobie, że aby odnieść sukces w tym biznesie, musisz m.in. robić smaczne jedzenie i zachęcać klientów do częstszego powracania do twojej restauracji. Naturalnie z tym twierdzeniem tworzysz dwa zespoły - jeden odpowiada za to, żeby jedzenie było smaczne, a drugi za to, żeby klienci częściej wracali. Każdy zespół ma swój cel, metrykę i problem do rozwiązania. Masz silne przekonanie, że jeśli oba zrealizują swoje cele, to klient będzie zadowolony, a twój biznes świetnie prosperujący, prawda?
To popatrz, co się dzieje dalej.
Zespół od smaku podnosi swoją metrykę drogimi składnikami i degustacyjnymi porcjami. Smak rośnie, porcje maleją, ale... klient wychodzi głodny. Zespół od powracalności dowozi swój cel rabatami, programem lojalnościowym i akcjami "happy hours". Powracalność rośnie, ale marża spada, więc kuchnia dostaje tańsze składniki. Kuchnia jest zmuszona, aby ograniczyć kartę i robi mniej dań. Smak jest oceniany wysoko, ale klient ani się nie najada, ani nie może znaleźć dla siebie nic ciekawego w nowej karcie. Z czasem jego powracalność spada. Oba zespoły walczą o ten sam budżet i o czas tego samego kucharza. Konflikty eskalują i rozstrzygają się w negocjacjach menedżerów obu zespołów zamiast w kontekście wartości klienta.
"To wina kucharza!"
Kucharz? Kucharz nie ma tu dużego wpływu na wartość klienta - o porcjach i karcie decyduje zespół od smaku, o kuponach i innych zachętach zespół od powracalności. Kucharz dostał więc cel, na który wpływ ma: liczbę talerzy wydanych na godzinę. Od dziś gotuje i wydaje porcje szybko.
Tego, czy klient wyszedł najedzony, nie ma w żadnej metryce, więc nie zajmuje się tym nikt.
Ergo: Oba zespoły mogą zrealizować swoje cele w stu procentach, a restauracja i tak upadnie.
Zamień nazwy. Zespół od smaku to twój zespół Engagement, który optymalizuje liczbę sesji, czas w aplikacji, czy DAU. Zespół od powracalności to zespół Retention, który walczy z churnem, wysyła powiadomienia, rozdaje kupony na powrót. Zgaduję, że obok siedzą jeszcze zespoły tj. Activation, Growth i Monetization. Zgadłem?
Kucharz to twój zespół platformowy albo komponentowy. Nie decyduje, co trafia na roadmapę, więc mierzy uptime, liczbę deployów i velocity - czyli talerze na godzinę.
A klient? Klient ma w nosie twoje cele i zespoły, bo ma zaraz cały dzień spotkań, a później wyjazd służbowy, więc przyszedł się najeść i wziąć kanapkę "na wynos".
Tak samo w Twoim przypadku, klient zatrudnia twój produkt do jednej konkretnej roboty - jego kluczowego Job-To-Be-Done tj. przelać pieniądze, znaleźć nocleg, wystawić fakturę, znaleźć pracę etc. Tej roboty żaden zespół nie ma w swoim OKR-ze. Każdy ma za to jakąś inną metrykę opisującą wycinek wizyty klienta.
Może sobie myślisz, że koniec końców, gdzieś tam na górze taki główny OKR spina wszystkie inne, zdekomponowane KR. Może i spina, ale tylko na papierze. W rzeczywistości zespoły są rozliczane ze swoich celów, a nie z jakiegoś wspólnego, na który nie mają bezpośredniego wpływu. Dlatego dostaniesz rywalizację, eskalacje, niską chęć współpracy, politykę, zrzucanie winy i... utratę klienta. I co najgorsze, nie połączysz fakty lokalnej optymalizacji zespołów ze słabymi wynikami, bo przecież wszyscy się tak bardzo starają.
Problemem jest Twoje przekonanie o tym, że "jak wszyscy są do wszystkiego, to są do niczego" i że trzeba dzielić, bo inaczej... <wstaw tu co chcesz> :)
A zatem, jeszcze raz - to nie jest pech ani „problem z ludźmi". To struktura, podział zespołów i odrębne cele, produkują patologiczne zachowania. W tej krótkiej historii zadziałało pięć mechanizmów. Sprawdź, przypomnij sobie, czy przypadkiem nie zauważyłeś ich w swoim ostatnim planowaniu kwartału :)
Lokalna optymalizacja. Każdy zespół optymalizuje swoją metrykę kosztem całości i robi to racjonalnie, bo z tej metryki jest rozliczany. Christopher Meyer pokazał w „Fast Cycle Time", że miary funkcyjne wprost napędzają lokalne optymalizacje, a większość opóźnień w rozwoju produktu powstaje na stykach między zespołami, nie w samej pracy zespołów. Zespół Engagement nie jest złośliwy, gdy dokłada kolejny angażujący feed zamiast skrócić klientowi drogę do wartości. Zespół Growth nie jest cyniczny, gdy dokleja do onboardingu ekran „zaproś znajomych", który wydłuża czas do pierwszego sukcesu, bo referrale to jego KR, a time-to-value już nie. Oba zespoły dowożą swoje cele. Dokładnie tak, jak je wyznaczyliście.
Dziury między metrykami. To, czego nie mierzy nikt, nie jest niczyją odpowiedzialnością. Podział problemu na metryki nigdy nie pokrywa całości. Zawsze zostają szczeliny, a w tych szczelinach mieszka zwykle to, po co klient naprawdę przyszedł. W restauracji było to najedzenie się. W produkcie bywa to czas od pierwszego kontaktu do pierwszej wartości, spójność doświadczenia / intuicyjność poruszania się między modułami, czy zaufanie.
Możesz wykonać prosty test - sprawdź kto w twojej organizacji ma w celach to, że klient przechodzi z onboardingu (np. zespół Activation) do regularnego użycia (np. zespół Engagement) bez zgrzytu? Jeśli odpowiedź brzmi „no… wszyscy trochę", to znaczy: nikt.
Wspólne zasoby jako pole bitwy. Budżet jest jeden, kucharz jest jeden, uwaga klienta jest jedna. Gdy zespoły mają rozłączne cele i wspólne zasoby, współpraca zamienia się w przeciąganie liny. W produkcie te liny znasz z codziennego życia: ekran startowy aplikacji (dashboard), na który każdy zespół chce wcisnąć swój widget; dzienny limit powiadomień, o który Retention kłóci się z Monetization; capacity zespołu platformowego, o które wszyscy piszą do jego menedżera. Decyzje, które powinny zapadać blisko klienta, zapadają na eskalacyjnych naradach menedżerskich, bo niestety tylko tam spotykają się interesy wszystkich stron. A czas leci... Zauważ fakt, że zespoły, aby zrobić coś wartościowego dla klienta, muszą liczyć się z dodatkowym, dużym wysiłkiem eskalacji, negocjacji, narażając się na stres, czekanie, multi-tasking etc. Dlatego nie dziw się, że w pewnym momencie odpuszczą. Rzucą ciche "nie mój cyrk, nie moje małpy" i zaczną robić to za co odpowiadają lokalnie - cele zastępcze.
Cele zastępcze. Gdy struktura odcina zespół od prawdziwego celu klienta, to zwykle zastępuje go takim, na jaki dany zespół ma wpływ. Kucharz nie może sprawić, żeby klient wyszedł najedzony, więc liczy talerze na godzinę. W produkcie tak samo. Zespół platformowy mierzy uptime i liczbę deployów, a zespoły „bliżej klienta" ratują się tzw. vanity metrics, jak nazwał je Eric Ries - pobraniami, rejestracjami, wyświetleniami. Liczbami, które przyjemnie rosną i niczego nie mówią o tym, czy klient wykonał swoją robotę i czy twój produkt mu to ułatwił. To nie jest lenistwo ani zła wola. Cel degraduje do granic wpływu zespołu - kto widzi tylko wycinek, ten może uczciwie obiecać tylko wycinkowy cel.
Prawo Goodharta. Gdy miara staje się celem, przestaje być dobrą miarą. DAU rośnie, bo powiadomienia zaganiają ludzi do otwarcia aplikacji raz w tygodniu na trzy sekundy. Churn spada, bo anulowanie subskrypcji jest utrudnione i wymaga teraz czterech kliknięć i rozmowy z botem. Dashboard świeci na zielono, quarterly review przebiega gładko. Metryki zdrowe, a klient... głodny. Twoje zespoły nie oszukują, tylko po prostu nauczyły się maksymalizować liczbę za którą odpowiadają.
Dlaczego inteligentni ludzie, doświadczeni liderzy, projektują takie dysfunkcyjne struktury?
Po pierwsze, tak nas trenują. „Dziel i zwyciężaj" to pierwszy poważny algorytm, którego uczy się każdy z nas. Weź problem zbyt duży, żeby go ogarnąć, podziel na podproblemy, rozwiąż osobno, sklej wyniki. Ten algorytm ma jednak drobny druk "działa tylko dla deterministycznych maszyn, nie dla złożonych, dynamicznych problemów tj. systemy społeczne". Doświadczenie klienta: aktywacja, zaangażowanie i retencja to nie są niezależne, deterministyczne podproblemy, tylko jedna podróż tego samego człowieka, który dodatkowo żyje w złożonym systemie społecznym. Lider, który wyrósł z inżynierii, nosi ten algorytm w kręgosłupie i stosuje go do wszystkiego, co wygląda na duży problem. Także do ludzi.
Po drugie, tak nas uczy szkoła - i to na długo przed studiami. Russell Ackoff powtarzał, że cały nasz system edukacji wpaja nam analizę, czyli rozkładanie rzeczy na części. Analiza mówi nam, jak coś jest zbudowane, ale nigdy nie powie jak części wchodzą ze sobą w interakcję powodując dane zachowanie. Ackoff ilustrował to samochodem mówiąc "Weź najlepszy silnik z Rolls-Royce'a, najlepszą skrzynię biegów z Mercedesa, najlepsze zawieszenie z Porsche i spróbuj to złożyć. Nie dostaniesz najlepszego samochodu świata. Nie dostaniesz żadnego samochodu, bo części do siebie nie pasują". Najlepszy onboarding, najlepszy feed i najlepszy program lojalnościowy, zaprojektowane osobno przez trzy zespoły, składają się w franken-produkt dokładnie tak samo. Są "najlepsze", ale nikt nie wie jak wchodzą ze sobą w interakcje i co odczuwa klient poruszający się po ścieżce w nadziei na załatwienie swojego JBTD. Descartes w „Rozprawie o metodzie" wprost radził dzielić każdą trudność na tyle części, na ile się da. Tak więc zachodnie myślenie uczy nas tego od czterystu lat.
Po trzecie, tak wyewoluował nasz mózg. Kategoryzacja to jedna z najbardziej podstawowych operacji poznawczych. Badania Eleanor Rosch pokazały, że porządkowanie świata w kategorie jest fundamentem ludzkiego poznania, a nie wyuczonym nawykiem. Ewolucyjnie miało to sens, bo szybka klasyfikacja „jadalne czy trujące", "swój czy obcy" ratowała życie. Stąd już tylko krok do odruchu, aby każdą trudność pociąć na części i dać jej odpowiedzialnego właściciela, metrykę i zespół. To nie jest głupota. To jest domyślne ustawienie naszego gatunku. Ja nazywam to „X-problem to X-manager", czyli np. "Mamy problem z jakością produktu, powołajmy menedżera ds. jakości produktu". Myślę, że to znasz.
Po czwarte, bo inni też tak mają. Gdzie nie pójdę, widzę firmy żyjące w organizacyjnych patologiach - stawiające coraz wyższe cele i jednocześnie, nieświadomie, ustawiające przeszkody na drodze do ich realizacji tj. masa zależności, wiele celów, priorytetów, mnóstwo projektów realizowanych naraz etc. Wieczna spotkanioza, eskalacje i permanentny brak czasu na doskonalenie - ani siebie, ani organizacji, ani produktu. To nie przypadek, że wszystkie firmy wyglądają podobnie. DiMaggio i Powell nazwali to izomorfizmem mimetycznym: gdy liderzy nie wiedzą, co naprawdę działa, kopiują to, co uchodzi za wzór. Lider wraca z konferencji z zespołami Growth i Retention w notatkach, nowy VP przynosi w teczce schemat poprzedniej firmy, a konsultant sprzedaje SAFe mówią, że to Agile w skali (no comment). Nikt nie sprawdza, czy wzorzec działa - wystarczy, że jest rozpoznawalny.
Gdy pokazuję, jak są zorganizowane najszybciej rosnące firmy dzisiejszego rynku, słyszę: „w Linear, Midjourney czy Cursorze to może się tak da, ale u nas nie, bo my jesteśmy poważną firmą". Poważną, czyli jaką? Cursor został najszybciej rosnącym produktem software'owym w historii zespołem mniejszym niż niejeden dział QA. Midjourney generuje setki milionów przychodu kilkudziesięcioma osobami bez klasycznych działów. Lovable dobiło do 100 milionów dolarów ARR w kilkanaście miesięcy, zanim urosło do rozmiaru jednego piętra Twojego biurowca. To nie są ciekawostki z Doliny, tylko dzisiejszy benchmark tempa, z którym konkurujesz o klienta. „Poważna struktura" z kilkoma warstwami koordynacji nie chroni przed tymi firmami, tylko przed dowiezieniem czegokolwiek (wartościowego?) szybciej niż one.
A teraz szybkie zadanie dla Ciebie:
Gdy klienci zaczną się skarżyć, że wychodzą głodni, wiesz, co zrobi lider wychowany na „dziel i zwyciężaj"?
Z dobrych intencji powoła trzeci zespół - od najedzenia klienta. Z własnym PO / Backlogiem / Celem.
Śmieszne? :) W twojej firmie ten zespół nazywa się być może Customer Experience, Onboarding Excellence albo - mój faworyt - Customer-Journey Team. To jest wzorzec „X-problem to X-manager" w pełnej krasie. System odpowiada na porażkę podziału kolejnym podziałem i nową rolą.
Yyyy zatrzymajmy się tu na chwilę. Można by zapytać, że skoro na rynku pojawił się nowy problem (szansa) jakim jest AI, to czy w firmie pojawi się też nowy zespół do AI i nowy manager od AI? Sprawdź u siebie, a my idźmy może dalej...
Nowy zespół dostaje własną metrykę (najpewniej NPS), która zaraz wejdzie w konflikt z dwiema poprzednimi. Pojawią się nowe szczeliny między metrykami, więc za rok powstanie czwarty zespół. Do koordynacji tego wszystkiego trzeba będzie powołać PMO, a do rozstrzygania sporów będzie potrzebny kolejny szczebel menedżerski. Organizacja rośnie, koszt koordynacji rośnie szybciej, a klient... wciąż wychodzi głodny.
Peter Senge ("5 dyscyplina") nazwał to zjawisko tak: "dzisiejsze problemy pochodzą z wczorajszych rozwiązań". Struktura, która wyprodukowała problem, nie rozwiąże go przez dodanie kolejnego elementu tej samej struktury. Ale dla mózgu wytrenowanego w analizie, każdy nowy problem wygląda jak kolejny podproblem do wydzielenia. Algorytm zjada własny ogon.
Piszę o tym do liderów, bo to nie zespoły rysują schemat organizacyjny. Podziały, cele i metryki przypisują ci, którzy mają władzę nad strukturą, a to właśnie struktura, jak uczy Senge, generuje zachowanie. Jeśli zespoły w twojej organizacji walczą ze sobą zamiast współpracować, to z bardzo dużym prawdopodobieństwem wykonują dokładnie ten program, który ktoś im napisał strukturą, politykami, procesami i osobnymi celami.
I tak z dobrych intencji rodzą się znajome patologie. Silosy, które bronią swoich metryk jak lokalnych królestw. Matryca z podwójnym raportowaniem, w której nikt nie wie, kogo naprawdę słuchać. PMO i koordynatorzy doklejani do każdego styku, którego struktura sama nie umie obsłużyć. Ludzie alokowani po pół etatu do trzech zespołów, lojalni wobec żadnego. Raportowanie "arbuzowe" - zielone na zewnątrz, czerwone w środku. Eskalacja jako domyślny sposób podejmowania decyzji. I rytualne szukanie winnych, gdy kwartał się nie spina, choć każdy zespół dowiózł swoje.
Piekiełko, w którym nikt nie ma interesu by zająć się klientem i jego JTBD.
Nikt tego nie chciał. Każdy z tych podziałów był kiedyś racjonalną odpowiedzią na realny ból. Właśnie dlatego ta pułapka jest tak skuteczna. Wpadają w nią najinteligentniejsi, z najlepszymi intencjami, nagradzani za każdy kolejny podział poczuciem, że „uporządkowali chaos", a na pytania od zespołów "ale jak my to mamy..." odpowiadają "wierzę, że sobie poradzicie".
Naprawdę można stworzyć środowisko - system wielozespołowej pracy produktowej - w którym zespoły chętnie ze sobą współpracują, bo to im się opłaca. Wspólnie realizują cele biznesowe za które wspólnie odpowiadają, obserwując zestaw wspólnych metryk.
Skoro problemem jest podział celów, rozwiązaniem nie jest lepszy podział celów. Rozwiązaniem jest wspólny cel i podział pracy - to zasadnicza różnica.
1. Zacznij od jednego celu dla całości. Cała restauracja ma jedną definicję sukcesu np. najedzony klient, który wraca, gdy jest głodny i jeszcze kupuje kanapki "na wynos". To North Star - miara monitorująca to, czy wartość jest dowożona do klienta. Cała grupa produktowa ma ten jeden cel, jedną nadrzędną miarę wartości dla klienta (o NS pisałem tu). Może to być liczba klientów, którzy co tydzień wykonują swoją kluczową robotę np. liczba osób szukających pracę, która została zatrudniona. Engagement, retention czy activation przestają być celami zespołów, a stają się tym, czym zawsze powinny były być, czyli sygnałami diagnostycznymi całości. Patrzysz na nie jak lekarz na tętno i ciśnienie, żeby zrozumieć system, znaleźć kolejne przyczyny i je usunąć, nie żeby rozliczyć zespół. Chcielibyście leczyć się u lekarza, który płaci osobnemu szpitalowi za obniżanie ciśnienia, a osobnemu za podnoszenie tętna? Ja bym jednak wolał do Dr House'a, który miał interdyscyplinarny zespół po ręką. Szkoda, że Dr House miał tylko jeden taki team, bo mógłbym wówczas opisać go jako przykład skalowania - wiele zespołów, równolegle ratujących życie, każdy dedykowany pacjentowi, którego życie właśnie ratują. Po wykonaniu zadania, biorą się na ratowanie życia kolejnego pacjenta. Cel jest jeden, wspólny dla wszystkich. Pacjenci są dzieleni zgodnie z priorytetami do wolnych zespołów, w których problemy są diagnozowane i opiekowane holistycznie.
2. Cel opisuj wynikiem u klienta, nie sposobem wykonania. Richard Hackman pokazał, że motywujący kierunek określa „co ma się zmienić", a nie „jak to zrobić". „Wdrożyć program lojalnościowy do końca Q3" - to nie cel, tylko zlecenie. Zespół rozliczany ze zleceń przestaje myśleć o kliencie i zaczyna myśleć o wykonaniu i pozytywym odbiorze zlecenia. „Klient, który zjadł u nas raz, wraca w ciągu tygodnia" - to jest cel, a program lojalnościowy może być jedną z dwudziestu rzeczy mającą na niego wpływ - hipotezą. Zespół może odkryć, że tańszą i skuteczniejszą drogą jest krótsza kolejka albo lepszy stolik, albo większe dania. Ten sam test zastosuj do własnych OKR-ów: jeśli Key Result da się „dowieźć" deployem, to nie jest wynik (outcome), tylko zatwierdzone zadanie (output) z datą.
3. Dziel pracę, nie wartość. OK, zespoły nadal są potrzebne, bo pięćdziesięciu osób nie posadzisz przy jednym stole do dyskutowania na co dzień. W przypadku wielu zespołów, każdy zespół bierze do realizacji kompletny problem klienta od początku do końca - na przykład „nowy klient małej firmy wystawia pierwszą fakturę w dziesięć minut" - a nie wycinek metryki czy warstwę technologii. Pracę czerpie z jednej wspólnej listy priorytetów, z jednego backlogu. Konflikt „truflowe risotto czy program lojalnościowy" nie znika, tylko przestaje być wojną podjazdową dwóch menedżerów o capacity, a staje się jawną decyzją priorytetową podjętą w jednym miejscu, z perspektywy całości. Wspólny cel, wspólna lista priorytetów, współpraca i wspólny sukces. Tak to ma działać.
Jest tu jeszcze jedna korzyść: dopiero zespół, który widzi cały problem, może uczciwie nieść cel powiązany z kluczowym JTBD klienta. Cele zastępcze nie znikają przez lepiej napisane OKR-y, tylko przez poszerzenie zasięgu zespołu do rozmiaru nadrzędnego celu.
4. Sukces zespołu mierz sukcesem całego produktu. To jedno zdanie robi całą różnicę, ale i jest trudne w zrozumieniu. Gdy mój zespół wygrywa tylko wtedy, gdy wygrywa całość, pomoc innemu zespołowi przestaje być stratą, a zaczyna być najkrótszą drogą do mojego celu. Przegląd kwartału zmienia pytanie z „czy dowieźliście swoje KR-y?" na „co zrobiliście, żeby produkt wygrał i ew. co was zatrzymało?". Współpraca przestaje wymagać dobrej woli i plakatów z wartościami firmy ;-) Ona wynika z rachunku opłacalności. Co zrobić aby mierzyć zespoły sukcesem całego produktu? Zdefiniować czym jest "cały produkt". Więcej znajdziesz tu.
5. Na problemy odpowiadaj zmianą struktury, nie nową rolą i nową metryką. Gdy między zespołami pojawia się dziura, odruch podpowiada powołanie właściciela dziury (X-problem to X-manager) tj. koordynatora, program managera, zespołu od Alignmentu. Oprzyj się temu patologicznemu zachowaniu. Zapytaj, jaki podział tę dziurę wyprodukował, i zmień podział - głównie scalając, nie dzieląc.
Zwalczaj swój wewnętrzny algorytm „dziel i zwyciężaj", zwalczaj przekonanie, że "jak wszyscy są od wszystkiego to są do niczego". Nie próbuj wdrożyć nowego frameworku OKR, zapomnij też, że ludzie "jakoś się dogadają". To są protezy i kłody utrudniające osiąganie celów firmy.
Zanim przypiszesz zespołom przyszłoroczne cele, zanim podzielisz je na wskroś ścieżki klienta, zrób kilka kroczków:
określ "Cały Produkt" - myśl szeroko, wyjdź mentalnie poza swój dział, a może nawet firmę i patrz oczami klienta.
Zastanów się "co?" tak naprawdę klient zatrudnia i "po co?" ostatecznie to robi.
Zapisz sobie tą szeroką definicję produktu, popatrz jakie tam masz kluczowe szanse i problemy do rozwiązania.
Określ kolejność tych problemów - zrób listę.
I teraz, zanim podzielisz zespoły i przypiszesz im cele i problemy do rozwiązania ze swojej listy, rozważ inny układ. Układ bez podziału, w którym wiele zespołów odpowiada za jeden wspólny wynik produktowy. Jak to miałoby działać? Wszystkie zespoły pracują w jednej np. 2-tygodniowej kadencji. Wspólnie planują prace pobierając najpilniejsze problemy i szanse z wierzchołka jednej, spriorytetyzowanej przez ciebie listy. Gdy problem zostaje rozwiązany - pobierany jest następny. Nikt nie optymalizuje własnej metryki we własnej małej domenie, jak activation, engagement itp. - wszyscy wspólnie eksplorują szanse z całości lejka, uczą się o dostarczanej wartości i robią to, co w danym momencie najważniejsze dla klienta i firmy.
Bonus! W takim układzie planowanie kwartalne przestaje być potrzebne. Praca ma charakter ciągły - cokolwiek trafi na szczyt listy, zostaje pobrane. A metryki obserwują wszyscy, cały czas, szukając kolejnych szans.
W razie pytań, wiesz gdzie mnie znaleźć.