20 osób kontra 400-osobowe IT
Znam zespół kilkunastu osób, który dowozi dziś więcej realnej wartości biznesowej niż cały kilkusetosobowy dział IT działający obok niego.
Nie dlatego, że pracują tam lepsi inżynierowie. Nie dlatego, że mają lepsze modele AI. Nie dlatego, że dostali większy budżet.
Różnica polega przede wszystkim na tym, jak ten zespół został zorganizowany.
Obok klasycznego, kilkusetosobowego działu IT działa niewielka grupa licząca około dwudziestu osób. Sami mówią o sobie: piraci.
Co ciekawe, mniej więcej jedna trzecia z nich nie jest nawet zawodowymi programistami. Są tam ludzie z biznesu, product, operations, danych, automatyzacji i technologii.
Działy biznesowe ich uwielbiają. Powód jest prosty: rzeczy, na które wcześniej czekało się miesiącami, zaczynają pojawiać się na produkcji po kilku tygodniach.
Ten model nazywam Statkiem Pirackim.
Dlaczego transformacja typu „zawracamy tankowiec” tak często grzęźnie
Większość dużych organizacji próbuje dziś wdrażać AI w sposób, w jaki prowadziła wcześniejsze transformacje technologiczne.
Powstaje steering committee, strategia AI, polityka bezpieczeństwa, governance framework, lista zatwierdzonych narzędzi, roadmapa, seria warsztatów i prezentacja dla zarządu.
Każdy z tych elementów może mieć sens. Problem zaczyna się wtedy, gdy po trzech miesiącach organizacja posiada 50-stronicową politykę AI, kilkanaście spotkań w kalendarzu i zero rzeczy działających na produkcji.
To klasyczny model zawracania tankowca.
Tankowiec ma tysiące zależności, stare systemy, procurement, security, compliance, architekturę enterprise, zespoły odpowiedzialne za poszczególne fragmenty systemu i wieloletni backlog.
Nie skręca szybko. I nie powinien.
Duża organizacja potrzebuje stabilności. Problem polega na tym, że innowacja potrzebuje dokładnie przeciwnego środowiska: małych pętli decyzyjnych, szybkiej informacji zwrotnej, bezpośredniego dostępu do sponsora i odpowiedzialności za rezultat.
Czym jest Statek Piracki?
Statek Piracki to mały, interdyscyplinarny zespół działający obok głównej organizacji technologicznej. Nie przeciwko niej. Obok niej.
Jego zadaniem nie jest zastąpić enterprise IT. Jego zadaniem jest szybko przetestować nowy model działania, zbudować pierwsze rozwiązania produkcyjne i pokazać, gdzie istnieje realna wartość.
1. Jest mały
Najczęściej kilkanaście lub kilkadziesiąt osób. Wystarczająco mało, aby wszyscy rozumieli cel, kontekst i aktualny stan pracy.
2. Jest interdyscyplinarny
Nie składa się wyłącznie z programistów. Może zawierać inżynierów, product, operations, UX, analityków, domain experts i ludzi biznesu.
W transformacji AI to kluczowe, ponieważ największa wartość powstaje zwykle na styku technologii i rzeczywistego procesu biznesowego.
3. Ma sponsora w zarządzie
Statek Piracki nie może raportować przez siedem poziomów organizacji. Potrzebuje ochronnego parasola. Najczęściej bezpośrednio CEO, COO, CTO lub członka zarządu odpowiedzialnego za transformację.
Sponsor nie powinien zarządzać zespołem operacyjnie. Powinien usuwać blokady i chronić zespół przed wciągnięciem w mechanikę procesów, które zostały zaprojektowane dla innego typu pracy.
4. Ma prawo działać szybciej
Nie oznacza to ignorowania bezpieczeństwa, prawa czy architektury. Oznacza możliwość działania poza pełnym procesem przeznaczonym dla zmian w krytycznych systemach core.
Jeżeli każdy eksperyment AI musi przejść ten sam proces co zmiana w SAP-ie obsługującym miliardy złotych sprzedaży, innowacja przegrywa jeszcze przed pierwszym wdrożeniem.
Stare IT nadal zostaje source of truth
To najważniejsze rozróżnienie w całym modelu.
Statek Piracki nie zakłada, że stare IT jest złe i należy je ominąć.
Klasyczne IT nadal pozostaje source of truth. Tam znajduje się SAP, ERP, CRM, identity, dane, infrastruktura, bezpieczeństwo i procesy krytyczne.
Piraci nie muszą tego zastępować. Ich zadaniem jest budowanie nowej warstwy wartości na istniejącej organizacji.
Najprostsza architektura wygląda tak:
- Core Enterprise IT — systemy prawdy i krytyczne procesy.
- Controlled Access Layer — API, eventy, read models, uprawnienia.
- Pirate Ship — AI agents, automatyzacje, nowe workflowy i internal products.
- Business — użytkownicy, operacje i wynik biznesowy.
Statek Piracki nie zatapia tankowca. Wypływa przed niego i sprawdza, gdzie właściwie powinniśmy płynąć.
Piracka flaga nie jest nowym pomysłem
Podczas prac nad pierwszym Macintoshem mały zespół Apple funkcjonował jako wyraźnie odrębna grupa. Piracka flaga zawieszona nad budynkiem stała się symbolem niezależności i innego sposobu pracy.
Najważniejsza lekcja nie polega jednak na romantyzowaniu buntu. Chodzi o stworzenie środowiska, w którym niewielka grupa może skupić się na nowym modelu produktu bez pełnego ciężaru organizacji zbudowanej do utrzymywania istniejącego biznesu.
Widzieliśmy ten sam schemat przy narodzinach e-commerce
Dwie dekady temu podobny konflikt pojawiał się wokół sprzedaży online.
Sprzedaż widziała kanibalizację sklepów. Logistyka widziała pojedyncze paczki zamiast palet. IT widziało kolejny system do utrzymywania, często zbudowany w technologiach, które nie pasowały do ówczesnych standardów enterprise.
Mądre zarządy tworzyły małe, niezależne działy e-commerce z własnymi celami, budżetem, zespołem i tempem pracy.
Dopóki online odpowiadał za 1% sprzedaży, pytano, czy ma sens. Kiedy dochodził do 10%, pytanie zmieniało się na: jak możemy go skalować szybciej?
Z AI dzieje się dziś coś bardzo podobnego.
AI jest dzisiaj w podobnym miejscu jak e-commerce dwadzieścia lat temu
Wszyscy widzą zmianę, ale istniejące działy patrzą na nią przez własne modele odpowiedzialności.
- IT widzi security, architecture i vendor risk.
- HR widzi kompetencje, stanowiska i odpowiedzialność.
- Legal widzi dane, IP i compliance.
- Biznes widzi szybsze procesy, niższy koszt i nowe możliwości.
Każda z tych perspektyw jest prawidłowa. Problem pojawia się wtedy, gdy wszystkie muszą zostać w pełni uzgodnione przed pierwszym wdrożeniem.
Wtedy organizacja może przez rok „transformować się w AI”, nie zmieniając żadnego realnego procesu.
Dlaczego AI wzmacnia przewagę małych zespołów
AI radykalnie zwiększa leverage małych zespołów.
Jeszcze kilka lat temu niewielka grupa potrzebowała osobnych developerów frontend, backend, QA, DevOps, analityków i rozbudowanego project managementu.
Dziś część tej pracy może zostać skompresowana przez coding agents, AI-assisted testing, generowanie dokumentacji, automatyczny research, workflow automation, AI analytics i infrastructure automation.
To nie oznacza, że wszystkie role znikają. Oznacza, że 12–20 bardzo dobrze dobranych osób może dziś przetestować znacznie większą liczbę hipotez i szybciej przejść od problemu do produkcji.
Dlaczego część piratów nie powinna być programistami
Transformacja AI nie jest wyłącznie problemem software engineeringu. Jest problemem redesignu pracy.
Najważniejsze pytania brzmią:
- Gdzie tracimy czas?
- Która decyzja jest wykonywana ręcznie?
- Gdzie ludzie przenoszą informacje między systemami?
- Gdzie wiedza żyje tylko w głowach pracowników?
- Który proces istnieje tylko dlatego, że systemy się ze sobą nie komunikują?
- Który manager jest w praktyce ludzkim API pomiędzy działami?
Najlepszą osobą do znalezienia takiego problemu często nie jest developer. Jest nią ktoś, kto wykonuje ten proces od dziesięciu lat.
Dlatego dobry Pirate Ship może łączyć engineerów, operations experts, product people, domain experts i AI-native builders.
Pirate Ship Operating Model™
Model Statku Pirackiego można opisać poprzez sześć zasad:
- Executive Sponsorship — bezpośrednia ochrona sponsora z zarządu.
- Small Cross-Functional Crew — mały zespół łączący technologię i domenę.
- Controlled Access to Core — dostęp do danych i systemów przez zdefiniowane interfejsy.
- Production First — celem jest realne użycie, nie kolejna prezentacja.
- Outcome Ownership — zespół odpowiada za wynik biznesowy, nie tylko dostarczenie artefaktu.
- Scale After Proof — standaryzacja następuje po potwierdzeniu wartości, a nie przed nim.
90-Day Pirate Ship Test™
Po 90 dniach transformacji AI powinniśmy móc odpowiedzieć na proste pytanie: co działa na produkcji?
Dobry Statek Piracki po trzech miesiącach powinien posiadać:
- kilka zweryfikowanych use case'ów,
- co najmniej jeden działający system lub workflow,
- prawdziwych użytkowników,
- pierwsze dane produkcyjne,
- listę rzeczy, które nie zadziałały,
- backlog kolejnych iteracji.
Typowy program „zawracamy tankowiec” może po tym samym czasie posiadać politykę AI, governance framework, listę vendorów, program szkoleniowy i serię prezentacji — ale nadal zero produkcji.
Polityki, governance i security są potrzebne. Powinny jednak powstawać w kontakcie z rzeczywistym wdrożeniem, a nie jako substytut wdrożenia.
Time to Production jako jedna z kluczowych metryk transformacji
W pierwszych miesiącach jedną z najważniejszych metryk powinno być Time to Production.
Nie liczba warsztatów, pomysłów, PoC, licencji Copilot ani przeszkolonych pracowników.
Tylko czas potrzebny, aby przejść od problemu biznesowego do rozwiązania używanego w prawdziwym procesie.
Jeżeli po trzech miesiącach nic nie działa na produkcji, warto zapytać: czy rzeczywiście transformujemy firmę, czy tylko zarządzamy transformacją?
Piraci również mogą zatonąć
Model ma poważne ryzyka. Autonomia bez granic może stworzyć shadow IT, security debt, duplikację danych, systemy bez właściciela, techniczny chaos i krytyczne procesy zależne od kilku osób.
Dlatego autonomia nie może oznaczać anarchii.
Dojrzały model łączy:
- freedom to build,
- clear architectural boundaries,
- controlled access to core systems,
- production ownership,
- observability,
- security guardrails,
- exit and integration criteria.
Kiedy Statek Piracki powinien wrócić do portu?
Nie każdy eksperyment powinien na zawsze pozostać poza główną organizacją.
1. Integracja
Udowodnione rozwiązanie staje się częścią głównej platformy lub standardowego portfolio IT.
2. Internal Product
Pirate team zachowuje ownership i rozwija rozwiązanie jako wewnętrzną platformę dla większej liczby działów.
3. Nowa jednostka
Jeżeli obszar staje się strategiczny, eksperymentalny zespół może stać się fundamentem nowej funkcji organizacyjnej — tak jak kiedyś działo się z e-commerce.
Pirate Ship Maturity Model™
- Stage 0 — Debate: AI istnieje głównie w prezentacjach i dyskusjach.
- Stage 1 — Pirate Ship: powstaje mały, autonomiczny zespół.
- Stage 2 — Production Proof: pierwsze workflowy i produkty działają produkcyjnie.
- Stage 3 — Business Pull: inne działy zaczynają same prosić o podobne rozwiązania.
- Stage 4 — Platformization: udowodnione wzorce trafiają do wspólnej infrastruktury.
- Stage 5 — Organizational Redesign: organizacja przeprojektowuje całe procesy wokół nowych możliwości AI.
Stage 5 jest prawdziwą transformacją. Nie rollout narzędzia. Nie licencja. Nie polityka. Zmiana sposobu działania organizacji.
Największy błąd: próbować od razu zmienić całą firmę
Duże organizacje często rozpoczynają od pytania: jak wdrożyć AI dla 10 000 pracowników?
Lepsze pytanie brzmi:
Jaki jeden proces możemy przebudować tak dobrze, aby 10 000 osób samo chciało podobnej zmiany?
Transformacja technologiczna rzadko zaczyna się od masowego rolloutu. Najpierw musi powstać przykład, który działa, pokazuje nową możliwość i buduje business pull.
Co mierzyć zamiast „adopcji AI”
Same logowania do narzędzi AI niewiele mówią o transformacji. Lepsze metryki to:
- Time to Production,
- czas procesu przed i po zmianie,
- liczba ręcznych handoffów usuniętych z workflowu,
- liczba decyzji wspieranych przez aktualny kontekst,
- częstotliwość użycia rozwiązania przez biznes,
- business pull z innych działów,
- udział wdrożeń, które przeszły z eksperymentu do trwałego ownershipu.
Executive checklist: czy potrzebujesz Statku Pirackiego?
- Czy transformacja AI od miesięcy istnieje głównie w prezentacjach?
- Czy biznes czeka na automatyzacje znacznie dłużej niż oczekuje?
- Czy każde AI use case przechodzi ten sam proces co zmiana w systemie core?
- Czy istnieje sponsor z zarządu gotowy usuwać blokady?
- Czy możemy bezpiecznie wystawić dane i funkcje core przez API lub eventy?
- Czy potrafimy wskazać 3–5 procesów z wysoką wartością i niskim ryzykiem startowym?
- Czy zespół może odpowiadać za rezultat end-to-end?
- Czy istnieją jasne kryteria przejścia z eksperymentu do platformizacji?
Nie wygrywa technologia. Wygrywa nowy model działania
Historia e-commerce jest dobrym ostrzeżeniem. Firmy, które patrzyły na internet jak na kolejny projekt IT, długo dyskutowały o integracji. Firmy, które zobaczyły nowy kanał biznesowy, budowały nowe organizacje.
Z AI będzie podobnie.
Największą przewagę nie uzyskają firmy, które jako pierwsze kupią Copilota, kolejny model, agenta albo platformę automatyzacji.
Uzyskają ją firmy, które jako pierwsze nauczą się organizować pracę inaczej.
Po czym poznać, że transformacja AI płynie w dobrą stronę?
Po bardzo prostym sygnale.
Po trzech miesiącach powinno istnieć coś, czego wcześniej nie było: proces, produkt, agent, automatyzacja albo nowy workflow. I powinien korzystać z tego prawdziwy użytkownik.
Jeżeli po trzech miesiącach powstała głównie kolejna seria spotkań, roadmap i dokument polityki AI na 50 stron, być może nie transformujecie organizacji.
Być może po prostu próbujecie zawrócić tankowiec.
A czasami znacznie rozsądniej jest zrobić coś prostszego:
Zwodować Statek Piracki.
Softech POV
W Softech patrzymy na transformację AI jako na problem projektowania systemu działania, a nie wyboru pojedynczego narzędzia. Mały, interdyscyplinarny zespół może szybko przejść od procesu biznesowego do działającego rozwiązania, wykorzystując istniejące systemy enterprise jako source of truth i budując nad nimi nową warstwę AI-native workflows.
W pierwszej fazie transformacji nie trzeba jeszcze zawracać całego tankowca. Najpierw trzeba pokazać, dokąd warto płynąć.