Pewien senior architekt przygotowywał prezentację dla zarządu przez trzy tygodnie. Miał mocne dane, dopracowane diagramy, scenariusz przećwiczony kilka razy. W dniu spotkania, po dwunastu minutach, CFO mu przerwał: „Ale konkretnie czego od nas potrzebujesz?". Architekt był na slajdzie 6 z 47 i pytanie przełożonego kompletnie go wytrąciło z rytmu.
Ten wzorzec widzę najczęściej w zespołach IT w globalnych firmach i ma on niewiele wspólnego z pewnością siebie czy sposobem mówienia. To problem strukturalny, którego kursy wystąpień publicznych zwykle nie rozwiązują, bo odpowiadają na zupełnie inne pytanie. Po dziesięciu latach pracy z zespołami technicznymi w firmach takich jak Vattenfall, Samsung, Ciklum czy Exadel widzę, co naprawdę działa w praktyce. Ten artykuł pokazuje czteroczęściowy framework, którym zbudujesz realne umiejętności prezentacyjne w swoim zespole IT w 90 dni.
Prawdziwym problemem nie są wystąpienia publiczne, tylko tłumaczenie
Inżynierowie, architekci i tech leadzi zwykle nie mają problemu z mówieniem. Codziennie tłumaczą sobie nawzajem skomplikowane systemy, prowadzą design review, kłócą się o trade-offy w wątkach na Slacku rozwiniętych do dziesiątego poziomu. Mówienie nie jest tu problemem.
Problem zaczyna się w momencie, w którym decyzja techniczna musi opuścić salę inżynieryjną. Zarząd, CFO, head of product – każdy z nich myśli inaczej. Inżynierowie myślą systemami, zależnościami i kompromisami. Biznes myśli ryzykiem, kosztem, terminem i decyzją do podjęcia. Obie strony są inteligentne, obie patrzą na ten sam problem, ale każda przerabia go w swoim języku decyzyjnym i większość prezentacji rozsypuje się dokładnie w punkcie tłumaczenia z jednego na drugi.
Senior architekt z otwierającej historii nie był nieklarowny, kiedy spędził dwanaście minut na kontekście, zanim przeszedł do rekomendacji. Był skrupulatny w sposobie, w jaki inżynierowie cenią skrupulatność. CFO po prostu potrzebował innego punktu wyjścia, a nikt nigdy nie pokazał temu architektowi, jak go dać, nie czując przy tym, że spłyca temat.
Tu większość szkoleń z prezentacji rozmija się z celem. Leczą objaw – ktoś zawiesił się na scenie – zamiast przyczyny, czyli tego, że struktura komunikatu była zbudowana dla zupełnie innej publiczności.
Dlaczego klasyczne szkolenia z prezentacji zawodzą w zespołach technicznych
Większość programów prezentacyjnych jest zbudowana wokół założenia, że problemem jest sposób dostarczenia. Trzymaj się prosto, mów wyraźnie, używaj pewnej gestykulacji, buduj kontakt z salą. To ma swoje miejsce, ale to nie jest miejsce, w którym zespoły IT realnie tracą publiczność.
Dziewięćdziesiąt procent prezentacji w zespole IT nie odbywa się na scenie. Odbywa się w sali konferencyjnej z pięcioma osobami, laptopem i połączeniem z trzema kolejnymi po drugiej stronie świata. Stawka jest realna, ale format kameralny i techniki sceniczne brzmią w nim sztucznie. Inżynierowie i analityczne umysły mają też dobry radar na nieautentyczność i w momencie, w którym prezentujący zaczyna grać pewność siebie, której nie czuje, jego wiarygodność leci na łeb.
Jest też głębsze niedopasowanie. Inżynierowie są zwykle analityczni, często introwertyczni i sceptyczni wobec wszystkiego, co każe im zachowywać się inaczej, niż myślą. Program, który każe im odgrywać ekstrawertyczną energię, nakłada na nich podatek przy każdej kolejnej prezentacji i większość po cichu uznaje, że gra niewarta świeczki. Wracają do gęstych slajdów, bo slajdy są przynajmniej uczciwe.
W zespołach technicznych działa odwrotny sposób. Zamiast doklejać warstwę performansu na inżynieryjne myślenie, lepiej dać im strukturę, dzięki której to myślenie stanie się czytelne dla nietechnicznej publiczności. Nie chodzi o to, żeby z cichego inżyniera zrobić mówcę charyzmatycznego. Chodzi o to, żeby jego logika wypowiedzi stała się logiką zrozumiałą dla odbiorców.
Framework: cztery sugestie, które naprawdę działają
Framework jest zbudowany wokół czterech sugestii dotyczących tego, jak ułożyć prezentację techniczną. Każda z nich odpowiada na jedną z czterech najczęstszych sytuacji, w których zespoły IT prezentują poza swoim zespołem: architecture review, walka o budżet, cross-functional demo i prośba o inwestycję w dług techniczny.
Żadna z sugestii nie wymaga nowych cech osobowości. Każda z nich wyrasta z tego, co inżynierowie już robią dobrze, i pokazuje, jak przełożyć to na publiczność, która nie ma kontekstu inżynieryjnego. Zespół jest w stanie poznać framework podczas jednego warsztatu i stosować go konsekwentnie w 90 dni, jeśli menedżer wraca do niego w jednej lub dwóch realnych prezentacjach tygodniowo.
Sugestia 1: Najpierw rekomendacja, potem kontekst
Domyślną strukturą inżyniera jest chronologia. Spojrzeliśmy na problem, rozważyliśmy opcje, przeprowadziliśmy testy, doszliśmy do rekomendacji. Tak właśnie dokumentuje się decyzję projektową i tak właśnie nie powinno wyglądać architecture review z CTO, który ma tego dnia sześć innych przeglądów do zrobienia.
Duże lepiej zacząć od rekomendacji decyzji i konkretnej prośby, a kontekst dać tym, którzy o niego dopytają. Pierwszy slajd odpowiada na trzy pytania: co rekomendujemy, czego od ciebie potrzebujemy i kiedy. Kolejne slajdy istnieją po to, żeby tę rekomendację wesprzeć, nie po to, żeby uzasadnić drogę, która do niej doprowadziła.
W praktyce oznacza to, że sprint demo albo architecture review otwiera się czymś w stylu: „Rekomendujemy migrację serwisu płatności na nową platformę w Q3. Potrzebujemy zatwierdzenia budżetu na dwóch inżynierów i czterotygodniowego okna migracyjnego. Zaraz powiem dlaczego". Wszystko, co następuje potem, służy temu otwarciu. Jeśli CTO ma pytania, ma teraz strukturę, do której może je odnieść. Jeśli nie ma, spotkanie kończy się w siedem minut zamiast w czterdzieści siedem.
Inżynierowie czasami się temu opierają, bo wygląda to tak, jakby pomijali pracę. Jest dokładnie odwrotnie. Praca cały czas tam jest, na slajdach od trzeciego do ósmego, dostępna dla każdego, kto chce w nią wejść głębiej. Zmienia się tylko to, że publiczność od pierwszego zdania wie, dokąd cała ta prezentacja zmierza.
Sugestia 2: Trzy liczby zamiast trzydziestu
Prezentacja nt. budżetu zespołu IT z CFO zwykle zawiera za dużo danych i za mało wsparcia rekomendacji. Inżynierowie wiedzą o tym dobrze, ale niewygoda związana z pominięciem części informacji jest tak silna, że slajdów robi się czterdzieści. Z tyłu głowy siedzi obawa, że ktoś zada pytanie, na które prezentacja nie odpowiada, i nie będzie czym bronić swojej pozycji.
Sugestia jest taka, żeby trzymać się trzech liczb na rekomendację: koszt, czas i ryzyko. Każda inna liczba żyje w backup slides albo w aneksie i odwołujesz się do niej tylko wtedy, gdy ktoś zapyta. Trzy liczby wystarczą CFO do podjęcia decyzji i nie wystarczą, żeby się w nich zgubił.
Ten mechanizm działa, bo wymusza jasność już na etapie przygotowania. Jeśli nie umiesz sprowadzić rekomendacji do trzech liczb, znaczy, że jeszcze nie rozumiesz jej wystarczająco dobrze, żeby ją sprzedać. Na CFO nie robi wrażenia objętość analizy. Robi na nim wrażenie pewność dobrze zdefiniowanej prośby. „Potrzebujemy 240 000 EUR, sześć miesięcy, szacujemy 20 procent ryzyka miesięcznego opóźnienia, jeśli integracja z dostawcą się przeciągnie" – takie zdanie daje CFO podstawę do działania. Arkusz z osiemnastoma scenariuszami daje mu podstawę do odłożenia tematu na dwa tygodnie.
Backup slides są ważne i powinny być świetnie zrobione. Są dowodem, że trzy liczby nie są wzięte z sufitu. Po prostu nie prowadzą rozmowy, tylko ją wspierają.
Sugestia 3: Tłumacz na dwóch poziomach – ogół i szczegół
Zobacz, jak Neil deGrasse Tyson tłumaczy czarną dziurę. Nie zaczyna od ogólnej teorii względności. Zaczyna od obrazu, który każdy ma w głowie, czegoś bliskiego stwierdzeniu „wyobraź sobie obszar przestrzeni, w którym grawitacja jest tak silna, że nawet światło nie może uciec". Kiedy ten obraz już jest, może wejść głębiej dla tych, którzy chcą fizyki, a publiczność, która chciała tylko obrazu, dalej z nim jest.
To jest model dla cross-functional demo i każdego momentu, w którym IT tłumaczy coś biznesowi. Domyślnym błędem jest startowanie od poziomu szczegółu, bo tam dzieje się prawdziwa robota. Skutek jest taki, że publiczność wypisuje się ze slajdu numer dwa, a nawet ludzie, którzy mogliby nadążyć za szczegółem, nie mają już ramy, w której mogliby go umieścić.
Sugestia jest taka, żeby zawsze prezentować na dwóch poziomach na tym samym slajdzie. Ogólny obraz na górze, językiem, którym osoba nietechniczna posłużyłaby się przy kawie. Szczegół poniżej, dostępny dla każdego, kto chce się w niego zagłębić. Migracja do nowej chmury, na górze: „Przenosimy te elementy systemu, które obsługują płatności klientów, na platformę, która jest szybsza, bardziej niezawodna i łatwiejsza do utrzymania przez nasz zespół". Poniżej: diagram architektury, porównanie latencji, strategia failoveru.
Obie publiczności są szanowane. CFO ma zdanie, które może powtórzyć zarządowi. Inżynierowie w sali mają strukturę, w którą mogą się zagłębić. Nic nie zostało spłycone. Szczegół jest cały czas tam, dokładnie w miejscu, w którym powinien być.
Sugestia 4: Pokaż trade-offy, które odrzuciłeś
Inżynierowie żyją w trade-offach. CAP theorem, latencja kontra spójność, build kontra buy, monolit kontra mikroserwisy, szybko kontra dobrze. Każda istotna decyzja techniczna jest trade-offem, a zespół zwykle rozważył trzy lub cztery opcje, zanim coś zarekomendował.
W prezentacjach prawie nic z tego myślenia nie trafia do sali. Inżynier prezentuje wybraną opcję, a opcje odrzucone zostają w design dokumencie. Z perspektywy publiczności wygląda to na rekomendację bez alternatyw, a to utrudnia zaufanie. Pojawia się odruch, żeby pchać się wstecz, prosić o więcej opcji albo odłożyć decyzję.
Sugestia jest taka, żeby odrzucone opcje stały się częścią prezentacji – krótko i pewnie. Jeden slajd, trzy opcje, dlaczego każda była rozważana, dlaczego każda została odłożona. Ma to szczególną moc w pitchu inwestycji w dług techniczny, gdzie zespół prosi biznes o sfinansowanie pracy, która nie wyprodukuje widocznych funkcjonalności. Pokazanie, co odrzuciłeś – „rozważaliśmy włączenie tego do roadmapy następnego kwartału, rozważaliśmy zlecenie refactoringu na zewnątrz, rozważaliśmy odłożenie tego na kolejne sześć miesięcy" – udowadnia, że rekomendacja nie jest jedyną rzeczą, o której myślałeś. Jest rzeczą, którą przemyślałeś najdokładniej.
Tę sugestię zespoły inżynieryjne adoptują najszybciej, bo nie każe im uczyć się nowej umiejętności. Każe im wnieść do sali coś, co już robią. Zmiana jest psychologiczna, nie techniczna. Inżynierowie przestają chować alternatywy i zaczynają używać ich jako dowodu na to, że potrafią ważyć decyzje.
Co się zmienia, gdy zespół IT to wdroży
Pierwsza zmiana pojawia się w czasie kalendarzowym. Decyzje, które wymagały dwóch albo trzech spotkań, zapadają na jednym. Wzorzec „wróćmy do tego za tydzień", który jest endemiczny w cross-functional spotkaniach IT, zauważalnie spada w ciągu kwartału. Inżynierowie spędzają mniej czasu na przygotowywaniu slajdów do follow-up meetings, które nie byłyby potrzebne, gdyby pierwsze spotkanie było ułożone inaczej.
Druga zmiana dotyczy postrzegania zespołu IT. Zespoły, które prezentują w ten sposób, przestają być widziane jako dział, który opóźnia decyzje, a zaczynają być widziane jako dział, który je umożliwia. To znaczy więcej, niż brzmi. Kiedy biznes ma zaufanie, że IT przyjdzie na spotkanie z jasną rekomendacją, trzema liczbami i widocznym zestawem trade-offów, rozmowa przestawia się z „przekonajcie nas" na „decydujmy". Rozmowy budżetowe stają się krótsze i częściej kończą się sukcesem.
Trzecia zmiana jest wewnętrzna i zwykle zaskakuje menedżerów. Inżynierowie sami zauważają, że bardziej lubią prezentacje, bo nie czują już, że odgrywają osobowość, która nie jest ich. Framework daje im prawo do tego, żeby być analitycznymi przed nieanalityczną publicznością – i robić to bez spłycania czegokolwiek. Introwertycy w zespole, którzy często produkują najlepsze techniczne myślenie, w końcu mają strukturę, która pozwala temu myśleniu pracować również poza salą inżynieryjną.
Jak to wdrożyć
Cztery sugestie da się przekazać podczas jednego warsztatu i większość zespołów zaczyna je stosować w ciągu dwóch tygodni. Trudniejsza część to adopcja – upewnienie się, że framework staje się domyślnym sposobem pracy zespołu, a nie wspomnieniem ze szkoleniowego dnia.
Tu specjalistyczny program zmienia wynik. Cztery sugestie są fundamentem, ale realne wdrożenie obejmuje dziesiątki dodatkowych wzorców, decyzji językowych i rozstrzygnięć na poziomie pojedynczego slajdu, które przerabiamy z zespołem na ich rzeczywistych, nadchodzących prezentacjach. Framework wchodzi szybciej, głębiej i utrzymuje się dłużej, kiedy doświadczony trener pracuje na realnych deckach, w realnych sytuacjach i daje feedback, któremu zespół ufa.
Od czego zacząć
Jeśli chcesz, żeby twój zespół IT prezentował w ten sposób w 90 dni, najszybsza droga to warsztat prowadzony przez ludzi, którzy robią to zawodowo. Zbudowaliśmy program wokół tych czterech sugestii i wzorców, które je otaczają. Prowadziliśmy go w zespołach technicznych w globalnych firmach, w których publicznością jest zarząd, CFO albo cross-functional grupa liderska.
Umów 30-minutową konsultację – zmapujemy cztery sugestie na konkretne sytuacje twojego zespołu i zaproponujemy zakres warsztatu dopasowany do twojego harmonogramu i budżetu.
Piotr Garlej
O autorze: Piotr Garlej jest Simple Communication Advocate z dziesięcioletnim doświadczeniem w pracy z zespołami technicznymi w globalnych organizacjach. Prowadził programy dla firm takich jak Vattenfall, NBCUniversal i Escardio, dwukrotnie wystąpił na TEDx i napisał książki Effective Presentations Step by Step oraz Storytelling czy prosta komunikacja?. Jego praca koncentruje się na zespołach analitycznych w IT, finansach i R&D, gdzie logika i struktura wygrywają ze sceniczną techniką.
