Jest taki moment w karierze dobrego inżyniera, w którym jego największa kompetencja zaczyna działać przeciwko niemu. To moment, w którym wchodzi na spotkanie z kimś, kto nie ma dostępu do repo.
Im ktoś jest lepszy technicznie, tym gorzej mu idzie wytłumaczenie, co właściwie robi, komuś spoza branży. To nie jest złośliwość losu ani wada charakteru, tylko udokumentowany efekt poznawczy: klątwa wiedzy. Eksperyment Elizabeth Newton ze Stanfordu, 1990. Jedna grupa wystukuje palcem rytm bardzo znanej piosenki, druga ma zgadnąć tytuł. Stukający szacowali, że trafi mniej więcej połowa słuchaczy. Trafiło 2,5 procent, czyli trzy osoby na sto dwadzieścia.
W głowie stukającego gra pełna orkiestra. Na zewnątrz słychać walenie w stół.
Twój mikroserwis to orkiestra. Dla CFO to walenie w stół. I żadne „ale ja im to dokładnie wytłumaczyłem" tego nie zmieni, bo problem nie leży w dokładności.
A teraz nałóż na to angielski.
Twój angielski jest odwrócony do góry nogami
Uczę angielskiego ludzi z IT od dekady, prawie wyłącznie w formule jeden na jeden. To kilka tysięcy godzin słuchania, jak polski senior mówi po angielsku, kiedy musi coś ugrać. I jest jedna rzecz, którą widzę u praktycznie każdego, niezależnie od poziomu certyfikatu.
Przeciętny polski senior ma angielski technicznie zaawansowany i konwersacyjnie juniorski. Bez zająknięcia powie idempotent, eventual consistency, circuit breaker, backpressure. Zawiesi się na „Let me put that in business terms".
To jest odwrotność krzywej, którą ma native speaker spoza IT, i ma konsekwencję, której moi klienci nie widzą, dopóki nie usłyszą jej nazwanej na głos. Pod presją mózg sięga po to, co ma najlepiej zautomatyzowane. A najlepiej zautomatyzowaną częścią Twojego angielskiego jest żargon. Czyli dokładnie ten rejestr, który Cię zabija w rozmowie z osobą nietechniczną.
To, co obserwuję co tydzień, wygląda tak: ten sam człowiek, który po polsku wytłumaczy własnej mamie, czym się zajmuje, po angielsku przed klientem zsuwa się w gęstą, rzeczownikową papkę. Nie dlatego, że nie umie. Dlatego, że w stresie wraca do rejestru, w którym czuje się kompetentny. Żargon jest jego strefą komfortu, a nie jego wyborem. Kiedy przerywam komuś w połowie i powtarzam jego własne zdanie, reakcja brzmi prawie zawsze tak samo: „no tak, ale ja nie chciałem tego tak powiedzieć".
I to nie jest problem „miękki". Badanie Bullock, Colón Amill, Shulman i Dixona (Public Understanding of Science, 2019, N = 650) pokazało, że obecność żargonu upośledza zdolność przetwarzania informacji, a to upośledzenie prowadzi do silniejszego motywowanego oporu wobec perswazji, wyższej percepcji ryzyka i niższego poparcia dla wdrożenia technologii. Najważniejszy szczegół tego eksperymentu: efekt utrzymuje się nawet wtedy, gdy terminy techniczne zostają w tekście zdefiniowane. Jak ujęła to Shulman, specjalistyczne słownictwo jest sygnałem mówiącym ludziom, że tu nie należą, i można im wyjaśnić znaczenie terminów, ale to już niczego nie zmieni, bo zdążyli poczuć, że ten komunikat nie jest dla nich.
Przeczytaj to drugi raz, bo to jest oś całego artykułu: żargon nie obniża zrozumienia, tylko podnosi percepcję ryzyka. Twój stakeholder nie myśli „nie rozumiem". Myśli „brzmi drogo i niepewnie, odłóżmy to".
Dlatego tak często słyszysz „Interesting, let's revisit this next quarter". To nie jest odrzucenie merytoryczne. To reakcja obronna na komunikat, który podniósł mu poziom niepokoju, zamiast go obniżyć.
Dlaczego „mów prościej" to bezużyteczna rada
Bo problem nie jest w słowach. Problem jest w kolejności.
Twój domyślny układ wypowiedzi wygląda tak: kontekst, potem analiza, potem zastrzeżenia, na końcu wniosek. To jest struktura dowodu. Tak się pisze design doc, tak się prowadzi post-mortem, tak się przekonuje drugiego inżyniera. Wniosek na końcu, bo dopiero wtedy jest uzasadniony.
Układ, którego oczekuje strona nietechniczna, jest dokładnie odwrotny: wniosek, potem uzasadnienie, potem szczegóły wyłącznie na żądanie. Wniosek na początku, bo słuchacz może wyjść po trzydziestu sekundach, i bo on nie ocenia Twojego rozumowania, tylko podejmuje decyzję.
Te dwie struktury są lustrzane. Dlatego przełączanie się między nimi to nie jest kwestia „prostszych słów". To przebudowa architektury komunikatu.
Mam na to jeden bardzo konkretny dowód z własnej praktyki. Najtrudniejsze przypadki, z jakimi pracuję, to wcale nie są ludzie ze słabym angielskim. To są ludzie z angielskim na C1 i wyżej, często po latach w międzynarodowej korporacji, którzy nadal wychodzą ze spotkań z niczym. Bo bariera nie jest językowa. Można mieć bezbłędną gramatykę i budować zdania w kolejności dowodu przez całą karierę.
Stos abstrakcji
Nie ma dwóch „języków", technicznego i biznesowego. To fałszywy podział, który każe Ci wybierać między precyzją a zrozumiałością, a wybór między nimi jest pułapką.
Jest jeden fakt i pięć warstw, na których można go wypowiedzieć. Każda warstwa jest w stu procentach prawdziwa. Różnią się tylko tym, czyje pytanie obsługują.
Weźmy konkret: klasyczny problem N+1 na endpoincie z zamówieniami.
┌─────────────────────────────────────────────────────────────┐
│ L5 KONSEKWENCJA zarząd · CFO · klient │
│ "We lose about 3% of checkouts on that page. │
│ Two days of work fixes it." │
├─────────────────────────────────────────────────────────────┤
│ L4 EFEKT DLA UŻYTKOWNIKA sales · marketing · support │
│ "Customers stare at a spinner on the orders page, │
│ and some of them give up." │
├─────────────────────────────────────────────────────────────┤
│ L3 ZACHOWANIE SYSTEMU PM · QA · klient techniczny │
│ "The order list takes four seconds to load │
│ under normal traffic." │
├─────────────────────────────────────────────────────────────┤
│ L2 ARCHITEKTURA inżynierowie · tech lead │
│ "The orders endpoint has an N+1 problem, │
│ there's no eager loading." │
├─────────────────────────────────────────────────────────────┤
│ L1 IMPLEMENTACJA Ty · code review │
│ "The ORM fires a separate query for every row │
│ inside the order loop." │
└─────────────────────────────────────────────────────────────┘
Pięć zdań, jeden fakt. Każde jest prawdziwe i każde jest szkodliwe, jeśli zostanie wypowiedziane do niewłaściwej osoby.
Zrób to samo z ryzykiem bezpieczeństwa, bo to jest obszar, w którym moi klienci tracą najwięcej i najczęściej:
┌─────────────────────────────────────────────────────────────┐
│ L5 "Someone could download our entire customer list. │
│ It's a two-day fix. I'd do it this week." │
├─────────────────────────────────────────────────────────────┤
│ L4 "An attacker could see other people's orders, │
│ including names and addresses." │
├─────────────────────────────────────────────────────────────┤
│ L3 "The search box passes user input straight to │
│ the database." │
├─────────────────────────────────────────────────────────────┤
│ L2 "We've got an SQL injection vector in the search │
│ endpoint, input isn't parameterised." │
├─────────────────────────────────────────────────────────────┤
│ L1 "Raw string concatenation in the WHERE clause │
│ of buildSearchQuery()." │
└─────────────────────────────────────────────────────────────┘
Jeśli zgłaszasz to na L2, dostajesz „thanks, add it to the backlog". Jeśli zgłaszasz to na L5, masz decyzję w tej samej rozmowie. Ta sama podatność, ta sama pilność, ten sam człowiek naprzeciwko. Różnica jest wyłącznie w warstwie.
Twój problem nie polega na tym, że mówisz zbyt skomplikowanie
Polega na tym, że masz tylko dwie warstwy z pięciu.
To jest diagnoza, którą stawiam na pierwszej lekcji i od której zaczynam pracę praktycznie z każdym klientem. L1 i L2 są rozwinięte, wyćwiczone, gotowe do użycia po angielsku w każdej sekundzie, bo używasz ich codziennie. L3, L4 i L5 po angielsku prawie nie istnieją, bo nigdy nie musiałeś ich budować. Po polsku je masz, bo jesteś native speakerem i improwizujesz w locie. Po angielsku improwizacja na górnych warstwach kończy się ogólnikami: „it's better now", „it's more stable", „it improves performance". Czyli zdaniami, które nie niosą żadnej informacji decyzyjnej.
Efekt jest taki, że startujesz z L1 albo L2, czyli z miejsca, w którym rozmówca nie ma żadnego zaczepienia. On nie ma jak przeliczyć L2 na decyzję, więc stosuje regułę awaryjną i nie robi nic. Brak decyzji zawsze wygląda bezpieczniej niż zła decyzja, zwłaszcza jeśli tej pierwszej nikt potem nie rozlicza.
Tak umierają refaktory, migracje, budżety na bezpieczeństwo i prośby o drugiego człowieka do zespołu. Nie dlatego, że ktoś powiedział „nie". Dlatego, że nikt nie powiedział „tak".
Trzy reguły poruszania się po stosie
Zawsze wchodzisz od góry. L5 to domyślne pierwsze zdanie w rozmowie z kimkolwiek spoza zespołu. Nie „na początek trochę kontekstu", nie „żeby to zrozumieć, trzeba wiedzieć, jak działa nasz pipeline". Pierwsze zdanie to konsekwencja, i nic innego.
Schodzisz o jeden poziom na jedno pytanie. Nigdy nie skaczesz z L5 na L1. Jeśli ktoś pyta „why does it take two days?", odpowiadasz na L4 albo L3. Skok o trzy poziomy w dół jest odbierany jako popis albo jako zemsta, nie jako wyjaśnienie. Sygnał, którym otwierasz sobie drogę w dół, brzmi: „Happy to go deeper if that's useful."
Musisz umieć zejść na L1 w ciągu jednej sekundy. I to jest reguła, której nie znajdziesz w poradnikach o mówieniu prostym językiem, bo one są pisane dla ludzi, którzy L1 nie mają wcale.
To ostatnie wymaga rozwinięcia, bo tu widzę pułapkę, w którą wpadają ludzie po pierwszym szkoleniu z komunikacji z biznesem. Trafiają do mnie już po takim kursie i objaw jest zawsze ten sam: nauczyli się mówić na L5 i zostali tam na stałe. Mówią wyłącznie o business value, impact, alignment i customer experience. Brzmi świetnie przez jakieś trzy tygodnie.
Potem kompetentny CTO albo doświadczony klient zadaje jedno pytanie w dół stosu, „Why exactly does that take three weeks?", i jeśli nie masz w tej sekundzie konkretu z L1, tracisz wiarygodność nie na tym spotkaniu, tylko na całą resztę współpracy. Bo właśnie potwierdziłeś podejrzenie, że mówisz slajdami.
Umiejętnością nie jest mówienie prosto. Umiejętnością jest sterowanie wysokością w czasie rzeczywistym. Góra stosu to wejście. Dół stosu to dowód, że nie ściemniasz. Potrzebujesz obu.
Jak zbudować warstwy, których nie masz: reguła 1-3-10
Stos nie powstaje na spotkaniu. Powstaje wcześniej, przy biurku, na piśmie. To jest chyba najczęstsze nieporozumienie, z jakim się spotykam: ludzie myślą, że chodzi o refleks. Nie chodzi. Chodzi o przygotowanie, które potem wygląda jak refleks.
Na każdy temat, który będziesz musiał omawiać, przygotuj trzy gotowe odpowiedzi po angielsku:
Jedno zdanie. Sama konsekwencja, zero mechanizmu. „It's slow because we ask the database the same question a thousand times."
Trzy zdania. Konsekwencja, przyczyna bez żargonu, rozwiązanie z ceną. To jest wersja, która wygrywa większość rozmów.
Dziesięć minut. Pełny rejestr inżynierski, na żądanie, z warunkami brzegowymi i alternatywami, które odrzuciłeś.
Zawsze zaczynasz od jedynki i schodzisz wyłącznie wtedy, gdy ktoś poprosi.
I tu pojawia się rzecz, której się nie spodziewałem, kiedy zaczynałem to ćwiczyć z klientami. Jeśli ktoś nie potrafi napisać wersji jednozdaniowej, prawie nigdy nie jest to problem językowy. To sygnał, że sam jeszcze nie wie, na czym polega konsekwencja. Ludzie odkrywają na lekcjach, że nie potrafią po angielsku powiedzieć czegoś, czego nigdy nie sformułowali po polsku. Język tylko obnaża lukę, której wcześniej nie było widać.
Kto siedzi naprzeciwko
Nie istnieje jeden „nietechniczny rozmówca". Istnieje kilka bardzo różnych walut, i jeśli płacisz nie tą co trzeba, transakcja nie dochodzi do skutku, choćby kwota była właściwa.
CFO kupuje przewidywalność, nie jakość
Nie interesuje go najlepsze rozwiązanie, tylko wariancja. Woli opcję droższą i pewną niż tańszą i rozstrzeloną, bo jego praca polega na tym, żeby nic go nie zaskoczyło w połowie kwartału.
- "It should take around three to six weeks, depending on how the legacy data looks."
+ "Four weeks. One unknown: the legacy data. I'll know by Friday if it adds two. Worst case, six."Ta sama informacja, tylko przekonwertowana na scenariusz zamiast na widełki. Dla Ciebie widełki to uczciwość. Dla niego dwukrotny rozrzut oznacza, że nie masz planu, tylko przeczucie. Ćwiczę tę jedną konwersję z klientami częściej niż jakąkolwiek inną i częściej niż jakakolwiek inna zmienia wynik rozmowy.
Founder kupuje opcjonalność
Myśli o tym, czego nie będzie mógł zrobić za rok, jeśli zdecyduje dziś. Sprzedawanie mu elegancji architektury nie zadziała nigdy, nie widziałem przypadku, żeby zadziałało. Dług techniczny w jego języku to nie dług, tylko zamknięte drzwi.
- "The architecture won't scale, we need to rewrite the billing module."
+ "This keeps the door open for the enterprise tier. Skip it now and adding it later costs three times as much."Sales kupuje to, co może obiecać klientowi
Najgroźniejszy rozmówca w całej firmie, bo Twoje słowa wychodzą z pokoju i lądują w kontrakcie, a Ty dowiadujesz się o tym z maila. Do każdej możliwości doklejaj cenę, zawsze w tym samym zdaniu, nigdy w następnym.
- "Yeah, that's technically possible."
+ "It's possible, but it's a six-week project and it's not on the roadmap. Don't promise it without talking to me first."Product Manager to najbardziej niedoceniane ryzyko
Zna słowa API, cache, migration, technical debt i używa ich w znaczeniach przesuniętych o jakieś trzydzieści procent względem Twoich. To jest gorsze niż brak wiedzy, bo rozmowa brzmi jak zgoda i nią nie jest. Obie strony wychodzą zadowolone i budują dwie różne rzeczy.
Jedyne zabezpieczenie to wymuszone odbicie komunikatu: „Just so we're aligned, what do you expect to happen when a user clicks that?". Zauważam, że ludzie boją się tego zdania, bo brzmi im protekcjonalnie. Nie jest. To checksum, i dokładnie tak należy to traktować.
Compliance i audytor kupują dowód
Tu przestają działać wszystkie techniki upraszczania, bo ten rozmówca potrzebuje precyzyjnego języka o granicach odpowiedzialności, a nie przystępnego obrazka. Nigdy nie mów „the system is secure". Tego zdania nie da się obronić, a Ty właśnie podpisałeś się pod nim sobą.
- "The system is secure."
+ "We encrypt data at rest and in transit, and we log all access. We haven't been independently audited - that's a gap."Pokazanie luki buduje tu wiarygodność, a nie ją niszczy. Człowiek, który sam zgłasza braki, jest wiarygodny we wszystkim pozostałym.
Klient w trakcie awarii kupuje poczucie kontroli
W kryzysie ludzie nie chcą wyjaśnień. Chcą wiedzieć, że ktoś trzyma stery i kiedy dostaną następną informację. Przyczyna źródłowa w pierwszej wiadomości jest odbierana jako tłumaczenie się zamiast działania. Szablon masz na końcu artykułu i radzę nauczyć się go na pamięć, bo w kryzysie nikt nie komponuje maili od zera, a angielski pod adrenaliną cofa się o poziom albo dwa.
Support i marketing kupują zdanie, które mogą powtórzyć
Ci ludzie nie będą Cię cytować. Będą Cię streszczać, z pamięci, przed klientem. Jeśli nie dasz im jednego gotowego zdania, wymyślą własne i to własne pojedzie dalej.
- "We've optimised the sync process and reduced the queue backlog."
+ "Orders now show up in the panel within a minute instead of twenty. You can tell customers it's fixed."Warstwa czysto językowa
To jest część, której nie znajdziesz w anglojęzycznych poradnikach o komunikacji z biznesem, bo one są pisane przez native speakerów dla native speakerów i nie widzą tego, co robi z angielszczyzną polska głowa. Wszystko poniżej pochodzi z rzeczy, które wyłapuję na lekcjach, nie z podręczników.
Rzeczownikowanie
Polski inżynier piszący po angielsku instynktownie buduje ciężkie konstrukcje rzeczownikowe, bo tak brzmi „profesjonalnie" i bo to kalka z polskiej korporacyjnej polszczyzny, w której też się dokonuje implementacji zamiast coś budować.
- "The implementation of the caching layer resulted in a significant reduction of response times."
+ "We added caching. Pages load in under a second now, instead of four."Reguła operacyjna do stosowania przy każdym mailu: znajdź rzeczownik na -tion, -ment albo -ance i zamień go z powrotem na czasownik. Implementation to we built. Reduction to it dropped. Optimization to we made it faster. Deployment to we shipped it.
Zysk jest podwójny i drugi z nich zauważyłem dopiero po latach poprawiania cudzych maili. Zdanie robi się krótsze, a przy okazji wraca do niego sprawca. Konstrukcja rzeczownikowa ukrywa, kto co zrobił, i w angielskim biznesowym czyta się to jako unikanie odpowiedzialności. Ludzie piszą tak, żeby zabrzmieć solidnie, a brzmią, jakby się chowali.
Latynizmy, czyli pułapka zastawiona specjalnie na Polaka
Słowa łacińskie w angielskim są dla nas przezroczyste, bo mamy ich odpowiedniki w polszczyźnie. Sięgamy po nie odruchowo, bo są łatwiejsze do odzyskania z pamięci. Problem w tym, że w angielskim to rejestr biurokratyczny, który brzmi wymijająco.
- utilize, implement, facilitate, terminate, commence, obtain
+ use, build, help, stop, start, get
- prior to, in order to, sufficient, approximately, demonstrate
+ before, to, enough, about, show
- at this point in time, in the event that, due to the fact that
+ now, if, becauseKrótkie, germańskie słowa brzmią po angielsku pewnie i decyzyjnie. Długie, łacińskie brzmią jak ktoś, kto zawczasu zabezpiecza się przed odpowiedzialnością. To jest dokładnie odwrotność tego, co chcesz komunikować, prosząc o budżet.
Kiedy mówię o tym klientom, najczęstsza reakcja brzmi: „ale przecież utilize brzmi lepiej niż use". Nie brzmi. Brzmi znajomo, bo jest podobne do polskiego, i to dwie zupełnie różne rzeczy.
Fałszywi przyjaciele, którzy kosztują najwięcej
Wybrałem te, które realnie wracają na lekcjach, a nie te z list w podręcznikach.
Eventually to nie „ewentualnie", tylko „ostatecznie, w końcu". „We'll eventually fix it" znaczy „kiedyś to naprawimy", czyli mówisz klientowi coś zupełnie innego, niż myślisz. Jeśli chodziło Ci o „ewentualnie", potrzebujesz if needed albo possibly. To jest, obok actually, najkosztowniejsza pomyłka na całej liście.
Actually to nie „aktualnie", tylko „właściwie, w rzeczywistości". „Aktualnie" to currently.
To control to nie „kontrolować" w sensie „sprawdzać". „I'll control the logs" brzmi jak przejęcie władzy nad logami. Chodziło Ci o check, review albo verify.
Pathetic to nie „patetyczny", tylko „żałosny". Nie opisuj tak niczyjego kodu, nawet zasłużenie.
According to me nie istnieje w angielskim. Jest in my view, my take is, I'd argue that.
I will inform you jest sztywne i lekko urzędowe. Naturalnie brzmi I'll let you know.
It's not possible w rozmowie z klientem amerykańskim to zatrzaśnięcie drzwi.
- "That's not possible."
+ "Not by Friday. Here's what we can do by Friday."To ostatnie łączy się bezpośrednio z tym, co opisywałem w artykule o low- i high-context. Polska bezpośredniość plus angielski bez warstwy dyplomatycznej daje mieszankę, która w polskim zespole czyta się jako szacunek do cudzego czasu, a u klienta z USA jako odmowa współpracy. Ten sam człowiek, ta sama intencja, dwa przeciwne odczyty.
Słowa, które detonują rozmowę
Kilka słów uruchamia po drugiej stronie stołu reakcję nieproporcjonalną do Twojej intencji. Zbieram je od lat, bo prawie zawsze wychodzą dopiero w trakcie ćwiczenia, nigdy z relacji klienta o tym, jak poszło spotkanie.
Never i always w kontekście technicznym są odbierane jako przesada i natychmiast zapraszają do szukania kontrprzykładu. Guarantee jest słowem prawniczym, nie inżynierskim, i nie powinno wyjść z Twoich ust w rozmowie z klientem. Obviously i as you know są odbierane jako protekcjonalne nawet wtedy, gdy są prawdziwe, a Polacy używają ich znacznie częściej niż native speakerzy, bo to kalka z „oczywiście" i „jak wiesz", które po polsku są neutralne. Simply i just w zdaniu „you just need to…" brzmią jak zarzut, że rozmówca jest wolny.
Dwa rodzaje hedgingu, z czego tylko jeden działa
Inżynier hedguje, żeby być dokładnym. Biznes słyszy w tym niepewność co do kompetencji. To jest chyba najbardziej niesprawiedliwy mechanizm w całej tej układance i najczęstsze źródło frustracji moich klientów: człowiek jest karany dokładnie za to, że jest rzetelny.
Rozwiązanie nie polega na usunięciu zastrzeżeń, bo to byłoby kłamstwo, tylko na etykietowaniu poziomu pewności.
- "It might be around three weeks, but it's hard to say, there are a few unknowns."
+ "I'm confident about the API work, that's two weeks. The unknown is the data migration. Best estimate: three weeks total, firm number on Thursday."Bank fraz, które warto mieć wyćwiczone do automatu:
I'm confident about X, less certain about Y.
My best estimate is…
What I'd need to confirm is…
If I had to commit to a number today, I'd say…
That's an assumption, not a fact. Let me verify it.
Ta ostatnia jest moim zdaniem najcenniejszą frazą w całym artykule. Oddziela wiedzę od hipotezy, czyli robi dokładnie to, czego biznes od Ciebie potrzebuje, a czego zwykle nie dostaje od nikogo w firmie.
Analogia musi mieć cenę
Dobra analogia pochodzi z życia rozmówcy, nie z Twojego, i niesie konsekwencję, a nie tylko obrazek. Analogia bez ceny to ozdobnik.
Dług techniczny: „It's like paying the minimum on a credit card. Every month the fix gets more expensive."
Refaktoryzacja: „It's rewiring the house. You won't see anything new, but the lights stop flickering."
Latencja: „Every click is a trip to the warehouse. We're moving the warehouse closer."
Legacy system: „We're renovating a building that people still live in."
Load balancing: „Opening more checkout lanes when the queue gets long."
Monitoring: „Right now we find out from customers. This is a smoke alarm."
To są analogie, które sprawdziłem na tylu klientach, że mogę za nie ręczyć. Uwaga na kalki: polskie porównania w dosłownym tłumaczeniu prawie nigdy nie działają, bo odwołują się do realiów, których rozmówca nie zna. Buduj z rzeczy uniwersalnych, czyli z pieniędzy, kolejek, remontów i ruchu drogowego.
Liczby zamieniaj na jednostki ich świata
17% of users to about one in six users. 200 ms faster to the page feels instant instead of sluggish. 99.9% uptime to roughly eight hours of downtime a year, i dopiero przy tej wersji ktoś na sali się budzi. Robię to przeliczenie na lekcjach i reakcja jest zawsze ta sama, także u samego klienta: „czekaj, to aż tyle?".
Three days of engineering to about four thousand euros of our time. Procenty są abstrakcją. Ułamki, godziny i pieniądze są konkretem.
Tempo i pauza
Rzecz, którą słyszę u każdego bez wyjątku, i jedyna, której nie da się wyćwiczyć samą teorią: nie-native speakerzy przyspieszają pod presją, żeby szybciej wyjść z niekomfortowej sytuacji. Słuchacz nie odczytuje tego jako stresu językowego. Odczytuje jako niepewność co do treści.
Po zdaniu z rekomendacją albo liczbą robisz pauzę na dwie sekundy i jej nie wypełniasz. Cisza po konkrecie brzmi jak kompetencja. Cisza wypełniona „so, yeah, basically…" brzmi jak proszenie o zgodę, a proszenie o zgodę zaprasza do jej nieudzielenia.
Drugi element tego samego problemu to długość zdania. W rejestrze decyzyjnym trzymaj się mniej więcej dwudziestu słów. Polskie zdanie wielokrotnie złożone przełożone na angielski jeden do jednego gubi słuchacza w połowie i brzmi jak zwlekanie z puentą.
Historie z frontu
Technically possible
Polski tech lead na callu z amerykańskim salesem, pytanie o integrację z SAP-em. Odpowiedź: „Yeah, that's technically possible". Miesiąc później klient podpisał kontrakt z tą integracją w zakresie. Zespół dowiedział się z maila.
Jedno przysłówkowe technically, w głowie inżyniera znaczące „nie łamie to praw fizyki", w kontrakcie znaczyło „zrobione i wycenione". Ten schemat widziałem w kilku wariantach i za każdym razem kończył się tak samo.
Refaktor, który przeleżał dwa lata
Senior przez cztery kwartały wnosił ten sam punkt na planowaniu: „We need to refactor the payment module, it's unmaintainable". Cztery razy usłyszał „next quarter".
Za piątym razem powiedział to samo z L5: „Every change to payments now takes three days instead of half a day. That's two weeks of engineering per quarter. Six weeks of work now stops the bleeding." Dostał zgodę na tym samym spotkaniu.
W technice nie zmieniło się nic. Zmieniła się jednostka miary.
Awaria wyjaśniona zbyt dobrze
Trzygodzinny outage u klienta w Wielkiej Brytanii. Pierwszy mail od zespołu: sześćset słów o przyczynie źródłowej, deadlocku i strategii retry, napisane porządnie i uczciwie. Klient eskalował do zarządu, bo przeczytał trzy akapity i nie znalazł odpowiedzi na jedyne pytanie, które miał, czyli kiedy to wróci.
Precyzja odebrana jako gadanie zamiast działania. Ten sam tekst wysłany dobę później, jako post-mortem, zbudowałby zaufanie. Kolejność, nie treść.
Zgoda, której nie było
PM na refinemencie: „So we just add an endpoint for the report, right?". Tech lead: „Yeah, more or less". Obaj wyszli zadowoleni.
PM miał na myśli raport generowany na żywo dla dowolnego zakresu dat. Tech lead miał na myśli endpoint zwracający zagregowane dane z nocnego joba. Różnicę zobaczyli po trzech tygodniach, na demo, przy kliencie. More or less to najdroższe dwa słowa w tej historii.
Pytanie, które nie było pytaniem
Nietechniczna dyrektorka operacyjna: „Do we really need all this testing?". Zespół odczytał to jako atak na jakość i odpowiedział wykładem o piramidzie testów.
Ona pytała o coś zupełnie innego: dlaczego release trwa dwa tygodnie, skoro obiecano jej pięć dni. To jest wzorzec, który każę klientom wyłapywać przede wszystkim: pytania osób nietechnicznych są prawie zawsze pytaniami o czas, koszt albo ryzyko, przebranymi za pytania techniczne. Zanim odpowiesz, przetłumacz pytanie.
Zderzenia, które zdarzają się co tydzień
Siedem sytuacji, w których warstwa jest źle dobrana, i gotowe przełożenie na wyższą. Wszystkie siedem wracają u mnie na lekcjach tak regularnie, że mam je opisane jako osobne ćwiczenia.
Estymacja. Mówisz „it depends on a few things", słyszą „nie ma pojęcia".
- "It depends on a few things."
+ "Four weeks, with one risk I'll resolve by Friday."Dług techniczny. Mówisz „the code is unmaintainable", słyszą „nie lubi kodu poprzednika".
- "The code is unmaintainable."
+ "Every change here costs three times what it should."Ryzyko bezpieczeństwa. Mówisz „there's an SQL injection vector", słyszą jakiś żargon, pewnie ważny, ale nie dziś.
- "There's an SQL injection vector in search."
+ "Someone could read our entire customer list. Two-day fix."Awaria. Mówisz „we hit a deadlock in the write path", słyszą „nie wiem, kiedy to wróci".
- "We hit a deadlock in the write path."
+ "Orders are down. Fix in about two hours. Next update at 14:00."Odmowa. Mówisz „that's not possible", słyszą „nie chce współpracować".
- "That's not possible."
+ "Not by Friday. Here's what is possible by Friday."Migracja. Mówisz „we're moving to Kubernetes", słyszą koszt bez korzyści.
- "We're moving to Kubernetes."
+ "Same system, but it stops falling over during sales peaks."Sukces. Mówisz „we reduced p99 latency by 40%", nie słyszą nic. I to jest najgorszy przypadek z całej listy, bo właśnie zmarnowałeś kwartał pracy. Nie zmarnowałeś go technicznie. Zmarnowałeś go w oczach ludzi, którzy decydują o Twoim następnym kwartale.
- "We reduced p99 latency by 40%."
+ "Checkout no longer times out. That was 3% of all orders."Co wdrożyć w tym tygodniu
Pierwsze zdanie to wniosek. Każdy mail, każda wypowiedź, każdy update zaczyna się od L5. Uzasadnienie idzie potem. Jeśli rozmówca przeczyta jedno zdanie i zamknie okno, ma mieć to, co najważniejsze.
Struktura 3-1-3 na każdą prośbę o decyzję. Trzy zdania kontekstu, jedna rekomendacja, trzy opcje z ceną wyrażoną w czasie, pieniądzu i ryzyku. Ludzie nietechniczni nie wybierają rozwiązań, tylko kompromisy, i jeśli nie dasz im kompromisu do wyboru, wybiorą status quo.
Wzorzec, który przerabiam z klientami najczęściej:
„We're going to miss the Q3 date. Two options: ship in September without the reporting module, or ship everything in November. I'd go with September, reporting is used by four clients and the delay costs us the retail rollout. I need a decision by Thursday."
Cztery zdania, zero żargonu, pełna kontrola nad ramą decyzji.
Szablon na awarię, do nauczenia na pamięć.
What: Checkout is failing for about 30% of users.
Who: UK and DE customers, since 11:20 CET.
Now: We've found the cause and we're deploying a fix.
Next update: 14:00 CET, or sooner if it's resolved.
Cztery linie, zero żargonu, zero przyczyny źródłowej. Root cause idzie do post-mortemu, nie do pierwszej wiadomości.
Test „so what" trzy razy. Bierzesz swoje zdanie i trzy razy pytasz, co z tego. We migrated to Postgres 16, i co z tego, queries are faster, i co z tego, reports load in seconds, not minutes, i co z tego, the finance team stops opening tickets about it. Ta ostatnia wersja jest Twoim pierwszym zdaniem.
Update bez ask to szum. Jeśli Twój status nie zawiera zdania zaczynającego się od „What I need from you is…" albo jawnego „No action needed", nikt nie wie, czy ma cokolwiek zrobić. Ta druga wersja też jest wartościowa i warto ją pisać świadomie.
Odbicie komunikatu na koniec każdej ważnej rozmowy. „Just so we're aligned, what's your understanding of what happens next?". Najtańsze ubezpieczenie w całej komunikacji technicznej i jedyne, które wykrywa fałszywą zgodę, zanim stanie się kosztem.
Wspólny słownik w zespole. Piętnaście terminów, których używacie z klientem, z jednym uzgodnionym tłumaczeniem na L5. Jedna strona, w repo, przy README. To jest to samo, co konwencja nazewnicza w kodzie, tylko dla ludzi.
Drill na trening. To ćwiczenie zadaję jako pracę własną, bo diagnozuje szybciej niż jakikolwiek test poziomujący. Wybierz jedną rzecz, którą zbudowałeś w tym kwartale. Nagraj po angielsku sześćdziesiąt sekund wyjaśnienia dla CFO, sześćdziesiąt dla dziesięciolatka i sześćdziesiąt dla drugiego seniora. Odsłuchaj wszystkie trzy jeden po drugim.
Jeśli brzmią podobnie, masz jedną warstwę zamiast pięciu. I to jest dokładnie ten deficyt, który kosztuje Cię awans, a nie akcent ani czasy. Powiem to jeszcze dosadniej, bo mam za sobą dekadę patrzenia, jak to działa: nie spotkałem człowieka, którego kariera zatrzymała się przez gramatykę. Spotykam za to regularnie kogoś, kogo zatrzymała nieumiejętność powiedzenia w trzydzieści sekund, po co wydać te pieniądze.
Twój kod operuje na jednym poziomie abstrakcji naraz. Twój angielski musi operować na pięciu i musisz się między nimi przełączać w czasie rzeczywistym, pod presją, w obcym języku, przed ludźmi, którzy decydują o Twoim budżecie.
To jest umiejętność techniczna, nie talent. Uczy się jej tak samo jak każdej innej: powtórzeniami i feedbackiem na konkretach.