16. října 2017

1:1, nejdůležitější nástroj team leadera

Říká se tomu one-on-one. V psané podobě můžete narazit na zápis OoO, O-o-O, 1on1 a různé další. Já používám 1:1, ale kreativitě se meze nekladou.

Za ta léta, co dělám team leadera, jsem se setkal s širokou paletou lidí a jejich zkušeností s 1:1. Jsou tací, kteří 1:1 nikdy neměli a někdy o něm dokonce ani neslyšeli. Jsou lidi, pro které je to jenom takový "manažment folklór". A pak je menšina těch, kteří 1:1 očekávají a vyžadují.

Jak už jsem psal v minulém článku (Technical Leader, mytické stvoření), potřebuju uzavřít určité období a shrnout, co jsem se naučil. Tady je moje moudro:
"Hlavním nástrojem vývojáře je IDE. Hlavním nástrojem Technical Leadera je Issue Tracking System. A hlavním nástrojem Team Leadera je 1:1." ~ SoftWare Samuraj

Můj příběh

Když jsem před nějakými osmi lety začal zvolna aspirovat na roli team leadera (ano, bylo to ještě předtím, než jsem začal psát tenhle blog), šel jsem na to svou obvyklou cestou, která se dá shrnout do tří slov: internet, knihy, praxe.

Hodně mi pomohl Michael Lopp, píšící blog Rands in Repose. Jeho nejlepší články tehdy vyšly v inspirativní knížce Managing Humans, na kterou mě upozornil na svém blogu Lukáš Křečan (jak to ten chlap dělá, že je vždycky o pár kroků přede mnou?).

Já sám jsem do té doby nikdy žádné pravidelné 1:1 neměl, jen takové to klasické performance review. Proto mě šokovalo, že bych měl organizovat 1:1 na týdenní bázi - neuměl jsem si to představit.

V té době jsem v někdejší firmě převzal/zdědil Java kompetenci. V reálu to znamenalo, že všichni seniornější Javisti už z firmy odešli. Nebylo od koho se učit, tak jsem si roli definoval sám. Naplánoval jsem si s klukama semestrální 1:1 a protože byli rozeseti na projektech po celé Praze, chodil jsem tam za nima.

Dalším milníkem bylo angažmá, kde došlo k nepřátelskému převzetí projektu (lehce jsem se tématu dotknul v článku (Ne)funkční tým). Pořád ještě jako juniorní team leader jsem bojoval, jak to šlo, podle svých tehdejších schopností. Jedna z věcí, které jsem zkusil a která byla dobrým krokem, bylo zavedení 1:1. Scházeli jsme se jednou za 1/4 roku.

A pak přišel další projekt - dostal jsem v kulminaci nálož 16 lidí (naštěstí to rostlo postupně). Opět jsem sáhl po knize (článek Management za zavřenými dveřmi) a opět jsem zredukoval periodu - scházeli jsme se na 1:1 jednou za měsíc.

   

Ano, už to přijde. Pointa. Ale tentokrát bez knihy. Když jsem nastupoval do nové práce, měl jsem neobvyklý luxus - mohl jsem si postavit svůj vlastní tým, úplně od začátku. S tímhle novým týmem jsem začal dělat to, co se všude radí bez výjimky - týdenní 1:1. Dělám to tak už téměř pět let a můžu jen konstatovat, že 1:1 je ten nejdůležitější nástroj, který team leader má.

Vize, benefit, smysl

1:1 je nástroj. Je to nástroj používaný mezi dvěma entitatmi - mezi team leaderem a členem týmu, ev. mezi manažerem a reportujícím. Aspektů, které tento nástroj může přinést je mnoho, ale já bych vypíchnul čtyři, které považuji za nejhodnotnější.
  • 1:1 je silný nástroj pro vytváření vztahu mezi team leaderem a členem týmu.
  • 1:1 kritický nástroj pro budování důvěry.
  • 1:1 je také nástroj na vytváření a ovlivňování týmové kultury.
  • A 1:1 je prostor a čas, který team leader dedikuje svým lidem.

Nejkritičtějším elementem je budování důvěry - pokud ve vztahu chybí důvěra, je těch benefitů jenom polovina (a míň).

Pravidla

Každý si umí představit analogii s autem, které potřebuje pravidelný servis, aby dobře fungovalo. Pokud ho zanedbáte (nebo už se to nevyplatí), tak se to nějak promítne, nastřádá. O 1:1 to platí také. A možná i víc, protože lidi nejsou stroje. Tady je pár pravidel, která vám můžou pomoct udržet 1:1 v dobrém stavu.

Pravidelnost

Běháte? Chcete uměhnout maraton (5k, 10k, 1/2 maraton)? Je potřeba, abyste pravidelně trénovali. Učíte se cizí jazyk? Je potřeba, abyste ho pravidelně procvičovali. Učíte se nový programovací jazyk/framework/technologii? Je potřeba je pravidelně používat. Jinak to nemá moc smysl a přínos je malý.

S 1:1 je to stejný. Jak říkal soudruh Lenin: pravidelnost, pravidelnost, pravidelnost. Rytmus je benefitem i podpůrnou konstrukcí.

Nezrušitelnost

Nikdy 1:1 nerušte. Nastavte si to jako železné pravidlo - jestli jste team leader, 1:1 je důležitejší než jakýkoli projekt. Projekt skončí, lidi vám zůstanou.

Když říkám nikdy, jsem si vědom absolutnosti toho slova. Já sám se snažím pít vodu, když kážu víno. Snažím se tomu ideálu aspoň přiblížit. Osobně to mám nastavené tak, že 1:1 ruším jenom když jsem (a) nemocný, (b) na dovolený, (c) na služební cestě. Pokud se něco kritického vyskytne v práci, snažím se 1:1 místo zrušení aspoň přeplánovat.

Rušení 1:1 má ještě jeden důležitý aspekt, ke kterému se vrátím v sekci Doporučení.

Respekt a vychování

Ono to přímo vyplývá ze zmíněného axiomu, že 1:1 je nástroj na vytváření vztahu - chovejte se ke členům svého týmu s respektem. Kromě běžné sociální slušnosti, bych vypíchnul reakci na vyrušení.

Na 1:1 neberte nikomu telefon. Nekontrolujte zprávy. Zdvořile odražte osobní vyrušení. Pokud vaše žena nejede do porodnice, tak vás nic neomlouvá, že se nevěnujete na 100 % člověku, kterého máte před sebou.

Mě když volá žena během 1:1 schůzky... típnu jí telefon. A zavolám potom. Když mi během 1:1 volá šéf, nezvednu mu to. Když šéf během schůzky vpadne do místnosti, řeknu že mám 1:1 a zastavím se potom. Za prvý jsem v právu a za druhý, je to slušnost.

Naslouchejte

Lidé ve vedoucích rolích mají často nepříjemný zlozvyk: moc mluví. I já - jako introvert - tím dost trpím a musím si to neustále (už po léta) připomínat. Někdy se mi to i daří. Naslouchejte. Poslouchejte, co vám kolegové chtějí říct. Když už máte jejich důvěru, tak ji nezahoďte.

Technology free

Předpokládám, že tohle hodně lidí šmahem odmítne, ale stejně to řeknu. Na 1:1 choďte bez technologií. Poznámky si pište na papír. Psát si během 1:1 na počítači - s libovonými bohulibými úmysly - je nevychované a neosobní. Pamatujete? Respekt a budování vztahu.

Pokud opravdu potřebujete mít vaše poznámky archivované na počítači, je to jenom vaše pohodlnost, co snižuje kvalitu komunikace.

Samozřejmě, pokud potřebujete svému kolegovi něco na počítači ukázat, je to v pořádku. Pokud ale před ním frontálně sedíte s počítačem před sebou, je to chucpe.

Obsah

Lidé, kteří se setkávají s 1:1 poprvé, můžou váhat, co je obsahem. Samozřejmě, je to primárně pracovní záležitost. Ale je v pořádku probírat i osobní a rodiné záležitosti. Jak tedy obsah 1:1 definovat?

Ještě než se přesunu k lehce konkrétním bodům, zmíním dva stěžejní principy:
  1. Nechte své kolegy spolu-vytvářet obsah 1:1. Ono i když se podíváte na ten zápis - 1:1 - mělo by to evokovat fifty-fifty, či win-win. Jsou věci, o kterých nemáte ani tušení, že by je vaši členové týmu chtěli řešit.
  2. Přizpůsobte 1:1 každemu člověku. Lidé jsou různí - mají různé povahy, senioritu, externí a životní zkušenosti, sociální a rodinný status. Můžou pocházet z jiných kultur a světadílů. Respektujte to a reflektujte to.

Pracovní témata

Pracovním tématem číslo jedna jsou problémy. Technologické problémy, projektové problémy, problémy ve vztazích v práci. To je to, co vaše lidi nejvíc trápí. Externí záležitosti vyřešit nemůžete, ale můžete aspoň svého kolegu vyslechnout a nabídnout empatii.

Interní problémy jsou dvojího druhu - ty, které daný člověk může vyřešit sám. Možná mu k tomu chybí odvaha, možná neví jak, možná jen potřebuje cítit vaši podporu. A pak interní problémy, které on vyřešit nemůže, ale můžete je vyřešit vy... protože jste (jeho) team leader. Tohle výživné téma by vydalo nejméně na článek - klíčové slovo: coaching.

Tématem číslo dva jsou úšpěchy. I drobné. Co se vašemu kolegovi povedlo? V čem se zlepšil? Co se naučil? Není u toho potřeba používat vyprázdněné superlativy, méně je více. Ale nemělo by to zapadnout.

Téma číslo tři: rozvoj. Co dělá váš kolega navíc, nad rámec "daily job"? Čte knihy? Zajímavý článek na internetu? Osobní projekt? Samozřejmě sem spadají i školení a podobné věci, i když ty se neplánují každý týden.

Téma číslo čtyři (záměrně není v TOP 3): něco jako "mikro-status". Záleží na kontextu. Pokud kolegu potkáváte na denním standupu, asi to nebude tak podstatný, možná i zbytečný. Pokud dělá na jiném projektu, hodí se vědět, jak vypadá aktuální projektový/technologický "snaphot". Bacha na micro-management!

Osobní témata

Asi je jasný, co se tím míní. Rozsah a hloubka se budou lišit od kvality vztrahu a míry důvěry. Já si běžně se členy týmu povídám o sportu, dovolený, rodině, koníčkách apod. Jde hlavně o to, co jste ochotni prozradit vy. (Jenom to nepřežeňte.)
"The most important action that a leader must take to encourage the building of trust on a team is to demonstrate vulnerability first." ~ Patrick Lencioni

Doporučení

Na závěr ještě pár doporučení, která rozvíjejí témata, která už zazněla.

Pokud vše dobře půjde, budete mít 1:1 s daným člověkem léta. Jak váš vzájemný vztah, tak vaše 1:1 by se mělo vyvíjet. Neupadněte do rutiny. Adaptujte (se). Změňte vaše individualizované 1:1 tak, aby to stále byl oboustranně prospěšný nástroj.

Jak už jsem naťuknul - neřešte problémy vašich lidí za každou cenu. Buďte umírnění a nechte je vyřešit maximum problémů, které zvládnou sami. Podpořte je, když selžou. Bez chyb není učení.

Vyhraďte si na 1:1 poznámky dedikovaný sešit. Budete mít historii na jednom místě.

A zlaté doporučení. Pokud vaši lidé odcházejí (z firmy) - stává se to - nerušte jim 1:1, ale pokračujte s nimi až do konce. Ukážete jim, že vám na nich i tak pořád záleží. V opačném případě budou mít pocit, že jste je hodili přes palubu.

Mind Map



Související články


3. října 2017

Technical Leader, mytické stvoření

tl;dr Pokud vás téma zajímá, ale nechce se vám číst dlouhý článek, skočte na sekci Model. Nic jiného číst nepotřebujete ;-)

Into the woods

Jak už jsem letos párkrát zmiňoval, procházím určitým přelomovým obdobím, jehož vedlejším, či hlavním(?) důsledkem je, že opouštím vyšlapané cesty. Prostě jsem si koupil bare-foot boty a sešel z dlážděných cest na trávu a lesní pěšiny.

Není to ale žádné pálení mostů. Jsem za tu cestu, kterou jsem urazil, vděčný a hodně jsem se na ní naučil. A abych mohl tenhle úsek putování uzavřít, rád bych se podělil ještě o několik témat, která do budoucna opouštím. Můj náhled, co to je technical leader, je jedním z nich.

Obiter dictum

Jako formální i neformální technical leader jsem pracoval řadu posledních let - v různém prostředí, pro různé zaměstnavatele, s různými týmy. Také jsem o této doméně hodně četl. Byla to role, která mne neskutečně bavila a ve které jsem se chtěl kontinuálně zlepšovat. Snad se mi to i dařilo.

Zároveň jsem viděl, jak lidé v mém blízkém a občas i (velmi) vzdáleném okolí tápou. Co by mělo být obsahem té role? Jak se mám naučit potřebné věci?

A občas jsem také viděl, jak měli lidé ambici stát se formálním technical leaderem, aniž by tušili co to obnáší a hrnuli se do toho s pouhými romantickými představami a vidinou nově deklarovaného statusu a finančních benefitů.

Kromě toho, že jsem sám v této roli pracoval, jsem i pár technical leaderů vychoval. No, vychoval - řekněme, že jsem jim nestál v cestě (ale to už je jiný příběh).

Takže i když vím, že "tam venku" existují lepší technical leadeři, než jsem já, cítím se trochu povolaný sdílet pár informací a osobních názorů. Už proto, že o tom nikdo moc nepíše. (A pár jednorožců už jsem viděl.)

Model

K roli technical leadera můžete mířit z jakékoli jiné technické role. Pro potřebu tohoto článku budeme vycházet z pozice vývojáře, ale můžete si za něj dosadit "obecného" (či specifického) SW Engineera.

Výchozím bodem by měl být vývojář, který je "rozumně" seniorní. Co znamená ono rozumně, nechám na vašem zdravém rozumnu ;-) Povýšení juniorního člověka na technical leadera nedává moc smysl.

K tomu, aby se člověk stal technical leaderem, musí mít, kromě svého ústředního skillu, ještě nějaký přesah. Co jsem za ty roky vypozoroval, je to většinou přesah do jedné ze tří oblastí: architektura, project management a team leading. A podobně jako u technical leadingu, mohou být tyto oblasti formální i neformální.


tl;dr Pokud jste rychločtenáři, můžete nyní přeskočit na sekci Gotický svorník (model re-visited). Pak už je to opravdu všechno :-P

Developer

Jedním z méně častých, i když také možných typů technical leadedra, je vývojář, který sice nemá přesah do výše naznačených oblastí, ale který má velmi hluboké znalosti své technické domény. Je to ten tzv. guru (trošku devalvované slovo, což?). Ale nejenom to - je také problem-solver a mentor. Umí vyřešit nejen své technické problémy, ale i svých kolegů a zároveň jim dát do "své" technologie potřebný vhled.

Uvádím tenhle typ jen pro úplnost. Většinou je zde někdy tenká, někdy hodně široká a rozmazaná hranice mezi velmi seniorním člověkem a "opravdovým" technical leaderem. Osobně jsem takových moc nepotkal. Ale je to validní cesta, pokud se necítíte povoláni k ostatním typům přesahů.

Architekt

Přesah do architektury je s přibývající senioritou běžný. Jako seniorní vývojář chcete vystrčit hlavu z písku své technické domény a podívat se, co se děje u souseda na dvoře. Časem si možná uvědomíte že mezi vaším (vývojářským) a sousedovým dvorem (architektura) není žádný plot. Jsou to dvě plochy téhož tělesa.

Jako technical leader s přesahem do architektury je vhodné umět navrhnout architekturu a zároveň ji zvládnout kompletně naimplementovat. Nikdy byste neměli z pusy vypustit ohavnou větičku, že něco je "implementační detail". To nechte ivory-tower architektům.

Je vhodné vidět daný software v celosti jeho life-cyclu. Nemít klapky na očích a nesoustředit se jen na aktuální (a nejzajímavější) vývojovou fázi. Jak například vypadají vaše logy? Budou sloužit jen pár měsíců vývojářům, nebo budou supportu/operations pomáhat roky na produkci?

Ovšem, není to jen o vás - je potřeba umět vysvětlit vaše návrhy svým méně seniorním kolegům a také jim pomoci s úseky, které jsou nad jejich síly (technicky, designově, myšlenkově).

Projekt Manager

Často se setkávám s tím, že vývojáři vlastně neví, za co je platí. Že dostávají peníze za to, že (efektivně) vyřeší nějaký business problém. To je věc, kterou si velmi dobře uvědomuje project manager - zná finanční rozměr projektu a měl by mít plán, jak to zvládnout.

Jako technical leader s přesahem do project managementu je vhodné umět sestavit implementační plán (v libovolné vyhovující formě). Naplánovat iteraci. Prioritizovat. Zvážit smysluplnost investovaného úsilí. Seřadit a spravovat časové slouslednosti - aby si vývojáři s tunelovým viděním nestěžovali, že je "něco" blokuje.

A také umět předvídat, odhalovat a mitigovat rizika. Umět řešit a případně eskalovat problémy: chybějící lidi, externí závislosti, nečekané události. Navrhnout a řídit vývojovou metodologii a umět ji podle kontextu modifikovat a přizpůsobit.

Team Leader

Team leader a technical leader jsou často překrývající se, nebo zaměňované pojmy. Temínem team leader zde myslím toho, kdo pracuje s lidmi, vede tým a má za něj zodpovědnost.

Jako technical leader s přesahem do team leadingu je vhodné... vést lidi. Komunikovat se svým týmem. Řešit jeho problémy a objevovat příležitosti. Mít individuální přístup k jeho členům - každý z nich je originál. Vystupovat jako facilitátor.

A nejpodstatnější věc - mít vizi a udržovat týmovou kulturu. Působit preventivně proti bad apples. Vytvořit dobře promazaný stroj, který vyhraje softwarové play-off.

Budu k vám upřímný. Tenhle přesah je ze všech nejtěžší a nejvíc adeptů na něm ztroskotá. Jde o to, se nepoložit a pokračovat. Zkusit to znova, až to půjde. Ono to půjde.

Gotický svorník (model re-visited)

V předšlých sekcích jsme naznačili možné přesahy, které může technical leader mít, kromě svého core-skillu. Někdy má přesah jen do jedné z těchto oblastí, někdy do dvou. Nejcennější ale je, pokud má přesah do všech tří domén a působí tak jako svorník klenby, která z těchto pilířů vyrůstá.


V reálním světě měnících se potřeb a požadavků, se ty přesahy budou organicky měnit a přelévat, někdy i během krátké doby (jednoho projektu). I když ale daný skill není zrovna potřeba, pořád obohacuje všechny zbývající aspekty.

Technical... Leader

Většina adeptů na technical leadera se soustředí na to první slovo v názvu role. Ale to druhé slovo - leader - tam není náhodně. Osobně bych řekl, že tenhle aspekt je v celkovém přínosu a smyslu ten důležitější. Protože technical leader, který není leader je jenom seniorní vývojář.

Důvod, proč je tato druhá složka opomíjená, je celkem prostý - techničtí lidé z ní mají obavy. Jak se stanu leaderem? Všichni uvidí, že to neumím! A tak se soustředí na to, co už dobře znají... technologie. Komfortní bublina. A možná tak trochu čekají, že ty věci kolem leadershipu, tak nějak přijdou samy. Snesou se z modrého nebe jako vavřínový věnec nesený holubicemi...

Ale něco vám řeknu: vy už jste se jako seniorn vývojáři narodili? Že ne? Že to trvalo léta praxe a učení se? Jasně, jasně. Prozradím vám tajemství: nic jako "natural born leader" neexistuje! Vede k němu úplně ta samá cesta, jakou jste už sami ušli. Zadejte si do Googlu heslo natural born leader a budete vědět, na čem ještě potřebujete pracovat. Většinou je to práce na celý život. Ale někdy se začít musí.

Jediná cesta?

Samozřejmě, že role technical leadera má mnoho podob. Kdybychom chtěli pokračovat v naznačeném modelu, mohli bychom přidat jako další oblast přesahu například business analýzu. Nebo QA. Nebo... Anebo modelovat/definovat tuhle měňavou roli úplně jinak.

Podstatné je dát vaší roli technical leadera to, co váš kontext potřebuje. Cesty páně jsou nevyzpytatelné a matka příroda je flexibilní a přizpůsobivá. Nechť vás síla na vaší cestě technical leadera provází.

Doporučená literatura

Pokud jste dočetli až sem, tak jste možná opravdoví čtenáři. A ti čtou opravdové knihy. O technical leadingu už pár titulů napsáno bylo. Jestli můžu doporučit jeden z nich, je to kniha Becoming a Technical Leader od Geralda Weinberga (@JerryWeinberg), která je jako truhlice narvaná drahokamy. Některé nedoceníte hned. Jak říká Jerry:
"Becoming a technical leader is not something that happens to you, but something that you do."

Související články


Související externí články