Pragmatycznie o...

Jeszcze kilka lat temu doświadczenie w popularnej technologii i dobrze przygotowane CV często wystarczały, żeby regularnie otrzymywać zaproszenia na rozmowy rekrutacyjne. Dzisiaj sytuacja wygląda inaczej.Firmy ostrożniej zatrudniają, kandydaci mierzą się z większą konkurencją, a znajomość technologii coraz częściej jest tylko punktem wyjścia do rozmowy o pracy.Czy oznacza to, że branża IT przeżywa kryzys? A może po latach intensywnego wzrostu rynek po prostu wraca do równowagi?W najnowszym odcinku podcastu „Pragmatycznie o…” Wiktor Żołnowski rozmawia z czterema ekspertami, którzy patrzą na rynek z perspektywy rekrutacji, zarządzania zespołami technologicznymi i współpracy z biznesem:* Weronika Hebda z InPost* Rafał Wywioł z Keepit* Bartosz Śliwa z Euvic* Luiza Lipień z Agile StudioIch obserwacje pokazują, że zmiany na rynku pracy IT nie sprowadzają się do mniejszej liczby ofert czy rosnącego wpływu AI. Zmienia się również to, jak firmy definiują wartościowego specjalistę.Poprzeczka niekoniecznie jest wyżej. Jest w innym miejscu.Przez lata w rekrutacji developerów duże znaczenie miała znajomość konkretnych technologii, frameworków i języków programowania.Te umiejętności nadal są potrzebne. Coraz częściej jednak nie wystarczają.Od dobrego inżyniera oczekuje się dziś nie tylko implementacji rozwiązania, ale również zrozumienia, dlaczego w ogóle warto je zbudować.W praktyce oznacza to umiejętność zadawania właściwych pytań, rozumienia ograniczeń biznesowych, podejmowania decyzji technicznych i współpracy z ludźmi o różnych kompetencjach.Wartość developera nie kończy się na działającym kodzie. Zaczyna się od problemu, który ten kod ma rozwiązać.To istotna zmiana także dla osób, które od lat pracują w branży i nie planują zmiany pracodawcy.AI zmienia sposób pracy, ale nie zastępuje odpowiedzialnościW rozmowach z ekspertami pojawia się ciekawa różnica podejść.Niektóre firmy sprawdzają dziś, jak kandydaci korzystają z AI podczas zadań technicznych. Inne doceniają znajomość tych narzędzi, ale nie traktują jej jako czynnika decydującego o zatrudnieniu.Trudno więc mówić o jednym standardzie obowiązującym na całym rynku.Jedna rzecz wydaje się jednak coraz ważniejsza: umiejętność świadomego wykorzystania narzędzi, a nie samo deklarowanie ich znajomości.Developer, który potrafi wygenerować kod, ale nie umie ocenić jego jakości, zrozumieć konsekwencji architektonicznych czy zweryfikować rozwiązania, niekoniecznie wnosi więcej wartości do zespołu.Podobny problem pojawia się na poziomie całych organizacji.W przywoływanym w odcinku raporcie DORA 2025 AI jest przedstawiane jako czynnik wzmacniający istniejące możliwości organizacji. Jeśli procesy działają dobrze, może pomagać zwiększać ich efektywność. Jeśli są chaotyczne, może również potęgować problemy.Samo wdrożenie narzędzia nie rozwiązuje problemów z komunikacją, priorytetami czy sposobem podejmowania decyzji.Co z juniorami, stawkami i pracą zdalną?To trzy kwestie, które szczególnie często pojawiają się w dyskusjach o kondycji branży IT.Juniorzy nadal mają możliwości rozpoczęcia kariery, ale znalezienie pierwszej pracy jest wymagające. Jednocześnie osoby wchodzące do branży mogą mieć pewną przewagę w naturalnym wykorzystywaniu nowych narzędzi.Wynagrodzenia, zdaniem naszych rozmówców, w wielu obszarach się ustabilizowały. Nie oznacza to jednak jednakowej sytuacji wszystkich specjalistów. Kompetencje eksperckie nadal mogą być wyceniane inaczej niż te dostępne powszechnie na rynku.Praca zdalna pozostaje ważnym elementem branży, ale coraz więcej organizacji dostrzega wartość bezpośredniej współpracy. Hybryda staje się istotną alternatywą dla modelu w pełni zdalnego, choć podejście poszczególnych firm nadal się różni.Wspólny mianownik? Nie ma już jednego prostego przepisu na atrakcyjną karierę w IT.Cztery pytania, które warto sobie zadać po wysłuchaniu odcinkaNiezależnie od tego, czy szukasz nowej pracy, zarządzasz zespołem, czy po prostu chcesz dalej rozwijać się jako specjalista, warto zrobić mały przegląd własnych kompetencji.1. Czy potrafię opowiedzieć o swojej pracy językiem problemów i rezultatów?Nie tylko „pracowałem w React i Node.js”, ale również: jaki problem rozwiązywał produkt, jakie decyzje podejmowałem i co udało się osiągnąć.2. Czy naprawdę potrafię wykorzystać AI w swoim procesie pracy?Nie chodzi o listę narzędzi wpisanych w CV. Znacznie bardziej wartościowy jest konkretny przykład pokazujący, jak dzięki nim rozwiązujesz problem i jak weryfikujesz rezultat.3. Czy moje doświadczenie jest widoczne również poza listą stanowisk?Portfolio, GitHub, projekty własne czy aktywność w społeczności technologicznej mogą pomóc pokazać sposób myślenia, którego nie widać w standardowym CV.4. Czy rozwijam kompetencje, które pomagają całemu zespołowi?Komunikacja, odpowiedzialność za rezultat, rozumienie biznesu i gotowość do kwestionowania założeń są trudniejsze do przedstawienia na liście technologii, ale mają realny wpływ na jakość pracy.Nie trzeba od razu zmieniać całego planu rozwoju. Wystarczy wybrać jeden obszar, w którym można zrobić konkretny postęp w najbliższych tygodniach.Rynek się zmienia. Warto rozumieć dlaczego.Najważniejszy wniosek z tego odcinka nie brzmi: „wszyscy powinni nauczyć się AI” ani „praca w IT przestała się opłacać”.Zmiany są bardziej złożone.Firmy coraz uważniej przyglądają się kompetencjom, współpracy i wartości, którą poszczególne osoby wnoszą do organizacji. Jednocześnie technologia zmienia sposób realizowania projektów, a wraz z nim oczekiwania wobec inżynierów.Dlatego warto obserwować rynek nie tylko wtedy, gdy szuka się nowego zatrudnienia.Zrozumienie tego, w jakim kierunku zmienia się branża, pozwala podejmować lepsze decyzje dotyczące własnego rozwoju, zespołu i produktów, które budujemy.W podcaście znajdziesz różne, nie zawsze zgodne ze sobą perspektywy ekspertów oraz konkretne wskazówki dotyczące rekrutacji i rozwoju kariery.Zapraszamy do odsłuchania całej rozmowy.A jak to wygląda z Twojej perspektywy? Co najbardziej zmieniło się w pracy specjalistów IT w ostatnich latach? Wymagania techniczne, sposób współpracy, możliwości rozwoju czy oczekiwania pracodawców?Podziel się swoją opinią w komentarzu.Raporty przywołane w odcinku:* DORA — State of AI-assisted Software Development 2025* Gartner — Top Strategic Trends in Software Engineering for 2025 and Beyond* Stack Overflow Developer Survey 2025Dane i obserwacje pochodzą z okresu publikacji poszczególnych źródeł oraz nagrania rozmów i mogą nie odzwierciedlać aktualnej sytuacji na całym rynku. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit pragmatycznieo.substack.com

Jeszcze kilka lat temu w Pragmatic Coders mieliśmy kryzys, który blokował nasz wzrost. Zespoły pracowały nierówno, klienci eskalowali problemy, a rola zarządu sprowadzała się do ciągłego gaszenia pożarów.To był moment, w którym zrozumieliśmy jedno: jeśli firma ma rosnąć, nie może działać “każdy po swojemu”. Potrzebuje standardów, egzekucji i systemu monitoringu - inaczej chaos wróci przy każdym kolejnym etapie wzrostu.Ten tekst jest skróconą wersją najważniejszych wniosków z odcinka o tym, jak efektywnie zarządzać zmianą organizacji: od postawienia standardu, przez edukację i egzekucję, aż po utrzymanie zmiany w czasie.1) Kto jest odpowiedzialny za zmianę w firmie?Zanim zaczniemy mówić o narzędziach i procesach, trzeba odpowiedzieć na jedno kluczowe pytanie: kto ma “dowodzić” transformacją?To nie są:* zewnętrzni konsultanci* Scrum Masterzy* Agile Coachowie* programiści* Product OwnerzyZa zmianę organizacji odpowiadają osoby, które nią zarządzają.W odcinku pada cytat Eliyahu Goldratta, który dobrze to podsumowuje: zarządzanie to wiedzieć, co zmienić, w co zmienić i jak wykonać zmianę. To jest rola managementu - i nie da się jej scedować na kogoś “z boku”.2) Co zmienić: jak wygląda kryzys “od środka”W naszym przypadku kryzys był rozpoznawalny po bardzo prostym sygnale: praca zarządu i liderów polegała głównie na reagowaniu.Kilka projektów równolegle, w jednym wybuch, potem w drugim, potem w trzecim. Ledwo coś uporządkowane - już następna eskalacja. W takim trybie nie da się:* poprawiać jakości systemowo* budować przewidywalności* skalować organizacjiTo był “stan A”: chaos i gaszenie pożarów.3) W co zmienić: standard jako fundament skalowaniaMieliśmy doświadczenia z czasów konsultingowych - uczyliśmy inne firmy Scruma, Kanbana, Lean, CD, TDD i szeroko pojętej pracy “by the book”.I w pewnym momencie powiedzieliśmy: dobra, to teraz robimy to u siebie. W praktyce oznaczało to jasną decyzję:Wszyscy w firmie pracują w Scrumie. Bez wyjątków.To ważne: standard musi być zrozumiały, konkretny i wspólny. Bez tego nie ma spójności, a spójność jest konieczna, jeśli firma ma rosnąć i wdrażać nowych ludzi bez rozwalania jakości.4) Jak wykonać zmianę: nie wystarczy “ogłosić standard”Samo narzucenie standardu nic nie zmieni, jeśli ludzie nie wiedzą, jak go spełniać.Dlatego kolejnym krokiem były szkolenia:* obowiązkowe szkolenia scrumowe dla wszystkich* onboardingowe szkolenia dla nowych osób* proces, który zapewnia, że wiedza trafia do ludzi systemowo, a nie przypadkiemWażny wniosek: z samych szkoleń ludzie wdrażają w praktyce zwykle tylko część wiedzy. Dlatego szkolenia muszą działać na poziomie całych zespołów - wtedy “sumarycznie” zespół jest w stanie wyciągnąć z tego znacznie więcej.5) Egzekucja: bez niej zmiana nie stanie się systemowaJeśli mówisz ludziom, czego oczekujesz, uczysz ich, jak mają pracować, ale nie egzekwujesz tego - to zmiana nie wydarzy się na poziomie organizacji.W najlepszym wypadku wdrożą ją pojedyncze ambitne osoby lub zespoły. Systemowo - rozjedzie się.Dlatego u nas standardy musiały zostać powiązane z:* procesami ewaluacji i rozwoju* rozmowami rozwojowymi* (wprost lub pośrednio) tym, jak oceniana jest praca zespołówNie chodzi o “karanie”. Chodzi o to, że organizacja działa zgodnie z tym, co jest wzmacniane i monitorowane.6) Monitoring: jak sprawdzić, czy standard działa w praktyce?I tu dochodzimy do najczęstszego błędu: kiedy pojawia się kryzys, ludzie myślą “Scrum nie działa” albo “nasze procesy nie działają”.A potem okazuje się, że problemem nie był proces - tylko to, że zespół przestał go stosować:* brak backlogu* retrospekcja trzy miesiące temu* rzeczy “poza standardem” prześlizgnęły się, bo ewaluacje są zbyt rzadkieDlatego wdrożyliśmy narzędzia monitoringu, np. Scrum Health Checklist:* kilkadziesiąt pytań do samooceny zespołu* możliwość przejścia checklisty razem z Agile Delivery Leadem* wynik punktowy pokazujący, jak dobrze zespół pracuje względem standarduDo tego kolejne checklisty:* Product Health Checklist (bardziej pod PO/PM)* checklisty techniczne (architektura, testy, CI/CD itd.)Ważne: monitoring dotyczy nie tylko wyników biznesowych, ale przede wszystkim tego, czy proces jest realnie stosowany.7) Utrzymanie zmiany: regres jest normalny, jeśli nie ma systemuPo udanej transformacji wszystko było okej… przez jakiś czas. A potem po około dwóch latach zaczęliśmy widzieć regres.To jest normalne: ludzie zapominają, rozluźniają standardy, wracają stare nawyki. Dlatego zmiana nie jest wydarzeniem - jest procesem.U nas pomogło podejście “panelu kontrolnego”:* wizualizacja procesów w narzędziu (Jira) w kolumnach typu: nie działa / działa źle / działa nieźle / działa dobrze* SLA i jasne kryteria, co oznacza “działa dobrze”* cykliczne spotkania managementu (co tydzień operacyjnie, raz w miesiącu przegląd metryk i historii)To pozwala widzieć regres wcześnie i reagować, zanim pojawią się eskalacje i pożary.PodsumowanieJeśli chcesz zmienić organizację, to musisz:* jasno wskazać, kto odpowiada za zmianę (management)* zdefiniować: co zmienić, w co zmienić i jak wykonać zmianę* wprowadzić standardy i dostarczyć wiedzę (szkolenia)* egzekwować standardy, a nie tylko o nich mówić* monitorować, czy proces działa w praktyce - zanim zaczniesz oceniać “czy Scrum działa”* utrzymać zmianę w czasie, bo regres pojawi się zawsze, jeśli nie ma systemu🎥 Obejrzyj pełny odcinek na YouTube This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit pragmatycznieo.substack.com

Pamiętasz ten mem z psem siedzącym w płonącym pokoju?W projektach technologicznych to nie jest żart. To bardzo częsty stan.Gunshow ComicOd ponad 12 lat zajmujemy się ratowaniem projektów, które miały „małe problemy”.Dziś prawie połowa naszych przychodów w Pragmatic Coders pochodzi właśnie z takich sytuacji - gdy ktoś orientuje się, że projekt nie tyle ma trudności, co… już się pali.Największy problem?Zazwyczaj wszyscy widzieli sygnały wcześniej.Tylko nikt nie chciał ich nazwać po imieniu.Dlaczego wczesne sygnały są tak ważne?Bo problemy w projekcie działają jak dług procentujący składanie.* Na początku są tanie do naprawy.* Z czasem zaczynają generować kolejne problemy.* W końcu gasisz już nie przyczynę, tylko skutki.* A potem skutki skutków.Im później reagujesz, tym:* trudniej znaleźć prawdziwą przyczynę,* więcej kosztuje naprawa,* więcej energii idzie w gaszenie pożarów zamiast budowanie wartości.1. Projekt „arbuz” - na zewnątrz zielony, w środku czerwonyTo jeden z najbardziej niebezpiecznych stanów.Wszystko wygląda dobrze:* taski w Jirze są „done”,* sprinty „zamknięte”,* statusy zielone,* prezentacje ładne,* screenshoty działają.Ale:* nikt nie daje produktu do realnego użycia,* demo jest kontrolowane i prowadzone „utartą ścieżką”,* nie ma możliwości swobodnego kliknięcia,* interesariusze nigdy nie użyli systemu samodzielnie.Widziałem projekt w banku z UK, gdzie przez prawie 2 lata wszystko było „na zielono”.Po zajrzeniu w kod znaleźliśmy setki pustych metod z komentarzem „do zaimplementowania później”.Taski były odhaczane.Produkt nie istniał.To jest właśnie arbuz.2. Nikt nie potrafi powiedzieć, po co budujemy ten produktZadaj w zespole jedno pytanie:„Jaki jest cel tego produktu?”Jeśli:* każda osoba odpowiada inaczej,* odpowiedzi są ogólnikowe,* albo nikt nie potrafi odpowiedzieć,to projekt już zaczyna się palić.Dodatkowe sygnały:* brak roadmapy albo roadmapa jako lista życzeń,* feature factory - ciągle coś dodajemy,* brak mierników sukcesu,* metryki mierzą output, nie outcome.Możesz dowozić sprinty i jednocześnie nie budować żadnej wartości biznesowej.To nie jest postęp. To ruch w miejscu.3. Delivery zaczyna się rozjeżdżaćPopatrz na:* rosnący lead time,* coraz więcej rzeczy „in progress”,* coraz mniej rzeczy realnie kończonych,* duży rework,* ciągłe zmiany priorytetów,* wąskie gardła w postaci jednej kluczowej osoby.Jeśli:* rozpoczynacie dużo,* kończycie mało,* a wszystko trwa coraz dłużej,to system jest przeciążony.Często winne są:* brak jasnych celów sprintu,* brak limitów WIP,* wieloetapowe akceptacje,* jeden ekspert domenowy, który wszystko blokuje.To są sygnały, które widać dużo wcześniej, niż wybuchnie pożar.4. Dług techniczny zaczyna sterować biznesemTechniczny pożar rzadko zaczyna się spektakularnie.Zaczyna się tak:* mała zmiana psuje coś w innym miejscu,* release to wielkie wydarzenie o 3:00 nad ranem,* testy są „na czerwono, ale i tak jedziemy na produkcję”,* o błędach dowiadujecie się od użytkowników.Jeśli developerzy regularnie mówią:„Tak się już nie da pracować”to warto ich posłuchać.W większości przypadków mają rację.Jeśli tego nie zrobisz, scenariusz bywa jeden z dwóch:* kosztowny refactoring pod presją,* rekomendacja: „wyrzućmy to i napiszmy od nowa”.Dziś, przy AI i przyspieszonym developmentcie, taka rekomendacja pada częściej niż 3–4 lata temu.Ale jeśli kultura i procesy się nie zmienią, nowy system skończy tak samo.5. Sygnały ludzkie - najbardziej niedocenianeTo często najwcześniejsze i najbardziej wyraźne objawy.Zwróć uwagę na:* wysoką rotację,* odchodzenie kluczowych osób,* cynizm i sarkazm w zespole,* postawę „robimy minimum, to i tak nie ma sensu”,* konflikty business vs delivery,* nadgodziny jako norma,* „superbohaterów”, którzy jako jedyni potrafią naprawić produkcję.Superbohater w projekcie to często ukryty symptom choroby systemowej.Jeśli wszystko zależy od jednej osoby, masz poważny problem.Dlaczego te sygnały są ignorowane?Najczęstsze powody:1. Mierzymy złe rzeczySkupiamy się na:* budżecie,* terminach,* velocity.Ignorujemy:* jakość,* błędy,* zadowolenie użytkowników,* realny outcome.2. Kultura „nie przynosimy złych wiadomości”W wielu organizacjach:* nikt nie chce być tym, który mówi „mamy problem”,* używa się słów „wyzwanie” zamiast „pożar”,* problemy zamiata się pod dywan.Z czasem patologia się normalizuje.„U nas tak zawsze było”.To jedno z najbardziej niebezpiecznych zdań w biznesie.Co robić, zanim będzie za późno?* Zacząć mierzyć właściwe rzeczy - outcome, nie tylko output.* Zapewnić realną transparentność.* Stosować procesy zgodnie z zasadami (Scrum, Kanban - naprawdę, nie „po swojemu”).* Słuchać developerów.* Reagować na pierwsze sygnały, nie na kryzys.Bo kiedy projekt już płonie naprawdę, opcje są drogie:* wymiana zespołu,* wymiana liderów,* wymiana technologii,* albo wszystko naraz.Najważniejsze pytanieNie brzmi:„Czy mamy problemy?”Bo każdy projekt je ma.Brzmi:„Czy reagujemy na pierwsze sygnały, czy czekamy, aż zapłonie sufit?”Jeśli czytając to rozpoznałeś kilka sygnałów u siebie - to dobra wiadomość.Bo najgorsze projekty to te, które płoną… i nikt jeszcze nie czuje dymu.🎥 Obejrzyj pełny materiał wideoW tym odcinku omawiam wszystkie sygnały bardziej szczegółowo i opisuje konkretne przykłady z projektów, które ratowaliśmy. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit pragmatycznieo.substack.com

Większość pitch decków nie działa.Nie dlatego, że są brzydkie.Nie dlatego, że mają złą kolejność slajdów.I nawet nie dlatego, że brakuje w nich „tajnego slajdu”, o którym piszą internetowi guru.Nie działają, bo są budowane na złych założeniach.W tym artykule pokażę Ci realny pitch deck, który otwierał mi drzwi do większości inwestorów i funduszy VC. Następnie rozłożymy go na czynniki pierwsze — slajd po slajdzie — i przeanalizujemy, co działało, a co dziś zrobiłbym inaczej.🎥 Obejrzyj pełną analizę wideoW tym materiale pokazuję cały pitch deck i omawiam go krok po kroku.👉 OBEJRZYJ NASZ FILM NA YOUTUBE📄 Zobacz pełną prezentacjęJeśli chcesz przeanalizować pitch deck samodzielnie, możesz zobaczyć pełną wersję prezentacji tutaj:Dlaczego większość poradników o pitch deckach wprowadza w błąd?Jeśli szukałeś informacji o pitch deckach, prawdopodobnie trafiłeś na analizy decków Ubera czy Airbnb.To świetne przykłady.Ale kompletnie bezużyteczne dla większości founderów.Dlaczego?Bo:* te startupy miały świetny model biznesowy od pierwszego dnia* bardzo szybko udowodniły trakcję* founderzy mieli doświadczenie i sieć kontaktówIch pitch deck nie był kluczem do sukcesu.Był dodatkiem do czegoś, co już działało.Jeśli nie masz globalnego brandu ani ogromnej trakcji, musisz zbudować deck inaczej.Czym naprawdę jest pitch deck?Pitch deck to nie prezentacja produktu.To narzędzie do:* otwierania drzwi do funduszy* konwertowania outreachu na spotkania* budowania wiarygodności w kilka minutKonwersją nie jest inwestycja.Konwersją jest zaproszenie na rozmowę.To fundamentalna różnica.Realny przykład: początek pitch decku Health FolderPoniżej zobaczysz fragment pierwszych slajdów decku — część narracyjną, która miała zbudować kontekst i emocjonalny punkt wejścia.Ponad dwa lata temu zdiagnozowano u mnie nowotwór złośliwy.I to jest moment, w którym historia Health Folder tak naprawdę się zaczęła.Podczas leczenia odkryłem ogromny problem:dokumentacja medyczna jest rozproszona, pacjenci są zostawieni sami sobie, a informacje o ich zdrowiu są przechowywane w papierowych teczkach.To nie jest efektywne.To nie jest skalowalne.I to nie jest XXI wiek.Health Folder powstał jako platforma oparta o AI, która:* pozwala pacjentom dodawać i porządkować dokumentację* zbiera dane o stanie zdrowia* wspiera proces monitorowania chorób przewlekłych* wykorzystuje moment, w którym „silver generation” realnie korzysta już ze smartfonówTo nie był „pomysł z kartki”.To był problem z życia.To nie jest zakończenie deckuTo jest otwarcie.Po tej części deck przechodził w:* dane rynkowe* model biznesowy* konkurencję* trakcję* strategię wzrostu* zespół* oraz „ask” (ile rundy i na co środki)Ta pierwsza część miała jeden cel:zbudować fundament pod twardą, liczbową część prezentacji.Dlaczego ten pitch konwertował?Nie dlatego, że był idealny.Tylko dlatego, że był:* spójny* logiczny* osadzony w realnym problemie* podparty danymi w dalszej częściNie zaczynał się od „rynek wart miliardy dolarów”.Zaczynał się od realnej sytuacji.Dopiero później wchodziły liczby.Co dziś zrobiłbym inaczej?Ten deck otwierał drzwi.Ale z perspektywy czasu:* część slajdów uprościłbym jeszcze bardziej* szybciej przeszedłbym do twardych danych* mocniej wyeksponowałbym trakcjęW wideo powyżej pokazuję dokładnie, które elementy działały najlepiej i które wymagały poprawy.👉 Jeśli jeszcze nie oglądałeś, wróć do sekcji z nagraniem i zobacz analizę krok po kroku.Najważniejsza lekcjaPitch deck nie sprzedaje produktu.Pitch deck sprzedaje:* wiarygodność* logikę* timing* potencjał wzrostuJeśli Twój deck nie otwiera drzwi, zadaj sobie trzy pytania:* Czy pokazuję realny problem, czy tylko wizję?* Czy mam dowody, czy tylko narrację?* Czy inwestor po 3 minutach rozumie, dlaczego to ma sens właśnie teraz?Jeśli nie — problem nie jest w rynku.Problem jest w konstrukcji decku.Jeśli jesteś w trakcie fundraisingu, napisz w komentarzu:* Na jakim etapie jesteś?* Czy masz już trakcję?* Co jest Twoim największym problemem w pitchowaniu?W kolejnych materiałach mogę rozebrać konkretne elementy decku (problem, trakcję, model biznesowy) na czynniki pierwsze.Pragmatycznie. Bez lukru. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit pragmatycznieo.substack.com

Budowanie startupu to nie tylko produkt i zespół. To także walka o uwagę i zaufanie ludzi, którzy mogą pomóc sfinansować rozwój. Na początku wydaje się, że wystarczy przygotować dobry pitch deck i wysłać go do dziesiątek funduszy. Szybko jednak przychodzi rozczarowanie - nikt nie odpowiada, albo padają kolejne „nie”.Ja też przez to przeszedłem. Spędziłem ponad rok, próbując zebrać finansowanie dla swojego startupu. Przetestowałem wiele metod - od klasycznych cold maili, przez próby zaczepiania inwestorów na konferencjach, aż po eksperymentalne sposoby, jak wysyłanie paczek czy gadżetów. Niektóre działały lepiej, inne gorzej, ale najważniejsze lekcje przyszły z doświadczenia i rozmów z innymi founderami.Lekcja 1: Relacje są ważniejsze niż „szybki strzał”Kiedyś uważałem, że networking z innymi founderami to strata czasu. Skoro szukam inwestora, to po co rozmawiać z kimś, kto sam szuka pieniędzy? Wydawało mi się, że jedynym sensownym kierunkiem jest jeżdżenie tam, gdzie są inwestorzy albo klienci.Dopiero z czasem odkryłem, że rozmowy z innymi founderami otwierają drzwi, których sam nie byłbym w stanie otworzyć. Ci, którzy już przeszli proces fundraisingu, wiedzą, do kogo warto iść, a kogo lepiej omijać. Mogą zrobić intro do funduszu, z którym pracowali - albo ostrzec, że dany inwestor nie jest dobrym partnerem.Najważniejsze: to właśnie oni często mogą dać ciepłe rekomendacje, które działają lepiej niż najlepszy pitch deck. Nigdy nie zdarzyło mi się, żeby ktoś po takim intro nie znalazł dla mnie przynajmniej pół godziny na rozmowę.Lekcja 2: Konferencje są jak ocean pełen rekinów - ale nie zawsze warto do niego skakaćNa początku byłem przekonany, że konferencje startupowe to najlepsze miejsce na pozyskanie inwestorów. W końcu wszyscy tam są. Szybko jednak zrozumiałem, że duże eventy to często czerwony ocean - dziesiątki founderów walczących o uwagę kilku inwestorów. Chaos, kolejki, rozmowy trwające po 10 minut. Mało kto cokolwiek zapamiętuje.O wiele lepiej sprawdzają się mniejsze, bardziej kameralne wydarzenia. Tam jest czas, żeby porozmawiać, spotkać tę samą osobę kilka razy w ciągu dnia, a nawet złapać kontakt przy kawie czy lunchu. Zdarzało się, że po kilku takich spotkaniach w różnych miejscach inwestor zaczynał mnie kojarzyć i sam dopytywał, jak idzie rozwój mojego produktu.Lekcja 3: Nie proś o pieniądze - proś o feedbackTo była jedna z najważniejszych rad, jaką dostałem od inwestora. Jeśli zaczynasz rozmowę od „szukam finansowania”, bardzo szybko zamykasz sobie drogę. Ale jeśli powiesz: „chciałbym poznać twoją opinię o naszym produkcie, o naszej wizji”, to otwierasz zupełnie inną przestrzeń.Ludzie, a inwestorzy w szczególności, lubią dzielić się wiedzą. Lubią być traktowani jako eksperci. Kiedy prosisz ich o feedback, nie tylko budujesz relację, ale też tworzysz okazję, żeby naprawdę zainteresowali się tym, co robisz. Paradoksalnie, często właśnie wtedy zaczynają sami myśleć o inwestycji.To prosta zasada: proś o feedback, a możesz dostać pieniądze. Proś o pieniądze, a najczęściej dostaniesz tylko feedback.Lekcja 4: Wracaj po „nie”Fundraising to maraton, nie sprint. Wielu founderów traktuje odmowę jako koniec rozmowy. Tymczasem inwestorzy często potrzebują czasu. Chcą zobaczyć, że się rozwijasz, że wyciągasz wnioski, że masz determinację.Dlatego warto wracać. Pokazać, co zmieniło się od ostatniego spotkania. Podzielić się nowymi liczbami, historią klienta, kolejnym kamieniem milowym. „Nie” może z czasem zamienić się w „tak” - i znam wiele przypadków, gdzie właśnie tak się stało.Lekcja 5: Znajdź właściwych inwestorówNa koniec - nie każdy inwestor jest dobrym inwestorem dla ciebie. Ważne jest nie tylko to, żeby ktoś miał pieniądze, ale żeby rozumiał twoją branżę, twój model biznesowy, twoją kulturę. W przeciwnym razie ryzykujesz, że pozyskasz kapitał, ale stracisz kontrolę albo energię na niekończące się konflikty.Lepiej mieć mniej pieniędzy, ale od kogoś, kto naprawdę rozumie, dokąd zmierzasz.PodsumowanieFundraising to sztuka cierpliwości i budowania relacji. To proces, w którym kluczowe są nie tylko prezentacje i excele, ale przede wszystkim ludzie - ich zaufanie, rekomendacje i chęć współpracy.👉 To tylko część lekcji, które zebrałem przez lata. W pełnym odcinku dzielę się jeszcze więcej przykładami i szczegółami - od moich własnych historii po triki, które naprawdę działają.🎥 Obejrzyj cały odcinek na YouTube: Pragmatycznie o... docieraniu do inwestorów i budowaniu relacji This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit pragmatycznieo.substack.com

Budowanie startupu to nie tylko pomysł i technologia – to także pytanie o to, skąd wziąć kapitał, który pozwoli firmie urosnąć. Źródeł jest wiele, ale każde z nich ma swoje plusy, minusy i najlepszy moment na wejście.👉 Poniżej znajdziesz listę najważniejszych źródeł finansowania startupów, ich zalety i pułapki. To skrót, który pomoże Ci poukładać wiedzę. Jeśli chcesz poznać przykłady, anegdoty i szczegółowe historie – koniecznie posłuchaj pełnego odcinka.3F i 4F – pierwszy kapitałPierwsze pieniądze często pochodzą z najbliższego otoczenia – family, friends, fools (a czasem founders). To niewielkie kwoty, które pozwalają ruszyć z miejsca: kupić domenę, zbudować MVP, opłacić pierwsze serwery. Ich zaleta? Szybkość i brak skomplikowanych formalności. Ich wada? Ryzyko, że stracisz pieniądze bliskich, jeśli projekt się nie powiedzie.Pre-seed i seedGdy produkt zaczyna nabierać kształtów, pojawia się potrzeba większego finansowania. Na tym etapie często wchodzą aniołowie biznesu – doświadczeni przedsiębiorcy inwestujący nie tylko pieniądze, ale i swoją wiedzę oraz kontakty. W pre-seedzie liczy się przede wszystkim zespół i wizja, w seedzie – pierwsze wskaźniki, które pokazują, że pomysł ma sens.Venture Capital i dalejKolejny krok to fundusze VC. Dają one dostęp do dużego kapitału, ale też stawiają wysokie wymagania. To nie są „łatwe pieniądze” – VC chcą szybkiego wzrostu i przygotowania spółki na kolejne rundy, aż do exit’u (np. sprzedaży albo wejścia na giełdę).Alternatywne ścieżkiNie każdy startup musi iść drogą VC. Coraz popularniejsze stają się:* granty i dotacje – szczególnie w Europie, gdzie fundusze publiczne wspierają innowacje,* family offices – prywatne majątki inwestujące strategicznie w wybrane branże,* corporate VC – czyli inwestycje od dużych firm szukających synergii,* crowdfunding udziałowy – sposób na zebranie kapitału bez oddawania kontroli pojedynczemu inwestorowi.Na co uważać?Pieniądze mogą pomóc, ale też zaszkodzić. Najczęstsze błędy founderów to:* wybór inwestora, który nie pasuje do kultury i wizji firmy,* oddanie zbyt dużej kontroli na wczesnym etapie,* pogoń za pieniędzmi dla samych pieniędzy, bez planu na ich realne wykorzystanie.Podsumowanie – pragmatyczne podejście do finansowaniaStartup potrzebuje kapitału, ale jeszcze bardziej potrzebuje właściwego partnera. Każde źródło finansowania ma swój moment – i rolą foundera jest wiedzieć, kiedy po które sięgnąć. Najważniejsze pytanie brzmi nie „ile pieniędzy potrzebuję?”, ale „co chcę dzięki nim osiągnąć?👉 To tylko skrót najważniejszych lekcji. Jeśli chcesz usłyszeć pełne historie, przykłady i rozwinięcie każdego wątku – obejrzyj cały odcinek na YouTube: „Pragmatycznie o tym, skąd się biorą pieniądze w startupach”. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit pragmatycznieo.substack.com

W tym odcinku dzielę się lekcjami, które wyniosłem z ponad 10 lat prowadzenia Pragmatic Coders – Software House’u, który zaczynał jako mała firma, a dziś pracuje z klientami na całym świecie.To nie będzie cukierkowa historia sukcesu. Opowiadam o błędach, porażkach, ale też o tym, co sprawdziło się najlepiej – tak, żebyście mogli wykorzystać te doświadczenia w swoich firmach i pracy.Jedna z historii, która mocno zapadła mi w pamięć, dotyczy naszej strony internetowej. Na początku zbudowaliśmy ją własnymi siłami – nie była najpiękniejsza, ale dobrze się pozycjonowała i generowała sporo leadów. Chcieliśmy to przeskalować, więc zainwestowaliśmy setki tysięcy złotych w zewnętrznych ekspertów od marketingu i SEO. Projekt trwał półtora roku, pochłonął masę energii i pieniędzy, a efekt? Strona praktycznie nie działała. Spadliśmy w wynikach wyszukiwania, zasięgi zniknęły, a nowa witryna nie generowała prawie żadnych klientów. Dopiero po czasie wróciliśmy do własnoręcznie stworzonej strony – i to ona znów zaczęła dowozić realne efekty.Ta lekcja nauczyła mnie, żeby nie ufać ekspertom wyłącznie na słowo, tylko sprawdzać ich w praktyce na małych zadaniach. Ekspertem jest ten, kto potrafi wdrożyć swoją wiedzę i realnie dostarczyć wartość – nie ten, kto tylko pięknie o niej opowiada.Oprócz tego w odcinku poruszam m.in.:* dlaczego rozmowy z klientami są fundamentem rozwoju,* jak unikać toksycznych i nieopłacalnych klientów,* jak budować kulturę, która przyciąga i zatrzymuje najlepszych ludzi,* kiedy programy naprawcze w rekrutacji nie mają sensu,* dlaczego szybkie decyzje (nawet niedoskonałe) często ratują firmę.To praktyczne lekcje, które zostają z przedsiębiorcą na zawsze. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit pragmatycznieo.substack.com

Na co dzień monitorujemy KPI w naszych firmach, diagnozujemy problemy zespołów i projektów — a kiedy ostatni raz zdiagnozowaliśmy siebie? W nowym odcinku "Pragmatycznie o..." Wiktor Żołnowski mówi szczerze o zdrowiu lidera. O tym, jak badania profilaktyczne, ruch, sen i zdrowe podejście do emocji wpływają nie tylko na długość życia, ale też na skuteczność w biznesie.Z tego odcinka dowiesz się:✅ Dlaczego wczesne badania mogą uratować Ci życie (na przykładzie osobistym)✅ Jakie choroby są najczęstszą przyczyną zgonów i jak im zapobiegać✅ Co naprawdę warto monitorować, jeśli chcesz być zdrowym liderem✅ Jak dieta, ruch i regeneracja przekładają się na wyniki w pracy✅ Dlaczego terapia i praca nad emocjami to nie fanaberia, a inwestycja w efektywnośćTo nie poradnik o fitnesie. To praktyczna rozmowa o tym, jak nie skończyć z wypaleniem, wrzodami i poczuciem, że "wszystko się sypie".Posłuchaj — zwłaszcza jeśli zarządzasz zespołem, prowadzisz biznes albo po prostu chcesz mieć siłę, by działać skutecznie na co dzień. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit pragmatycznieo.substack.com

W tym odcinku Wiktor Żołnowski testuje podejście „kodowania bez znajomości kodu” i sprawdza, czy da się stworzyć działający plugin do WordPressa tylko przy pomocy narzędzi AI, takich jak Cursor czy ChatGPT.Z tego odcinka dowiesz się:– Co faktycznie działa, a co rozwala Ci WordPressa– Jakie błędy popełniają początkujący i zaawansowani– Dlaczego krótkie prompty nie wystarczą przy większych projektach– Kiedy vibe coding staje się pułapką– I czy naprawdę można programować, nie wiedząc, jak działa kod🎥 Oglądaj odcinek na YouTube:🔗 Wiktor Żołnowski na LinkedIn:https://www.linkedin.com/in/wiktorzolnowski🌐 Pragmatic Coders – firma stojąca za tym podcastem:https://www.pragmaticcoders.com This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit pragmatycznieo.substack.com

W maju 2025 roku internet zalały obrazy w stylu Ghibli generowane przez AI. W tym odcinku na chłodno rozprawiam się z mitami i fakenewsami, które wywołały burzę wokół grafiki i sztucznej inteligencji.Z tego odcinka dowiesz się:– Czy Studio Ghibli naprawdę wzywa do zakazu używania ich stylu– Co naprawdę powiedział Hayao Miyazaki o AI– Dlaczego AI to tylko narzędzie, a nie zagrożenie– Jakie regulacje nadchodzą i czego możemy się spodziewać– Dlaczego w erze AI marka osobista i autentyczność są ważniejsze niż kiedykolwiekZamiast strachu – pragmatyczne spojrzenie na zmiany w branży kreatywnej.🎥 Oglądaj odcinek na YouTube:🔗 Mateusz Szostek na LinkedIn:https://www.linkedin.com/in/mateusz-szostek-886411161🌐 Pragmatic Coders – firma stojąca za tym podcastem:https://www.pragmaticcoders.com This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit pragmatycznieo.substack.com