Ce am învățat conducând o echipă de ingineri la Oracle

Am petrecut patru ani ca team lead la Oracle Global Services, într-o echipă împărțită între România și Kansas City, pe sisteme clinice. Peste douăzeci de milestone-uri, o diferență de opt ore și un domeniu în care o greșeală are consecințe dincolo de un rollback.

Nu e un manifest de management. Sunt cele câteva lucruri pe care mi le-aș spune mie la început, scrise pentru inginerii care se gândesc la aceeași trecere — și pentru cei care vor să înțeleagă ce face de fapt lead-ul lor toată ziua.

Ce se schimbă de fapt?

Varianta onestă: rezultatul tău încetează să fie cod și devine capacitatea altora de a produce cod. Sună a afiș motivațional. Are însă o consecință foarte concretă — dispare bucla de feedback care îți spunea dacă te descurci.

Ca inginer, știi joi dacă munca de luni a fost bună. Ca lead, semnalul vine în săptămâni și e zgomotos. Primul meu instinct a fost să continui să scriu cod, pentru că acolo încă puteam simți că sunt util. Instinctul e de înțeles și e o capcană: echipa aștepta decizii pe care eram prea ocupat ca să le iau.

Înainte	După
Rezolvi tu cea mai grea problemă	Te asiguri că cea mai grea problemă e rezolvată de omul potrivit
Îți cunoști în profunzime partea ta de sistem	Știi unde sunt cusăturile și cine ce știe
Îți optimizezi propriul debit	Optimizezi ca echipa să nu fie blocată
Feedback în zile	Feedback în săptămâni, indirect
Scopul e să ai dreptate	Să ai dreptate și să fii singur e un eșec

Ultimul rând mi-a luat cel mai mult.

Ar trebui să te oprești din scris cod?

Nu complet și nu din motivul invocat de obicei.

Argumentul pe care îl auzi e „rămâi tehnic ca să-ți păstrezi credibilitatea“. E real, dar secundar. Motivul mai bun e că, dacă nu mai atingi codul, estimările ți se degradează tăcut — începi să crezi propriul model mental despre o bază de cod pe care n-ai mai deschis-o de un an și angajezi echipa la termene bazate pe el.

Ce a funcționat la mine: rămâi în cod, dar alege muncă întreruptibilă și în afara drumului critic. Tooling, build, infrastructură de teste, migrarea pentru care n-are nimeni timp. Niciodată funcționalitatea de care depinde milestone-ul. În clipa în care task-ul tău e pe drumul critic, fiecare întrerupere devine un cost care te enervează — iar un lead pe care îl enervează întreruperile a încetat să-și facă meseria.

Cât costă de fapt diferența de fus orar?

Opt ore între Brașov și Kansas City înseamnă cam două ore de suprapunere într-o zi bună. Toată lumea știe că asta costă comunicare. Mai puțin evident e care dintre costuri pot fi evitate.

Eșecul scump nu e întârzierea — e o întrebare care primește răspuns în 24 de ore. O singură întrebare blocantă pusă la ora greșită costă o zi întreagă, iar trei dintr-astea într-un sprint înseamnă un milestone ratat care arată ca o eroare de estimare.

Ce am schimbat:

• Scris, implicit. O decizie care trăiește într-un call există doar pentru cei care au fost în call. Deciziile scrise supraviețuiesc fusului orar. Și, nu întâmplător, e exact ce vrea oricum de la tine un mediu reglementat.
• Optimizezi pentru deblocare, nu pentru status. Fereastra de suprapunere e cea mai rară resursă pe care o ai. Consumarea ei pe un tur de status — informație care putea fi citită asincron — e cea mai frecventă risipă pe care am văzut-o.
• Pune întrebările într-o formă la care se poate răspunde cât tu dormi. „Ce părere ai despre X?“ costă un tur-retur. „Merg pe A dacă nu obiectezi, pentru că B strică cazul Y“ costă un tur-retur doar dacă obiectează cineva. A doua formă e o deprindere și se poate învăța.

Cum faci review fără să devii tu gâtul de sticlă?

Review-ul e locul unde un lead are cea mai mare pârghie și face cel mai mult rău.

Două greșeli pe care le-am făcut. Prima: am făcut review la tot, ceea ce m-a transformat într-o coadă și a învățat echipa că respectarea calității e treaba mea, nu a lor. A doua, corectând-o pe prima: n-am mai făcut review la nimic, ceea ce a lăsat standardele să derive în patru direcții simultan.

Unde am ajuns:

• Fă review la granițe, nu la interioare. Interfețe publice, schimbări de model de date, orice atinge securitatea sau calea de audit, orice creează un precedent. Corpul unei funcții bine testate e review-ul altcuiva.
• Separă „asta e greșit“ de „eu aș fi făcut altfel“. Spune explicit care dintre ele e. Preferința stilistică a unui lead e auzită ca o cerință și vei consuma o după-amiază de echipă pe ceva ce nu te interesa.
• Explică de ce, o dată. Un comentariu de review care spune doar ce să schimbi nu învață pe nimeni nimic și îl vei scrie din nou luna viitoare. Unul care explică raționamentul e o lecție; aceluiași om nu-i va mai trebui a doua oară.

Instinctul de mentorat pe care ți-l formează asta se transferă bine și în afara serviciului, de altfel — am regăsit exact același tipar în voluntariatul cu copiii care învață să programeze la CoderDojo Brașov. „De ce“ scalează; „ce“ nu.

Ce facem cu estimările?

Cel mai util lucru pe care l-am învățat despre estimări e că cea mai mare parte a erorii nu stă în estimare.

Echipele nu greșesc de obicei cât durează munca. Greșesc cât de multă altă muncă va apărea, cât vor sta review-urile la coadă, câte dependențe se vor mișca. Timpul de inginerie e estimat rezonabil; tot ce e în jurul lui e estimat la zero.

Două practici au făcut mai mult decât orice tehnică de estimare:

• Estimează intervale și spune de ce depinde intervalul. „Trei până la opt zile, opt dacă integrarea externă se poartă ca data trecută“ e informație. „Cinci zile“ e un număr care va fi tratat ca un angajament.
• Ține evidența a ce te-a blocat efectiv. După câteva sprinturi, tiparul e vizibil și plictisitor — aceleași două-trei surse de întârziere, de fiecare dată. Lista aia valorează mai mult decât orice grafic de velocitate, pentru că pe ea poți acționa.

Ce a învățat domeniul reglementat și se generalizează?

Sistemele clinice vin cu suprasarcină de proces: trasabilitate, schimbări controlate, verificare documentată. E ușor să citești asta ca frecare pură și o parte chiar este.

Dar obiceiul de fond se generalizează mai departe decât mă așteptam: ți se cere, de rutină, să explici de ce crezi că ceva funcționează. Nu să afirmi — să arăți raționamentul și dovezile.

E un obicei bun oriunde. Face design review-urile mai ascuțite, face comentariile de cod concrete și e diferența dintre „am testat“ și „uite ce am testat și ce am ales deliberat să nu testez“. L-am dus mai departe în propriile produse, unde nu mi-l cere nimeni, pentru că se dovedește a fi exact modul în care eviți să livrezi ceva despre care doar speri că merge.

Singurul lucru pe care mi l-aș spune

Decide și spune ce te-ar face să te răzgândești.

Cel mai dăunător lucru pe care l-am făcut în primul an a fost să amân decizii în numele consensului. O echipă blocată pe o decizie nu-ți percepe prudența ca pe chibzuință; o percepe ca ambiguitate și umple golul cu patru presupuneri diferite.

O decizie care se dovedește greșită e recuperabilă — de obicei ieftin, de obicei în același sprint. Patru oameni lăsați să ghicească două săptămâni nu sunt. Decide, scrie raționamentul și numește explicit ce dovadă te-ar face să te întorci. Ultima clauză e cea care face compatibilă decizia rapidă cu greșeala ocazională.

Dacă treci într-un rol de lead și vrei să discuți cu cineva care a făcut deja greșelile evidente, o fac cu plăcere.