Engineering manager warszawskiego oddziału amerykańskiej firmy SaaS dostaje wiadomość od VP Engineering z Austin: „Planujemy dziesięć nowych etatów w przyszłym roku. Finanse dostały ofertę z Guadalajary. Przygotuj na czwartek argumenty, dlaczego mielibyśmy rozbudować zespół w Polsce, a nie w Meksyku”. Manager zna swój zespół, zna stawki na polskim rynku i wie, że Meksyk ma jedną przewagę, której nie da się zagadać: ludzie w Guadalajarze zaczynają i kończą pracę mniej więcej wtedy, co ludzie w Teksasie.
Ten artykuł piszemy dla niego — i dla każdego, kto w Polsce prowadzi rozmowę z amerykańskim decydentem o tym, gdzie umieścić zespół inżynierski: dla menedżera polskiego oddziału firmy z centralą w USA, dla CTO polskiej firmy z oddziałem za oceanem i dla szefa delivery, który odpowiada na pytanie klienta „a czemu nie Meksyk?”. Wybraliśmy taką perspektywę świadomie. Polski czytelnik rzadko sam wybiera między Meksykiem a Polską, ale bardzo często musi tę decyzję komuś uczciwie przygotować. A rekomendacja, która udaje, że sześć godzin różnicy nie ma znaczenia, przegrywa w pierwszych pięciu minutach spotkania.
Teza, której bronimy, będzie trochę niewygodna dla obu stron: wybór między Meksykiem a Polską powinien zapadać osobno dla każdego strumienia pracy, na podstawie tego, ile godzin współpracy w czasie rzeczywistym ta praca naprawdę wymaga — a nie jako jedna decyzja krajowa dla całego budżetu inżynierskiego. Przewaga Meksyku we wspólnych godzinach pracy jest realna i duża. Przewagi Polski też są realne, ale procentują tylko w pracy, którą da się zorganizować wokół stałego okna wspólnego czasu. Kto przekonuje centralę, że „Polska jest lepsza do wszystkiego”, traci wiarygodność, gdy pierwszy incydent produkcyjny o 15:00 w Teksasie zastanie polski zespół po pracy.
Zastrzeżenie na wstępie: ARDURA Consulting to polska firma, która dostarcza seniorów z Polski i ma biuro w Nowym Jorku. Mamy oczywisty interes po polskiej stronie tego porównania — dlatego zaczynamy od miejsc, w których wygrywa Meksyk.
Dlaczego pytanie „Meksyk czy Polska” jest źle postawione?
Bo traktuje organizację inżynierską jak jeden blok pracy o jednych potrzebach komunikacyjnych. Tymczasem typowy dział produktowy prowadzi jednocześnie kilka rodzajów pracy: odkrywanie produktu (discovery) z projektantami i product managerami, dostarczanie funkcji z dobrze przygotowanego backlogu, prace platformowe i infrastrukturalne, automatyzację testów, potoki danych, utrzymanie starszego modułu i wsparcie produkcji. Każda z nich potrzebuje innej ilości synchronicznego czasu z ludźmi w USA.
Discovery to praca oparta na rozmowie. Projektant, product manager i dwóch inżynierów, którzy szkicują nowy proces onboardingu, rozmawiają kilka razy dziennie, a każda godzina między pytaniem a odpowiedzią wydłuża cykl. Wsparcie produkcji dla klientów w USA wymaga kogoś, kto jest przytomny i w pracy wtedy, gdy klienci z produktu korzystają. Te dwa strumienie mają mocny argument za Meksykiem albo za inżynierami zatrudnionymi w samych Stanach.
Dostarczanie funkcji z dopracowanego backlogu, migracja z jasną architekturą docelową, program automatyzacji testów czy budowa potoków danych zachowują się inaczej. Potrzebują kilku godzin dobrego kontaktu dziennie — na stand-up, decyzje projektowe, rozmowy przy code review i odblokowywanie — a potem długich okresów skupionej pracy. Takie strumienie mogą świetnie działać przy sześciu godzinach różnicy, pod warunkiem że okno wspólnego czasu jest chronione, a zespół zapisuje ustalenia.
Dlatego pierwsze pytanie nie brzmi „który kraj”, tylko „ile godzin wspólnego czasu potrzebuje każdy strumień pracy i co się stanie z dostarczaniem, jeśli dostanie mniej”. Gdy menedżer ma tę liczbę dla każdego strumienia, pytanie o kraj w dużej mierze rozstrzyga się samo. Ogólne porównanie modeli lokalizacji opisaliśmy w tekście o offshoringu, nearshoringu i onshoringu; tutaj zawężamy temat do jednej konkretnej decyzji amerykańskiej firmy.
Uwaga terminologiczna, przydatna w rozmowie z Amerykanami: z perspektywy USA Polska nie jest „nearshore” w sensie geograficznym. W amerykańskim słowniku nearshore to zwykle Ameryka Łacińska, a Europa Środkowa to offshore z dobrym pokryciem poranka. Lepiej powiedzieć to samemu, niż dać się na tym złapać.
Jak duża jest naprawdę różnica czasu, miesiąc po miesiącu?
Większa niż „jedna godzina” dla Meksyku w niektórych miastach i mniejsza niż „sześć godzin” dla Polski w niektórych tygodniach. Dwa fakty, które prezentacje dostawców często podają nieprecyzyjnie, warto znać dokładnie.
Po pierwsze, Meksyk w większości kraju nie zmienia już czasu. Ustawa przyjęta w październiku 2022 roku zniosła czas letni na poziomie krajowym, z wyjątkiem Baja California i części gmin przy granicy z USA. Ciudad de México, Guadalajara i Monterrey — trzy największe ośrodki technologiczne — są w strefie Zona Centro, UTC-6 przez cały rok. Różnica między Ciudad de México a miastem w USA zmienia się więc wtedy, gdy zmieniają czas Stany, choć Meksyk zegarów nie przestawia.
Po drugie, USA i UE zmieniają czas w innych terminach. Zgodnie z amerykańską ustawą Energy Policy Act z 2005 roku czas letni w USA zaczyna się w drugą niedzielę marca i kończy w pierwszą niedzielę listopada — w 2026 roku 8 marca i 1 listopada. Zgodnie z dyrektywą 2000/84/WE czas letni w Europie zaczyna się w ostatnią niedzielę marca i kończy w ostatnią niedzielę października — w 2026 roku 29 marca i 25 października. Przez około trzy tygodnie w marcu i tydzień na przełomie października i listopada różnica między Warszawą a Nowym Jorkiem wynosi pięć godzin zamiast sześciu. Cykliczne spotkanie ustawione „na 9:00 czasu nowojorskiego” dwa razy w roku przesuwa się w Polsce o godzinę — i to w tych tygodniach najczęściej ktoś nie przychodzi na daily.
Różnica czasu w godzinach — czas lokalny w Warszawie lub Ciudad de México względem miasta w USA:
| Miasto w USA | Warszawa, zima w USA (lis–mar) | Warszawa, lato w USA (mar–paź) | Warszawa, tygodnie przejściowe | Ciudad de México, zima w USA | Ciudad de México, lato w USA |
|---|---|---|---|---|---|
| Nowy Jork (czas wschodni) | Warszawa 6 h do przodu | 6 h do przodu | 5 h do przodu | CDMX 1 h z tyłu | 2 h z tyłu |
| Chicago, Austin (czas centralny) | 7 h do przodu | 7 h do przodu | 6 h do przodu | ta sama godzina | 1 h z tyłu |
| Denver (czas górski) | 8 h do przodu | 8 h do przodu | 7 h do przodu | 1 h do przodu | ta sama godzina |
| San Francisco, Seattle (czas pacyficzny) | 9 h do przodu | 9 h do przodu | 8 h do przodu | 2 h do przodu | 1 h do przodu |
Źródło: obliczenia własne na podstawie powyższych reguł (Ciudad de México UTC-6 przez cały rok; Warszawa UTC+1 zimą i UTC+2 latem; strefy USA od UTC-5 do UTC-8 zimą, latem o godzinę mniej).
Tabela pokazuje przewagę Meksyku bez upiększeń. Dla zespołu w Austin czy Chicago Ciudad de México ma tę samą godzinę albo jest godzinę z tyłu. Dla zespołu w San Francisco jest godzinę lub dwie do przodu — to nadal prawie pełny wspólny dzień pracy. Polska dobrze pasuje do poranka na Wschodnim Wybrzeżu i słabo do Zachodniego. Jeśli kierownictwo inżynierskie siedzi w Kalifornii i oczekuje, że zespół będzie na tych samych spotkaniach każdego popołudnia, Polska jest dla tej pracy złą odpowiedzią — i lepiej, żeby centrala usłyszała to od polskiego menedżera niż odkryła sama.
Co naprawdę daje wspólny czas pracy?
Krótkie pętle informacji zwrotnej. Gdy inżynier w Guadalajarze o 14:00 trafia na niejasność w historyjce, product manager w Chicago może odpowiedzieć o 14:05. Gdy inżynier w Warszawie trafia na tę samą niejasność o 14:00, w Chicago jest 7:00. Jeśli pytania nie dało się przewidzieć, inżynier zgaduje, przełącza się na inne zadanie albo czeka na otwarcie okna. Kilka takich pytań dziennie w pięcioosobowym zespole to prawdziwy koszt odległości.
Wspólny czas to także obecność w momentach, które się liczą: incydent produkcyjny o 15:00 czasu wschodniego, przegląd projektu, który zamienia się w sesję przy tablicy, wdrożenie, przy którym ktoś musi patrzeć na dashboardy razem z amerykańskim dyżurnym. Meksyk daje te momenty z definicji. Polska daje część z nich w oknie i żadnego po jego zamknięciu — chyba że firma zapłaci za przesunięte godziny albo dyżury.
Czego wspólny czas nie daje, to jakości myślenia. Zespół pracujący w tych samych godzinach, który niczego nie zapisuje, przyjmuje niejasne historyjki i wszystkie wyjaśnienia zostawia na spotkania, będzie wolniejszy niż zespół oddalony o sześć godzin, który dokumentuje decyzje, dopracowuje historyjki przed sprintem i wykorzystuje okno na decyzje, a nie na raportowanie statusu. Wspólny czas wzmacnia nawyki zespołu, ale ich nie zastępuje.
To jest sedno argumentu dla centrali: przewaga Meksyku jest rozstrzygająca w pracy, w której pętle zwrotne są krótkie z natury i nie da się ich wydłużyć bez spowolnienia produktu. W pracy, w której pętle można wydłużyć lepszym przygotowaniem, przewaga maleje, a większą wagę zaczynają mieć pozostałe czynniki z tego artykułu.
Które rodzaje pracy wymagają więcej niż czterech godzin wspólnego czasu?
Przydatna reguła: jeśli strumień pracy potrzebuje więcej niż czterech godzin synchronicznego kontaktu dziennie z ludźmi w USA, żeby utrzymać tempo, nie powinien trafić do Polski. Cztery godziny to mniej więcej maksimum, jakie polski zespół może dać Wschodniemu Wybrzeżu bez codziennej pracy wieczorami — a codzienna praca wieczorami to najprostszy sposób na utratę seniorów.
Praca, która zwykle wymaga więcej niż czterech godzin:
- Wczesne discovery i funkcje mocno oparte na projektowaniu. Wymagania zmieniają się w ciągu dnia, decyzje zapadają w rozmowie.
- Wsparcie produkcji dla klientów w godzinach pracy w USA. Jeśli SLA mówi, że senior odpowiada w 30 minut do 18:00 czasu pacyficznego, ludzie na dyżurze muszą wtedy być w pracy i wypoczęci.
- Programowanie w parach lub w grupie z amerykańskimi inżynierami jako domyślny sposób pracy. Niektóre zespoły naprawdę tak pracują; wtedy potrzeba wspólnego czasu jest bliska pełnemu dniu.
- Integracje u klientów i wsparcie sprzedaży, gdy inżynier uczestniczy w rozmowach z klientami z USA.
Praca, która zwykle dobrze działa przy dwóch do czterech godzinach:
- Dostarczanie funkcji z dopracowanego backlogu, ze stand-upem, refinementem i przeglądem w oknie.
- Prace platformowe, DevOps i infrastruktura, gdzie większość wysiłku to skupiona implementacja, a punkty koordynacji są przewidywalne.
- Automatyzacja testów i inżynieria jakości, zwłaszcza gdy zespół podejmuje pracę z poprzedniego dnia w USA i raportuje następnego ranka.
- Inżynieria danych i migracje z jasnym modelem docelowym.
- Modernizacja i utrzymanie dobrze wydzielonych komponentów.
Część pracy wręcz zyskuje na różnicy czasu. Nocne testy regresji, które polski inżynier QA przegląda przed rozpoczęciem dnia w USA, albo code review zrobione, gdy amerykański zespół śpi, skracają czas od commita do merge’a. To prawdziwa korzyść z pracy „za słońcem”, ale tylko tam, gdzie przekazanie pracy jest czyste.
Warto też uczciwie sprawdzić, do której kategorii należy dana praca. Wiele zespołów uważa, że potrzebuje pełnego dnia wspólnego czasu, bo zawsze tak pracowało, a nie dlatego, że praca tego wymaga. Inne nie doceniają, jak wiele doraźnych rozmów zawiera ich proces. Dwutygodniowy przegląd tego, gdzie inżynierowie faktycznie spędzają czas synchroniczny — na spotkaniach, w wątkach na Slacku, w rozmowach — daje centrali lepszą odpowiedź niż intuicja. Polski menedżer, który przyniesie taki pomiar na spotkanie, rozmawia o danych, a nie o preferencjach.
Jak prowadzić zespół z oknem wspólnego czasu dwóch do czterech godzin?
Traktując okno jak rzadki zasób i projektując wokół niego cały dzień. Zespoły, którym to wychodzi, mają kilka wspólnych nawyków.
Ustalić okno na stałe i zapisać je w umowie. „Nakładanie się godzin z USA” to nie zobowiązanie. „Zespół jest dostępny od 9:00 do 12:00 czasu wschodniego w każdy dzień roboczy, także w tygodniach zmiany czasu” — to jest zobowiązanie. ARDURA właśnie dlatego ustala stałe okno wspólnego czasu w każdej współpracy z klientem z USA. Trzeba też opisać, co dzieje się w tygodniach przejściowych w marcu i październiku, gdy różnica wynosi pięć godzin zamiast sześciu.
Sprawdzić arytmetykę każdej obietnicy. Cztery godziny wspólnego czasu z czasem centralnym oznaczają, że zespół w Polsce codziennie pracuje do 20:00 lub dłużej. Da się tak pracować przez jakiś czas, ale trzeba zapytać, jak dostawca utrzyma to bez wypalenia ludzi i czy obietnica obowiązuje także w tygodniach zmiany czasu. Dla menedżera polskiego oddziału to również kwestia uczciwości wobec własnego zespołu: nie warto obiecywać centrali okna, którego ludzie nie wytrzymają przez rok.
Wykorzystywać okno na decyzje, nie na status. Stand-up może być krótki i częściowo asynchroniczny. Cenne użycie wspólnego czasu to dyskusje projektowe, odblokowywanie, wspólna praca nad trudnymi problemami i przeglądy wymagające rozmowy. Zespół, który trzy wspólne godziny wypełnia czterema spotkaniami statusowymi, po prostu je marnuje.
Dopracowywać przed budowaniem. Historyjki, które wchodzą do sprintu z kryteriami akceptacji, przykładami i znanymi zależnościami, wymagają znacznie mniej pytań. Okno obsługuje wtedy wyjątki, a nie rutynę. Ta dyscyplina pomaga też zespołowi w USA.
Dać zespołowi w Polsce prawo do decyzji. Jeśli każdy wybór architektoniczny wymaga zatwierdzenia w USA, zespół połowę dnia czeka. Trzeba ustalić, które decyzje zespół podejmuje sam, o których informuje, a które wymagają akceptacji. Senior tech lead po polskiej stronie z realnymi uprawnieniami jest wart więcej niż dodatkowa godzina wspólnego czasu.
Zapisywać. Rejestry decyzji, krótka pisemna aktualizacja przed otwarciem okna, nagrane sesje projektowe dla nieobecnych. Komunikacja asynchroniczna to umiejętność — warto zapytać dostawcę, jak jej uczy i jak ją sprawdza.
Mieć plan na incydenty. Trzeba z góry zdecydować, kto reaguje na problem produkcyjny o 16:00 czasu wschodniego, gdy dzień w Polsce się skończył: zespół w USA albo płatny dyżur z jasnymi zasadami. Pozostawienie tego bez decyzji to prosta droga od różnicy czasu do awarii.
Jak wygląda porównanie kosztów zrobione porządnie?
Jako całkowity koszt jednostki dostarczonej pracy w horyzoncie co najmniej sześciu miesięcy, a nie porównanie dwóch stawek godzinowych. Stawka w nagłówku oferty to liczba, o którą konkurują dostawcy, i jednocześnie liczba, która najrzadziej decyduje o prawdziwym koszcie.
Punkt odniesienia dla centrali jest amerykański. Według US Bureau of Labor Statistics mediana rocznego wynagrodzenia programistów (software developers) w USA wynosiła w maju 2025 roku 135 980 dolarów. To samo wynagrodzenie — amerykański pracodawca dolicza do niego świadczenia, podatki od wynagrodzeń, sprzęt, koszt rekrutacji i czas menedżerów. Zarówno Meksyk, jak i Polska oferują seniorów o wyraźnie niższym pełnym koszcie niż porównywalny etat w USA, i właśnie dlatego to porównanie w ogóle się toczy.
Po polskiej stronie możemy podać to, co wynika z naszego cennika: senior backend developer w ARDURA kosztuje 1 440–2 080 PLN netto za dzień (co odpowiada skali 180–260 zł/h), a tech lead lub architekt 2 080–2 800 PLN za dzień, bez opłat rekrutacyjnych i bez dodatkowych kosztów. W euro to odpowiednio 335–485 EUR i 485–650 EUR dziennie. Pełna tabela ról jest w cenniku. Przy budżecie liczonym w dolarach trzeba przeliczyć po bieżącym kursie i z góry ustalić, kto ponosi ryzyko kursowe w umowie na rok lub dłużej.
Po meksykańskiej stronie nie podamy liczby. Nie znaleźliśmy nazwanego, datowanego źródła, które porównywałoby stawki seniorów u meksykańskich dostawców w sposób porównywalny, a liczby z blogów dostawców rzadko mają spójną definicję. Możemy natomiast powiedzieć, jak zrobić porównanie uczciwie. Od każdego dostawcy — w Meksyku i w Polsce — trzeba dostać to samo:
- Pełną stawkę dla roli i poziomu, w jednej walucie, z pisemną definicją, co obejmuje.
- Zasady fakturowania: które dni są płatne, co ze świętami, chorobą i urlopem w danym kraju.
- Okres wypowiedzenia i minimalny czas trwania umowy. W ARDURA umowę można zakończyć z 30-dniowym wypowiedzeniem.
- Czas od podpisu do inżyniera produktywnego w repozytorium. Nasz standard to dwa tygodnie.
- Warunki wymiany specjalisty. Dajemy dwutygodniową gwarancję satysfakcji z bezpłatną wymianą oraz wymianę w ciągu pięciu dni roboczych, jeśli specjalista odejdzie.
- Dane o rotacji z ostatnich dwunastu miesięcy dla zamawianych ról. Nasz publikowany wskaźnik to 99% retencji specjalistów.
Następnie prosty model: stawka plus koszt czasu wdrożenia, przemnożone przez oczekiwaną rotację i koszt każdej wymiany (utrata wiedzy, ponowne wdrożenie, wolniejsze sprinty), plus koszt potrzebnego modelu koordynacji — przesunięte godziny, dyżury, podróże. Liczone na sześć i dwanaście miesięcy. Rotacja to zmienna, która najczęściej odwraca wynik porównania stawek; w tekście o rotacji specjalistów w projektach outsourcingowych pokazujemy, jak ją mierzyć i co zapisać w umowie.
Jeszcze jedna pozycja, o której modele zapominają: koszt niedopasowania wspólnego czasu. Jeśli polski zespół dostanie pracę wymagającą sześciu godzin wspólnego czasu, firma zapłaci za to czekaniem, wolniejszymi decyzjami i wieczornymi rozmowami. Jeśli meksykański zespół dostanie pracę, która dobrze działałaby przy trzech godzinach, firma mogła zapłacić za przewagę, której nie wykorzystała. Dopasowanie pracy do lokalizacji to najtańsza oszczędność, jaka jest dostępna. Menedżerom polskich oddziałów, którzy liczą koszt własnego zespołu, przyda się też nasze zestawienie całkowitego kosztu pracodawcy w 2026 roku na UoP, B2B i w body leasingu.
Gdzie w tej decyzji mieści się dostępność kadry?
Ma większe znaczenie, niż sugerują średnie krajowe, bo firma nie zatrudnia kraju, tylko pięć konkretnych osób z konkretnymi umiejętnościami. Oba kraje mają duże zasoby inżynierów, centra badawczo-rozwojowe międzynarodowych firm i dojrzały rynek dostawców. Użyteczne pytanie jest węższe: czy ten dostawca pokaże mocnych seniorów w naszym stosie, w naszym terminie, którzy zostaną na dłużej?
Niektóre technologie i domeny są głębiej obsadzone na jednym rynku niż na drugim, a uczciwy sposób, żeby to sprawdzić, to test, a nie slajd. Każdy dostawca z krótkiej listy dostaje ten sam profil roli, na przykład „senior Java z Kafką i architekturą zdarzeniową, domena fintech, dostępny za cztery tygodnie”, a potem porównuje się, co wraca: ilu kandydatów, jak mocnych, jak szybko i ilu przechodzi rozmowę techniczną. Taki dwutygodniowy test mówi więcej niż raport rynkowy — i jest argumentem, który centrala w USA przyjmie, bo sama może go powtórzyć.
W Polsce najgłębsze zasoby są w Javie, .NET, JavaScripcie i TypeScripcie, Pythonie, chmurze i DevOps oraz inżynierii jakości, skupione w Warszawie, Krakowie, Wrocławiu, Trójmieście i Poznaniu. Polska jest też mocną opcją, gdy potrzebni są ludzie pracujący na co dzień w reżimie regulacji UE — przy systemach objętych RODO albo w unijnych usługach finansowych — bo przynoszą ten kontekst ze sobą.
Najmocniejszym argumentem Meksyku nie jest konkretna technologia, tylko połączenie wspólnego czasu i bliskości: inżynierowie, którzy wchodzą w amerykański dzień pracy i mogą dolecieć do biura w kilka godzin. Jeśli praca opiera się na współpracy, nieco krótsza lista kandydatów w dokładnie naszym stosie może nadal być lepszym wyborem.
Nie należy też zakładać, że „senior” znaczy to samo u różnych dostawców. Trzeba zapytać o lata doświadczenia, zakres dotychczasowej odpowiedzialności i rozmowę techniczną, której dostawca używa — a potem i tak przeprowadzić własną.
Czym różnią się ryzyka prawne w Meksyku i w Polsce?
Oba kraje są legalnym, ugruntowanym miejscem zakupu usług inżynierskich. Ryzyka mają różny kształt, a menedżer przygotowujący rekomendację powinien wiedzieć, jakie pytania wysłać do prawników, zanim umowa do nich trafi.
Meksyk: rejestr usług wyspecjalizowanych. Meksykańskie prawo pracy ogranicza podwykonawstwo polegające na udostępnianiu personelu i dopuszcza świadczenie usług wyspecjalizowanych na warunkach z art. 13 i 15 Ley Federal del Trabajo. Dostawcy, którzy oddają własnych pracowników do dyspozycji podmiotu trzeciego w ramach usług wyspecjalizowanych, muszą być wpisani do REPSE — rejestru prowadzonego przez Secretaría del Trabajo y Previsión Social. Czy i jak dotyczy to konkretnej umowy, zależy od struktury: amerykańska firma kupująca usługi transgranicznie od meksykańskiego dostawcy jest w innej sytuacji niż amerykańska spółka zależna w Meksyku korzystająca z lokalnej agencji. Trzeba zapytać dostawcę o status w REPSE, a meksykańskiego prawnika — o zastosowanie do danej struktury.
Meksyk: dane osobowe. 20 marca 2025 roku Meksyk ogłosił nowe ustawy o przejrzystości i ochronie danych osobowych, a federalny instytut ochrony danych INAI został zlikwidowany; jego funkcje przejął organ w ramach Sekretariatu ds. Walki z Korupcją i Dobrego Rządzenia. Jeśli zespół w Meksyku ma przetwarzać dane osobowe, trzeba sprawdzić, czy praktyki dostawcy odpowiadają obecnej ustawie i obecnemu organowi nadzorczemu, a nie stanowi sprzed 2025 roku.
Meksyk: ramy handlowe. Umowa USMCA, obowiązująca od 1 lipca 2020 roku, ma rozdział o handlu cyfrowym i wbudowany mechanizm przeglądu: zgodnie z art. 34.7 strony przeprowadzają wspólny przegląd w szóstą rocznicę wejścia w życie i potwierdzają, czy chcą przedłużyć umowę na kolejne 16 lat; jeśli któraś nie potwierdzi, przeglądy stają się coroczne. Przy wieloletnim zobowiązaniu inżynierskim warto poprosić dział prawny centrali o aktualny stan tego przeglądu, zamiast zakładać którykolwiek wynik.
Polska: dostawcę obejmuje RODO. RODO stosuje się do przetwarzania w związku z działalnością jednostki organizacyjnej administratora lub podmiotu przetwarzającego w UE, więc polski dostawca przetwarzający dane osobowe dla amerykańskiej firmy robi to z obowiązkami podmiotu przetwarzającego, niezależnie od tego, kto jest administratorem. Dla firm z USA, które mają klientów w Europie, to przewaga: zespół już pracuje w regułach, których musi przestrzegać ich europejski biznes. Dla produktu działającego tylko w USA to głównie dodatkowa dokumentacja, którą kompetentny dostawca obsługuje standardową umową powierzenia. Jeśli dane osobowe płyną z UE do systemów w USA, EU-US Data Privacy Framework na podstawie decyzji Komisji Europejskiej stwierdzającej odpowiedni stopień ochrony z 10 lipca 2023 roku pozwala na transfer do certyfikowanych organizacji w USA; trzeba sprawdzić, czy firma ma certyfikację, albo zastosować standardowe klauzule umowne.
Polska: struktura zatrudnienia. Wielu polskich seniorów pracuje jako samozatrudnieni na kontrakcie B2B, a nie na etacie. To legalne i powszechne, ale zmienia domyślną własność efektów pracy — o czym w kolejnej sekcji. Amerykańska centrala często o tym nie wie, a polski menedżer powinien to powiedzieć wprost.
Wymagania bezpieczeństwa to osobna kwestia, niezależna od geografii, i powinny być identyczne w obu krajach: kontrola dostępu, polityka urządzeń, zarządzanie sekretami, bezpieczne wytwarzanie. Listę opisaliśmy w tekście o security by design i zero trust w wymaganiach wobec dostawcy.
Do kogo należy kod i dlaczego umowa musi mówić to wprost?
Bo domyślne reguły w obu krajach nie odpowiadają domyślnemu założeniu amerykańskiego kupującego. Amerykańskie firmy są przyzwyczajone do formuły „work made for hire” i szerokich klauzul przeniesienia praw. Te nawyki nie przenoszą się automatycznie.
W Polsce ustawa o prawie autorskim i prawach pokrewnych chroni programy komputerowe jak utwory. Art. 74 ust. 3 przyznaje prawa majątkowe do programu stworzonego przez pracownika w ramach obowiązków ze stosunku pracy pracodawcy, o ile umowa nie stanowi inaczej. Ta reguła dotyczy jednak pracowników. Przy oprogramowaniu pisanym przez kontraktora na B2B prawa trzeba przenieść umową, a obowiązują dwa wymogi formalne: zgodnie z art. 53 umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności, a zgodnie z art. 41 ust. 2 obejmuje tylko pola eksploatacji wyraźnie w niej wymienione. Jednozdaniowa klauzula „all IP belongs to the client” w anglojęzycznej umowie ramowej może nie działać tak, jak zakłada centrala.
Praktyczna odpowiedź to łańcuch przeniesień, który trzyma się na każdym ogniwie: od inżyniera do dostawcy, na piśmie, z wymienionymi polami eksploatacji, i od dostawcy do klienta w ten sam sposób. Warto poprosić dostawcę o klauzulę, której używa z własnymi kontraktorami, a nie tylko o tę z umowy z klientem. Dla menedżera polskiego oddziału to także dobry moment, żeby sprawdzić umowy własnego zespołu B2B.
W Meksyku obowiązuje ta sama zasada: trzeba sprawdzić, jak prawa przechodzą od każdego inżyniera do dostawcy i od dostawcy do klienta według prawa meksykańskiego, i dać klauzulę do potwierdzenia meksykańskiemu prawnikowi. Nie streszczamy tu meksykańskiego prawa autorskiego, bo streszczenie to nie jest to, na czym chce się polegać, gdy chodzi o własność kluczowego produktu.
Jak podróże, kultura pracy i język wpływają na codzienną współpracę?
Mniej, niż twierdzą dostawcy po obu stronach, i w kilku konkretnych sprawach, które mają znaczenie.
Podróże to wyraźna przewaga Meksyku. Loty z głównych meksykańskich ośrodków technologicznych do miast w USA są krótkie, a zespół może przyjechać do biura na tydzień planowania bez przelotu przez ocean. Jeśli firma oczekuje kwartalnych spotkań na miejscu albo praca dotyczy sprzętu, magazynu czy lokalizacji klienta w USA, bliskość ma wartość. Podróż z Polski na Wschodnie Wybrzeże to lot dalekodystansowy i adaptacja do zmiany czasu — wystarcza na okazjonalne tygodnie wdrożeniowe i kwartalne planowanie, ale nie na częste wizyty doraźne.
Język rzadko jest problemem na poziomie seniorskim w którymkolwiek z krajów. Seniorzy, o których mowa, pracują po angielsku na co dzień, czytają tę samą dokumentację i używają tych samych narzędzi. Warto to sprawdzić na rozmowie: poprosić kandydata o wyjaśnienie dawnej decyzji projektowej i jej kompromisów i posłuchać, czy potrafi jasno się nie zgodzić. To ważniejsze niż akcent.
Różnice w kulturze pracy dotyczą bardziej ludzi i dostawców niż narodów. Jedni inżynierowie powiedzą wprost, że plan nie zadziała; inni spróbują, żeby zadziałał, i powiedzą później. Jedne zespoły eskalują wcześnie, inne rozwiązują po cichu. Nie trzeba teorii kultur narodowych, żeby tym zarządzać. Trzeba jawnych oczekiwań: kiedy zgłaszać ryzyko, jak się nie zgadzać na przeglądzie projektu, co znaczy „zrobione”. Spisać je w pierwszym tygodniu i wrócić do nich na pierwszej retrospektywie. Polskim zespołom pracującym z Amerykanami często przydaje się jedna uwaga: amerykański rozmówca może odebrać bezpośrednie „to nie zadziała” bez propozycji alternatywy jako brak zaangażowania — warto od razu dodawać, co zadziała.
O co zapytać dostawcę w obu krajach przed podpisaniem umowy?
O to samo, żeby odpowiedzi dało się porównać. Poniższa macierz decyzyjna łączy pytanie o wspólny czas z kosztami, prawem i dostępnością kadry. Można ją położyć na stole w rozmowie z centralą.
| Kryterium | Przemawia za Meksykiem | Przemawia za Polską | Pytanie do każdego dostawcy |
|---|---|---|---|
| Godziny synchroniczne potrzebne w strumieniu pracy | Ponad 4 godziny dziennie | 2–4 godziny dziennie, w stałym oknie | „W jakich godzinach mojej strefy zespół będzie dostępny, także w marcu i październiku?” |
| Gdzie siedzi kierownictwo inżynierskie | Czas centralny, górski lub pacyficzny | Czas wschodni albo kierownictwo akceptujące poranne okno | „Kto po waszej stronie ma prawo do decyzji poza wspólnymi godzinami?” |
| Wsparcie produkcji w godzinach pracy w USA | Wymagane przez większość dnia w USA | Pokrywa je zespół w USA albo zdefiniowany dyżur | „Ile kosztuje dyżur i jak jest obsadzony?” |
| Klienci i regulacje | Produkt tylko na rynek USA, dane w USA | Klienci w UE, ekspozycja na RODO, regulacje finansowe lub medyczne UE | „W jakich środowiskach regulowanych pracowali wasi inżynierowie?” |
| Potrzeba spotkań na miejscu | Częste wizyty lub praca fizyczna w USA | Wizyty kwartalne lub okazjonalne | „Kto płaci za podróże i jak często inżynierowie odwiedzają klientów?” |
| Głębia kadry w danym stosie | Test krótkiej listy pokazuje mocnych kandydatów | Test krótkiej listy pokazuje mocnych kandydatów | „Pokażcie trzech kandydatów na dokładnie ten profil w dziesięć dni.” |
| Warunki umowy | Porównanie według tych samych definicji | Porównanie według tych samych definicji | „Definicja stawki, wypowiedzenie, czas wdrożenia, wymiana, rotacja z 12 miesięcy?” |
| Łańcuch praw IP | Meksykański prawnik potwierdza przeniesienie | Pisemne przeniesienie z polami eksploatacji | „Pokażcie klauzulę IP, której używacie z własnymi inżynierami.” |
| Rejestracje i dane | Status w REPSE, aktualne prawo o danych | Umowa powierzenia wg RODO, mechanizm transferu | „Jakie rejestracje i umowy o danych podpiszecie?” |
Dwie dodatkowe kontrole. Po pierwsze, referencje od klientów z tego samego regionu USA — z pytaniem wprost o wspólny czas: czy był dotrzymywany i co działo się przy zmianach czasu. Po drugie, pytanie, co się dzieje w pierwszych dwóch tygodniach, jeśli inżynier się nie sprawdza. Dostawca, który ma jasną odpowiedź, robił to wcześniej. Przy wyborze i późniejszym prowadzeniu kilku dostawców przydaje się uporządkowane zarządzanie dostawcami.
Kiedy właściwą odpowiedzią jest zespół podzielony między Meksyk a Polskę?
Częściej, niż zasugeruje którykolwiek z dostawców — w organizacjach na tyle dużych, żeby prowadzić dwa zespoły z wyraźną granicą między nimi. Firma z 40 inżynierami może umieścić zespoły funkcji produktowych i wsparcie w Meksyku, blisko amerykańskich product managerów, a inżynierię platformy, automatyzację testów i inżynierię danych w Polsce, gdzie praca mieści się w stałym oknie, a kadra seniorów w tych specjalizacjach jest mocna.
Podział działa, gdy granica jest interfejsem, a nie przekazaniem. Dwa zespoły, z których każdy odpowiada za usługę lub zdolność, z udokumentowanymi API i własnymi backlogami, mogą pracować w różnych strefach bez wchodzenia sobie w drogę. Dwa zespoły, które przerzucają tę samą historyjkę przez osiem godzin różnicy czasu, mnożą koszt koordynacji, którego chciano uniknąć.
Dla małego zespołu podział to zły pomysł. Poniżej mniej więcej dziesięciu inżynierów poza USA narzut dwóch dostawców, dwóch umów, dwóch procesów wdrożenia i dwóch zestawów rytuałów zwykle przewyższa korzyść. Wtedy lepiej wybrać lokalizację pasującą do strumienia najbardziej zależnego od wspólnego czasu i zorganizować wokół niej resztę.
Przy podziale trzeba zdecydować, który zespół odpowiada za pracę nocną. Testy, ładowanie danych i wdrożenia zaplanowane poza godzinami pracy w USA mogą być przeglądane przez polski zespół, zanim zacznie się amerykański dzień — wtedy różnica czasu skraca cykl, zamiast go wydłużać. Dla polskiego menedżera to często najmocniejszy argument: nie „jesteśmy tańsi”, tylko „przejmujemy te strumienie, w których różnica czasu pracuje na waszą korzyść”.
Jakie są kluczowe wnioski przed rozmową z centralą w USA?
Meksyk i Polska to wiarygodne miejsca na zespół inżynierski dla firmy z USA. Wiarygodne do innej pracy — a błąd, którego trzeba uniknąć, to traktowanie decyzji jako jednego wyboru kraju na podstawie stawek.
Sześć punktów na czwartkowe spotkanie:
- Decydować osobno dla każdego strumienia pracy. Oszacować, ile godzin dziennie synchronicznego kontaktu z USA potrzebuje każdy strumień. Ponad cztery — Meksyk albo zespół w USA; dwie do czterech w stałym oknie — tu konkuruje Polska.
- Szanować arytmetykę zegarów. Ciudad de México ma UTC-6 przez cały rok. Warszawa jest sześć godzin przed Nowym Jorkiem, siedem przed Chicago i dziewięć przed Kalifornią, a w tygodniach zmiany czasu w marcu i październiku pięć przed Nowym Jorkiem. Przy kierownictwie na Zachodnim Wybrzeżu Polska słabo pasuje do pracy opartej na współpracy — i warto to powiedzieć pierwszemu.
- Porównywać pełny koszt jednostki pracy, nie stawki. Te same definicje u każdego dostawcy, czas wdrożenia, rotacja i model koordynacji, horyzont 6–12 miesięcy.
- Sprawdzić dostępność kadry na prawdziwym profilu roli. Ten sam profil dla każdego dostawcy i porównanie wyników po dziesięciu dniach.
- Wcześnie wysłać właściwe pytania prawne. Status w REPSE i aktualne prawo o danych w Meksyku; umowa powierzenia, mechanizm transferu i pisemny łańcuch praw IP w Polsce.
- Rozważyć podział tylko przy odpowiedniej skali, z wyraźną granicą opartą na interfejsach.
Jeśli część planu Twojej firmy mieści się w stałym oknie wspólnego czasu ze Wschodnim Wybrzeżem — prace platformowe, automatyzacja testów, inżynieria danych, dostarczanie z dopracowanego backlogu — ARDURA może ją obsadzić seniorami z Polski w modelu body leasingu: dwa tygodnie do wdrożenia, stałe okno wspólnego czasu zapisane w umowie, dwutygodniowa gwarancja satysfakcji, wymiana w pięć dni roboczych i lokalny punkt kontaktu w naszym biurze w Nowym Jorku. Zobacz, jak działa nearshoring IT z Polski, albo umów rozmowę i przynieś listę strumieni pracy — powiemy, które naszym zdaniem pasują do Polski, a które nie.