Sunday, September 8, 2024

How to successfully start in the engineering leadership role

A couple of years ago, I read the famous First 90 Days book that introduces many useful frameworks for how to succeed in a new position in a new company.

Armored by the book and partial experience with some principles, I joined Oddin.gg as a CTO. Here is what helped me the most within the first months.

Be explicit about your time — build your 30–60–90 plan

Usually, for these roles, you are hired to change critical things and set them up for success. The key is to figure out what these are and how to prioritize them. However, what you need is time to get context.

Therefore, I composed an early version of the 30–60–90 plan in Notion, or 15–45–90 if you want, just within the first days in the company. It’s open-ended with the focus on the first weeks so you can fill the remaining later.

I shared the doc with my direct manager, the CEO. First, to align who should I meet, what topics should I focus on, etc. Second, to create transparency about my time.

Equipped with this initial habit, we discuss the plan and progress weekly. New themes gradually popped up and formed a new backlog. Roughly in the month of the initial period, I had a very solid set of initiatives to crack later.

Using these to formulate the rest of the 30–60–90 plan was a natural progression — basically, they filled up the second and the third month. CEO and I discussed the progress on proposed changes weekly, validated inputs and outputs, and aligned on the next steps.

And, in the end, it was a mutual win-win. A great way for him to hand over the context and, for me, build the trust that I invested in the right next things.

Tip: make your 30–60–90 plan and the backlog public within the company, e.g. in Notion as a board, to make sure everyone in the organization can understand your direction.

Early wins

To name a chapter from the First 90 days with the biggest impact on my work, it’s definitely Secure early wins. As my previous manager used to say: your team must feel immediately that the job is better under your leadership.

You don’t have infinite time to succeed no matter how high your new role is on the career ladder. People expect immediate improvements.

The antipattern is to choose a big thing taking a lot of time as a first challenge. You might even not have enough space and time to accomplish it before the end of the trial period.

The best strategy is to focus on smaller challenges and fix them, so there is apparent evidence that you can bring success to the company. 

It doesn’t have to be complex or complicated challenges but rather something to show your capabilities.

Tip: focus on narrowing down some of the old wrongs that your role might influence.

Meet literally everyone in your org

To build your new backlog, you need to get as much context as possible.

Talk to everyone. Schedule initial 121s with all direct or indirect reports, introduce yourself and create a safe zone to enable sharing of the most inner thoughts, ideas, or feedback from people.

You want to create your fresh point of view so you might perceive other things as important than some else. 

Don’t listen only to your direct reports or peers, listen to everyone.

You can hear about unfair compensations, radical people, low transparency for decisions, or old unfulfilled promises. All these are the right input for your backlog and should influence your prioritization.

Tip: don’t be afraid to make early wins from small challenges from 121s discussions, these are good candidates.

Create your communication channels

Specifically in the remote companies, the communication is the key. It’s better to overcommunicate than undercommunicate.

In the age of Slack, create a set of channels so you can talk to your people — and they can talk to you.

I ended up with the four key channels:

  • to the whole org — all the people
  • to your direct reports
  • to all leaders in your org — PMs, engineering managers, or designers
  • to your peers — other directors, “C” level, etc.

Give others some time to get used to it, they will gradually start writing there as well.

Tip: you might appreciate having a naming policy for Slack channels if the count exceeds the reasonable number. 

Don’t be afraid to execute changes soon

The reorg might not be your first tool when joining, on the other hand, you should be confident in making changes. Some techniques advise listening only in the first month and changing afterward once your position is more stable.

However, if there is something apparently wrong, you should change in straight away. No matter if it’s your first month in the role.

Otherwise, you might lose the opportunity window and potential early wins. Ensure you have enough context by carefully discussing things before the change.


These are the five most impactful approaches I used recently.

I definitely recommend reading the First 90 days because the book and the frameworks go much far beyond the trial period, I’d even bet these are enough to manage the organization for years.

Tuesday, March 10, 2020

Co nám funguje: zero bug policy

Občas s dětmi koukám na Šmouly. Tak mě napadlo, co by asi tak řekl svým tvrdým hlasem Mrzout. No nejspíš: “nemám rád policy!”. Já také ne. Jestli nám ale nějaké pravidlo pomohlo ke štěstí, bylo to tohle.

Jistě jste během vaší kariéry narazili na mnoho různých přístupů, jak se postavit k bugům.

Pamatuji si, že v Systinetu jsme měli na té naší komponentě stovky reportovaných bugů. Releasovalo se tehdy těch sedm či osm let dozadu jednou za pár měsíců. Tehdy jsme se vypořádávali s bugy prioritou. Release šel ven jen tehdy, když nebyly reportované žádné P1 — urgent či critical ani P2 — užaninevimcotobylo :-)

Na Service Virtualization jsme těch bugů v QC měli také hromadu, ale nebylo to tak kritické. Mimochodem, na Quality center jsme měli tehdy lightweight Bugzilla interface, protože tehdejší QC moloch stahoval stovky megabajtů do browseru při spuštění, aby se vůbec načetla celá stránka. Díky Mafry. Člověk si to už ani nedokáže představit.

V Liftagu je nás trošku méně, releasujeme do produkce několikrát týdně. Představa stovek červených bugů v Jiře nás nelákala. Také se musíme otáčet. Nějaké simple silver-bullet pravidlo by se nám hodilo. Vyříkávat si neustále s PM či někým dalším, zda to opravdu je bug, či není, je zdlouhavé.

Bylo nutné oddělit zrno od plev. Říct si ano či ne velmi rychle. Vždy je málo času, a tak prioritizovat bugy vůči featurám je cesta do pekel.

Co nám pomohlo?

Zero bug policy?

Je to jednoduché flow, jak se vypořádat s bugy. Mým zdrojem celé realizace byl tehdy tento článek.

Přístup má vlastně pouze dvě pravidla:

  1. Bugy fixujete hned, a nebo maximálně příští sprint. Nedávát je nikdy dál.
  2. Bug je něco, s čím nedokážete dále žít a je nutné jej opravit.

Někteří z vás se určitě od začátku smějí, že mít nula reportovaných bugů není možné. Máte jich přece stovky.

Zásadní je zvládnout dobře druhé pravidlo. Je reportované issue opravdu bug hodný fixnutí a nebo je pouze nějaká nice-to-have nová featura, kterou někdo z XYZ považuje za nutnou?

Pomohl nám rozhodovací strom z obrázku:

  1. Nejde spustit appku v produkci? Zákazník nemůže na platební bráně zaplatit? Nejde vyhledávat v mapách? Pokud leží překážka na kritické cestě appkou, všeho necháváme a celý team se soustředí na fix produkční issue. Ztrácíme totiž peníze, zákaznickou loajalitu.
  2. Něco nefunguje? Neexistuje workaround? Nedokážeme s tím issue dál žít? Oukej, je to bug, fixujeme příští sprint.
  3. Něco nefunguje? Jo ono to nefunguje už tři roky? Je to něco, s čím dokážeme žít, protože existuje snadný workaround? Bug v Jiře přehazujeme na user story a dále normálně prioritizujeme jako featuru s produktem. Pokud totiž dokážeme žít se současným řešením, issue je ve skutečnosti improvement současného chování, ne chyba.
  4. Bylo by lepší, kdyby to takhle fungovalo? Napadá mě, že by to takhle bylo lepší? Tak to je nová featura. Chováme se k ní jako v bodu tři.

Jak jsme postupovali ve třech krocích

Na začátku jsme udělali experiment. Řekli si, že do toho jdeme a uvidíme. Přinejhorším to zase zrušíme.

1. Triage bugů

Pokud máte hromadu bugů, nejprve je potřeba je projít a přehodit ne-bugy na user-stories nebo cokoliv, co používáte. Chce to pár hodin času, pevnou ruku a nebát se přehazovat či dokonce zavírat.

Následující obrázek je historie našich bugů v Jiře. Je tam vidět ten prvotní náběh v červnu 2016. V lednu 2017 jsme se rozhodli, že žádné bugy a tak to žuchlo na zhruba polovinu.

2. Zvládnutí zbylé kupy bugů

Pokud jste jich měli opravdu hodně, hodně vám také zbyde. Důležité je udělat plán, jak se dostanete k nule. Je vše třeba vysvětlit managementu, vzít si na to čas. Málokdy se vám stane, že můžete zastavit vývoj nových věcí, abyste pár týdnů pouze fixovali.

Důležité je dostat se během rozumné doby na nulu.

Na našem grafu je vidět, že správná implementace zero bug policy nám trvala zhruba od půlky roku 2017 do prosince.

Jsou tam také vidět dva peaky. To je čas, kdy si vzal Honza Android a pak iOS appku do pucu. Na začátku nareportoval hromadu issues. Ve druhém případě iOS jsme si s Honzou domluvili plán, že se do pár měsíců zbavíme iOS bugů. Tenhle plán jsme probrali i s produktem, aby také počítali s tím, že nedokážeme udělat tolik nových věcí v appce.

Buďme realističtí.

3. Udržení pozitivní nuly

Celý princip funguje jen tehdy, pokud se někdy dostanete shora k nule a tu nulu udržíte.

Lidská mentalita funguje tak, že když pošlete jeden, dva či tři bugy dál s tím, že je ofixujete později, je to jako kdybyste jich tam poslali hned padesát.

Team vám pak nebude věřit váš záměr a systematicky začnou všichni toto pravidlo porušovat.

Na grafu je to ta pila. Tu chcete. Ukazuje, že reportované bugy stíháte fixovat. U nás se držíme zhruba kolem 10 či 15 bugů, které se nám daří další sprint zavřít.

Jak se nám to daří?

Ve své podstatě stačí projít úspěšně třemi popsanými kroky a na konci držet pilu. Jira sama vám umí zobrazit graf created/resolved issues, takže to můžete sledovat na jakékoliv časové úrovni velmi snadno.

Tohle pravidlo nám pomohlo zjednodušit přístup a rozhodování s bugy, kdy výjimečně probíráme prioritu déle než bychom si všichni přáli.

Od té doby se cítí všichni na poli bugů dobře, protože máme pravidlo, které je jasné a deterministické, a zároveň vede k udržitelnému provozování platformy 24/7.

Monday, December 30, 2019

Jak děláme A/B testování

 Technika A/B testování je velmi mocný nástroj jak posouvat business dopředu testováním a měřením nových nebo existujících featur či jejich dalších iterací na reálných zákaznících.

Proč A/B testy?

Ve chvíli, kdy se ve startupu rozhodnete implementovat nějaký nápad, investujete vaše peníze. Jistě chcete mít nějakou návratnost této investice nebo alespoň dohlédnout, kdy se tak stane.

Jak ovšem poznat, že nový kus kódu opravdu přinesl nějakou pozitivní změnu? V Liftagu třeba jízdy.

Určitě můžete měřit jak často se používá nová featura, nás ale zajímá její dopad na hlavní metriky businessu.

Potřebujete zodpovědet otázku: nenastala by pozitivní či negativní změna metrik i kdybychom neudělali vůbec nic?

Od toho existují A/B testy.

Zdroj: https://www.invespcro.com/

V Liftagu jsme historicky mnoho nápadů implementovali na základě přesvědčení, že to prostě musí fungovat. A/B testování přineslo mnoho překvapení. Zjistili jsme, že i ty nejskvělejší nápady mohou skončit naopak poklesem business metrik, i když na začátku bychom na tuhle variantu vsadili klidně celou výplatu :-)

Jak postupujeme, když realizujeme nějaký A/B test?

  1. Nejprve je třeba se shodnout na zadání a měřených metrikách
  2. Zvolíme vhodné možnosti řešení: A, B, C, atp.
  3. Zvolíme segmenty zákazníků, na kterých to budeme testovat
  4. Zvážíme riziko a zvolíme procenta, která bude daný segment pro danou variantu mít
  5. Pustíme to konečně na zákazníky
  6. Měříme metriky až do chvíle statistické signifikance
  7. Vyhodnocujeme -> analyzujeme -> aplikujeme nové nastavení -> vracíme se do bodu #4
  8. Iterujeme dokud nedosáhneme kýženého úspěchu nebo nevyčerpáme všechny nápady na řešení

1. Problém a metriky

Definovat správně problém a najít vhodné metriky je pochopitelně naprosto zásadní. Někdy máte nápad na featuru, ale nevíte, co vlastně řeší za problém pro business. Konkrétní definici problému jsme často rozlouskli až úvahou nad tím, jaké metriky vlastně chceme měřit, a kam doufáme, že s nimi pohneme. Některé věci se nám původně zdály krásné, ale vůbec nakonec nevedly tou správnou cestou.

Metriky je dobré sepsat, ověřit, zda je vůbec umíme měřit, projít s týmem.

Ve chvíli, kdy víme proč a jak to proč budete měřit, máme krásnou definici zadání s týmem.

2. Možnosti řešení

Pokud známe problém a to proč, v týmu kreativních lidí, kterých je v Liftagu snad většina, vždycky vymyslíme kupu variant řešení.

Důležité je si uvědomit, že jedno must-have řešení je nedělat nic. Bez komparace s ním nikdy nezjistíte, zda váš inkrement práce je k něčemu dobrý. Jedná se o klasickou kontrolku.

3. Segmenty zákazníků

Dalším krokem je zvolit na koho vlastně s danou featurou míříme a s kým ji svážeme. Je možné, aby každá nová objednávka měla jinou variantu řešení, nebo je nutné, aby každý pasažér či řidič viděli konzistentně jeden typ?

Někdy se z definice problému hodí jedno řešení, jindy zase druhé.

4. Riziko a procenta segmentů

Vždy, když něco sázíme do produkce, snažíme se to udělat vypnutelné pomocí konfigurace feature flagů nebo databáze. Budujeme prostředí, kde je možné udělat chybu, ze které se umíme snadno vybrousit.

Stejné pravidlo roll-outu používáme u A/B testů. Na začátku pustíme featuru na malé procento uživatelů a postupně stoupáme na definovaný target. Pochopitelně risk ratio záleží na typu vylepšení. Pokud se jedná o okrajovou věc, můžeme jít do většího rizika, pokud leží na kritické cestě appkou, nemůžeme riskovat puštění rovnou na větší procento uživatelů.

5. Spuštění na reálné zákazníky

Po spuštění featury na živé zákazníky koukáme především na metriky či na logy, zda vše vůbec funguje, není nulová konverze atp.

V tuhle chvíli nemá smysl koukat na konkrétní hodnoty business metrik, tzn. zda je nějaká z nich 55 nebo 64, ale spíš na kontext: funguje to dle očekávání pro danou objednávku či zákazníka, proč si daný pasažér nevybral tohoto řidiče nebo zda to není moc drahé.

Čím dál tím víc se nám vyplácí mít možnost sledovat všechno v real-time a ne zpožděně druhý den přes BI stack.

6. Měření metrik a statistická signifikance

První AB testy v Liftagu se nám nepodařilo dotáhnout do konce právě kvůli chybné interpretaci výsledků. Ať už zle zvolených metrik či neznalosti funkce statistické signifikance.

Zdroj: https://cxl.com/blog/magical-95-statistical-significance/

Každá metrika má totiž tendenci se vlnit. Během určitého časového období nám konverze létá klidně o deset procentních bodů. Podle toho, jak se vyspí pár našich uživatelů, zda zaprší nebo mrzne či je konec prázdnin, samozřejmě nechcete odpískat nějakou naprogramovanou featuru. Všechno má nějaký vliv. Čím kratší období, tím jsme měli větší šanci, že náš test má prostě smůlu a tahle smůla se může lepit pouze na jednu z variant. Existuje mnoho článků, kde je statistická signifikance hezky popsaná, např. tady.

My používáme prostý kalkulátor, který vám říká s jak velkou pravděpodobností můžete věřit výsledku.

Krom statistické signifikance také pozorujeme něco čemu říkáme business cyklus. Ten je v Liftagu roven délce měsíce. Experimentálně jsme přišli na to, že chování uživatelů se opakuje v měsíčním cyklu, takže první týden může signifikantně vítězit jedna varianta leč čtvrtý je to ale už agregovaně varianta B.

Proto testy necháváme dokud nejsou výsledky signifikantní a testy neběží alespoň měsíc.

7. Kolečko iterace

Snažili jsme se vždy udělat jedno celé kolečko od měření, analýzy dat, vymyšlení dalšího kroku a přenastavení.

Tahle část typicky obsahuje analýzu větších — měsíčních — dat, takže rádi používáme náš BI stackDalší kroky se snažíme vymýšlet v cross Liftago teamu s business ownerem. Ten je vtažený do každého vyhodnocení, účastní se “standupu”, prezentace dat atp. Jsme tak velmi akční a můžeme během pár minut do testů zahrnout klidně nějakou odvážnější variantu.

Jakmile víme co dál, provedeme další nastavení, reset testů a zahájíme další iteraci.

8. Iterování

Fungujeme stejně jako phases v rugby. Někdy trvá deset fází než dojdete pro pětku, někdy lehce proběhnete půlku hřiště a někdy prostě o míč přijdete ve druhé fázi.

Přeloženo ze sportovní řeči: iterujete, dokud nepřijdete na variantu s kladným výsledkem, a nebo nerezignujete s tím, že vám došly varianty a ta kontrolní zůstává ta nejlepší.

V některých případech jsme si došli během jednoho kolečka pro vítěznou variantu, která šla rychle na všechny uživatele. V jiném případě jsme za šest iterací našli určité nastavení, které vyhovovalo nějakému procentu našich zákazníků, ale o nějakém plošném globálním vítězství ani potuchy.

A/B testování je prostě hledání, které může skončit vypnutím a zahozením naprogramovaného kusu kódu. V takovém případě ani nic lepšího udělat nemůžeme, protože díky relevantním A/B testům víme, že nám to přináší zápornou hodnotu. Tedy je lepší nedělat nic :-)

Speciální bod bych věnoval tomu, kdy s A/B testem skončit a vítěznou variantu pustit na všechny uživatele. Moje zkušenost je taková, že vše se mění. Vítězná konfigurace může dobře fungovat pár měsíců, trh se změní a najednou může házet horší výsledky. Tohle potřebujete ale vědět. Osobně bych tedy doporučoval držet kontrolku, např. 5 procent, delší dobu a občas ověřit zda vítězná varianta stále dává nejvíc. Přijdete sice u těch pěti percent o increment, ale za cenu, že máte měření z trhu. To je k nezaplacení.

Co nám A/B testy přinesly?

  1. Důvěru v to, že naši zákazníci používají featury a nastavení, které přináší největší hodnotu ze všech verzí, které jsme vymysleli a naprogramovali.
  2. Férový process na vyhodnocení všech názorů na řešení problému. Když neděláte A/B testy, někdy zvítězí názor nejvíc křičícího účastníka debaty v teamu nebo nejvýše postaveného v “org chartu”. S A/B testy se dostane na všechny a realita pak ukáže.
  3. Nemusíme trávit čas neproduktivní analýzou před implementací problému, která je vždy plná pouhých dohadů. Měříte až ve chvíli, kdy máte reálné výsledky od zákazníků. Tvrdá data.
  4. Propojení firmy, když v jednom teamu sedí datový člověk, business owner i backend engineer. Přesah, buy-in a celkově zainteresovanost.
  5. Oprášení matematiky a statistiky ze školních lavic :-)

Tuesday, April 2, 2019

Jak v Liftagu ověřujeme hypotézy na datech pomoci Omnisci

 V minulém článku jsem psal o tom, jak necháváme lidi pracovat s daty, aby si mohli ověřit nápady přímo na nich a nemuseli tak čekat na typicky přehlcené BI oddělení.

Abyste si mohli analyzovat všelijaké nápady, musíte projít dvěma kroky:

  1. Předpřipravit si data, používáme je ve formě super table
  2. Začít skládat nápady do grafů a začít ověřovat svoje hypotézy

Plachta aka super-table

Visualizace v OmniSci jsou silné nad jednou tabulkou. Neumí to dělat vůbec žádné joiny. Což se nakonec ukazuje jakou featura a ne bug.

Fungujeme tak, že máme jednu obrovskou tabulku, kde je všechno pro danou doménu, třeba objednávky či uživatele. Každá řádka má typicky dvě části:

  1. Data spojená s danou entitou. Třeba objednávkou. Její datum, čas, idčka, souřadnice, adresy, platby atp.
  2. Napočítaná data k určitým atributům entity. Např. k příslušnému pasažerovi u objednávky máme napočítaný celkový počet objednávek, které udělal za poslední dobu, počet jízd za poslední dobu, průměrný nabídnutý tarif za poslední dobu atp.

Sloupců prvního typu máme tak 80, druhého 150. Vtip je v tom, že ty dopočítané atributy časem přidáváme podle toho jak hluboko se dostáváme k jádru daného problému.

V tomhle bodě je důležité lidem nebránit v tom, aby si k dané plachtě připočítali cokoliv dle libosti. V tom je ten point rychlého ověření v datech.

Napočítání řešíme takhle:

  1. Všechno máme ideálně v jednom view tak, aby ho šlo snadno upravovat. A časem i refactorovat. Svoje změny tak vidíte ihned v datech.
  2. Výpočet view běží nad Snowflake. Nepotřebujete řešit indexy, Snowflake umí window funkce, takže můžete dělat i velmi složité věci pro připočítaná data. Např. agregace pro objednávky v časovém okolí.
  3. Přes S3 potom data putují do Omnisci.

OmniSci core database je optimalizovaná pro miliony řádků a zjevně stovky sloupců. Za realtimu. GPU podporu zatím vynechme, k tomu se můžeme vrátit později.

Event oriented přístup

Výše jsem nakousl strukturu plachty. Časem se nám velmi osvědčilo podvolit se přístupu OmniSci, takže to rád rozeberu do detailů.

Jak jsem již zmiňoval, jednotlivé plachty mají dva druhy fieldů: ty přímo spojené s doménou a ty dopočítané pro určitou vlastnost.

Lze na to koukat i jiným způsobem: daná entita je event v systému. Například jedna konkrétní vygenerovaná objednávka v určitém čase, místě atp. K němu vy potom lepíte v čase a místě platné informace.

Co to přesně znamená? Uvedu příklad.

Objednávka vznikla v daném čase a místě pro dané pasažéra. Tento pasažér v daném momentu měl určité statistiky. Dejme tomu za předchozích 90 dní k tomuto datu udělal deset objednávek a z nich bylo pět jízd. Zároveň těch pět jízd bylo odjeto s průměrným tarifem 24,5 czk. Těchto dopočítaných hodnot platných pro daný čas máme hromadu.

Jak s tím pracovat? Pojďme do části použití v OmniSci.

Bádání nad problémem

V OmniSci lze pár kliknutími přidávat grafy do boardu. Nemusíte nic předpočítávat ani sestavovat. Všechno si uděláte hezky za online a realtime.

Začínám vždycky tím, že si vyberu nějaký datum či den. Třeba úterý za několik posledních týdnů. Na histogramu mohu vybrat třeba jen dopoledne.

Protože mě zajímá jen pražské centrum, tak přidám mapu.

Dál se chci zaměřit na objednávky, které hodnotíme jako populární.

A celé jsem to dělal, abych podíval, jak dlouhé jízdy naši zákazníci jezdí a čím je platí.

Tady teď mohu zapojit ten eventový přístup. Na předchozích grafech máme vybrané určité objednávky pro určitý typ lidí. Pokud mám u každé z nich napočítané určité statistiky, mohu se hravě podívat, jací pasažéři to jsou. Tedy jaké vzdálenosti běžně jezdí a zda se liší od těch, které vidíme teď.

Jak to funguje doopravdy?

No, úplně stejně. Začnete s nějakou hypotézou a přidáváte a přidáváte grafy. V nich pak vybíráte segmenty, které vás nejvíc zajímají. Dokud nedojdete ke kořenu tohoto problému.

Naposled jsme takhle koukali na to jak se nám daří ve špičče a zda naše chování můžeme vylepšit. Nejdříve si vyberete opět datum, čas, místo na mapě. Potom si přidáte určité charakteristiky řidičů. Do druhého grafu vedle si dáte poptávku. A pomocí dopočítaných statistik se koukáte co a jak se v ty dané časy děje, kdo jezdí, jakou má dostupnost a jak se třeba akceptuje.

Celkem snadno se takhle doberete odpovědi na vaši otázku, zda má smysl programovat featuru XYZ, která řeší problém ABC. A nebo obráceně: zda ten problém vůbec máte. Ale to je námět na další článek 🙂