Článek přináší detailní pohled na polochou strukturu engineering týmů během transformace Directu.

Tenhle modul rozebírá tři propojené věci:

1. Plochá struktura v praxi — jak vypadala a co se (ne)změnilo
2. Self-design scaling — samoorganizované škálování rostoucích týmů
3. Kompetenční matice — jak udělat z růstu do šířky něco měřitelného

‍

Duben 2025: z maticového podporovatelství plochá struktura

Když v dubnu 2025 padly formální role a hierarchie, říkal jsem si, že je to jen krok, který stejně už všichni žijeme: z „frontenďáků" a „backenďáků" se dávno staly Rychlé roty, Legendy, Strážci a Migranti. Málokdo říkal „jsem frontendista" — spíš „jsem Migrant" nebo „jsem Legenda". Stačilo sepsat pár směrnic s people and culture týmem a právníky, a tím dotáhnout formální stránku.

Nové role

• Developer — jednotná role (na trhu dnes spíš software engineer nebo product engineer; v mém podání totéž).
• Technology lead — většinou z původních team leaderů. Nově mají na starost technologii jako celek a fungují jako mentoři: ne „dovzdělat a babysittovat", ale starat se, aby se kompetence kolem dané technologie rozvíjely a aby se držel technologický backlog napříč aplikacemi.
• Development lead — původní „kladívka", pravé ruce Product Ownerů; zodpovídají za end-to-end dodávku.
• Agilní kouči — ve stejné rovině; konečně se posunuli blíž k produktovým týmům a organizaci.

Začali jsme tím budovat team-based organizační design s tyrkysovými a self-design principy.

Jak to fungovalo v praxi

Všech 70 lidí bylo na jedné hromadě v jednom týmu přímo pod Engineering týmem. Na samotném fungování se nic dramatického nezměnilo. Každý developer věděl, který technology lead mu s rozvojem pomůže, a který development lead je ten jeho parťák v jeho businessovém segmentu.

Zajímavá změna byla v tom, co lídři „vidí". Historicky měli team leadeři lidi ve struktuře, takže viděli i organizační detaily (peníze, dovolené). Technology leadi a kladívka tohle najednou neviděli — a na to si museli zvyknout. Předávali jsme tak zodpovědnost do lidí.

Self-design scaling: jak škálovat tým, který přerostl

Jak týmy dorostly na 12 i víc lidí, narazili jsme na klasický problém: velký tým má horší vzájemnou koordinaci i komunikaci. Klasické řešení je rozdělit ho shora a přidělit práci. My jsme šli jinudy — samoorganizovaně, přes self-design pattern:

• Tým pořád pracoval nad jedním společným backlogem.
• Refinement dělal celý tým — všichni rozuměli celku a směru.
• Na planningu přišel Product Owner, ukázal priority — a tým se sám rozpadl podle práce do mikrotýmů (menších skupinek).
• Sprintová práce pak běžela v malých, efektivních mikrotýmech.

Jednou větou: refinovali jako celý tým, sprintovali jako efektivní mikrotým.

To zásadní: nikdo týmy neřezal a neurčoval, kdo na čem dělá. Lidé se podle práce a kompetencí rozdělili sami, sprint co sprint. Byla to přesně ta schopnost, která se osvědčila už v krizovém létě 2024 — jen teď zvládnutá vědomě a opakovaně.

‍

Kompetenční matice: jak udělat z růstu do šířky něco měřitelného

Aby šířka („hrabičky") nebyla jen heslo, potřebovali jsme ji zviditelnit. Vznikla kompetenční matice se dvěma osami.

Osa 1: technické dovednosti — do detailu

Ne jen hrubé „backend / frontend / databáze / mobil", ale konkrétní klíčové kompetence každé technologie. Tady jsme objevili něco důležitého:

Lidé se výrazně aktivněji učí, když přesně vědí, co se učí. Málokterý backenďák se chtěl učit „frontend" (styly, layouty). Ale „sáhnout si do JavaScriptové logiky"? Tam se cítil doma. A naopak — kdo chtěl do backendu, bál se nastavování serverů, ale „nadesignovat si API" ho lákalo.

Rozpad na konkrétní kompetence (ne jen technologie) tedy nebyl administrativa — byl to motor učení.

Osa 2: seniorita v dané dovednosti (úrovně 1–5)

Každá dovednost měla úroveň zvládnutí:

• 1 — přispěvatel: umím si rozjet projekt a upravit základní věci (např. v Reactu změnit proměnnou, obsah checkboxu, rozšířit formulář);
• pokračuje přes juniora a seniora až po architekta.

Každá úroveň měla popsané, co člověk musí umět. A jedno chytré pravidlo navíc: aby ses stal seniorem v nějaké kompetenci, musel jsi mentorovat někoho méně zkušeného. Tím jsme systémově — ne dobrovolnicky — zabudovali do firmy mentor-mentee vztahy.

(sem vizuál: ukázka kompetenční matice + graf vývoje počtu kompetencí na developera v čase)

‍

Velké překvapení: poměr „hrabičkářů" vyskočil na 70 %

Číslo, které překvapilo i mě.

Co tomu pomohlo: dřív tam byl skrytý blok — „jsem frontendista, víc peněz dostanu, až budu seniornější frontendista." My jsme začali jasně říkat: peníze zvedneme i za růst do šířky. A nebylo to jen heslo — mělo to konkrétní mechaniku. Peníze se v Directu vyhodnocovaly každé půl roku, a při tom hodnocení jsme se dívali přímo do kompetenční matice: posun člověka do šířky (nové kompetence, vyšší úrovně) byl jedním z podkladů, na jejichž základě měl, nebo neměl nárok na přidání. Nemusel si o to nikdo zvlášť říkat — růst byl vidět v matici a promítal se do hodnocení. Pro mě je člověk, který umí víc kompetencí, minimálně stejně cenný jako úzký specialista. Peníze samozřejmě nebyla ta jediná motivace, ale jednoduše se na nich ten posun znázorňuje.

Pozor — cílem nikdy nebylo mít jen full-stacky ani jen generalisty, ani jen specialisty. Vždycky šlo o zdravý poměr. Hloubka je pořád potřeba; jen už není jediná cesta, jak být cenný a růst.

‍

Co si z tohoto modulu vzít

1. Plochá struktura funguje, když jen formalizuje realitu — ne když ji násilím předbíhá. Nejdřív změňte fungování, pak teprve organigram.
2. Velký tým nemusíte řezat shora. Self-design pattern (jeden backlog, refinement celku, samorozpad na planningu) škáluje bez mikromanagementu.
3. Rozpadněte kompetence do detailu — lidé se učí ochotněji, když vidí konkrétní dovednost, ne abstraktní „technologii".
4. Zabudujte mentoring do definice seniority. „Senior = mentoruje" udělá z rozvoje ostatních povinnost, ne dobrovolnictví.
5. Odměňujte šířku, ne jen hloubku — jinak vám lidé zůstanou zabarikádovaní ve své specializaci a budou na sebe čekat.

‍