Există un mit persistent în engineering management: odată ce treci în leadership, ar trebui să te îndepărtezi de cod. Deleagă totul. Ai încredere în echipă. Nu mai revizui PR-uri. Concentrează-te pe „strategie."
Nu sunt de acord.
Nu pentru că n-aș avea încredere în echipa mea, am. Ci pentru că în clipa în care pierd contactul cu ce se întâmplă efectiv în codebase, pierd și abilitatea de a lua decizii bune despre el.
Falsa dihotomie
Industria a creat o logică binară: ești ori IC, ori manager. Tehnic sau strategic. Cu mâinile în cod sau deasupra lucrurilor.
Dar cei mai buni engineering manageri cu care am lucrat, și tipul de manager pe care încerc să-l fiu, operează în zona de mijloc, cea incomodă. Suficient de aproape de muncă ca să simtă când ceva nu e în regulă, dar suficient de departe ca să vadă tipare pe care echipa nu le poate vedea din interiorul unui sprint.
Nu e vorba despre a scrie cod de producție în fiecare zi. E vorba despre menținerea unei fluențe tehnice suficiente ca să:
- Pui întrebările potrivite în discuțiile de arhitectură, nu întrebări de formă
- Identifici riscuri devreme care altfel ar ieși la suprafață trei sprint-uri mai târziu ca „complexitate neașteptată"
- Deblochezi oamenii eficient pentru că înțelegi problema lor, nu doar ticket-ul
- Câștigi încrederea inginerilor software care își dau seama când managerul lor chiar pricepe compromisurile prin care trec
Cum arată „a rămâne tehnic" în practică
Pentru mine, nu e despre a face commit-uri pe branch-ul principal. E despre un set de obiceiuri:
-
Citesc PR-uri cu regularitate. Nu ca să caut nod în papură, ci ca să rămân orientat. Vreau să știu ce se schimbă, unde crește complexitatea și cum gândește echipa la probleme.
-
Particip la discuțiile de arhitectură ca participant, nu ca aprobator. Vin cu opinii, dar le țin ușor. Scopul e să ascuțesc gândirea echipei, nu să trec peste ea.
-
Fac prototipuri când ajută. Uneori cel mai rapid mod de a evalua o direcție e să construiești o versiune brută. Fac asta când chiar deblochează o decizie, nu ca să demonstrez că încă pot programa.
-
Rămân la curent cu ecosistemul. Nu fiecare framework nou, dar schimbările mari. Tooling AI, pattern-uri de infrastructură, evoluția limbajelor. Suficient cât să știu ce e semnal și ce e zgomot.
Pericolul EM-ului non-tehnic
Am văzut ce se întâmplă când engineering managerii se deconectează complet de partea tehnică:
Se bazează în întregime pe ce le spune echipa, ceea ce sună bine în teorie, dar echipele adesea nu scot problemele la suprafață până nu devin urgente. Un manager cu experiență tehnică prinde semnalele din timp: neliniștea care crește într-o conversație despre refactoring, PR-ul deschis de două săptămâni, decizia de arhitectură cu care toată lumea a fost de acord dar în care nimeni nu crede.
Pierd și credibilitate. Inginerii sunt generoși, vor colabora cu un manager mai puțin tehnic dacă e sincer în privința lipsurilor sale. Dar nu vor avea încredere într-unul care pretinde că înțelege și în mod evident nu înțelege. Diferența se vede. Se vede în întrebările pe care le pui, în compromisurile pe care le accepți și în deciziile pe care le escalezi.
Echilibrul e chiar jobul
A fi un Engineering Manager tehnic nu înseamnă a face munca echipei. Înseamnă a te menține suficient de calibrat ca să conduci bine. Înseamnă să știi când să faci zoom in și când zoom out. Înseamnă să rezist presiunii de a deveni un operator de ședințe full-time al cărui singur instrument e calendarul.
Echipele pe care le-am condus mi-au transmis constant același lucru: apreciază că au un manager care înțelege cu ce se confruntă. Nu unul care programează pentru ei, unul care pricepe.
Aceasta e ștacheta pe care încerc s-o mențin. Și cred că mai mulți Engineering Manageri ar trebui s-o facă.
E un subiect la care mă gândesc des. Dacă navighezi tranziția de la IC la manager sau încerci să-ți dai seama cum rămâi tehnic ca lider, mi-ar plăcea să aud cum abordezi asta.