Jak Zapier buduje kulturę uczenia się w zespołach inżynierskich #EN228

Poniższe notatki zostały przygotowane na podstawie podcastu „CTO Insights” z udziałem Mojtaby Hosseini, VP Engineering w Zapier. Wszystkie przemyślenia, obserwacje i strategie przedstawione w artykule pochodzą bezpośrednio z tej rozmowy.

TL;DR

Inżynieria to nauka stosowana w służbie klientów – zespoły muszą łączyć uczenie się, zastosowanie oraz wartość dla użytkowników
4-letnia ewolucja metryk – przejście od odgórnych wskaźników do zespołowych, samoorganizujących się pomiarów wydajności
Pięć kategorii metryk – product, workload, productivity, service level oraz team engagement jako framework wyboru
AI wymaga nowego podejścia – skupienie na adopcji (leading indicators) przed produktywnością (lagging indicators)
Cross-departmental AI – pomaganie innym działom w adopcji AI wymusza doskonalenie własnych praktyk inżynierskich
Szybkość uczenia się jest ważniejsza niż osiągnięcie konkretnego poziomu wydajności
Dzielenie się wiedzą – kluczowe dla całej branży w erze AI

Inżynieria jako nauka stosowana w służbie klientów

Hosseini przedstawia filozofię, zgodnie z którą Zapier traktuje inżynierię jako naukę stosowaną w służbie klientów. Jego zespół opiera działanie na trzech fundamentalnych filarach. Pierwszy to nauka – systematyczne uczenie się przez jakościowe oraz ilościowe metryki. Drugi filar to zastosowanie – tworzenie pętli sprzężenia zwrotnego między uczeniem się a rzeczywistym wpływem na produkt. Trzeci element to skupienie na klientach jako ostatecznych beneficjentach wszystkich podejmowanych działań.

Ta filozofia bezpośrednio wpłynęła na ewolucję mechanizmów zbierania opinii od użytkowników. Początkowo wszyscy pracownicy Zapier, niezależnie od zajmowanego stanowiska, poświęcali kilka godzin tygodniowo na rotację w dziale wsparcia. Jednak wraz ze wzrostem firmy podejście to przestało być efektywne.

Dziś Zapier stosuje skalowalne mechanizmy zbierania opinii klientów:

Support ride-alongs – inżynierowie obserwują pracę zespołu wsparcia i uczą się metod debugowania problemów
Voice of Customer – miesięczne sesje agregujące opinie oraz komentarze użytkowników dla konkretnych zespołów
Watch parties – zespoły obserwują klientów używających nowych funkcji w fazie alpha/beta
Support top 10 – regularne przekazywanie najczęstszych problemów zgłaszanych przez użytkowników
Dogfooding – inżynierowie używają Zapier do automatyzacji własnych procesów (np. automatyczne podsumowania długich wątków Slack w dokumenty)
Engineering response team – współpraca z zespołami sprzedaży oraz solution engineering przy potencjalnych klientach
Bezpośrednie kanały Slack – dla wczesnych produktów w beta, inżynierowie uczestniczą w tych samych kanałach co klienci z programu wczesnego dostępu

Podejście różni się w zależności od dojrzałości produktu. W przypadku nowych funkcji pętla sprzężenia zwrotnego może działać tego samego dnia – klient zgłasza problem, a inżynier natychmiast go naprawia. Z kolei dla dojrzałych produktów konieczny jest balans między długoterminową mapą drogową a bieżącymi problemami.

Jak opinie klientów wpływają na mapę drogową? Hosseini wyjaśnia, że „to zależy od dojrzałości produktu”. W przypadku nowych, niestabilnych funkcji w fazie beta feedback jest niemal natychmiastowy oraz ma najwyższy priorytet. Dla dojrzałych produktów, które istnieją od dekady, konieczne jest bardziej zrównoważone podejście uwzględniające zarówno długoterminową wizję, jak i bieżące zadania – krytyczne zgłoszenia, błędy oraz ogólne utrzymanie systemu.

To podejście pozwala uniknąć „błędu ocalałego” – sytuacji, w której firma słucha tylko istniejących klientów, ignorując potencjalnych użytkowników.

4-letnia ewolucja metryk inżynierskich

Hosseini wprowadził metryki inżynierskie w Zapier około 4 lata temu, gdy nie były jeszcze tak popularne jak obecnie. Jego motywacją była świadomość, że inżynieria to nauka stosowana – bez pomiarów nie ma prawdziwego zrozumienia tego, co działa. Kontekst czasowy był również istotny – w latach 2020-2022 szybki wzrost rynku pozwalał firmom nie zastanawiać się nad tym, które wskaźniki wejściowe napędzają wskaźniki wyjściowe.

Hosseini definiuje wysoką wydajność nie jako konkretny poziom do osiągnięcia, ale jako szybkość uczenia się zespołu. Jak wyjaśnia: „To nie tyle próg, który zespół musi osiągnąć, ile nachylenie krzywej, z jaką się uczy”. Standard wysokiej wydajności stale rośnie – to, co było magiczne 5 lat temu, dziś stanowi podstawowe wymagania dla klientów.

Początkowe metryki były, jak sam przyznaje, „złe”. Zespół rozpoczął od DORA metrics oraz podstawowego wskaźnika: czy zespół przewidywalnie realizuje miesięczne zobowiązania. Jednak Hosseini podkreśla, że pierwsza iteracja metryk zawsze będzie niedoskonała, ale ważne jest rozpoczęcie procesu pomiarów.

Kluczową lekcją było jasne zakomunikowanie zespołom na samym początku: „Nasze pierwsze metryki prawdopodobnie będą złe. Nie będą pomocne i to jest w porządku.” Chodziło bowiem o wyrobienie nawyku mierzenia oraz uczenia się, a nie o znalezienie idealnego wskaźnika za pierwszym razem.

Kluczowym błędem było niewyjaśnienie zespołom, że pierwsze metryki będą zastępowane lepszymi. Kolejnym błędem było próbowanie narzucenia tych samych wskaźników wszystkim zespołom. Różne zespoły działają w różnych kontekstach – nowy produkt w fazie dopasowania do rynku potrzebuje innych wskaźników niż dziesięcioletni system wymagający utrzymania.

Transformacja z podejścia odgórnego na zespołowe była stopniowa i przebiegała przez miesięczne przeglądy operacyjne. Na początku Hosseini osobiście analizował metryki wszystkich zespołów. Następnie dyrektorzy zaczęli zadawać te pytania. Potem kierownicy inżynierii przejęli tę rolę podczas retrospektyw. W rezultacie zespoły zaczęły zadawać sobie nawzajem pytania typu: „Widziałem, że macie 80% nowych funkcji, tylko 20% utrzymania. Czy to oznacza, że akumulujecie dług techniczny?”

Pięć kategorii metryk w Zapier

Hosseini opracował framework pięciu kategorii metryk, z których zespoły mogą wybierać najbardziej odpowiednie:

1. Product metrics

Zaangażowanie oraz adopcja ze strony klientów
Standardowe dla większości zespołów
Zespoły platformowe mierzą wpływ na wewnętrznych klientów

2. Workload metrics

Podział zasobów: praca planowana vs nieplanowana
Utrzymanie vs tworzenie nowych funkcji
Pomaga pokazywać kierownikom produktu koszt długu technicznego

3. Productivity metrics

Czas cyklu, czas realizacji, prędkość w story points
Metryki jakości: incydenty, czas odzyskiwania, czas wykrywania

4. Service level metrics

SLI, uptime, dostępność
Wskaźniki zdrowia serwisów, za które zespół odpowiada

5. Team engagement

Zaangażowanie w pracę oraz zrozumienie strategii
Czy obciążenie pracą jest zrównoważone i sustainable

Zespoły same wybierają, na której kategorii się skupić w zależności od swoich problemów. Konkretny przykład: zespół obciążony długiem technicznym może pokazać kierownikowi produktu: „Spędzamy 70% zasobów na utrzymanie systemu przez liczbę serwisów, które mamy. To za dużo.” Wywołuje to rozmowę o inwestycji w spłatę długu technicznego, aby obniżyć ten procent.

Z kolei zespół z dobrą prędkością, ale niskim zaangażowaniem może potrzebować lepszej komunikacji długoterminowej strategii – ludzie produkują funkcje, jednak nie rozumieją, dokąd to wszystko zmierza.

Standardowe dla wszystkich zespołów pozostają: kapitalizacja inżynierii (podział utrzymanie vs nowa praca – potrzebny księgowości, ale też użyteczny dla zespołów), badania zaangażowania co 6 miesięcy, metryki produktowe oraz metryki incydentów.

AI jako narzędzie uczenia się

Hosseini zauważa, że Zapier miał szczęście wprowadzając metryki 4 lata temu. Gdy pojawiły się przełomy AI (ChatGPT-4 około 2 lat temu), każdy lider inżynierii zaczął otrzymywać pytania o wpływ AI na organizację. Firmy bez ustalonych metryk są „kilka kwartałów z tyłu” – muszą najpierw wprowadzić pomiary, dopiero potem mierzyć wpływ AI. Posiadanie ugruntowanej kultury metryk dało Zapierowi przewagę, gdy nadeszła rewolucja AI.

W kontekście AI Hosseini stosuje podejście oparte na wskaźnikach wyprzedzających zamiast opóźnionych. Adopcja narzędzi AI jest ważniejsza niż natychmiastowy wzrost produktywności.

Zespół mierzy, ilu inżynierów używa narzędzi AI codziennie. Jeśli nie są zmuszani, a mimo to chcą kontynuować, to dobry sygnał przyszłej produktywności. Hosseini zauważa, że zmiana narzędzi może początkowo obniżyć produktywność – inżynierowie muszą przebudować swoje procesy pracy oraz nauczyć się nowych skrótów klawiszowych.

Wpływ AI różni się między zespołami. Zespoły pracujące nad nowymi projektami od zera widzą poprawę czasu cyklu dzięki szybszemu prototypowaniu. Natomiast zespoły pracujące z kodem legacy w monolitycznych systemach mogą nie widzieć takiego samego efektu.

Checklist: Implementacja AI w zespołach inżynierskich

Zmierz poziom bazowy metryk przed wprowadzeniem narzędzi AI
Skup się na adopcji (daily usage) jako wskaźniku wyprzedzającym
Akceptuj początkowy spadek produktywności podczas nauki
Różnicuj oczekiwania dla różnych typów projektów
Stwórz mechanizmy dzielenia się wiedzą między zespołami
Mierz tempo uczenia się, nie tylko końcowe rezultaty
Dla zespołów eksperymentalnych: priorytet na uczenie się przed produktywnością

Niektóre zespoły eksperymentują z AI, a jako miarę sukcesu mają liczbę i jakość zdobytej wiedzy oraz dzielenie się nią. Jak wyjaśnia Hosseini: „Jeśli tydzień po tygodniu dzielisz się tym, że użyłeś replit, V0, czy cursor w ten czy inny sposób – to jest miara sukcesu”.

Wspieranie innych działów w adopcji AI

Hosseini opisuje ciekawy „judo move” – sytuację, w której inne działy mogą zacząć wykonywać część pracy inżynierskiej dzięki AI.

Zespoły wsparcia mogą teraz wykraczać poza triage. Z cursor rules oraz wytycznymi od inżynierów tworzą pierwsze pull requesty. Podczas incydentów, zamiast tylko przekazywać „jest problem, oto wpływ na klientów”, mogą używać AI z dostępem do logów oraz MCP z Sentry, aby zaproponować hipotezę, gdzie leży problem.

Kierownicy produktu oraz designerzy mogą otwierać merge requesty dla małych zmian designu, które wcześniej lądowały w backlogu z powodu niskiego priorytetu. Nie są w 100% pewni, czy rozwiązanie jest dobre, ale mogą zaproponować pierwszy draft.

Paradoks „judo move”: Wydaje się, że inżynieria pomaga innym działom, jednak w rzeczywistości inne działy pomagają inżynierii stać się lepszą. Aby umożliwić pracownikom nietechnicznym bezpieczne współtworzenie, inżynieria musi drastycznie poprawić:

Dokumentację dla zewnętrznych współtwórców
Testy oraz wytyczne dla użytkowników nietechnicznych
Procesy wdrażania oraz A/B testing
Cursor rules oraz Claude MD files
Lepsze zarządzanie flagami

AI staje się katalizatorem doskonalenia praktyk inżynierskich – zespoły myślą, że pomagają innym, ale to inni pomagają im być lepszymi.

Kluczowe wnioski dla liderów inżynierii

Hosseini podkreśla, że najważniejsza jest „velocity of learning” – szybkość uczenia się. To zarówno tempo, jak i wielkość zdobywanej wiedzy. Wszystko, co sprawiło, że zespół był dotąd skuteczny, musi ewoluować w kierunku następnych wyzwań.

Mechanizm uczenia się oznacza akceptację błędów oraz niepowodzeń. Inżynierowie z natury chcą robić rzeczy lepiej – czy samochody mogą jeździć szybciej, czy możemy latać wyżej, czy możemy podnosić cięższe rzeczy? To samo podejście powinno dotyczyć zespołów oraz procesów – czy nasze zespoły mogą być lepsze, czy nasze procesy mogą być lepsze?

„Always be learning” – to kluczowe motto według Hosseini.

Kończy również apelem – nie radą, ale „prośbą” – do innych liderów o dzielenie się doświadczeniami: „Wszyscy jesteśmy w erze AI, wszyscy eksperymentujemy i uczymy się. Chciałbym, żeby jak najwięcej osób dzieliło się tym, co widzą, żebyśmy nie wynajdywali koła wielokrotnie w organizacjach. Chętnie podzielę się błędami, które popełniam, żeby inni nie musieli ich robić.”

Kluczowy insight

Doskonałość przez delegację

Standardowo myślimy: Każda godzina pracy inżyniera poświęcona na wsparcie innych działów to strata dla rozwoju produktu.

W praktyce okazuje się, że: Strategiczne wyposażenie innych działów w narzędzia AI do rozwiązywania prostych problemów technicznych jest inwestycją w jakość własnego zespołu. Taki model zmusza inżynierów do stworzenia lepszej dokumentacji, solidniejszych testów oraz bardziej niezawodnych procesów, ponieważ system musi być niemal doskonały, aby mógł go bezpiecznie obsługiwać ktoś bez głębokiej wiedzy technicznej.

Dlaczego to jest istotne: Pozorne „pomaganie” innym działom w rzeczywistości napędza doskonałość w twoim własnym zespole. To nie jest koszt – to inwestycja w jakość.

Test na jutro: Następnym razem, gdy ktoś z działu nietechnicznego poprosi o pomoc z technicznym zadaniem, zamiast robić to za nich spróbuj stworzyć dokumentację/narzędzia, które pozwolą im to zrobić samodzielnie i sprawdź, jak to wpłynie na jakość twoich procesów.

Praktyczna checklista dla liderów inżynierii

Skupienie na kliencie:

Czy inżynierowie mają regularny, bezpośredni kontakt z problemami klientów oraz zespołem wsparcia?
Czy istnieje formalny proces zbierania oraz analizowania opinii zwrotnych od użytkowników?
Czy dla nowych produktów tworzysz ultraszybkie pętle zwrotne (np. wspólne kanały Slack)?

Metryki oraz pomiary:

Czy definiujesz wydajność jako zdolność do nauki, a nie tylko realizację celów?
Czy komunikujesz jasno, że pierwsze próby z metrykami mogą być nieudane i jest to część procesu?
Czy dajesz zespołom autonomię w wyborze wskaźników najlepiej odpowiadających ich aktualnym wyzwaniom?

Wdrożenie AI:

Czy mierzysz adopcję narzędzi AI jako główny wskaźnik sukcesu na początkowym etapie?
Czy tworzysz bezpieczną przestrzeń do eksperymentów z AI, gdzie głównym celem jest nauka?
Czy szukasz sposobów, by AI pomogło innym działom, wykorzystując to jako okazję do poprawy własnych procesów?

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów oraz innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je w podcaście „CTO Insights”: https://www.youtube.com/watch?v=V7XC-gs7T04

Metadane artykułu:

Główne słowo kluczowe: metryki zespołów inżynierskich

Słowa kluczowe: Mojtaba Hosseini Zapier, kultura uczenia się IT, produktywność programistów, implementacja AI w firmach, customer-centric engineering, DORA metrics, zarządzanie zespołami tech

Zajawka: Jak Zapier przez 4 lata zbudował kulturę uczenia się i wysokiej wydajności zespołów inżynierskich – notatki z rozmowy z VP Engineering

Description: 4-letnia ewolucja metryk w Zapier: od odgórnych pomiarów do zarządzanych przez zespoły wskaźników wydajności, uczenia się i adopcji AI