---
title: "Platform engineering: business case, który przekona zarząd"
description: "Zarząd nie płaci za procenty. Business case dla platform engineering: jeden kwartał roadmapy, zwrot w trzech, dowożenie w parze z adopcją produktu."
url: "https://www.marian.coach/pl/blog/platform-team-business-case/"
lang: "pl"
image: "https://www.marian.coach/images/blog/platform-team-business-case/infographic.webp"
---

![Platform engineering: business case, który przekona zarząd](https://www.marian.coach/images/blog/platform-team-business-case/infographic.webp)

„W tym roku dowieźliśmy więcej funkcji niż w zeszłym. Przychodów z tego nie widziałem”. Tak odpowiedział Head of Product, kiedy Tomáš, VP of Engineering, obiecał zarządowi trzy razy większą przepustowość. Business case dla platform engineering, czyli uzasadnienie biznesowe dla zespołu platformowego, to prośba, która przetrwa taką odpowiedź: oddaj mi jeden kwartał roadmapy, a w ciągu trzech kolejnych pokażę zwrot, w pieniądzach.

Tomáš (to nie jego prawdziwe imię) kieruje inżynierią w firmie B2B SaaS. Jego zespoły platformowe spędzają 60% czasu na utrzymaniu produkcji, 2% na otwieraniu swoich komponentów dla innych zespołów i 38% na budowaniu funkcji. Zespoły produktowe bez nich nie ruszą, więc każda inicjatywa obejmująca kilka zespołów czeka w czyjejś kolejce.

Jego prezentacja była dobra. Zależności narysowane jak spaghetti, autonomiczne zespoły, cel 3x. Każda liczba w niej była procentem.

Brakowało jednego slajdu i powiedziałem mu to wprost. W całej prezentacji nie było ani jednego dolara. [Raport Stripe „The Developer Coefficient”](https://stripe.com/files/reports/the-developer-coefficient.pdf) pokazał, że programiści spędzają 17,3 godziny z 41,1-godzinnego tygodnia na utrzymaniu, złym kodzie i długu technologicznym (technical debt). Twój zarząd już płaci ten rachunek, więc pokaż mu fakturę.

## Zarząd finansuje datę zwrotu

Zapytaj ChatGPT, jak zdobyć finansowanie na zespół platformowy, a powie Ci, żeby „przestać sprzedawać to jako usprawnienie inżynierii i zacząć sprzedawać jako inwestycję biznesową”. Słusznie, tylko że to za mało. Inwestycja bez daty to życzenie.

Więc podaj datę. „Daj mi połowę Q1. Odzyskasz ją do końca roku, a od tego momentu jedziemy szybciej”. Nie żebrzesz o czas na platformę. Jesteś VP, który sprzedaje inwestycję.

Procent zaprasza do targowania się o procent. Data zwrotu, czyli okres zwrotu (payback period) przełożony na kalendarz, zaprasza do decyzji, a decyzja należy do ludzi przy stole. Właśnie tam chcesz ją mieć.

Rachunek jest wystarczająco duży, żeby to udźwignąć. Dyrektorzy IT (CIO) w badaniu [McKinsey](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity) przyznali, że od 10 do 20% budżetu technologicznego przeznaczonego na nowe produkty idzie na spłatę długu technologicznego.

Tomáš miał szczęście. Jego CEO w weekend przed wyjazdowym spotkaniem zarządu przeżył własny moment „pociąg odjeżdża bez nas” i był gotów rozbić roadmapę. Ale mandatu nie dostaje się po godzinie rozmowy, a slajd ze zwrotem to ten, z którym wracasz raz za razem. W Mews i w firmach, którym doradzam od tamtej pory, widziałem, że ta walka trwa od pół roku do roku, zanim ludzie zrozumieją: nie sprzedajesz wolniejszej roadmapy, tylko przyspieszasz firmę.

## Zanim poprosisz o czas, zmierz, dokąd on idzie

Nie sprzedasz daty zwrotu, jeśli o dzisiejszym stanie tylko zgadujesz. Pierwszy slajd pokazuje, dokąd idzie czas teraz, a liczby muszą pochodzić od zespołów, nie od Ciebie.

### Pięć koszyków: planowane i nieplanowane

Podziel czas każdego zespołu na pracę nad roadmapą, inwestycję w platformę, reaktywną pracę na produkcji (incydenty, dyżury, hotfixy), eskalacje od klientów i pomoc innym zespołom. Pierwsze dwa koszyki są planowane, trzy ostatnie w większości nie. Udział pracy nieplanowanej to Twoja liczba na nagłówek: pokazuje, ile miejsca na roadmapę Twoje zespoły naprawdę mają.

### Bez timesheetów

Każdy Team Lead rozpisuje czas swojego zespołu w osobodniach na pięć koszyków. Piętnaście minut, dokładność ±10% wystarczy. Przez dwa tygodnie rób to jako pilotaż, potem przejdź na kroczące sześć tygodni, bo jeden duży incydent potrafi kompletnie wypaczyć dwa tygodnie.

### Zapisz, kto zlecił

Przy każdym koszyku zapisz, który dział zlecił tę pracę. Wtedy moce przerobowe stają się budżetem, który rozdzielasz: „Twój dział ma w tym kwartale 400 osobodni, sam decydujesz, co w nie wejdzie”. Nowa prośba staje się wymianą, a spór o priorytety przechodzi do ludzi, którzy za te priorytety odpowiadają.

### Zamień dni na pieniądze

Liczba osobodni razy pełny koszt dnia pracy. To liczba, którą czyta CFO. Jeśli wycena decyzji inżynierskiej dla zarządu to dla Ciebie nowość, mniejszą wersję tego rachunku opisałem w tekście o tym, [jak rozmawiać z zarządem](https://www.marian.coach/pl/blog/how-to-talk-to-executives/).

Tak wyglądał pomiar i cel Tomáša. To liczby jednej prawdziwej firmy, zanonimizowane. Cel dla zespołów produktowych jest celem, nie pomiarem.

| Typ zespołu | Praca | Dziś | Cel |
| --- | --- | --- | --- |
| Zespoły platformowe | Utrzymanie produkcji | 60% | 30% |
| Zespoły platformowe | Otwieranie komponentów dla innych zespołów | 2% | 50% |
| Zespoły platformowe | Funkcje dla klientów | 38% | 20% |
| Zespoły produktowe | Utrzymanie produkcji | 35% | 10% |
| Zespoły produktowe | Zmiany w platformie (przez kontrybucję) | 3% | 10% |
| Zespoły produktowe | Funkcje dla klientów | 62% | 80% |

Spójrz na ostatni wiersz. Zespoły produktowe już dziś spędzają 62% czasu na funkcjach.

Hamuje je 35%, które spędzają z głową odwróconą w stronę produkcji, i kolejka, w której stoją do platformy. Więcej czasu na funkcje to efekt uboczny usunięcia tych dwóch rzeczy. Jeśli przed zbudowaniem tego slajdu chcesz spojrzenia z zewnątrz na to, dokąd idzie czas Twoich zespołów, do tego służy [audyt produktywności zespołów inżynierskich](https://www.marian.coach/engineering-teams-productivity-audit/).

Punkt odniesienia spoza jednej firmy: zasada Marty’ego Cagana z [SVPG](https://www.svpg.com/engineering-wants-to-rewrite/) daje inżynierii 20% mocy przerobowych na starcie, a więcej, gdy system jest w złym stanie.

## Zespół platformowy buduje funkcje na końcu

Kolejność priorytetów Tomáša dla zespołów platformowych: najpierw produkcja, potem otwieranie komponentów, funkcje na końcu. 30% na produkcję to pożądany udział, nie limit: kiedy produkcja płonie, produkcja wygrywa.

![Odręczny szkic zatytułowany Platform teams. Po lewej, przekreślone: 60% production, 38% features. Po prawej, zakreślone na zielono: 30% production, 50% open components, 20% features.](https://www.marian.coach/images/blog/platform-team-business-case/capacity-flip.webp)

Odwrócenie proporcji w zespołach platformowych, o które poprosił Tomáš. Dzisiejszych 2% na otwieranie komponentów nie ma na rysunku.

Dlaczego funkcje na końcu? Dziesięć autonomicznych zespołów, które potrzebują tych samych pięciu osób ze wspólnego rdzenia, to nie dziesięć równoległych strumieni pracy. Przez kilka tygodni jadą szybko, a potem znowu czekają na code review, odpowiedzi i zależności.

Kolejka tylko się przesunęła. [Badania DORA](https://dora.dev/capabilities/platform-engineering/) nazywają to „downstream disorder”: zyski z szybszego pisania kodu zjadają wąskie gardła w testach, przeglądach bezpieczeństwa i dalej.

### Zamknij 10%, otwórz 90%

Mały zestaw komponentów zostaje w całości w rękach właściciela: uwierzytelnianie, autoryzacja, prywatność, czyli miejsca, w których chcesz być ostrożny. W planie Tomáša to około 10% zmian. Pozostałe 90% staje się „własnym, ale otwartym”: właściciel rozdziela zależności, dokumentuje, spisuje intencje i ograniczenia, dodaje testy i buduje bezpieczne ścieżki, żeby każdy zespół mógł kontrybuować bez psucia rdzenia.

![Odręczny szkic dwóch prostokątów. Mały fioletowy: Critical components 10%, owned end to end, auth, authorization, privacy. Większy zielony: Open components 90%, any team contributes, ze strzałkami wchodzącymi ze wszystkich stron.](https://www.marian.coach/images/blog/platform-team-business-case/critical-open.webp)

Zasada 90/10: 90% zmian przechodzi przez otwarte komponenty.

### Kontrybucja działa w obie strony

Zespoły produktowe zmieniają platformę, kiedy tego potrzebują. Zespoły platformowe zmieniają kod produktowy, kiedy wymaga tego produkcja, na przykład, gdy coś pada albo nie wyrabia wydajnościowo. Obie strony muszą się pogodzić z tym, że w ich kodzie grzebie ktoś inny. Po latach silnej własności każdy komponent w firmie Tomáša obrósł biurokracją, a on chce się pozbyć 90% tych procedur.

### Nie buduj do szuflady

Żadnej funkcji platformy „bo może się przyda za trzy lata”. Buduj to, czego zespół potrzebuje teraz. Platforma idzie tam, dokąd idą zespoły produktowe, a nie wybiega przed nie.

### Mierz platformę tym, jak szybko biegną inni

Zespoły platformowe ocenia się po tym, o ile szybciej dowożą zespoły produktowe, a nie po tym, co same zbudowały. Tak w praktyce wygląda zespół platformowy w ujęciu [Team Topologies](https://teamtopologies.com/key-concepts): wewnętrzny produkt, który istnieje po to, żeby przyspieszać zespoły stream-aligned, czyli te, które dowożą zmiany prosto do klienta. Jeśli chcesz zrozumieć samą rolę, opisałem ją w tekście o [roli platform engineera](https://www.marian.coach/platform-engineer-role/).

Głos przeciwny zasługuje na uczciwe wysłuchanie. [Raport DORA 2024](https://dora.dev/research/2024/2024-DORA-Report-Infographic.pdf) pokazał 6% wzrostu produktywności zespołu przy dedykowanym zespole platformowym i 8% spadku przepustowości wśród tych, którzy z platformy korzystają. Źle zrobiona platforma Cię spowalnia i właśnie dlatego mierzysz ją szybkością innych zespołów, a najpierw udowadniasz ją na jednym zadaniu.

## Zamień procenty na pieniądze: slajd jeden za trzy

To slajd, którego Tomáš nie miał. Składają się na niego trzy liczby.

### Ile kosztuje ten kwartał

Liczba osobodni zdjętych z roadmapy razy pełny koszt dnia pracy. To Twoja inwestycja, w pieniądzach.

### Kiedy to wraca

Część roadmapy, którą tracisz w kwartale inwestycji, zestawiona z tym, co odzyskujesz potem, kwartał po kwartale, aż narastające saldo wyjdzie na plus. Licz się z tym, że przez mniej więcej dwa miesiące zespoły zwolnią albo prawie staną, bo będą wdrażać nowe narzędzia i nowy sposób pracy. Napisz to wprost na slajdzie: zwalniamy, żeby potem przyspieszyć.

Nie zgaduj przyspieszenia. Weź je z pilotażu (o nim w następnej sekcji): to, co pokaże zadanie referencyjne przy pierwszym odczycie, jest Twoją liczbą na Q2, i nie ekstrapolujesz dalej, niż pilotaż udowodnił.

### Ile to jest warte

Twój CPO powinien wiedzieć, ile przychodu generujecie co kwartał i ile z tego przypada na nowe funkcje. To Twoja cena za kwartał roadmapy. Wpisz wynik na slajd jako hipotezę, ale liczbę wpisz. Wtedy ludzie przestają debatować, czy w ogóle się na to zgodzić.

Tak wygląda kształt tego rachunku, na liczbach wymyślonych na potrzeby tego tekstu (przykład, a nie dane Tomáša). Wynik liczę w „dzisiejszych kwartałach”, gdzie 1,0 to kwartał taki jak obecny, a nowe funkcje przynoszą 3 mln USD przychodu na kwartał.

| Kwartał | Dowieziona roadmapa | Narastające saldo | Dodatkowy przychód względem dziś, jeśli adopcja się utrzyma |
| --- | --- | --- | --- |
| Q1, inwestycja | 0,5 | −0,5 | −1,5 mln USD |
| Q2 | 1,2 | −0,3 | +0,6 mln USD |
| Q3 | 1,4 | +0,1, punkt zwrotu | +1,2 mln USD |
| Q4 | 1,6 | +0,7 | +1,8 mln USD |

Jeden kwartał oddajesz, trzy potrzebujesz, żeby go odzyskać: pod koniec Q4 jesteś 0,7 kwartału do przodu, czyli około 2,1 mln USD. Jeśli w drugim roku utrzymasz tempo z Q4, każdy kwartał daje 0,6 kwartału dodatkowego wyniku, około 7,2 mln USD rocznie.

Przeczytaj jeszcze raz nagłówek ostatniej kolumny. „Jeśli adopcja się utrzyma” to zarzut Head of Product, wpisany na Twój własny slajd. I to dlatego istnieje następna sekcja.

Prace nad niezawodnością i bezpieczeństwem też dostają liczbę przychodową. [ValueSum](https://www.rubick.com/valuesum-metric/) Jade’a Rubicka ocenia dowiezioną pozycję tak, że 100 punktów oznacza dodanie 100% ARR w ciągu roku, pomnożone przez prawdopodobieństwo sukcesu. Jego przykład z niezawodnością, krok po kroku:

| Krok | Wynik |
| --- | --- |
| Jedna trzecia klientów może odejść przez tę niestabilność | 33 |
| To raczej duzi klienci, więc w praktyce chodzi o około 45% przychodu | 45 |
| Realne ryzyko odejścia na klienta to około 20%: 45 × 20% | 9 |
| Szkody wizerunkowe podwajają wynik: 9 × 2 | 18 |

Rubick daje Ci też argument za stałym udziałem platformy zamiast walki o każdy projekt osobno: „pewien procent każdej organizacji inżynierskiej powinien zajmować się rzeczami, które z czasem czynią organizację bardziej efektywną”, bo taka praca „zwykle dostaje za mało”, jeśli optymalizujesz wyłącznie pod dowiezioną wartość.

## „Dowieźliśmy więcej, a przychody stoją” to słuszny zarzut

Head of Product miał rację. To, że przyspieszymy maszynę, nie znaczy, że w tym tempie będziemy dowozić właściwe rzeczy. [Raport Pendo o adopcji funkcji](https://go.pendo.io/rs/185-LQW-370/images/Pendo_Whitepaper_2020_FeatureAdoptionReport_Refresh.pdf) pokazał, że 80% funkcji w przeciętnym produkcie software’owym jest używanych rzadko albo wcale.

Business case potrzebuje więc drugiego właściciela. Opowiedziałem Tomášowi, jak robiliśmy to w [Mews](https://www.mews.com/), gdzie jako VP of Engineering rozwinąłem inżynierię z 8 do 80 zespołów. Mój KPI, ten, z którego byłem znany: co kwartał dowoziłem co najmniej 80% roadmapy. Gdybym nie dowiózł, mogli mnie zwolnić.

Mierzyłem to jako wkład w roadmapę: jaki procent czasu moich zespołów idzie na roadmapę, a jaki poza nią. Dwa zespoły pracujące poza roadmapą, z jakiegokolwiek powodu, stawiały pod znakiem zapytania cały kwartał. Swoich liderów uczyłem zasady, według której sam żyłem: jeśli nie dowieziesz mi roadmapy, ja też mam problem.

Mój odpowiednik po stronie produktu miał inny KPI. „Dzięki, Marianie, że zbudowałeś mi szybką maszynę. Ale to ja muszę do niej coś wrzucać”. Jego zadaniem było karmić moją roadmapę rzeczami, które mają znaczenie, mierzonymi adopcją produktu. Celowo ustawiliśmy to tak, żebyśmy byli parą bliźniaków.

> Szybsza maszyna sama niczego nie sprzeda. Ktoś musi odpowiadać za to, co do niej wpada.

Każda inicjatywa była przypisana do kwartału i miała w [Jira](https://www.atlassian.com/software/jira) własne pole z oceną adopcji. Przyznaję, ocenialiśmy ręcznie, żadnej automatycznej metryki nie było:

| Ocena | Co oznacza | Liczy się do 65%? |
| --- | --- | --- |
| Bardzo wysoka | Zarabia dla nas dużo pieniędzy | Tak |
| Wysoka | Zgodnie z oczekiwaniami | Tak |
| Neutralna | Zarabia tyle, ile kosztowała: ludzie, licencje, infrastruktura | Nie |
| Katastrofa | Nie zarabia na swój koszt | Nie |
| Do oceny | Za wcześnie na ocenę, dozwolone najwyżej przez jeden kwartał | Nie |

Wyczucie czasu to część dobrej decyzji produktowej, więc nic nie zostaje bez oceny dłużej niż kwartał.

Ja miałem 80% dowiezionej roadmapy. Lider produktu obok mnie miał 65% adopcji produktu, czyli ocen wysokich albo bardzo wysokich. Czekanie się nie liczy, bo czekanie nie generuje pieniędzy.

I szczerze mówiąc, krzyczeliśmy na siebie. „Trzymam dla Ciebie szybką roadmapę, a Ty wrzucasz do niej śmieci? Potem moi ludzie są niezadowoleni i ktoś odchodzi”.

Czasem mówiłem, że coś nie ma miejsca na roadmapie. Czasem on chciał oznaczyć coś jako sukces, a ja mówiłem, że to raczej nie jest sukces. Ale wtedy masz już sensowne dyskusje, o wartości.

Rubick dochodzi do tego samego miejsca z drugiej strony. Zaleca ponowną ocenę każdej funkcji [trzy albo sześć miesięcy po dowiezieniu](https://www.rubick.com/valuesum-metric/) i zachowanie obu ocen, przewidywanej i wstecznej. Dwie kolejne zasady z tej pracy skopiowałbym od razu: wartość oceniają liderzy produktu albo działów, nie inżynieria, a oceny nie używa się do oceniania ludzi ani zespołów.

Tomášowi nie udało się jeszcze uzgodnić KPI adopcji na samej górze, więc jego wersja bliźniaków działa poziom niżej: każdy autonomiczny obszar dostaje Product Managera i Engineering Managera, którzy razem odpowiadają za jeden wynik biznesowy. Taka para powinna istnieć na każdym poziomie: zespół, dyrektor, VP, CTO i CPO. Jeśli jako [Engineering Director](https://www.marian.coach/engineering-director-mentor/) ustawiasz to poniżej poziomu VP, Twój odpowiednik po stronie produktu jest Twoim bliźniakiem.

## Udowodnij to na jednym zadaniu, zanim poprosisz o całą organizację

Tomáš sam napisał małą zmianę w kodzie, pierwszą od dwóch lat. Powinna zająć trzy godziny. Code review, pipeline’y i brak informacji o tym, jak zmiana uderzy w klientów, zrobiły z niej dzień pracy, a bramki wdrożeniowe rozciągnęły samo wdrożenie do tygodnia.

To zadanie stało się punktem odniesienia, czyli benchmarkiem:

| Zadanie referencyjne | Dziś | Koniec pilotażu | Docelowo |
| --- | --- | --- | --- |
| Development | 1 dzień | ~4 godziny | 2 godziny |
| Wdrożenie | 1 tydzień | kilka dni | 2 godziny |

Na pilotaż wyznaczył jeden cel. Do pierwszego odczytu 60% punktów tarcia na ścieżce tego zadania ma się poprawić. Każdy z nich jest mały: godzina tu, pół godziny tam, piętnaście minut gdzie indziej.

Jeśli Twoje zespoły pracują z agentami AI, lista punktów tarcia obejmuje też to, czego agent nie potrafi: zauważyć wolnego endpointu, zanim zauważy go klient, znać historii produktu, uruchomić instancji deweloperskiej, obserwować wdrożenia.

### Na pilotaż wybierz spokojny zespół

Tomáš zaczął od zespołu z lekką roadmapą, żeby pilotaż nie zabił planu. Punkt odniesienia jest Ci potrzebny wcześniej niż transformacja.

### Pożycz mu SWAT od narzędzi

Mała grupa od narzędzi buduje to, czego zespół pilotażowy nie zbuduje sam: feature flagi, szybsze pipeline’y, cokolwiek wyjdzie z listy punktów tarcia. Po pilotażu SWAT staje się zwykłym zespołem z większą liczbą ludzi.

### Przytnij obszary do liderów, których masz

Tomáš skrócił listę kandydatów na obszary dla autonomicznych zespołów z 18 do 5. Każdy obszar potrzebuje mocnego lidera po stronie inżynierii i mocnego lidera po stronie produktu, a Tomáš ma pięć takich par. Obecni liderzy biorą mniej obszarów, za to szerszych, bez nowej warstwy zarządzania.

## Business case w sześciu slajdach: przykład i co bym dodał

Z taką prezentacją chciałbym, żeby Tomáš wszedł na salę. Każdy slajd odpowiada na jedno pytanie, które zarząd i tak zada.

| Slajd | Na jakie pytanie odpowiada | Co na nim jest |
| --- | --- | --- |
| 1\. Ile kosztuje dziś | Na co idą nasze pieniądze na inżynierię? | Podział mocy przerobowych, udział pracy nieplanowanej, w pieniądzach, według zlecającego działu |
| 2\. Dlaczego jesteśmy wolni | Dlaczego więcej ludzi nas nie przyspiesza? | Wspólne komponenty, na które czeka każdy zespół |
| 3\. Kontrakt | Na co zespoły będą poświęcać czas zamiast tego? | Docelowy podział dla każdego typu zespołu, zasada 90/10, raport co sprint |
| 4\. Wymiana | Z czego rezygnujemy i kiedy to wraca? | Koszt kwartału, narastające saldo, przychód, jeśli adopcja się utrzyma |
| 5\. Papierek lakmusowy | Skąd będziemy wiedzieć, zanim postawimy na to całą organizację? | Zadanie referencyjne, zespół pilotażowy, data pierwszego odczytu |
| 6\. Kto odpowiada za wynik | Kto sprawi, że szybsza maszyna zacznie zarabiać? | KPI dowożenia, KPI adopcji, imienni właściciele, skala ocen |

Konspekt, arkusz mocy przerobowych i arkusz zwrotu spakowałem do darmowego zestawu: [pobierz zestaw z szablonem business case dla platformy](https://www.marian.coach/downloads/platform-business-case-kit.zip) (zip, 16 KB: Markdown, Word i trzy arkusze CSV, na razie po angielsku, bez podawania e-maila).

Przynieś propozycję, nie samą fotografię stanu. Sam stan zachęca do pytania „czemu tyle na wsparcie?”, a potem decyduje ktoś inny. Niech dane zbierają Twoi dyrektorzy. Twoje zadanie to je zinterpretować i zaproponować jedną zmianę.

Co sprint raportuj kontrakt względem rzeczywistości. Co kwartał moje 100% było podzielone na trzy uzgodnione pudełka, produkt, technologię i całą resztę, i sprawdzałem je w każdym sprincie. Kiedy rozjazd rośnie, właściwa decyzja bywa paradoksalna: zatrzymaj prace techniczne na dwa sprinty i rób produkt, żeby wrócić do równowagi.

A najtrudniejsze przychodzi po „tak”. Nie wszyscy się przestawią, bo albo nie biorą na siebie odpowiedzialności, albo nie potrafią pracować w parze i mają za duże ego. Kilka z tych osób będzie musiało odejść.

Tomáš wyszedł ze zgodą na start pilotażu. Pierwszy odczyt jeszcze przed nim, więc liczb z jego zadania referencyjnego nie mogę Ci jeszcze pokazać. Kiedy się pojawią, dopiszę je tutaj. Co powie Twój zarząd, kiedy poprosisz o jeden kwartał i obiecasz trzy z powrotem? Jeśli chcesz zbudować ten slajd razem ze mną, zanim go pokażesz, do tego służy mój [mentoring dla CTO](https://www.marian.coach/cto-mentor/).

## Najczęstsze pytania

### Jak przekonać CEO do inwestycji w zespół platformowy?

+

Poproś o konkretną ilość czasu roadmapy, w jednym kwartale, i powiedz, kiedy ten czas wróci. Pokaż, ile w pieniądzach kosztują dzisiejsze moce przerobowe, jaka ich część jest nieplanowana, co zespół platformowy zrobi z odzyskanym czasem i jaką hipotezę przychodową daje tempo, które zyskasz potem. Na koniec wskaż, kto po stronie produktu odpowiada za adopcję tego, co szybsze zespoły dowiozą.

### Jak przygotować business case dla platform engineering?

+

Sześć slajdów: ile kosztuje stan obecny, dlaczego jesteście wolni, kontrakt na moce przerobowe dla każdego typu zespołu, wymiana (jeden kwartał oddany, trzy z powrotem), jedno zadanie referencyjne jako papierek lakmusowy oraz sparowane KPI dowożenia i adopcji. Każda liczba jest albo zmierzona przez Twoich liderów zespołów, albo opisana jako hipoteza.

### Jaki procent czasu zespołu inżynierskiego powinien iść na platformę, a jaki na nowe funkcje?

+

Nie ma uniwersalnego podziału. Jedna z firm, którym pomagam jako mentor, celuje w zespołach platformowych w 30% na produkcję, 50% na otwieranie komponentów dla innych zespołów i 20% na funkcje, a w zespołach produktowych w 10% na produkcję, 10% na zmiany w platformie i 80% na funkcje. Reguła kciuka Marty'ego Cagana z SVPG oddaje inżynierii z góry 20% całych mocy przerobowych, więcej, jeśli system jest w złym stanie.

### Jaki jest zwrot z inwestycji w zespół platformowy i kiedy się zwraca?

+

Licz go w mocach przerobowych roadmapy: co oddajesz w kwartale inwestycji, a co odzyskujesz potem. W przykładowym planie z tego tekstu zespoły zwalniają na mniej więcej dwa miesiące, inwestycja wychodzi na zero w trzecim kwartale, a pod koniec czwartego jest już na plusie. Stronę pieniężną liczysz jako przychód przypisany do nowych funkcji pomnożony przez dodatkowy wynik zespołów.

### Dowozimy więcej funkcji, a przychody się nie ruszyły. Dlaczego szybsza inżynieria miałaby pomóc?

+

Sama z siebie nie pomoże. Szybkość zamienia się w przychód dopiero wtedy, gdy ktoś odpowiada za adopcję tego, co trafia na produkcję. Połącz KPI inżynierii za dowożenie roadmapy z KPI produktu za adopcję, oceniaj każdą inicjatywę po wydaniu, a szybsza maszyna dostanie do przerobienia pracę, która zarabia.

[Mentoring 1:1](https://www.marian.coach/engineering-manager-mentor/)

## Chcesz przejść od rad do działania?

Mentoring 1:1 dla Engineering Managerów, Tech Leadów i CTO. 317 mentee od 2019 roku. Za sesję ocenioną poniżej 8/10 nie płacisz. Pierwsze intro jest bezpłatne.

[Umów bezpłatne 30-minutowe intro →](https://www.marian.coach/meet)

## Czytaj dalej

-   [![Przed AI Engineering Manager tkwi w plątaninie strzałek łączących go z zespołem i innymi managerami; po AI między managerem a zespołem stoi warstwa AI, skryptów i danych](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/infographic.webp)
    
    ### Rozpiętość kierowania: 16+ podwładnych dzięki AI
    
    Rozpiętość kierowania od 5 do 8 osób to limit obiegu informacji. AI dla managerów w praktyce: EM prowadzi 26 podwładnych w tych samych godzinach.
    
    1 listopada 2026 · Autor: Marian
    
    Czytaj →
    
    
    
    ](https://www.marian.coach/pl/blog/how-many-direct-reports-too-many/)
-   [![Jak rozmawiać z zarządem: najpierw wyceń, potem się spieraj](https://www.marian.coach/images/blog/how-to-talk-to-executives/infographic.webp)
    
    ### Jak rozmawiać z zarządem: najpierw wyceń, potem się spieraj
    
    Inżynier przegrywa spór z zarządem, kiedy ma rację w złej walucie. Wyceń obie opcje, przynieś liczbę trafną w 80% i wróć z rekomendacją.
    
    20 października 2026 · Autor: Marian
    
    Czytaj →
    
    
    
    ](https://www.marian.coach/pl/blog/how-to-talk-to-executives/)
-   [![Spec-driven development w SAP: z 19 dni do 5,5](https://www.marian.coach/images/blog/spec-driven-development-sap/infographic.webp)
    
    ### Spec-driven development w SAP: z 19 dni do 5,5
    
    18-osobowy zespół SAP skrócił medianę czasu cyklu z 19 do około 5,5 dnia w pięć tygodni. Zdaniem zespołu najbardziej pomogła ocena specyfikacji przed ABAP.
    
    25 października 2026 · Autor: Marian
    
    Czytaj →
    
    
    
    ](https://www.marian.coach/pl/blog/spec-driven-development-sap/)

### Nowe artykuły prosto na Twoją skrzynkę.

Your emailZapisz się

Jesteś na liście.

Dziś nic nie przyjdzie. Pierwszego maila wyślę, gdy lista ruszy, a Ty będziesz na niej od początku.

[Connect on LinkedIn →](https://www.linkedin.com/in/mariankamenistak/)[See the free tools →](https://www.marian.coach/ai-coaching-tools/)

## Structured data

```json
{"@context":"https://schema.org","@type":"ProfessionalService","name":"Marian Kamenistak | Engineering Leadership Mentoring","url":"https://www.marian.coach/pl/blog/platform-team-business-case/","image":"https://www.marian.coach/images/blog/platform-team-business-case/infographic.webp","description":"Zarząd nie płaci za procenty. Business case dla platform engineering: jeden kwartał roadmapy, zwrot w trzech, dowożenie w parze z adopcją produktu.","serviceType":["Engineering leadership mentoring","Engineering manager coaching","CTO coaching","Fractional CTO","Leadership development for software engineers"],"hasOfferCatalog":{"@type":"OfferCatalog","name":"Engineering leadership mentoring and advisory","itemListElement":[{"@type":"Offer","itemOffered":{"@type":"Service","name":"1:1 engineering leadership mentoring","description":"One-to-one mentoring for engineering leaders from Staff Engineer to CTO. 60-minute sessions, weekly or bi-weekly.","url":"https://www.marian.coach/pricing/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Engineering manager coaching","description":"Coaching for first-time and experienced engineering managers: delegation, performance, hiring, team scaling.","url":"https://www.marian.coach/engineering-manager-mentor/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"CTO and VP Engineering mentoring","description":"Mentoring for CTOs, VPs of Engineering and Heads of Engineering running 30-200 person organisations.","url":"https://www.marian.coach/cto-mentor/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Mentor in Residence","description":"A dedicated onsite mentor for your engineering organisation, booked by the quarter.","url":"https://www.marian.coach/mentor-in-residence/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Fractional CTO","description":"Part-time CTO engagements for companies without a full-time technology leader.","url":"https://www.marian.coach/fractional-cto/"}}]},"telephone":"+420 736 519 879","email":"marian@marian.coach","sameAs":["https://www.linkedin.com/in/mariankamenistak/","https://www.youtube.com/@engineeringleaders","https://github.com/marian-kamenistak","https://www.engineeringleaders.io/","https://www.elc-conference.io/","https://www.marianslist.com/","https://www.mentoringhub.io/"],"address":{"@type":"PostalAddress","streetAddress":"Varšavská 715/36, Vinohrady","addressLocality":"Praha 2","postalCode":"12000","addressCountry":"CZ"},"geo":{"@type":"GeoCoordinates","latitude":50.0734418,"longitude":14.4385757},"openingHoursSpecification":[{"@type":"OpeningHoursSpecification","dayOfWeek":["Monday","Tuesday","Wednesday","Thursday","Friday"],"opens":"09:00","closes":"17:00"}],"priceRange":"329–395 EUR","areaServed":[{"@type":"Place","name":"Europe"},{"@type":"Country","name":"Czechia"},{"@type":"Country","name":"Slovakia"},{"@type":"Country","name":"Poland"},{"@type":"Place","name":"North America"}]}
{"@context":"https://schema.org","@type":"Person","@id":"https://www.marian.coach/#person","name":"Marian Kamenistak","url":"https://www.marian.coach/","image":"https://www.marian.coach/images/blog/platform-team-business-case/infographic.webp","jobTitle":["Engineering Leadership Mentor","Fractional CTO & Chief AI Officer","Founder, Engineering Leaders Community","Engineering Manager Coach","CTO Coach","Keynote Speaker"],"hasOccupation":[{"@type":"Occupation","name":"Engineering Leadership Mentor"},{"@type":"Occupation","name":"Fractional CTO & Chief AI Officer"}],"worksFor":{"@type":"Organization","name":"Engineering Leaders Community","url":"https://www.engineeringleaders.io/"},"alumniOf":[{"@type":"Organization","name":"Mews"},{"@type":"Organization","name":"Databricks"}],"knowsLanguage":["English","Czech","Slovak"],"knowsAbout":["Engineering leadership","Engineering management","Scaling engineering teams","CTO mentoring","Engineering org design","VP of Engineering role","Engineering director role","CTPO role","Team lead development","Staff engineer career path","Fractional CTO engagements","AI-assisted engineering leadership","Conference keynotes on engineering leadership","Panel moderation","Podcast guest — engineering leadership"],"homeLocation":{"@type":"Place","name":"Prague, Czechia"},"sameAs":["https://www.linkedin.com/in/mariankamenistak/","https://www.youtube.com/@engineeringleaders","https://github.com/marian-kamenistak","https://www.engineeringleaders.io/","https://www.elc-conference.io/","https://www.marianslist.com/","https://www.mentoringhub.io/","https://www.crunchbase.com/person/marian-kamenistak","https://www.wikidata.org/wiki/Q140488098","https://developers.mews.com/author/marian/","https://startupdisrupt.com/speakers/marian-kamenistak/","https://theorg.com/org/engineering-leaders-community/org-chart/marian-kamenistak"]}
{"@context":"https://schema.org","@type":"WebPage","url":"https://www.marian.coach/pl/blog/platform-team-business-case/","name":"Platform engineering: business case, który przekona zarząd","inLanguage":"pl","dateModified":"2026-11-01T00:00:00.000Z"}
{"@context":"https://schema.org","@type":"FAQPage","inLanguage":"pl","mainEntity":[{"@type":"Question","name":"Jak przekonać CEO do inwestycji w zespół platformowy?","acceptedAnswer":{"@type":"Answer","text":"Poproś o konkretną ilość czasu roadmapy, w jednym kwartale, i powiedz, kiedy ten czas wróci. Pokaż, ile w pieniądzach kosztują dzisiejsze moce przerobowe, jaka ich część jest nieplanowana, co zespół platformowy zrobi z odzyskanym czasem i jaką hipotezę przychodową daje tempo, które zyskasz potem. Na koniec wskaż, kto po stronie produktu odpowiada za adopcję tego, co szybsze zespoły dowiozą."}},{"@type":"Question","name":"Jak przygotować business case dla platform engineering?","acceptedAnswer":{"@type":"Answer","text":"Sześć slajdów: ile kosztuje stan obecny, dlaczego jesteście wolni, kontrakt na moce przerobowe dla każdego typu zespołu, wymiana (jeden kwartał oddany, trzy z powrotem), jedno zadanie referencyjne jako papierek lakmusowy oraz sparowane KPI dowożenia i adopcji. Każda liczba jest albo zmierzona przez Twoich liderów zespołów, albo opisana jako hipoteza."}},{"@type":"Question","name":"Jaki procent czasu zespołu inżynierskiego powinien iść na platformę, a jaki na nowe funkcje?","acceptedAnswer":{"@type":"Answer","text":"Nie ma uniwersalnego podziału. Jedna z firm, którym pomagam jako mentor, celuje w zespołach platformowych w 30% na produkcję, 50% na otwieranie komponentów dla innych zespołów i 20% na funkcje, a w zespołach produktowych w 10% na produkcję, 10% na zmiany w platformie i 80% na funkcje. Reguła kciuka Marty'ego Cagana z SVPG oddaje inżynierii z góry 20% całych mocy przerobowych, więcej, jeśli system jest w złym stanie."}},{"@type":"Question","name":"Jaki jest zwrot z inwestycji w zespół platformowy i kiedy się zwraca?","acceptedAnswer":{"@type":"Answer","text":"Licz go w mocach przerobowych roadmapy: co oddajesz w kwartale inwestycji, a co odzyskujesz potem. W przykładowym planie z tego tekstu zespoły zwalniają na mniej więcej dwa miesiące, inwestycja wychodzi na zero w trzecim kwartale, a pod koniec czwartego jest już na plusie. Stronę pieniężną liczysz jako przychód przypisany do nowych funkcji pomnożony przez dodatkowy wynik zespołów."}},{"@type":"Question","name":"Dowozimy więcej funkcji, a przychody się nie ruszyły. Dlaczego szybsza inżynieria miałaby pomóc?","acceptedAnswer":{"@type":"Answer","text":"Sama z siebie nie pomoże. Szybkość zamienia się w przychód dopiero wtedy, gdy ktoś odpowiada za adopcję tego, co trafia na produkcję. Połącz KPI inżynierii za dowożenie roadmapy z KPI produktu za adopcję, oceniaj każdą inicjatywę po wydaniu, a szybsza maszyna dostanie do przerobienia pracę, która zarabia."}}]}
{"@context":"https://schema.org","@type":"BlogPosting","headline":"Platform engineering: business case, który przekona zarząd","description":"Zarząd nie płaci za procenty. Business case dla platform engineering: jeden kwartał roadmapy, zwrot w trzech, dowożenie w parze z adopcją produktu.","inLanguage":"pl","articleSection":"engineering-management","datePublished":"2026-11-01T00:00:00.000Z","dateModified":"2026-11-01T00:00:00.000Z","author":{"@id":"https://www.marian.coach/#person"},"publisher":{"@type":"Organization","name":"Marian Kamenistak","url":"https://www.marian.coach/","logo":{"@type":"ImageObject","url":"https://www.marian.coach/favicon-192x192.webp","width":192,"height":192}},"image":{"@type":"ImageObject","url":"https://www.marian.coach/images/blog/platform-team-business-case/infographic.webp"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.marian.coach/pl/blog/platform-team-business-case/"},"keywords":"engineering-management, platform-engineering, cto, leadership","wordCount":2764,"timeRequired":"PT13M","isAccessibleForFree":true}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Strona główna","item":"https://www.marian.coach/pl/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://www.marian.coach/pl/blog/"},{"@type":"ListItem","position":3,"name":"Platform engineering: business case, który przekona zarząd","item":"https://www.marian.coach/pl/blog/platform-team-business-case/"}]}
```