Kdy přestává být výhoda dělat všechno sám?

Když člověk začíná podnikat nebo stavět vlastní produkty, schopnost udělat si co nejvíc věcí sám je obrovská výhoda.

Napíše kód. Udělá web. Zavolá klientovi. Připraví nabídku. Vyřeší problém v produkci. Zkontroluje výsledek a večer ještě vystaví fakturu.

Nemusí čekat na ostatní a většinu problémů dokáže odstranit jednoduše tím, že si k nim sedne.

Dlouho jsem přesně takhle fungoval i já.

A dává to smysl. Na začátku není potřeba budovat sofistikovanou organizační strukturu. Potřebujete hlavně dostat věci ven, získat zákazníky a zjistit, co vůbec funguje.

Jenže postupně nastane zvláštní moment.

To, co firmu na začátku zrychlovalo, ji začne brzdit.

Protože pokud všechny důležité věci stále vedou přes jednoho člověka, růst firmy znamená hlavně to, že na stejného člověka přichází čím dál víc práce, rozhodnutí a problémů.

A tehdy už nestačí být dobrý builder.

Je potřeba začít fungovat jako operator.

Builder mode je na začátku správně

Nemyslím si, že by měl founder od prvního dne přemýšlet, jak se z každé práce co nejrychleji odstranit.

Naopak.

Právě období, kdy je člověk hluboko uvnitř samotné práce, mu často vytvoří znalosti, bez kterých by později nedokázal dobře řídit ostatní.

Když sám realizuje projekty, vidí, kde vznikají problémy. Zjistí, co zákazníci skutečně očekávají. Pozná, které části práce jsou komplikované, co se pravidelně opakuje a kde se nejvíc ztrácí čas.

Tohle se velmi špatně učí z dashboardu.

Builder má navíc jednu obrovskou výhodu: velmi krátkou vzdálenost mezi problémem a řešením.

Něco nefunguje?

Opraví to.

Klient něco potřebuje?

Vyřeší to.

Je potřeba rychle změnit produkt?

Udělá změnu.

V malé firmě je tahle schopnost extrémně cenná.

Problém není builder mode.

Problém je zůstat v něm příliš dlouho.

V určitou chvíli se vlastní schopnost stane bottleneckem

Tohle je na celé změně asi nejméně intuitivní.

Čím schopnější founder je, tím déle může špatně škálovatelný způsob fungování udržet při životě.

Pokud dokážu rychle vyřešit problém, je jednodušší ho prostě vyřešit než někomu vysvětlovat, jak ho má řešit příště.

Pokud dobře znám klienta, je rychlejší odpovědět mu sám.

Pokud dokážu nejlépe zkontrolovat kvalitu výstupu, mám tendenci projít všechno před odevzdáním.

Každé jednotlivé rozhodnutí dává smysl.

V součtu ale vznikne firma, ve které jsem postupně součástí téměř každého workflow.

Řeším klienty, priority, kvalitu práce, obchod, finance, problémy v projektech a zároveň se pořád snažím dělat část samotné produkce.

Čím více práce firma získá, tím více jí dokáže tým odbavit.

Ale zároveň vzniká více věcí, které se nakonec stejně vrátí ke mně.

A v určité chvíli začne být jasné, že další růst už neomezuje schopnost týmu něco vyrobit.

Omezuje ho moje pozornost.

To je podle mě jeden z hlavních momentů přechodu z buildera na operatora.

Operator není člověk, který přestal pracovat

Slovo operator může působit, jako by šlo o člověka, který už nic nevyrábí a pouze deleguje práci ostatním.

Takhle ten rozdíl nevnímám.

Operator stále řeší problémy. Jen se snaží řešit jinou jejich vrstvu.

Builder se ptá:

Jak to udělám?

Operator častěji:

Jak zajistíme, aby se tohle spolehlivě dělo?

To je zásadní rozdíl.

Pokud nám například pravidelně unikají follow-upy s klienty, builder může otevřít inbox a všechny je doposílat.

Operator řeší, proč se vůbec může stát, že follow-up závisí na tom, jestli si na něj někdo vzpomene.

Pokud se opakovaně odevzdávají projekty s podobnými chybami, builder chyby opraví před odevzdáním.

Operator přemýšlí, proč je systém kontroly nezachytil dřív.

Pokud člen týmu neví, co má dělat dál, builder mu úkol zadá.

Operator řeší, proč další krok nebyl jasný už ze systému práce.

Výsledek je pomalejší okamžitě, ale rychlejší dlouhodobě.

A právě tohle pro mě bylo těžké pochopit.

Když umíte něco vyřešit za deset minut, je psychologicky velmi těžké strávit hodinu tím, že nastavíte způsob, díky kterému to příště nebude muset řešit nikdo.

Největší změna není delegace. Je to změna vlastní definice produktivity.

Builder má velmi jednoduchý pocit produktivity.

Na konci dne vidí, co vytvořil.

Dokončený web. Napsaný kód. Odeslanou nabídku. Vyřešený problém. Hotový design.

Operator může mít na konci velmi důležitého dne mnohem méně hmatatelných výsledků.

Rozhodl, co se dělat nebude.

Upravil odpovědnosti v týmu.

Vyřešil problém, který by jinak vznikal každý týden.

Dal člověku kontext, díky kterému bude příště schopný rozhodnout sám.

Zrušil proces, který už nedával smysl.

Nastavil způsob kontroly kvality.

Na první pohled toho „neudělal“ tolik.

Ve skutečnosti ale mohl ovlivnit stovky hodin budoucí práce.

Tohle je podle mě jeden z největších mentálních přechodů.

Přestat měřit vlastní hodnotu podle množství práce, kterou jsem osobně dokončil, a začít ji měřit podle výsledku systému, za který odpovídám.

Delegovat práci je jednoduché. Delegovat odpovědnost už méně.

Delegace bývá často prezentovaná jako relativně mechanická věc.

Máte moc práce, takže část úkolů dáte někomu dalšímu.

Jenže samotné přesunutí tasku problém příliš neřeší, pokud musí founder i potom každé rozhodnutí schválit, všechno kontrolovat a pokaždé doplňovat chybějící kontext.

V takovém případě jsme nedelegovali práci.

Jen jsme vytvořili další handoff.

Člověk něco připraví → founder to projde → vrátí připomínky → člověk to předělá → founder znovu zkontroluje.

Kapacita možná trochu narostla, ale rozhodovací bottleneck zůstal stejný.

Skutečná delegace podle mě nastává až ve chvíli, kdy druhý člověk rozumí:

• jakého výsledku chceme dosáhnout,
• podle čeho poznáme dobrou práci,
• jaké jsou hranice jeho rozhodování,
• které trade-offy jsou přijatelné,
• a kdy má problém eskalovat.

Pak nepředávám pouze task.

Předávám část ownershipu.

A to je mnohem těžší.

Nejtěžší je přijmout, že někdo jiný to udělá jinak

Builder si během let vytvoří vlastní způsob práce.

Ví, jak by napsal konkrétní část kódu. Jak by strukturoval nabídku. Co by napsal klientovi. Jak by navrhl řešení.

Když potom stejnou práci převezme někdo jiný, téměř vždy ji udělá trochu jinak.

A první instinkt bývá:

Já bych to udělal jinak.

Otázka ale není, jestli bych to udělal stejně.

Otázka je, jestli je výsledek dostatečně dobrý.

Pokud existuje pouze jedna správná formulace každého e-mailu, jedna správná cesta implementace a jeden správný způsob řešení každého problému, nikdy se z operativy skutečně nedostanu.

Musím být schopný oddělit věci, kde na přesném postupu opravdu záleží, od věcí, kde je důležitý hlavně výsledek.

To neznamená snížit standard.

Znamená to standard konečně definovat.

Kvalita nesmí existovat pouze v hlavě foundera

Tohle je podle mě jedna z největších pastí.

Founder často ví, že určitý výstup „není dost dobrý“.

Jenže když se ho někdo zeptá proč, odpověď je směs zkušenosti, intuice a desítek detailů, které nikdy nebyly nikde popsány.

Dokud všechno dělá sám, není to problém.

Jakmile práci přebírá tým, stává se z toho zásadní omezení.

Pokud standard existuje pouze v mojí hlavě, jsem jediný člověk, který může garantovat jeho dodržování.

A pak se není čemu divit, že mám pocit, že musím všechno kontrolovat.

Řešením není kontrolovat rychleji.

Je potřeba dostat větší část tohoto standardu ven.

Co musí být vždy hotové před odevzdáním?

Které věci kontrolujeme?

Jak vypadá kvalitní výsledek?

Které chyby jsou nepřijatelné?

Co člověk může rozhodnout sám?

Nemusí z toho vzniknout obrovský manuál.

Často stačí checklist, dobré zadání, šablona, příklad kvalitního výstupu nebo několik jasných pravidel.

Pointa je v tom, že kvalita se musí stát vlastností procesu, ne vlastností mojí přítomnosti.

Informace se musí přesunout z hlavy do firmy

Podobné je to s kontextem.

Na začátku mám v hlavě prakticky všechno.

Pamatuji si, co klient řekl před třemi měsíci. Proč jsme se rozhodli něco udělat určitým způsobem. Co jsme mu slíbili. Kdo na čem pracuje a co má následovat.

Dokud je firma malá, může to fungovat překvapivě dobře.

Jenže každý další projekt, člověk a zákazník přidává další informace.

A lidská hlava není databáze.

Ve chvíli, kdy se mě ostatní musí pravidelně ptát na informace, které by mohl znát systém, nejsem už jen zdrojem kontextu.

Jsem API s velmi špatným uptime.

Proto pro mě přechod k operatorovi znamená také postupně přesouvat znalost tam, kde k ní mají přístup ostatní.

Rozhodnutí do projektů.

Procesy do dokumentace.

Úkoly do projektového řízení.

Klientský kontext tam, kde se s ním skutečně pracuje.

Ne proto, že bych měl potřebu všechno dokumentovat.

Ale proto, aby firma nemusela při každém rozhodnutí načítat informace z jednoho člověka.

Pozor ale na opačný extrém

Když člověk začne řešit systém, velmi snadno propadne procesům.

Najednou má každá činnost SOP. Každý problém checklist. Každý status meeting. Každý projekt deset custom polí.

Firma možná přestane být závislá na founderovi, ale začne být závislá na administrativě.

To není cíl.

Systém má práci zjednodušovat, ne dokazovat, že jsme procesně vyspělí.

Pokud je rychlejší se normálně domluvit než vyplňovat formulář, pravděpodobně formulář nepotřebujeme.

Pokud proces řeší problém, který se stane jednou za půl roku, možná nemá cenu ho formalizovat.

Pokud se naopak stejná věc pokazila potřetí během měsíce, pravděpodobně už nechci řešit její čtvrtý výskyt ručně.

Operator podle mě není člověk, který všechno převádí na proces.

Je to člověk, který dokáže rozlišit, co stojí za systematizaci a co je lepší prostě jednou vyřešit.

Můj kalendář začal být dobrý diagnostický nástroj

Jedna z věcí, podle kterých jde vlastní roli poměrně dobře poznat, je způsob, jakým člověk tráví čas.

Pokud je většina týdne stále zaplněná úkoly, které musí osobně vykonat, je velmi pravděpodobné, že pořád převažuje builder mode.

To nemusí být špatně.

Já stále chci být blízko samotným projektům, technologiím a práci pro klienty. Nechci se dostat do pozice, kdy už jen sleduji dashboardy a vůbec nevím, co se uvnitř firmy skutečně děje.

Rozdíl je v něčem jiném.

Chci si práci vybírat podle toho, kde má moje přímá účast největší hodnotu, ne podle toho, kde zrovna vznikla díra, kterou nikdo jiný neumí zaplnit.

To znamená trávit víc času směrem, klíčovými rozhodnutími, klientskými vztahy, kvalitou systému a problémy, které zatím nemají jasné řešení.

A méně času opakující se prací, kterou lze předat, standardizovat nebo automatizovat.

To je pro mě mnohem užitečnější definice přechodu z buildera na operatora než „přestat dělat“.

Čtyři změny, které jsou podle mě nejdůležitější

Kdybych ten přechod měl zjednodušit, vidím ho hlavně ve čtyřech změnách.

1. Z tasků na výsledky

Místo kontroly, kolik práce bylo hotovo, řešit, jestli jsme dosáhli toho, čeho jsme chtěli dosáhnout.

To zní jednoduše, ale mění to způsob zadávání práce, reportingu i hodnocení lidí.

2. Z řešení problémů na odstraňování jejich příčin

Ne každý problém potřebuje proces.

Opakující se problém ale pravděpodobně potřebuje něco víc než další jednorázovou opravu.

3. Z delegování práce na delegování rozhodování

Cílem není mít tým lidí, kteří čekají, až jim founder řekne další krok.

Cílem je mít lidi, kteří dokážou stále větší množství správných rozhodnutí udělat sami.

4. Z osobní kontroly na kontrolní mechanismy

Nemůžu být finální QA vrstva úplně všeho.

Potřebuji systém, který dokáže většinu chyb zachytit dřív a ke mně dostane hlavně věci, kde je skutečně potřeba můj úsudek.

Právě tady podle mě vzniká leverage.

Ne v tom, že začnu pracovat rychleji.

Ale v tom, že kvalita výsledku začne být čím dál méně závislá na množství mojí osobní práce.

Přechod není jednorázový

Neexistuje ráno, kdy se člověk probudí jako builder, a večer už je operator.

Obě role se dlouhou dobu překrývají.

Jeden den řeším směr firmy a delegaci. Druhý den sedím několik hodin nad technickým problémem, protože právě tam v danou chvíli dává moje práce největší smysl.

To mi nepřijde jako selhání přechodu.

Cílem podle mě není odstranit buildera.

Schopnost něco skutečně vytvořit je pořád obrovská výhoda. Umožňuje zůstat blízko produktu, rozumět realitě a v případě potřeby se dostat hluboko do problému.

Jen už nesmí být jediným způsobem, jakým vytvářím hodnotu.

Pokud je firma větší než já, nemůže růst pouze tím, že já budu pracovat víc.

Co tedy znamená stát se operatorem?

Dřív bych odpověděl něco jako: delegovat, automatizovat a vytvářet procesy.

Dnes mi to přijde příliš povrchní.

Skutečná změna je podle mě v odpovědnosti.

Builder nese odpovědnost hlavně za svoji práci.

Operator postupně nese odpovědnost za prostředí, ve kterém vzniká práce ostatních.

Za to, jestli jsou priority jasné.

Jestli informace proudí na správná místa.

Jestli lidé dokážou rozhodovat.

Jestli se kvalita dá opakovat.

Jestli systém ukáže problém dostatečně brzo.

A jestli firma dokáže fungovat i ve chvíli, kdy jeden konkrétní člověk není k dispozici.

Tohle je mnohem méně uspokojivé než dokončit něco vlastníma rukama.

Ale zároveň to vytváří úplně jiný typ leverage.

Na začátku podnikání jsem problémy často řešil větou:

„Já to udělám.“

Dnes mi čím dál častěji přijde důležitější jiná otázka:

„Co musíme změnit, aby to příště nemuselo čekat na mě?“

A právě někde mezi těmito dvěma větami podle mě začíná přechod z buildera na operatora.

Zdroje

• Donella H. Meadows — Thinking in Systems: A Primer
• Andrew S. Grove — High Output Management