Nagovor

Tole ne bo powerpoint all over, ker bi rad da me poslušate in ob tem razmišljate o svojih občutkih, ciljih, pričakovanjih in kako dejansko funkcionirate na delovnem mestu.

Rad bi predstavil primer prakse ... ki ni nujno dobra v vseh okoljih... ampak se je pokazala pozitivna večkrat kot drugi pristopi. Kot vse v življenju po Dunning Krugerju, "ne vemo, česa ne vemo", smo pogosto preveč samozavestni. Jaz danes ne vem nič o informatiki, čeprav delam to že 40 let in sem pred 20 leti vedel vse. In nič nisem pozabil. WTF? Verjetno prehajam na drugo stran krivulje, kjer je odgovor na vsa vprašanja "it depends".

Ne oproščam se za vdor angleščine v ta talk. "Takšno je življenje," so rekli na TV.

Torej, kdo rešuje križanko s kulijem? Ostali ne rešujete križank, ker nihče ne bo priznal, da je pussy in uporablja svinčnik.

OK, zdaj vem, da imam pred sabo polno samozavestnih programerjev.

Prenesimo to samozavest v naše delo. Danes bi rad z vami delil izkušnjo, kako sem sodeloval v več projektih, kjer smo razdelili vloge in podprli samozavest, ki je samo drug način izražanja radovednosti in raziskovanja in osnova za rast, v smislu, to obvladam, to znam, kako bi lahko to uporabil v drugačnem okolju ali nadgradil.

Odločanje ni privilegij ampak fokusiranje pritiska

Beseda, ki se za to običajno uporablja, je avtoriteta, in mislim, da je ta beseda napačna, ker opisuje zgolj zunanjo, vidno plat takšne ureditve, ne pa tistega, kar se v resnici dogaja v ozadju. Ko je v ekipi ena oseba tista, ki odloča, se s tem ne spremeni, čigave ideje bodo na koncu zgrajene, saj dobra ideja običajno zmaga ne glede na to, kdo jo je prvi izrekel, ampak se spremeni to, kdo nosi posledice, ko se šest mesecev pozneje pri nepredvidenem incidentu v produkciji izkaže, da je bila odločitev napačna. Ta teža mora nekje pristati, in vprašanje, na katero si vsaka ekipa odgovori bodisi zavestno bodisi po inerciji, je, ali bo ta teža ležala na enem človeku ali pa se bo potihem razporedila med vse, ki so bili v sobi, ko ste se o stvari dogovorili.

Pri nas jo damo na eno osebo, pa ne zato, ker bi bila presoja ekipe nezanesljiva, saj ima ekipa v praksi običajno prav in je naloga vodje v veliki meri ravno v tem, da posluša dovolj pozorno, da opazi, kdaj ima prav, ampak zato, ker človek, ki opravlja skrbno in natančno delo, ne bi smel hkrati nositi še strahu, da bo na koncu obtožen za načrtovanje sistema, v katerem dela.

Vse, kar sledi, velja za določeno vrsto ekipe. V mislih imam majhno ekipo, oddelek znotraj večjega podjetja ali agencijsko skupino, ki gradi programsko opremo, od katere je odvisen posel, kjer brezhibno delovanje resnično šteje in kjer se bo sistem vzdrževal leta, ne le par mesecev. To je okolje z dvema lastnostima, ki krojita celotno debato, in sicer da en človek še vedno lahko resnično drži celoten sistem v glavi in da so ljudje, ki opravljajo delo zaposleni, ki so sprejeli službo, ne pa ustanovitelji, ki so prevzeli tveganje. Če greste v organizacijo s petdesetimi inženirji, sistema tako ali tako ne more več držati en sam posameznik, in če greste v startup, kjer imajo vsi lastniške deleže, se računica o tem, kdo naj nosi posledice, spremeni na obeh straneh. Nobena od teh dveh situacij ni okolje, za katero mi gradimo.

Tega stališča ne zagovarjam, da bi nadziral sodelavce. Ureditev, ki bi si jo v resnici želel, je ravno nasprotna, takšna, kjer vsak pushne in deploya takrat, ko sam presodi, da je delo pripravljeno, kjer sistem to brez pritoževanja požre, jaz pa berem časopis in pijuckam koktajle. Danes temu rečejo AI, alkoholna inteligenca. Večkrat sem poskušal zgraditi tak način dela, a vedno znova naletim na to, da tisto, kar takšno ureditev omogoča, ni zaupanje, saj ljudem, s katerimi delam, zaupam, temveč raven skupnega konteksta, ki ga majhna ekipa z običajno fluktuacijo in običajnimi roki skoraj nikoli ne uspe ohranjati dovolj dolgo. Model, ki ga opisujem tukaj, je torej sledenje temu, kako stvari v resnici tečejo, ne pa želja o tem, kako bi morale teči.

Deljena odgovornost - kaj konsenz potihem naredi ljudem

Privlačnost demokratične strukture je očitna in namen za njo je običajno dober, saj nihče ne predlaga skupnega odločanja zato, da bi inženirjem zagrenil življenje, pa vendar le redko iskreno pogledamo, kakšen učinek ima takšen pristop na ljudi znotraj njega. Ko odločitev pripada skupini, tudi odgovornost za to odločitev pripada skupini, kar zveni kot solidarnost vse do trenutka, ko gre nekaj narobe in opazuješ, kaj se takrat v resnici zgodi v sobi. Zgodi se to, da vsak začne za nazaj rekonstruirati svoje stališče iz prvotne razprave in potihem vzpostavljati tezo, da je imel že takrat določene pomisleke.

To ni nepoštenost ampak samoohranitveni nagon, in točno to bo takšna organizacija, ki porazdeli odgovornost, ne da bi porazdelila tudi zaščito, sprožila v povsem razumnih ljudeh. Cena tega se pokaže že pred samo napako v obliki varovanja hrbta, saj bo inženir, ki ve, da bo delno odgovoren za odločitev, na katero je imel le delni vpliv, razpravljal obrambno namesto odprto, raje bo izbral rešitev, ki jo bo kasneje najlažje upravičiti, kot pa tisto, za katero v resnici verjame, da je boljša, in energijo, ki bi jo lahko vložil v delo, bo porabil za pozicioniranje. Sedel sem na precej takšnih sestankih in rezultat je vedno enak, in sicer da je razprava daljša, kot si jo problem zasluži, in da nihče ne zveni, kot da govori tisto, kar v resnici misli.

Skupne odločitve dajejo občutek solidarnosti vse do trenutka, ko gre nekaj narobe, takrat pa vsi v sobi ugotovijo, da so imeli že od začetka pomisleke.

Ko torej vodja reče, da je odločitev njegova, ima ta stavek dva dela in običajno slišimo samo prvega, ki pravi, da bo izbral on, medtem ko je druga, tista resnično pomembna polovica v tem, da bo takrat, ko se izbira izkaže za napačno, pogovor z naročnikom, stranko ali vodstvom opravil sam in v njem ne bo imenovan nihče iz ekipe.

Poslušanje je večji del tega dela

Nič od tega ne deluje, če je odločitev sprejeta v izolaciji, in vodja, ki odloča, ne da bi prej zbral razmišljanja ekipe, ne nosi odgovornosti, ampak zgolj preskakuje tisti del naloge, zaradi katerega je to odgovornost sploh mogoče prevzeti. Inženirji, ki vsak dan opravljajo konkretno delo, vedo stvari, ki jih vodja ne ve, ker so bili znotraj kode, ker so na lastni koži občutili, kje se koda upira ... in ker so si običajno ustvarili mnenje, ki je vredno veliko več, kot nakazuje njihova raven samozavesti, saj je zraslo iz neposrednega stika s kodo, ne pa iz predstavitve.

Od vodje pričakujemo, da naredi nestrinjanje poceni, kar pomeni, da aktivno izvleče ugovor, ki ga je nekdo zadržan izreči, da dobro argumentiran izziv obravnava kot nasvet in ne kot oviro, ter da je vidno pripravljen spremeniti svoje stališče, ko je argument boljši od tistega, s katerim je sam prišel nas sestanek. Vodja, ki ga nikoli nihče ne prepriča v nasprotno, je nehal prejemati prave povratne informacije že veliko prej, preden je to sploh opazil. Ljudje se hitro prilagodimo in nehamo trošiti energijo za argumente, ki ne padejo na plodna tla.

Razlika, ki je tukaj bistvena, je razlika med odločitvijo in idejami. Ideje zbiramo od vseh, tehtamo jih po njihovi vsebini in pogosto izbrana pot pripada tistemu v ekipi, ki jo je najbolj prepričljivo zagovarjal, medtem ko odločitev, torej dejanje, s katerim se razprava zapre in se sprejme vse, kar iz nje sledi, pripada eni osebi, kar sta dve različni stvari. Če ju zmešamo, se struktura, ki naj bi ljudi ščitila, spremeni v strukturo, ki jih utiša.

Ideje zagovarjamo vsi, le breme odločitve mora nositi ena oseba.

Zakaj mora biti vodja tehničen

To je del, kjer dobi ta argument konkretno obliko, ker ne moreš prevzeti odgovornosti za odločitev, ki je sam nisi sposoben oceniti. Vodja, čigar moč je v delu z ljudmi in ki je pri vsaki tehnični presoji odvisen od sodelavca, lahko sicer drži naziv odločevalca, a v resnici počne samo to, da inženirja vpraša za odgovor, ta odgovor ponovi navzgor po lestvici in dejansko težo odločitve pusti pri osebi, ki mu je odgovor dala. Ta inženir zelo dobro ve, da če je bil odgovor napačen, je bil to njegov odgovor.

Vodja, ki ne zna oceniti odgovora, ni sprejel odločitve, prevzel je samo naziv.

To je napaka, ki jo želim izpostaviti neposredno, ker je navzven videti kot delegiranje, v resnici pa deluje kot prelaganje odgovornosti. Ekipa to razliko začuti takoj, saj se vprašanje, speljano skozi nekoga, ki ga ne zna presoditi, vrne nazaj kot prošnja za potrditev namesto kot odločitev, potrditev pa je tisto, kar inženirji dajo takrat, ko od njih zahtevaš, da jamčijo za nekaj v imenu nekoga drugega.

Tehnično podkovan vodja lahko sprejme predlog, ga razume dovolj dobro, da se z njim tudi ne strinja, in nato iskreno stoji za izidom. To je edina različica te ureditve, ki pritisk dejansko odstrani, namesto da bi ga samo prestavila. Zato raje vzamemo močnega inženirja in mu pustimo, da se priuči podpornih veščin, ker se moderiranja, pisne komunikacije, vodenja sestanka, time managementa in sporočanja neprijetnih novic naročniku motiviran odrasel človek lahko nauči, medtem ko se tehnična globina nabira počasi skozi leta, ko si se pri sistemih motil na tristo različnih načinov.

Konkretna oblika tega pristopa

Lastništvo (ownership po slovensko) v tem modelu ni simbolično, saj vodja opravlja ključno inženirsko delo, tako da nosilne dele sistema zasnuje oseba, ki bo pozneje zanje tudi odgovarjala. In ta poravnava med avtorstvom ter odgovornostjo spremeni resnost odločitev na način, ki ga je težko fejkat. Vodja skrbi za release, ne kot ceremonialno potrditev na koncu pipeline-a, ampak kot oseba, ki ve, kaj je v buildu, kaj se je spremenilo v podatkovni shemi in na katero od sprememb tega tedna je treba biti pozoren.

Vodja je glavna povezava z deležniki produkta, in to je del, ki nosi največjo težo, saj ravno iz tega kanala izvira večina pritiska na ekipo. Tako da rok, ki je prišel kot pričakovanje ... sprememba obsega, ki je bila opisana kot majhna, ali incident, ki zahteva razlago, še preden je kdorkoli končal diagnostiko, vse to pristane na koledarju ene osebe, namesto da bi se kot stalna tesnoba razlilo po celotni ekipi.

Filter je na pritisku, ne na informacijah. Zaščititi ekipo pred slabim vremenom ni isto kot jim reči, da sije sonce.

Tukaj se splača biti natančen, ker se ti dve stvari ves čas zamenjujeta. Inženirji se pri nas še vedno pogovarjajo z ljudmi, ki programsko opremo uporabljajo, še vedno sedijo na sestankih, kjer domenski strokovnjak razlaga, zakaj proces deluje tako, kot deluje, in še vedno slišijo pritožbo neposredno namesto kot povzet ticket, saj bo ekipa, ki zahteve dobiva le iz druge roke, gradila po povzetku namesto po dejanski potrebi. Tisto, česar ne dobijo, so eskalacije, tesnoba zaradi rokov in prikrita grožnja, ki včasih nastane ob sicer povsem legitimni zahtevi.

Poleg tega obstaja še korist konsistence, saj ima sistem z enim arhitekturnim avtorjem običajno en način obravnave napak, en vzorec za dostop do baze in eno konvencijo poimenovanja, ki se ni spreminjala glede na to, kdo je bil prejšnji mesec najbolj aktiven.

Kje se ta pristop zlomi

Ta model ni zastonj.

Najbolj očitno tveganje je, da je en sam owner hkrati ena sama točka odpovedi, in ekipa, katere celoten arhitekturni kontekst živi v eni glavi, ima resen problem tisti teden, ko ta glava ni dosegljiva. Rrešitev je v tem, da porazdelimo kontekst namesto lastništva, kar pomeni, da stvari zapisujemo tudi takrat, ko se zdijo samoumevne, in da release dovolj pogosto rotiramo prek namestnika, da postopek pozna več kot ena oseba.

Potem je tu ozko grlo, ko je videti, kot da model deluje odlično vse do trenutka, ko ne deluje več. Pretok je omejen s pozornostjo enega človeka, ekipa, ki čaka na pregled kode, pa je ekipa, ki ne dostavlja. Pri nas se je obneslo to, da smo povsem jasni glede tega, da je vodja lastnik arhitekture, podatkovne sheme, releasea in zunanjih contractov, medtem ko je ekipa lastnik implementacije znotraj teh meja, ne da bi morala za vsak korak prositi za dovoljenje.

Izgorelost je tveganje, ki ga jemljem najbolj resno od vseh, saj združevanje ključnega inženirskega dela, odgovornosti za release in pritiska deležnikov v eno vlogo ustvari delo brez naravnega konca, prihoda v cilj z drugimi besedami. Vodja v takšni obliki potrebuje resnično zaščiten čas za fokus. Potrebuje lastnike in upravo, ki je pripravljena reči ne v njegovem imenu, kjer pa te podpore ni, model ustvari eno odlično leto, ki mu sledi odpoved.

Najbližje bistvu tega zapisa je način, ko odgovornost zdrsne v nadzor, ne da bi vodja to sploh opazil, ker sta od znotraj oba občutka povsem enaka in tehnično podprta. Vodja lahko ekipo zaklene v svoje osebne preference ter temu reče doslednost, opozorilni znak pri tem pa ni konflikt, ampak ravno njegova odsotnost. Ekipa, ki je nehala ugovarjati, ni prišla do soglasja, temveč se je naučila, da jo ugovarjanje nekaj stane.

Tukaj je tudi problem nasledstva. Tu se želim upreti različici tega problema, ki se običajno izpostavlja, in sicer argumentu, da morajo inženirji nositi odločitve, da bi lahko rasli, saj mislim, da je rast kot univerzalni cilj močno precenjena. Večina dobrih inženirjev, ki jih poznam, bremena odločanja ne želi niti takrat, ko je ustrezno finančno nagrajeno. To ni pomanjkljivost, ki bi jo bilo treba popraviti, ampak legitimna preferenca o tem, kakšno naj bo delovno življenje. Človek je sprejel službo zato, da rešuje probleme znotraj določenega obsega in gre domov, tiho dodajanje teže daljnosežnih odločitev tej vlogi pa je sprememba tistega, na kar je pristal ob podpisu pogobe. Predpostavka, da si vsak na skrivaj želi lastništva, prihaja od ustanoviteljev in popoldanskih projektov, kjer je nagrada resnična in je bila izbira prostovoljna, in ne preživi prehoda v okolje, o katerem tu govorimo. Zato je pošten način opisa tega problema to, da gre za tveganje kontinuitete za organizacijo, ne pa za razvojno vrzel v ekipi, in odgovor je v tem, da zaposlimo ali vzgojimo drugo osebo, ki si to težo resnično želi, namesto da jo razdelimo med ljudi, ki zanjo nikoli niso prosili.

Zakaj se še vedno odločamo za to

Prednosti, o katerih se običajno razpravlja, sta doslednost in jasna odgovornost. Tiste, ki so se izkazale za še pomembnejše, so povezane s tem, kako ekipa dela, ko eliminiraš strah. Inženirji, ki vedo, da ne bodo posamično odgovorni za odločitev na ravni sistema, razpravljajo bolj odprto, hitreje stopijo za izbranim pristopom in so pripravljeni poskusiti nekaj, kar morda ne bo delovalo. Iz istega razloga postanejo bolj iskrene ocene časa, saj ni nobene spodbude za napihovanje ocen proti krivdi, ki je ne bo.

Codebase z enim arhitekturnim avtorjem je tudi veliko lažji za generiranje kode, kar je pomembno za framework, usmerjen v codegen, in vse bolj za delo z AI-orodji, saj je oboje odvisno od tega, ali so vzorci dovolj predvidljivi, da je neko kodo mogoče izpeljati iz prejšnje. Hkrati postane hitrejši onboarding, ker nov inženir s tem, ko se nauči enega vzorca, spozna celoten sistem.

Že prej sem zagovarjal, da je motor močne ekipe običajno majhna skupina motiviranih mid-level inženirjev, in to je drugi konec istega argumenta, ker je tisto, kar naredi to skupino hitro, ravno okvir, znotraj katerega lahko dela, in nekdo, ki stoji med njimi in naročnikom.

Kako to počnemo pri nas

Široko razdeljena odgovornost ni povsod napačna, in obstajajo ekipe ter področja, kjer je porazdeljeno tehnično vodstvo očitno boljša izbira, še posebej takrat, ko je delo resnično raziskovalno ali ko je skupina prerasla obseg enega vodje. Znotraj okvira, ki sem ga opisal na začetku, je zgoščevanje odgovornosti v eni tehnično močni osebi prineslo boljše delo in več fokusa kot katerakoli druga ureditev, kjer se je odgovornost delila. Še nikoli nisem videl ekipe, ki bi obžalovala, da natančno ve, kdo odgovarja.

DEBATA in potem zaključim.

ZAKLJUČEK

Misel s katero bi zaključil je naslednja:

Team lead naj bo dovolj izkušen da pokrije ekipo z argumenti in pusti ljudem svobodo ustvarjanja brez posledic za napake.