---
title: "Business case pro platform engineering: přesvědč vedení"
description: "Vedení nefinancuje platformní týmy podle procent. Požádej o jeden kvartál roadmapy, ukaž návratnost do tří a spáruj delivery s adopcí produktu."
url: "https://www.marian.coach/cs/blog/business-case-pro-platform-engineering/"
lang: "cs"
image: "https://www.marian.coach/images/blog/platform-team-business-case/infographic.webp"
---

![Business case pro platform engineering: přesvědč vedení](https://www.marian.coach/images/blog/platform-team-business-case/infographic.webp)

„Letos jsme vydali víc funkcí než loni. Tržby jsem neviděl.“ Tohle odpověděl Head of Product, když Tomáš, VP Engineering, slíbil vedení trojnásobný výkon. Business case pro platformní tým je žádost, která takovou odpověď přežije: jeden kvartál kapacity roadmapy a doložený plán, jak se v penězích vrátí do tří kvartálů.

Tomáš (ve skutečnosti se jmenuje jinak) vede tech oddělení v B2B SaaS firmě. Jeho platformní týmy tráví 60 % času udržováním produkce, 2 % otevíráním svých komponent ostatním týmům a 38 % stavěním funkcí. Produktové týmy se bez nich nepohnou, takže každá iniciativa napříč týmy čeká v něčí frontě.

Jeho deck byl dobrý. Závislosti nakreslené jako špagety, autonomní týmy, cíl 3×. Každé číslo v něm bylo v procentech.

Jeden slide chyběl a řekl jsem mu to. V celém decku nebyl ani jeden dolar. [Developer Coefficient od Stripe](https://stripe.com/files/reports/the-developer-coefficient.pdf) zjistil, že vývojáři stráví 17,3 hodiny ze 41,1hodinového týdne údržbou, špatným kódem a technickým dluhem. Tvoje vedení ten účet už platí, tak mu ukaž fakturu.

## Vedení schvaluje datum návratnosti investice

Zeptej se ChatGPT, jak prosadit peníze na platformní tým, a poradí ti, ať to „přestaneš prodávat jako zlepšení v engineeringu a začneš to prodávat jako byznysovou investici“. Pravda, jenže to nestačí. Investice bez data je přání.

Tak to datum řekni. „Dej mi polovinu Q1. Do konce roku ti ji vrátím a od té doby pojedeme rychleji.“ Neškrábeš na dveře kvůli času na platformu. Jsi VP, který prodává investici.

Procento svádí k vyjednávání o procentu. Doba návratnosti investice svádí k rozhodnutí a to rozhodnutí patří lidem v místnosti. Přesně tam ho chceš mít.

Účet je dost velký, aby to unesl. CIO v průzkumu [McKinsey](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity) přiznali, že 10 až 20 % technologického rozpočtu určeného na nové produkty skončí u tech debtu.

Tomáš měl štěstí. Jeho CEO zažil víkend před výjezdem vedení vlastní moment „vlak nám ujíždí“ a byl připravený roadmapu rozbít. Jenže mandát nevznikne z jedné hodiny mluvení a slide s návratností je to, s čím se budeš vracet pořád dokola. V Mews a ve firmách, kterým od té doby radím, jsem viděl, že ten boj trvá půl roku až rok, než to lidem dojde: neprodáváš pomalejší roadmapu, zrychluješ firmu.

## Změř, kam kapacita teče, než si o ni řekneš

Datum návratnosti neprodáš na odhadu dnešního stavu. První slide ukazuje, kam čas teče teď, a čísla musí přijít od týmů, ne od tebe.

### Pět kategorií: plánovaná, nebo neplánovaná práce

Rozděl čas každého týmu na práci na roadmapě, investici do platformy, reaktivní práci na produkci (incidenty, on-call, hotfixy), eskalace od zákazníků a pomoc jiným týmům. První dvě kategorie jsou plánované, zbylé tři většinou ne. Neplánovaný podíl je tvoje hlavní číslo: říká, kolik místa na roadmapu tvoje týmy doopravdy mají.

### Žádné výkazy hodin

Každý team lead rozdělí člověkodny svého týmu do pěti kategorií. Zabere to patnáct minut a přesnost ±10 % stačí. Dva týdny to jeď jako pilot, pak přepni na klouzavých šest týdnů, protože jeden velký incident dva týdny úplně rozhodí.

### Zapiš, kdo o práci požádal

Ke každé kategorii napiš, která divize o práci požádala. Z kapacity se tím stane rozpočet, který můžeš rozdělit: „Tvoje divize má tenhle kvartál 400 člověkodnů, co do nich půjde, rozhoduješ ty.“ Nový požadavek je pak výměna a spor o priority se přesune k lidem, kterým priority patří.

### Převeď dny na peníze

Člověkodny krát plná cena jednoho dne, tedy mzda, odvody a režie. To je číslo, které CFO čte. Jestli jsi pro vedení ještě nikdy nenaceňoval technické rozhodnutí, menší verzi téhle úvahy jsem popsal v článku [komunikace s vedením](https://www.marian.coach/cs/blog/komunikace-s-vedenim/).

Takhle vypadalo Tomášovo měření a cíl. Jsou to čísla jedné skutečné firmy, anonymizovaná. Cíl pro produktové týmy je cíl, ne měření.

| Typ týmu | Práce | Dnes | Cíl |
| --- | --- | --- | --- |
| Platformní týmy | Udržování produkce v chodu | 60 % | 30 % |
| Platformní týmy | Otevírání komponent ostatním týmům | 2 % | 50 % |
| Platformní týmy | Funkce pro zákazníky | 38 % | 20 % |
| Produktové týmy | Udržování produkce v chodu | 35 % | 10 % |
| Produktové týmy | Změny v platformě (formou příspěvků do jejího kódu) | 3 % | 10 % |
| Produktové týmy | Funkce pro zákazníky | 62 % | 80 % |

Podívej se na poslední řádek. Produktové týmy už teď dávají do funkcí 62 % času.

Brzdí je těch 35 %, kdy se ohlížejí za produkcí, a fronta, ve které stojí na platformu. Víc kapacity na funkce je vedlejší efekt toho, že tohle odstraníš. Jestli chceš, aby se ti na čas tvých týmů někdo podíval zvenku, než tenhle slide postavíš, k tomu je [audit produktivity engineering týmů](https://www.marian.coach/cs/engineering-teams-productivity-audit/).

Pro srovnání mimo jednu firmu: pravidlo Martyho Cagana ze [SVPG](https://www.svpg.com/engineering-wants-to-rewrite/) dává engineeringu 20 % kapacity hned na začátku, a víc, když je systém ve špatném stavu.

## Tvůj platformní tým má stavět funkce až nakonec

Tomášovo pořadí priorit pro platformní týmy: nejdřív produkce, potom otevírání komponent, funkce až nakonec. 30 % na produkci je cílový podíl, ne strop. Když produkce hoří, vyhrává produkce.

![Ručně kreslená skica s nadpisem Platform teams (platformní týmy). Vlevo přeškrtnuto 60% production (produkce) a 38% features (funkce). Vpravo zeleně zakroužkováno 30% production, 50% open components (otevřené komponenty) a 20% features.](https://www.marian.coach/images/blog/platform-team-business-case/capacity-flip.webp)

Obrat u platformních týmů, o který Tomáš požádal: produkce z 60 % na 30 %, otevřené komponenty na 50 %, funkce na 20 %. Dnešní 2 % na otevírání komponent na obrázku nejsou.

Proč funkce až nakonec? Deset autonomních týmů, které všechny potřebují stejných pět lidí ve sdíleném jádru, nejsou deset paralelních proudů. Pár týdnů jedou rychle a pak zase čekají na review, odpovědi a závislosti.

Fronta se jen přesunula. [Výzkum DORA](https://dora.dev/capabilities/platform-engineering/) tomu říká „downstream disorder“, tedy nepořádek v dalších fázích: co se získá rychlejším psaním kódu, spolknou úzká hrdla v testování, bezpečnostním review a dál.

### 10 % vlastnit, 90 % otevřít

Malá sada komponent zůstává vlastněná od začátku do konce: autentizace, autorizace, ochrana soukromí, věci, u kterých chceš být opatrný. V Tomášově plánu je to asi 10 % změn. Zbylých 90 % bude „vlastněných, ale otevřených“. Vlastník je oddělí od zbytku, zdokumentuje, sepíše záměry a limity, přidá testy a postaví bezpečné cesty, aby kterýkoli tým mohl přispět, aniž by rozbil jádro.

![Ručně kreslená skica dvou krabic. Malá fialová: Critical components 10% (kritické komponenty), owned end to end, auth, authorization, privacy. Větší zelená: Open components 90% (otevřené komponenty), any team contributes, se šipkami ze všech stran.](https://www.marian.coach/images/blog/platform-team-business-case/critical-open.webp)

Pravidlo 90/10: 90 % změn teče přes otevřené komponenty.

### Příspěvky tečou oběma směry

Produktové týmy mění platformu, když to potřebují. Platformní týmy mění produktový kód, když to potřebuje produkce, třeba když něco spadne nebo výkonově nestíhá. Obě strany musí unést, že jim v kódu sedí někdo jiný. Roky silného vlastnictví obalily v Tomášově firmě každou komponentu byrokracií a on chce 90 % z ní pryč.

### Nestav do šuplíku

Žádná schopnost „protože se za tři roky může hodit“. Stav, co tým potřebuje teď. Platforma jde tam, kam jdou produktové týmy, a neutíká jim napřed.

### Platformu měř podle toho, jak rychle běží ostatní

Platformní týmy se měří tím, o kolik rychleji dodávají produktové týmy, ne tím, co samy postavily. Tak v praxi vypadá platformní tým podle [Team Topologies](https://teamtopologies.com/key-concepts): interní produkt, který existuje proto, aby zrychlil stream-aligned týmy, tedy ty, které dodávají přímo zákazníkům. O samotné roli jsem psal v článku [platform engineer](https://www.marian.coach/cs/platform-engineer/).

Opačný názor si zaslouží férové slyšení. [Report DORA za rok 2024](https://dora.dev/research/2024/2024-DORA-Report-Infographic.pdf) zjistil, že dedikovaný platformní tým zvedá produktivitu týmů o 6 %, ale u těch, kdo platformu používají, klesla průchodnost o 8 %. Špatně udělaná platforma tě zpomalí. Právě proto ji měříš rychlostí ostatních týmů a nejdřív ji dokážeš na jednom úkolu.

## Převeď procenta na peníze: slide jeden za tři

Tohle je slide, který Tomáš neměl. Tvoří ho tři čísla.

### Kolik ten kvartál stojí

Člověkodny přesunuté z roadmapy krát plná cena dne. To je tvoje investice v penězích.

### Kdy se vrátí

Výstup roadmapy, který v investičním kvartálu ztratíš, proti tomu, co po něm získáš, kvartál po kvartálu, dokud průběžný zůstatek nepřejde do plusu. Počítej s tím, že týmy asi na dva měsíce zpomalí, nebo se skoro zastaví, zatímco si osvojují nové nástroje a nový způsob práce. Řekni to na slidu nahlas: zpomalíme, abychom pak jeli rychleji.

Zrychlení si nevymýšlej. Vezmi ho z pilotu (o něm další sekce). Co ukáže benchmarkový úkol při prvním měření, to je tvoje číslo pro Q2, a dál, než pilot dokázal, neextrapoluješ.

### Kolik to vynese

Tvůj CPO by měl vědět, kolik tržeb každý kvartál děláte a kolik z nich se připisuje nové funkcionalitě. To je tvoje cena za kvartál roadmapy. Výsledek dej na slide jako hypotézu, ale číslo tam dej. Teprve pak se lidi přestanou přít, jestli to vůbec dovolit.

Takhle to vypadá s čísly vymyšlenými pro tenhle článek (ilustrativní, ne Tomášova). Výstup je v „dnešních kvartálech“, kde 1,0 je kvartál jako ten současný, a z nové funkcionality pochází 3 mil. USD tržeb za kvartál.

| Kvartál | Výstup roadmapy | Průběžný zůstatek | Tržby navíc proti dnešku, pokud adopce vydrží |
| --- | --- | --- | --- |
| Q1, investice | 0,5 | −0,5 | −1,5 mil. USD |
| Q2 | 1,2 | −0,3 | +0,6 mil. USD |
| Q3 | 1,4 | +0,1, bod zvratu | +1,2 mil. USD |
| Q4 | 1,6 | +0,7 | +1,8 mil. USD |

Jeden kvartál dáš, tři ti ho vrátí: na konci Q4 jsi 0,7 kvartálu napřed, zhruba 2,1 mil. USD. Když druhý rok udrží rychlost z Q4, je to 0,6 kvartálu výstupu navíc každý kvartál, zhruba 7,2 mil. USD ročně.

Přečti si záhlaví posledního sloupce ještě jednou. „Pokud adopce vydrží“ je námitka Head of Product napsaná na tvém vlastním slidu. Kvůli ní existuje další sekce.

Práce na spolehlivosti a bezpečnosti dostane číslo v tržbách taky. [ValueSum](https://www.rubick.com/valuesum-metric/) od Jadea Rubicka boduje dodanou položku tak, že 100 bodů znamená přidat 100 % ARR za jeden rok, vynásobeno pravděpodobností úspěchu. Jeho příklad se spolehlivostí, krok za krokem:

| Krok | Body |
| --- | --- |
| Třetině zákazníků kvůli téhle nestabilitě hrozí, že odejdou | 33 |
| Jsou to spíš velcí zákazníci, takže jde zhruba o 45 % tržeb | 45 |
| Skutečné riziko odchodu na zákazníka je asi 20 %: 45 × 20 % | 9 |
| Poškozená pověst to zdvojnásobí: 9 × 2 | 18 |

Rubick ti dává i argument pro stálý podíl na platformu místo boje o každý projekt: „určité procento každé tech organizace by se mělo věnovat věcem, které organizaci časem zefektivní“, protože taková práce „obvykle přijde zkrátka“, když optimalizuješ jen na dodanou hodnotu.

## „Dodali jsme víc a tržby se nehnuly“ je správná námitka

Head of Product měl pravdu. To, že zrychlíme stroj, neznamená, že tou rychlostí budeme dodávat správné věci. [Report Pendo o adopci funkcí](https://go.pendo.io/rs/185-LQW-370/images/Pendo_Whitepaper_2020_FeatureAdoptionReport_Refresh.pdf) zjistil, že 80 % funkcí v průměrném softwarovém produktu se používá zřídka nebo vůbec.

Business case proto potřebuje druhého vlastníka. Řekl jsem Tomášovi, jak jsme to dělali v [Mews](https://www.mews.com/), kde jsem jako VP Engineering vybudoval tech z 8 na 80 týmů. Moje KPI, podle kterého mě znali: každý kvartál jsem dodal aspoň 80 % roadmapy. Kdybych nedodal, mohli mě vyhodit.

Sledoval jsem to jako podíl na roadmapě: kolik procent času mých týmů jde na roadmapu a kolik mimo ni. Dva týmy, které z jakéhokoli důvodu pracují mimo roadmapu, ohrozí celý kvartál. Svoje manažery jsem učil pravidlo, podle kterého jsem žil: když mi nepřineseš roadmapu, mám problém i já.

Můj produktový protějšek měl jiné KPI. „Díky, Mariane, žes mi postavil rychlý stroj. Jenže já do něj musím házet věci.“ Jeho prací bylo krmit mou roadmapu věcmi, na kterých záleží, a měřilo se to adopcí produktu. Nastavili jsme to schválně tak, abychom fungovali jako dvojčata.

> Rychlejší stroj sám nic neprodá. Někdo musí vlastnit to, co do něj jde.

Každá iniciativa byla zamčená v kvartálu a měla v [Jiře](https://www.atlassian.com/software/jira) vlastní pole se známkou adopce. Přiznám se, známkovali jsme ručně, žádnou automatickou metriku jsme neměli:

| Známka | Co znamená | Počítá se do 65 %? |
| --- | --- | --- |
| Ultra vysoká | Vydělává nám hodně peněz | Ano |
| Vysoká | Podle očekávání | Ano |
| Neutrální | Vydělá, co stála: lidi, licence, infrastrukturu | Ne |
| Katastrofa | Nevydělá ani na svoje náklady | Ne |
| K vyhodnocení | Na známku je brzo, povoleno nejvýš na jeden kvartál | Ne |

K dobrému produktovému rozhodnutí patří i načasování, takže nic nezůstane bez známky déle než kvartál.

Já měl 80 % dodané roadmapy. Šéf produktu vedle mě měl 65 % adopce produktu, tedy známku vysoká nebo ultra vysoká. Čekání se nepočítá, protože čekání peníze nevydělává.

A upřímně, řvali jsme na sebe. „Držím pro tebe rychlou roadmapu a ty do ní házíš šmejd? Pak jsou moji lidi nešťastní a někdo odejde.“

Občas jsem řekl, že nějaká věc do roadmapy nepatří. Občas chtěl on něco označit za úspěch a já řekl, že úspěch to asi není. Jenže to už jsou diskuse, které mají smysl: o hodnotě.

Rubick dochází ke stejnému závěru z druhé strany. Doporučuje každou funkci znovu obodovat [tři nebo šest měsíců po dodání](https://www.rubick.com/valuesum-metric/) a nechat si předpovězené i zpětné skóre. Z jeho práce bych převzal ještě dvě pravidla: hodnotu bodují šéfové produktu nebo divizí, ne tech, a skóre nepoužíváš k hodnocení jednotlivců ani týmů.

Tomášovi se zatím nepodařilo prosadit KPI adopce nahoře, takže jeho verze dvojčat sedí o úroveň níž. Každá autonomní oblast dostane Product Managera a Engineering Managera, kteří spolu vlastní jeden byznysový výsledek. Pár by měl existovat na každé úrovni: tým, director, VP, CTO a CPO. Jestli jsi [Engineering Director](https://www.marian.coach/cs/engineering-director-mentor/) a stavíš tohle pod úrovní VP, tvůj produktový protějšek je tvoje dvojče.

## Dokaž to na jednom úkolu, než si řekneš o celou organizaci

Tomáš sám napsal malou změnu v kódu, svoji první za dva roky. Měla trvat tři hodiny. Review, pipeliny a informace, které nemohl najít, totiž jak změna dopadne na zákazníky, z ní udělaly den vývoje. Schvalovací brány pak protáhly nasazení na týden.

Z toho úkolu se stal benchmark:

| Benchmarkový úkol | Dnes | Konec pilotu | Dlouhodobě |
| --- | --- | --- | --- |
| Vývoj | 1 den | ~4 hodiny | 2 hodiny |
| Nasazení | 1 týden | pár dní | 2 hodiny |

Pro pilot si dal jeden cíl. Do prvního měření se zlepší 60 % míst, kde to na cestě toho úkolu drhne. Každé je malé, tady hodina, tam půl hodiny, jinde patnáct minut.

Pokud tvoje týmy pracují s AI agenty, patří do seznamu toho, co drhne, i to, co agent neumí: uvidět pomalý endpoint dřív než zákazník, znát historii produktu, spustit si vývojovou instanci, sledovat nasazení.

### Na pilot vyber klidný tým

Tomáš začal s týmem, který měl lehkou roadmapu, aby pilot nezabil plán. Referenci potřebuješ dřív než transformaci.

### Půjč mu SWAT na nástroje

Malá skupina pro nástroje postaví, co si pilotní tým nepostaví sám: feature flagy, rychlejší pipeliny, cokoli si seznam řekne. Po pilotu se ze SWATu stane normální tým s víc lidmi.

### Oblastí udělej tolik, kolik máš lídrů

Tomáš zkrátil seznam kandidátních oblastí pro autonomní týmy z 18 na 5. Každá oblast potřebuje silného technického a silného produktového lídra a pět takových párů má. Stávající lídři vlastní méně oblastí, zato širších, a žádná nová vrstva vedení nevzniká.

## Business case na šest slidů: vzor a co bych přidal

S takovým deckem bych chtěl, aby Tomáš přišel. Každý slide odpovídá na jednu otázku, kterou se někdo z vedení stejně zeptá.

| Slide | Otázka, na kterou odpovídá | Co na něm je |
| --- | --- | --- |
| 1\. Kolik stojí dnešek | Kam jdou naše peníze na vývoj? | Rozdělení kapacity, neplánovaný podíl, v penězích, podle divize, která práci zadala |
| 2\. Proč jsme pomalí | Proč nás víc lidí nezrychlí? | Sdílené komponenty, na které čeká každý tým |
| 3\. Dohoda o kapacitě | Na co budou týmy místo toho dávat čas? | Cílové rozdělení podle typu týmu, pravidlo 90/10, report každý sprint |
| 4\. Výměna | Čeho se vzdáme a kdy se nám to vrátí? | Cena kvartálu, průběžný zůstatek, tržby, pokud adopce vydrží |
| 5\. Lakmusový test | Jak to poznáme, než vsadíme celou organizaci? | Benchmarkový úkol, pilotní tým, datum prvního měření |
| 6\. Kdo vlastní výsledek | Kdo zařídí, aby rychlejší stroj vydělával? | KPI za delivery, KPI za adopci, vlastníci jménem, škála známek |

Osnovu, tabulku kapacity a tabulku návratnosti jsem dal do kitu zdarma: [stáhni si kit pro business case platformy](https://www.marian.coach/downloads/platform-business-case-kit.zip) (zip, 16 kB, zatím anglicky: Markdown, Word a tři tabulky v CSV, bez e-mailu).

Přines návrh, ne jen fotku stavu. Samotný snímek svádí k otázce „proč tolik na support?“ a pak rozhodne někdo jiný. Data ať sbírají tvoji directoři. Tvoje práce je vyložit je a navrhnout jednu změnu.

Dohodu porovnávej s realitou každý sprint. Každý kvartál jsem měl svých 100 % rozdělených do tří dohodnutých přihrádek, produkt, tech a všechno ostatní, a každý sprint jsem je kontroloval. Když rozdíl roste, správné rozhodnutí je někdy paradoxní: na dva sprinty technickou práci zastavit a dělat produktovou, aby se rovnováha vrátila.

A ta těžká část přijde až po „ano“. Ne každý tu změnu udělá. Jedni nepřevezmou vlastnictví, druzí neumí pracovat v páru, protože mají velké ego. Pár z nich bude muset odejít.

Tomáš odešel se souhlasem spustit pilot. První měření ho teprve čeká, takže jeho benchmarková čísla ti zatím ukázat nemůžu. Až budou, doplním je sem. Co řekne tvoje vedení, až si řekneš o jeden kvartál a slíbíš tři zpátky? Jestli chceš ten slide postavit se mnou, než ho odprezentuješ, k tomu je můj [mentoring pro CTO](https://www.marian.coach/cs/cto-mentor/).

## Časté dotazy

### Jak přesvědčit CEO, aby investoval do platformního týmu?

+

Řekni si o konkrétní kus roadmapy v jednom kvartálu a rovnou řekni, kdy se vrátí. Ukaž, kolik dnešní kapacita stojí v penězích, jaká její část je neplánovaná, co platformní tým s uvolněným časem udělá a jakou hypotézu o tržbách máš pro rychlost, která přijde potom. Nakonec jmenuj člověka z produktu, který vlastní adopci toho, co rychlejší týmy dodají.

### Jak sestavit business case pro platform engineering?

+

Stačí šest slidů: kolik stojí dnešek, proč jsou týmy pomalé, dohoda o kapacitě pro každý typ týmu, výměna jednoho kvartálu za tři, jeden benchmarkový úkol jako lakmusový test a spárované KPI za delivery a za adopci. Každé číslo buď změřili tvoji team leadi, nebo je na slidu označené jako hypotéza.

### Kolik procent kapacity vývoje dát na platformu a kolik na nové funkce?

+

Univerzální poměr neexistuje. Jedna firma, kterou mentoruju, cílí u platformních týmů na 30 % produkce, 50 % otevírání komponent pro ostatní týmy a 20 % funkcí. U produktových týmů na 10 % produkce, 10 % změn v platformě a 80 % funkcí. Marty Cagan ze SVPG radí dát technickému týmu 20 % celé kapacity předem a víc, když je systém ve špatném stavu.

### Jaká je návratnost investice do platformního týmu a kdy se vrátí?

+

Počítej ji v kapacitě roadmapy: co v investičním kvartálu obětuješ proti tomu, co se ti vrátí potom. V ilustrativním plánu z tohoto článku týmy zhruba na dva měsíce zpomalí, bod zvratu přijde během třetího kvartálu a na konci čtvrtého jsi v plusu. V penězích jsou to tržby připsané nové funkcionalitě krát výstup navíc.

### Dodáváme víc funkcí a tržby se nehýbou. Pomůže vůbec rychlejší vývoj?

+

Sám od sebe ne. Rychlost se promění v tržby, jen když někdo vlastní adopci toho, co se dodá. Spáruj KPI tech oddělení za delivery roadmapy s KPI produktu za adopci, každou iniciativu po vydání oznámkuj a rychlejší stroj začne dostávat práci, která vydělává.

[Mentoring](https://www.marian.coach/cs/cto-mentor/)

## Chceš přesvědčit vedení o investici do platformy? Postavíme to spolu.

Naceníme dnešní kapacitu, nastavíme výměnu jednoho kvartálu za tři a s tvým produktovým protějškem domluvíme KPI adopce, ještě než vejdeš do místnosti. Jeden kvartál 1:1 mentoringu: 6 sessions za 3 měsíce.

[Zobrazit balíček Jeden kvartál →](https://www.marian.coach/cs/cenik/#pricing)

## Přečti si dál

-   [![Před AI (Before AI) sedí Engineering Manager v klubku šipek mezi týmem a kolegy (Team & peers); po AI (After AI) je mezi manažerem a týmem vrstva AI, skriptů a dat (AI, Scripts, Data)](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/infographic.webp)
    
    ### Span of control: kolik podřízených je moc? S AI zvládneš 16+
    
    Rozpětí řízení 5 až 8 lidí bylo stropem pro přehazování informací. S menteem jsme postavili EM Dashboard: EM vede 26 podřízených za stejnou pracovní dobu.
    
    1\. listopadu 2026 · Autor Marian
    
    Přečíst →
    
    
    
    ](https://www.marian.coach/cs/blog/how-many-direct-reports-too-many/)
-   [![Komunikace s vedením: nejdřív spočítej, pak argumentuj](https://www.marian.coach/images/blog/how-to-talk-to-executives/infographic.webp)
    
    ### Komunikace s vedením: nejdřív spočítej, pak argumentuj
    
    Inženýři prohrávají spory s vedením, protože mají pravdu ve špatné měně. Spočítej obě varianty, přines číslo na 80 % a vrať se s doporučením.
    
    20\. října 2026 · Autor Marian
    
    Přečíst →
    
    
    
    ](https://www.marian.coach/cs/blog/komunikace-s-vedenim/)
-   [![Mentor a engineering lídryně při rozhovoru 1:1 u kulatého stolku, mezi nimi cedulka mentoringové zóny.](https://www.marian.coach/_astro/mentoring-07.CaYSBaNE_Z29eHul.webp)
    
    ### Engineering Manager: co role vlastní a co předáváš
    
    Co je Engineering Manager? Role, skutečné odpovědnosti, co senior inženýr při přechodu předává dál a čtyři způsoby, jak se první rok pokazí.
    
    9\. října 2026 · Autor Marian
    
    Přečíst →
    
    
    
    ](https://www.marian.coach/cs/engineering-manager/)

### Nové články rovnou do mailu.

Your emailOdebírat

Jsi na seznamu.

Dnes ti nic nepřijde. První email pošlu, až bude seznam živý, a ty na něm budeš od začá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/cs/blog/business-case-pro-platform-engineering/","image":"https://www.marian.coach/images/blog/platform-team-business-case/infographic.webp","description":"Vedení nefinancuje platformní týmy podle procent. Požádej o jeden kvartál roadmapy, ukaž návratnost do tří a spáruj delivery s adopcí produktu.","serviceType":["Engineering leadership mentoring","Engineering manager coaching","CTO coaching","Fractional CTO","Leadership development for software engineers"],"hasOfferCatalog":{"@type":"OfferCatalog","name":"Mentoring a poradenství pro IT manažery","itemListElement":[{"@type":"Offer","itemOffered":{"@type":"Service","name":"1:1 mentoring pro IT manažery","description":"Mentoring 1:1 od Staff Engineera po CTO. Sezení na 60 minut, každý týden nebo jednou za dva.","url":"https://www.marian.coach/cs/cenik/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Koučink pro Engineering Managery","description":"Koučink pro první i zkušené Engineering Managery: delegování, výkon, hiring, škálování týmu.","url":"https://www.marian.coach/cs/engineering-manager-mentor/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Mentoring pro CTO a VP Engineering","description":"Mentoring pro CTO, VP of Engineering a Head of Engineering, kteří vedou organizace od 30 do 200 lidí.","url":"https://www.marian.coach/cs/cto-mentor/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Firemní mentor","description":"Dvorní mentor pro tvoji engineering organizaci, onsite, rezervovaný po kvartálech.","url":"https://www.marian.coach/cs/mentor-in-residence/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Fractional CTO","description":"Fractional CTO engagementy pro firmy, které nemají technického lídra na plný úvazek.","url":"https://www.marian.coach/cs/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/cs/blog/business-case-pro-platform-engineering/","name":"Business case pro platform engineering: přesvědč vedení","inLanguage":"cs","dateModified":"2026-11-01T00:00:00.000Z"}
{"@context":"https://schema.org","@type":"FAQPage","inLanguage":"cs","mainEntity":[{"@type":"Question","name":"Jak přesvědčit CEO, aby investoval do platformního týmu?","acceptedAnswer":{"@type":"Answer","text":"Řekni si o konkrétní kus roadmapy v jednom kvartálu a rovnou řekni, kdy se vrátí. Ukaž, kolik dnešní kapacita stojí v penězích, jaká její část je neplánovaná, co platformní tým s uvolněným časem udělá a jakou hypotézu o tržbách máš pro rychlost, která přijde potom. Nakonec jmenuj člověka z produktu, který vlastní adopci toho, co rychlejší týmy dodají."}},{"@type":"Question","name":"Jak sestavit business case pro platform engineering?","acceptedAnswer":{"@type":"Answer","text":"Stačí šest slidů: kolik stojí dnešek, proč jsou týmy pomalé, dohoda o kapacitě pro každý typ týmu, výměna jednoho kvartálu za tři, jeden benchmarkový úkol jako lakmusový test a spárované KPI za delivery a za adopci. Každé číslo buď změřili tvoji team leadi, nebo je na slidu označené jako hypotéza."}},{"@type":"Question","name":"Kolik procent kapacity vývoje dát na platformu a kolik na nové funkce?","acceptedAnswer":{"@type":"Answer","text":"Univerzální poměr neexistuje. Jedna firma, kterou mentoruju, cílí u platformních týmů na 30 % produkce, 50 % otevírání komponent pro ostatní týmy a 20 % funkcí. U produktových týmů na 10 % produkce, 10 % změn v platformě a 80 % funkcí. Marty Cagan ze SVPG radí dát technickému týmu 20 % celé kapacity předem a víc, když je systém ve špatném stavu."}},{"@type":"Question","name":"Jaká je návratnost investice do platformního týmu a kdy se vrátí?","acceptedAnswer":{"@type":"Answer","text":"Počítej ji v kapacitě roadmapy: co v investičním kvartálu obětuješ proti tomu, co se ti vrátí potom. V ilustrativním plánu z tohoto článku týmy zhruba na dva měsíce zpomalí, bod zvratu přijde během třetího kvartálu a na konci čtvrtého jsi v plusu. V penězích jsou to tržby připsané nové funkcionalitě krát výstup navíc."}},{"@type":"Question","name":"Dodáváme víc funkcí a tržby se nehýbou. Pomůže vůbec rychlejší vývoj?","acceptedAnswer":{"@type":"Answer","text":"Sám od sebe ne. Rychlost se promění v tržby, jen když někdo vlastní adopci toho, co se dodá. Spáruj KPI tech oddělení za delivery roadmapy s KPI produktu za adopci, každou iniciativu po vydání oznámkuj a rychlejší stroj začne dostávat práci, která vydělává."}}]}
{"@context":"https://schema.org","@type":"BlogPosting","headline":"Business case pro platform engineering: přesvědč vedení","description":"Vedení nefinancuje platformní týmy podle procent. Požádej o jeden kvartál roadmapy, ukaž návratnost do tří a spáruj delivery s adopcí produktu.","inLanguage":"cs","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/cs/blog/business-case-pro-platform-engineering/"},"keywords":"engineering-management, platform-engineering, cto, leadership","wordCount":2724,"timeRequired":"PT12M","isAccessibleForFree":true}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Domů","item":"https://www.marian.coach/cs/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://www.marian.coach/cs/blog/"},{"@type":"ListItem","position":3,"name":"Business case pro platform engineering: přesvědč vedení","item":"https://www.marian.coach/cs/blog/business-case-pro-platform-engineering/"}]}
```