Zarządzanie · 4 min czytania
Ten o pobieżnym kopiowaniu
Kopiowanie rozwiązań innych firm to dobra heurystyka, ale tylko gdy rozumiemy mechanikę. Pobieżne kopiowanie modelu Spotify czy OKR-ów daje fasadę, nie wynik.
Dlaczego kopiujesz rozwiązania, które nie zadziałają w Twojej firmie?
Kopiowanie cudzych rozwiązań to dobra heurystyka. Ktoś już zmierzył się z podobnym problemem, więc korzystamy z jego doświadczenia, zamiast zaczynać od zera. Kłopot w tym, że często kopiujemy pobieżnie. Widzimy sukces Spotify czy Google, więc kopiujemy ich struktury (Squady/Tribes) lub rytuały (OKR-y), licząc na podobne wyniki. Kopiowanie atrybutów sukcesu bez zrozumienia mechaniki ich powstawania może się jednak źle skończyć.
Szablon to często tylko fasada. Nicholas Carr i Simon Wardley już lata temu zauważyli, że przewaga konkurencyjna nie bierze się z posiadania narzędzi, ale z umiejętności ich ewolucji.
Jakie błędy popełniamy, kopiując?
Popełniamy tu dwa zasadnicze błędy.
Pierwszym jest mylenie mapy z terenem. Spotify Model nie jest instrukcją obsługi, to opis tego, jak jedna konkretna firma rozwiązywała swoje problemy w 2012 roku. Kopiując go ślepo, wdrażamy rozwiązanie problemów, których prawdopodobnie nie mamy.
Drugim błędem jest fałszywa dychotomia. Często myślimy: albo bierzemy gotowy szablon, albo wymyślamy koło na nowo. To pułapka myślowa. Najskuteczniejsi liderzy wykorzystują szablony jako „rusztowanie”, ale to ich modele mentalne pozwalają im wiedzieć, kiedy to rusztowanie zdemontować.
Jak przejść od kopiowania do realnej inżynierii procesów?
Budowa modelu mentalnego to nie buzzword, to proces dekonstrukcji.
Zamiast pytać „Co oni zrobili?”, warto zastosować Zasadę Pierwszych Przyczyn (First Principles Thinking). Rozbijmy system na części pierwsze. Czy Google używa OKR-ów, bo są modne? Nie, robią to, by rozwiązać problem rozproszonej decyzyjności w skali globalnej. Jeśli Twój zespół liczy 10 osób, OKR-y mogą być jedynie zbędnym narzutem.
Równie istotna jest Analiza Ograniczeń (Theory of Constraints). Gdzie jest Twoje realne wąskie gardło? Jeśli problemem jest brak kompetencji, nowe narzędzie do zarządzania zadaniami tylko szybciej pokaże Ci Twoją porażkę.
Czego uczą Two-Pizza Teams?
Świetnym przykładem jest Amazon i słynne „Two-Pizza Teams” (zespoły tak małe, że można je nakarmić dwiema pizzami). Jeff Bezos nie wprowadził ich, bo przeczytał o tym w podręczniku Agile. On zrozumiał fizykę systemu: im więcej osób w projekcie, tym wyższy jest koszt komunikacji. Narzędzie (mały zespół) było efektem zrozumienia, że energia ucieka na uzgadnianie wersji, zamiast na budowanie produktu.
Jak sprawdzić rozwiązanie przed wdrożeniem?
Zanim następnym razem wdrożymy zmianę, zamiast powtarzać banały, przeprowadźmy rzetelny Pre-mortem:
- Zweryfikuj kontekst. Czy to rozwiązanie powstało w kulturze wysokiego zaufania, podczas gdy u nas dominuje hierarchia? Dlaczego skopiowane rozwiązanie może nie pasować do reszty organizacji, pokazuję na przykładzie sudoku.
- Wyceń koszt alternatywny. Co przestaniemy robić, żeby znaleźć miejsce na ten nowy proces?
- Szukaj „Dlaczego”. Jeśli w dokumentacji frameworka nie widzisz opisanej logiki, nie dotykaj go.
Łatwiej jest kopiować czy budować?
Bibliografia
- Gigerenzer, G. (2007). Gut Feelings: The Intelligence of the Unconscious. Viking.
- Carr, N. G. (2003). IT Doesn’t Matter. Harvard Business Review, 81(5), 41–49.
- Wardley, S. (2016). Wardley Maps: Topographical intelligence in business.
- Kniberg, H., Ivarsson, A. (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds.
- Goldratt, E. M. (1984). The Goal. North River Press.
💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem
Tomasz Żelezny
Scrum Master · Agile Coach
Pomagam zespołom robić mniej rzeczy naraz i kończyć więcej. Piszę o przepływie pracy, decyzjach i o tym, gdzie znika wysiłek zespołów.
Twój zespół może więcej niż dowozi.
Zobacz, jak pomagam