👩💻 11 pytań do Dawida Ostrowskiego (Head of Google Developer Experts Program) o tym jak docierać z produktami do inżynierów?
[9 min] O tym jak budować Developer Relations, przykładach OKRów, 5 kluczowych elementów programu DevRelations budowanego od podstaw i co to jest OCH.
Drodzy
Z Dawidem Ostrowskim znamy się od wielu lat, jeszcze gdy scena startupowa raczkowała w Krakowie. Dziś Dawid rezyduje w Szwajcarii, skąd zarządza globalnymi zespołami odpowiedzialnymi za największe programy Developer Relations w Google dla programistów i startupów i postanowiłem go trochę przepytać.
W wywiadzie dużo wskazówek i frameworków dotyczących budowania relacji z deweloperami oraz jak docierać do tej grupy z usługami i produktami. Szczególnie polecam wywiad osobom zajmujących się sprzedażą, marketingiem, product managementem oraz startupom i firmom budującym narzędzia i technologie skierowane do developerów (B2D).
Jest to wprowadzenie do tematu DevRel, więc liczę, że Was zainspiruje do zgłębienia tematu. Polecam też dodać Dawida na LinkedIn, bo dzieli się dobrymi treściami i chętnie doradza startupom 💪
Kilka wątków:
Przykłady OKRów w Developer Relations (case study: OpenAI)
OCH, czyli 3 obszary metryk: Outreach, Collaboration, Healthy Community
Przykłady narzędzi używanych do budowania relacji z developerami
Gdzie umiejscowić DevRelations w organizacji (case studies: JetBrains, Twilio, SAP)?
Jak wygląda codzienna działalność zespołu DevRelations i gdzie przecina się z produktem, sprzedażą i marketingiem?
5 kluczowych elementów programu DevRelations, jak go budować i jakich błędów unikać (case studies m.in. Garmin, Nike, LakeFS)?
3 najważniejsze komponenty których inżynierowie oczekują od programów DevRelations
Czas potrzebny na przeczytanie: 9 min 47 sekund.
1. Jaka była Twoja ścieżka w Google do Head of Google Developer Experts Program?
Moje zainteresowanie technologiami Google sięga czasów na długo przed moim dołączeniem do firmy. Korzystałem zwłaszcza z Cloud, Apps Script i szeregu różnych ciekawych API - Maps, Drive, etc. Działałem również w ramach meetupów - byłem współorganizatorem Google Technology User Group, prezentowałem, prowadziłem szkolenia.
Powyższe doświadczenia pozwoliły mi dołączyć w 2012 roku do Google jako Program Manager w zespole Developer Relations. Zacząłem jako tzw. “Regional Lead” - uruchamiałem i wspierałem programy Google Developers w Polsce i kilku ościennych krajach, by po pewnym czasie zostać managerem zespołu na region CEE.
W 2015 roku, po zamknięciu ówczesnego krakowskiego biura Google znalazłem się w Szwajcarii, wkrótce przejmując obowiązki lidera globalnego zespołu odpowiedzialnego za cały program Google Developer Experts. Od ubiegłego roku, mój zespół ma w portfolio już kilka globalnych programów - m.in. GDE, Accelerator Mentors, Alumni oraz Developer Exchange.
2. Google to mekka OKRów, ale teraz przewrotnie: jak byś jako Googler ujął OKRy dla OpenAI pod kątem Developer Relations?
OKRy naszych programów w Google zazwyczaj skupione są na 3 głównych obszarach:
Outreach - np. ile osób zobaczy treści tworzone przez ekspertów, ile osób przyszło na prezentacje, ile osób ukończyło warsztaty lub zdobyło certyfikat
Collaboration with Product Areas - np. programy early access, feedback
Healthy community - np. poziom aktywności, diversity
Współpracujemy z ok. 12 dużymi produktami developerskimi (np. Android, Cloud, AI/ML) i każdy z nich będzie miał szczegółowe OKRy ustawione w zależności od wyższych celów organizacji, typu produktu, jego pozycji na rynku.
OpenAI jest bardzo ciekawym przypadkiem. Produkt, który jest relatywnie krótko na rynku, ale jest bardzo znany wśród konsumentów. Pierwsze API zostało udostępnione w 2020 roku ale platforma deweloperska zyskuje na popularności od niedawna - od ogłoszenia 1 marca 2023 dostępu do ChatGPT API w wersji gpt-3.5-turbo - 10-cio krotnie tańszego w użytkowaniu od poprzednich modeli. Bazując na tych informacjach skupiłbym OKRy na wzroście ilości aktywnych użytkowników w każdym segmencie lejka, oraz spróbował stworzyć pierwsze zręby feedbacku. Przykładowe OKRy mogłyby wyglądać np. tak:
O1 - More active and engaged users across the funnel
KR1 - +X% more visitors to the platform’s website (KR wspólny z Marketingiem)
KR2 - +X% visitors who created a profile
KR3 - +X% users who configured payments
O2 - Create basic feedback loop
KR1 - +X% questions with chatgpt tag on StackOverflow
KR2 - Establish relationship with X top StackOverflow contributors active in chatgpt tag
3. Jak zmieniła się Twoja rola na przestrzeni ostatnich 5 lat (np. jak rozłożyły się akcenty, zmieniały cele, metryki)?
Na pewno wzrosła skala - wiele naszych programów powiększyło się w ostatnich latach kilkukrotnie, np. Program GDE około 5x - do obecnych 1000+ ekspertów w 80+ krajach.
Było to możliwe dzięki lepiej zdefiniowanym procesom, uzgodnionym z większą ilością partnerskich zespołów wewnątrz firmy. Wyszliśmy również poza fazę spreadsheetów i korzystamy z profesjonalnych, często wysoce customizowanych narzędzi - jak Bevy z Kalifornii czy Advocu - tu ciekawostka - z Krakowa.
Co do akcentów, to wspieramy zawsze to, na czym w danym okresie zależy firmie - pierwszym dużym “pushem” był dla mnie Google+. Android czy Cloud są priorytetami ciągle, i to się nie zmienia. Od mniej więcej roku priorytetem są rozwiązania AI/ML
Nastąpiła również profesjonalizacja mierzenia tego co robimy. Próbowaliśmy wielu podejść i wiele po drodze się nauczyliśmy - np. jak mierzyć rzeczy pozornie niemierzalne - relacje z zespołami produktowymi, interakcje, rozwój społeczności, kontrybucje ekspertów. W przypadku tej ostatniej metryki, po wielu latach prób i błędów skupiliśmy się na:
Ręcznym raportowaniu aktywności (każda automatyzacja prowadziła do spadku jakości raportowanych aktywności)
Rozdzieleniu metryk online od tych “in-person”
W świecie online główną metryką jest ilość opublikowanych treści (artykułów, video) a dopiero metryką dodatkową ilość wyświetleń. W świecie “in-person” interesuje nas głównie “ile osób było na sali” - aczkolwiek odróżniamy prezentacje od warsztatów i mentoringu ze względu na wyraźnie inne poziomy zaangażowania uczestników i prowadzących.
4. Co jest głównym celem Developer Relations i jak je można najlepiej mierzyć?
W tym temacie nadal toczy się dość szeroka debata, aczkolwiek moja opinia pozostaje od wielu lat ta sama. Głównym celem Developer Relations jest product adoption wśród developerów. Bardzo upraszczając mój punkt widzenia - Developer Relations zaczyna się “zazębiając się z Marketingiem” a kończy w okolicach pre-sales engineering support (również często się zazębiając). Developer Relations pracuje jednak z całą “macierzą” organizacji w firmie. Może wspierać działania PR dostarczając świetne historie, wspierać sprzedaż, wysiłki public policy.
Adopcja oznacza, że developerzy dany produkt znają, umieją z niego korzystać i korzystają. To czy za niego płacą, jest sprawą trochę poza DevRel, zależącą od produktu, polityki cenowej i modelu sprzedaży.
Mierzenie celów DevRel jest również wielką i rozwijającą się dziedziną. Dobór tego co trzeba mierzyć zależy od produktu, jego pozycji na rynku i wielu innych czynników. Często zaczynamy od prostych metryk w stylu “ilu developerów założyło konto i korzysta z API”, ale możemy mierzyć również wysiłki budujące świadomość produktu (np. X ludzi przyszło na nasz event, lub X ludzi zobaczyło nasz blog post). Metryki typowo sprzedażowe są również stosowane (np. X developerów przeszło z bezpłatnej wersji narzędzia, na płatną wersję PRO).
5. Google to jedna z największych na świecie firm technologicznych, więc istnieje ryzyko pewnego “uprzedzenia” z Twojej strony. Dla jakich firm Developer Relations ma sens i czym różni się od marketingu, public relations czy sales? Jak w strukturze firmy umiejscowić zespół Developer Relations?
Im bardziej developerzy są kluczową publiką dla danej firmy, tym bardziej powinna wzrastać pozycja zespołu Developer Relations. W przypadku szczególnym - jeśli głównym produktem firmy jest np. narzędzie dla developerów, to według mnie Developer Relations powinno być jedną z organizacji najwyższego poziomu, raportującą bezpośrednio do CEO. Tak jest np. w JetBrains - firmie, która stworzyła m.in. język Kotlin czy środowisko IntelliJ będące również podstawą Android Studio.
W Google, Developer Relations jest częścią działu inżynieryjnego (Engineering). W innych firmach zespół często “ląduje” w organizacji produktowej lub w dziale marketingu. W SAP programistami zajmuje się dział Learning będący częścią People Operations, a w Twilio “Developer Network” raportuje do “Chief Customer Officer”.
Każde z tych podejść ma swoje plusy - jak np. krótkie pętle feedback’owe - i minusy - jak np. trudność w ustaleniu wspólnych celów. Wysokopoziomowe podsumowanie zamieściłem poniżej oraz w tym poście na LinkedIn.
6. Jak budowałeś swój zespół i jakie typu działania podejmują jego członkowie?
Budowa zespołu trwała długo, podobnie jak dochodzenie do jasno określonych obszarów odpowiedzialności. Był to kilkumiesięczny proces angażujący każdego członka zespołu.
Nasz zespół jest centralną, globalną organizacją wspierającą kilka programów. Współpracujemy z kilkunastoma “Liderami Regionalnymi”, którzy prowadzą nasze inicjatywy w konkretnych krajach. Bardzo ważna jest współpraca z zespołami produktowymi oraz zewnętrznymi dostawcami. Oprócz wysokopoziomowej strategii, codzienna działalność operacyjna skupia się na:
dostarczaniu wartości członkom społeczności (np. Ilość kontaktów z produktem, wsparcie w user jounrey, szkolenia, “swag”, wystawione certyfikaty)
obsłudze członkostwa w programach (np. onboarding, diversity, eskalacje w przypadku problemów)
współpracy z wewnętrznymi zespołami (np. zbieranie feedbacku, organizacja early access programs)
utrzymaniu platform (m.in. współpraca z vendorami i dostawcami, customizacja, zapewnienie prywatności)
szeroko pojętej promocji i marketingu (np. promocja treści opublikowanych przez ekspertów na kanałach Google, filmy promocyjne, działania marketingowe zgodne z kalendarzem wydarzeń w roku)
Żeby dobrze wykonywać wyżej wymienione działania, potrzebny jest naprawdę dobry zespół o zróżnicowanych umiejętnościach. Żeby pracować w Developer Relations nie trzeba być programistą, ale na pewno warto być osobą “techniczną”. Mimo że tylko ok. 70% mojego zespołu ma wykształcenie techniczne, to wszyscy co najmniej potrafią pisać proste skrypty 🙂
Oprócz wyczucia technologii, krytyczna w Developer Relations jest umiejętność nawiązywania kontaktów i dobra komunikacja. W przypadku zespołów takich jak mój, dodatkowo wymaga się dużego doświadczenia w zarządzaniu programami - umiejętności definiowania i śledzenia metryk, tworzenia i utrzymywania procesów biznesowych.
7. Jak wygląda współpraca zespołu DevRel z innymi zespołami wewnątrz w firmie, gdzie są największe punkty styku, a gdzie orkiestracja prac jest najtrudniejsza?
Developer Relations pracuje nie tylko z programistami “na zewnątrz”, ale również z wieloma zespołami wewnątrz firmy. Dla działu PR jesteśmy w stanie dostarczać ciekawe historie o wykorzystaniu naszych narzędzi developerskich. Dobry program społecznościowy DevRel jest w stanie takie historie “wyłapać” i przekazać w odpowiednim momencie.
Z działem Marketingu łączy nas wspólna praca nad świadomością użytkowników i klientów. Część działań się pokrywa, zwłaszcza we “wczesnych etapach lejka”. Często mamy wspólne OKRy jeśli chodzi o mierzenie aktywności online np. w social media.
Zespoły produktowe i inżynieryjne najczęściej zainteresowane są feedbackiem pochodzącym od programistów spoza firmy. Staramy się być bardzo proaktywni w tym obszarze, organizując sesje, programy “early access”, “trusted testers”, “developer advisory boards”.
Mimo, że w Google celem naszych programów nie jest rekrutacja, znam przypadki gdzie Developer Relations pomaga również ściągnąć najlepsze osoby do firmy.
Największymi wyzwaniami przy współpracy “cross-functional” są:
niespójność celów w różnych organizacjach (np. top customers vs. long-tail)
używanie rozbieżnych metryk (co to jest “zaangażowanie”?)
niespójne nazewnictwo (kto to jest developer?), a zwłaszcza bezwiedne aplikowanie praktyk z jednego obszaru do drugiego.
Sztandarowym anty-wzorcem jest na przykład aplikowanie krótkoterminowych metryk marketingowych i sprzedażowych, połączonych ze skupieniem się na zachętach (incentives) - podczas pracy ze społecznościami developerskimi. Wytworzona w ten sposób pewna transakcyjność w relacjach, utrudnia jakiekolwiek skalowanie programów “community”.
8. Jak wygląda budowanie programu DevRel od podstaw i jakie byś wyróżnił elementy/komponenty takiego programu?
Budowanie programu dla developerów warto zacząć od dogłębnej analizy produktu, który chcemy promować / sprzedawać. Należy wziąć pod uwagę:
Typ produktu (np. developer-focused jak Stripe lub consumer-focused jak Allegro)
Grupy docelowe (API dla każdego jak np. what3words vs. wyspecjalizowane produkty do wąskich zastosowań jak LakeFS)
Pozycję na rynku (wszyscy nas znają, więc zależy nam na wysokiej jakości aplikacjach - jak Android obecnie vs. rozwijamy nowy ekosystem, chcemy mieć dużo aplikacji - jak Android 15 lat temu 🙂)
Model biznesowy (żyjemy z udostępniania Ci API - jak Twilio vs. API masz w prezencie jeśli kupisz nasz główny produkt - jak Google Workspace)
Obecną świadomość marki/produktu (znana marka z mało znanym programem dla developerów - np. Nike vs. mniej znana marka, z bardzo znanym API - np. Garmin)
W wyniku powyższej analizy, będzie można z większa pewnością stwierdzić, gdzie warto zacząć. Czy zatrudniamy “Technical Writera” aby poprawić naszą dokumentację i przykłady? A może lepiej zacząć od wydzielenia kogoś z działu inżynieryjnego aby skupić się na problemach z API zgłaszanych przez zewnętrznych developerów? A może potrzebujemy Adwokata/Ewangelisty aby zwiększyć rozpoznawalność produktu przez treści online i wystąpienia publiczne? A może mamy już grono pasjonatów i warto by zorganizować ich w społeczność?
Pomocne będą raporty, które badają trendy wśród programistów. Doświadczeni developerzy wymieniają zazwyczaj 3 najważniejsze komponenty których oczekują od programów DevRel:
Tutoriale / how-tos videos (wszystko, co można zrobić zrobił chyba już Flutter)
Narzędzia developerskie, uproszczone integracje, biblioteki (polecam podpatrzeć jak robi to Stripe)
9. Załóżmy, że jako startup tworzę narzędzia dla inżynierów. Jakie błędy w budowaniu relacji z developerami widzsz najczęściej lub co często jest pomijane?
Niestety u wielu firm chcących na poważnie zająć się developerami widzę (1) podejście one-man-army, czyli wszystko na raz. Najczęstszy model, to zatrudnienie jednej osoby, umieszczenie jej w dziale marketingu i przypisanie zadań z całego spektrum DevRel: od tworzenia dokumentacji, przez prezentowanie, publikowanie, obsługę forum, angażowanie społeczności, po wsparcie partnerów i pre-sales. Na pewno na początku warto przeprowadzić analizę wspomnianą wcześniej i wybrać tylko niektóre z najlepiej dopasowanych działań, a następnie zatrudnić osobę z odpowiednimi umiejętnościami w tym zakresie.
Warto ponownie zwrócić uwagę aby (2) bezwiedne nie kopiować “mindsetu”, pojęć, metryk, narzędzi, procesów, aktywności czy OKRów z Marketingu lub Sprzedaży. Developerzy to specyficzna publika i wymaga specyficznego podejścia! Relacje budujemy długoterminowo, a podejście “coś za coś” szybko przestanie być skalowalne.
(3) Kiepski User Experience i Developer Experience. Raz opublikowane API bardzo trudno zamknąć, a wersjonowanie pomaga tylko trochę 🙂 API zwracające nieznane, losowe błędy, niespójna dokumentacja, zbyt skomplikowany “onboarding” - to wszystko może odrzucić developerów i sprawić, że wysiłki w dziedzinie budowy programu DevRel pójdą na marne.
10. Chciałbym abyś podał przykłady inicjatyw, które podejmowaliście w Google, ale również przykłady z innych firm, które Twoim zdaniem zasługują na wzmiankę.
Bardzo ciekawym przeżyciem - zarówno od strony organizatora, jak i uczestnika - są duże konferencje developerskie jak Google I/O, F8, WWDC. Atmosfera jest zawsze niesamowita a możliwości poszerzenia wiedzy i networku są nie do odtworzenia gdzie indziej.
Szczególne miejsce w moim sercu zajmują programy społecznościowe takie jak GDG, Java User Group, Developer Circles od Facebooka. Dla wielu osób, w tym dla mnie, to właśnie takie społeczności były pierwszym kontaktem z programami DevRel. Społeczności takie dają nieocenione wsparcie swoim członkom i są programem obowiązkowym dla każdej osoby zaczynającej przygodę z Developer Relations.
Opisując programy eksperckie takie jak prowadzone przez mój zespół Google Developer Experts czy Accelerator Mentors - trudno mi być obiektywnym. Wierzę, że są jednym z największych osiągnięć Developer Relations, jako że mają niebywały stosunek korzyści do inwestycji. Nie oznacza to jednak, że każdej firmie polecałbym zaczynać od tego typu programu, ponieważ zazwyczaj wymaga on istnienia już uprzednio rozwiniętego ekosystemu. Można jednak zapewnić firmie pewne możliwości interakcji z developerami w dość prosty sposób: założyć tag na StackOverflow i go monitorować, stworzyć forum lub założyć serwer Discord. To pozwoli po pewnym czasie, w naturalny sposób wyłonić najbardziej zaangażowanych ekspertów.
11. Co jest obecnie największym wyzwaniem w Developer Relations i jakie trendy dostrzegasz?
Wielkim wyzwaniem jest atrybucja wpływu Developer Relations na sprzedaż. Jak wspominałem wcześniej, celem DevRel jest adopcja produktu (używanie lub kupno). Działania DevRel są jednak bardzo skalowalne i często rozciągnięte w czasie, dlatego (1) trudno czasem jasno przypisać DevRel wpływ jaki rzeczywiście miał na sprzedaż. Jeżeli developer usłyszał o produkcie na meetupie, a następnie wspomniał o nim swojej CTO, która pół roku później po “cold call” od sprzedawcy zdecydowała o zakupie - to trudno stwierdzić, kto najbardziej pomógł w tej sprzedaży. Środowisko DevRel ciągle podejmuje wysiłki aby coraz lepiej pokazywać wpływ DevRel na konkretne metryki biznesowe.
(2) Diversity jest podobnie dużym problemem w Developer Relations jak w pozostałych działach sektora IT. Przekrój populacji wielu programów dla developerów jest wyraźnie zaburzony względem ogólnej populacji, co skutkuje np. gorszymi produktami, nie odpowiadającymi potrzebom wszystkich klientów. Słynne są już historie np. o filtrach do zdjęć, które działały zupełnie nieodpowiednio dla osób o innym niż biały kolorze skóry, czy też jawnej stronniczości (bias) w sposobie w jaki prezentowane są kobiety w niektórych modelach generacyjnego AI.
Jeśli chodzi o trendy, to obserwuję, że Developer Relations się rozwija - np. (3) powstają specjalistyczne usługi związane z tym działem IT (agencje consultingowe, agencje rekrutacyjne, dedykowane narzędzia). IT “pożera” coraz to szersze obszary biznesu, więc i developerzy stają się coraz częściej obywatelami pierwszej kategorii, co sprawia, że firmy szukają ludzi, którzy umieliby się nimi zająć 🙂
Po więcej gorąco polecam dodać Dawida na LinkedIn lub odezwać się. Dawid jako mentor pomaga z ramienia Google, więc szczególnie rekomenduję to startupom i firmom budującym narzędzia i technologie skierowane do developerów.
Miłej niedzieli,
Kamil Stanuch
PS. Jak oceniasz dzisiejszy mail?