Nimeni nu mi-a pus un manual de management în mână și nu mi-a zis „e rândul tău." Tranziția de la a scrie cod full-time la a conduce oameni s-a întâmplat în modul în care se întâmplă cele mai multe schimbări de carieră semnificative: treptat, apoi dintr-odată.
Nu m-am trezit într-o dimineață și am decis să devin Engineering Manager. M-am trezit și am realizat că deja eram unul, doar fără titlu.
A început cu asumarea, nu cu ambiție
Când am fondat Creative Coding în 2011, eram 100% individual contributor. Scriam codul, îl deployam, îl debugam la 2 noaptea și vorbeam cu clienții a doua zi dimineață. Nu exista echipă. Eram doar eu și munca.
Dar pe măsură ce compania a crescut la șapte developeri, ceva s-a schimbat. Încă scriam cod, dar din ce în ce mai mult din zi se ducea pe alte lucruri. Revizuiam ce construiau alții. Explicam decizii de arhitectură. Stăteam cu un developer junior care era blocat pe o problemă și realizam că a-l ajuta să găsească răspunsul era mai valoros decât să-l găsesc eu.
Nu mă gândeam la asta ca management. Mă gândeam doar că fac ce trebuie făcut.
Tranziția invizibilă
Privind înapoi, tranziția s-a întâmplat în straturi:
Stratul 1: Mentorat tehnic. Cineva te întreabă ceva. Apoi altcineva. Apoi începi să observi tipare, aceeași confuzie, aceeași capcană arhitecturală, și începi să le adresezi din proprie inițiativă. Nu conduci pe nimeni. Doar împărtășești context. Dar ești deja lider.
Stratul 2: Asumarea livrării. Începi să-ți pese nu doar dacă codul tău funcționează, ci dacă proiectul se livrează. Observi când cineva e blocat și intervii, nu ca să-i scrii codul, ci ca să-i scoți obstacole din cale. Începi să gândești în termeni de output al echipei, nu doar al tău.
Stratul 3: Investiția în oameni. Realizezi că cel mai bun lucru pe care-l poți face pentru proiect nu e să scrii cea mai deșteaptă funcție, ci să te asiguri că persoana care o scrie înțelege problema suficient de profund încât să ia decizii bune fără tine. Începi să investești în oameni pentru că e lucrul cu cel mai mare efect de pârghie.
Stratul 4: Gândirea strategică. Nu mai întrebi „ce ar trebui să construiesc?" și începi să întrebi „ce ar trebui să construim și de ce?" Începi să faci legătura între business și echipa de engineering: traduci priorități, respingi timeline-uri nerealiste, militezi pentru investiție tehnică.
Fiecare strat s-a simțit natural. Niciunul nu s-a simțit ca o schimbare de carieră. Dar împreună, exact asta au fost.
Ce am adus din lumea de IC
Cel mai mare avantaj al unei tranziții naturale e că nu-ți pierzi identitatea tehnică. O evoluezi.
Încă revizuiesc PR-uri. Nu ca să fiu gatekeeper, ci ca să rămân calibrat. Încă particip la discuțiile de arhitectură ca participant, nu doar ca aprobator. Încă fac prototipuri când asta ajută la deblocarea unei decizii. Încă îmi pasă profund de calitatea codului, de system design și de developer experience.
Fluența tehnică nu e ceva opțional. E ceea ce dă credibilitate leadership-ului. Inginerii simt când managerul lor înțelege compromisurile prin care navighează. Simt și când blufează. Diferența e încrederea, iar încrederea e fundația a tot ce urmează.
Ce a trebuit să învăț pe calea grea
Tranziția n-a fost lină peste tot. Câteva lucruri pe care le-am greșit:
Să renunț la statutul de cel mai bun IC din cameră. Când treci în leadership, valoarea ta nu mai e în codul pe care-l scrii. E în codul pe care-l scrie echipa ta, în deciziile pe care le iau și în mediul pe care-l creezi. E evident la nivel intelectual și brutal de greu la nivel emoțional, mai ales când vezi un PR și te gândești „eu aș fi făcut asta altfel."
Să am conversații dificile devreme. Ca IC, poți evita fricțiunea interpersonală pur și simplu făcând treabă excelentă. Ca lider, nu poți. Am învățat, lent, dureros, că cel mai bun lucru pe care-l poți face e să dai feedback sincer devreme, nu să aștepți până devine criză.
Să rezist impulsului de a rezolva totul. Instinctul care m-a făcut un IC bun (vezi o problemă, rezolv-o) a devenit un dezavantaj ca lider. Dacă rezolv fiecare problemă, echipa nu-și construiește niciodată mușchiul de a le rezolva singură. Să înveți să pui întrebarea potrivită în loc să dai răspunsul potrivit a fost una dintre cele mai grele abilități de dezvoltat.
Să înțeleg că tăcerea nu e acord. În munca de IC, dacă nimeni nu obiectează, planul e probabil bun. În leadership, tăcerea înseamnă adesea că oamenii nu se simt suficient de în siguranță ca să contrazică. Să creezi spațiu pentru dezacord sincer e o abilitate pe care încă o rafinez.
Momentul în care am știut că e drumul potrivit
A fost o săptămână specifică (nu-mi amintesc data exactă, dar îmi amintesc senzația) când am realizat că îmi dă mai multă satisfacție să-l văd pe un inginer software junior reușind o funcționalitate complexă decât mi-ar fi dat construind-o eu.
Acela a fost momentul. Nu sunt un IC care se întâmplă să conducă oameni. Sunt un lider care se întâmplă să înțeleagă codul.
Distincția contează. Nu e vorba despre a alege între tehnic și managerial. E vorba despre a le integra pe amândouă în ceva cu adevărat mai valoros decât oricare separat.
De ce cred că drumul natural e subestimat
Industria tinde să formalizeze tranziția de la IC la manager. Sunt programe, framework-uri, career ladder-uri cu așteptări precis definite. Și au valoare, creează claritate și corectitudine.
Dar cred că e ceva important în drumul organic. Când tranziționezi natural, aduci o autenticitate greu de fabricat. N-ai devenit manager pentru că era treapta următoare pe scară. Ai devenit unul pentru că ai început să-ți pese de succesul echipei mai mult decât de propriul output, și, în cele din urmă, titlul a ajuns din urmă realitatea.
Dacă ești un IC care se simte atras spre mentorat, spre asumarea livrării, spre a gândi la echipă înaintea task-ului, nu rezista. Nu-ți abandonezi identitatea tehnică. O extinzi.
Tranziția de la IC la manager e unul dintre cele mai discutate subiecte din engineering și unul dintre cele mai personale. Dacă ești în mijlocul ei și vrei să vorbim despre ce experimentezi, scrie-mi. Am trecut prin asta.