Principalul scop al unui manager, cu exemple din ultimul meu proiect

Nu mai e loc pe Linkedin de cretini care au fost sefi pe tura peste 2-3 Pateli Gigei transpirati dintr-un call center si mor sa va dezvaluie secretele managementului. Ca se stie, in orice angajat zace un leader latent care entuziasmeaza multimile, ridica productivitatea la cer si tine locul parintelui ideal, pe care nu l-ai avut niciodata. Sta cunoasterea si dorinta de iluminare a discipolilor sub presiune in ei, nu alta!

Apropo de asta, nu am inteles niciodata de ce e atata agitatie cu “public speaking” in ultima vreme. Nu am vazut in nicio corporatie pe unde am fost vreunul urcat pe birou sa tina discursuri. Ok, inteleg ca sunt dubiosi care se duc la TED X sa auda someri vorbind, dar nu e ca si cum fac multi asta, nu? La ce fololeste?

Si nu ma refer aici la imbecili gen Simon Sinek care-s un apogeu al cretinismului motivational, ci la tot felul de ciudati care nu au facut nimic semnificativ niciodata in management, dar stiu ei cum e sa fii sef. Ca ce dracu, e cel mai usor lucru din lume, nu? Dai ordine, fraierii fac, scoti un ban bun, toata lumea fericita!

Ceea ce eu am invatat din toti anii astia de project management, real management, scrum master (fara servant leader, ca aia e un fel de diaree constipata), product management, bla , bla e ca un sef trebuie sa ajute pe aia de sub el sa isi faca treaba. Cat mai bine SI MAI INDEPENDENT. Sau sa ii schimbe daca-s praf.

Da da, cu cat te freaca la cap mai putin subordonatii pentru orice, cu atat merg lucrurile mai bine. Bine, asta fara sa ii repezi daca te deranjeaza, da? Si nu ii disperi cu 1001 sedinte, mailuri, chaturi, directive, regulamente, ordine si proceduri. Toate astea (daca nu lucrezi la NASA) trebuiesc simplificate la maxim, ca altfel tot pe tine te va durea capul.

Si sa stiti ca meme-le ala cu un meeting care trebuia sa fie un email e foarte real, ma gandesc la asta de fiecare data cand dau invite la o sedinta. Dar unele sunt necesare si asta este, secretul e sa nu crezi ca toate sunt!

Exemplu concret: cu niste luni in urma am preluat un proiect, cu un produs deja pe piata si care mergea destul de bine comercial. Un startup la stadiul de tranzitie spre companie mica, cu probleme la facut saltul asta.

Din pacate in interiorul echipei lucrurile nu stateau asa de bine ca pe piata. Atat la dezvoltarea web cat si la mobile era haos, suportul era asaltat de clienti, bugurile apareau de peste tot, iar workflow-ul de la idee la release suferea grav. Jobul meu? Sa fac ordine by all means, Dumnezeu adjunct in companie.

Asa ca mi-am suflecat manecile si m-am pus pe treaba. Am vorbit cu toata lumea si am inteles la inceput cum merg lucrurile si cine face ce. Asta e esential, nu poti schimba fara sa intelegi, cum fac multi iluminati d-astia in zilele noastre. Nu vii cu idei de acasa, pentru ca fiecare proiect e unic. Si nu exista “cele 10 metode prin care oamenii de succes schimba un proiect” si cretinatati din astea.

Si era haos, cand se intampla ceva erau toti gramada pe toate canalele din Slack, testarea se calca pe picioare cu suportul, API-urile facute de devii de backend aveau probleme pe mobile etc etc etc. Pana si aplicatia de project management era una gresita si haotica.

In fiecare zi era sfarsitul lumii, clienti se plangeau de diverse, unele buguri nu dispareau, se fixau unele si crapau altele etc. Clar niste baieti nu isi faceau treaba. Dupa ce am inlocuit cei trei testeri cu unii care stiau ce fac si i-am inplicat in workflow-ul de suport sa valideze buguri si plangeri, a inceput sa se faca liniste. Si sa inteleg ca sunt mai probleme la development.

Intre timp facusem si un workflow pentru suport si le povestisem cum merge developmentul, ca nu e magic cum credeau ei si nu e reavointa ca nu se fixeaza tot asap. Asa ca s-au mai calmat si au colaborat foarte bine cu testarea. E foarte important sa le explici tuturor ce fac ceilalti si de ce.

Avand niste liniste pe partea asta, am trecut la echipa de devi si am realizat ca din cati aveam, doar 2-3 stiau pe ce lume sunt. Adus cativa devi noi, un business analyst pentru partea de product si inceput tranzitia si acolo, organizat ce se face si cum se face si pus un project manager nou peste ei (trecut la Jira, sprinturi de 2 saptamani, taskuri clare si concise, pentru cei ce inteleg asta)

Ultima a fost echipa de mobile, care acum cu partea de backend deja organizata s-a mai calmat cu ce aveau nevoie si au inceput sa comunice mai bine cu cei de la web. Si acolo implicat un business analyst, schimbat ceva devi, adus un lead nou. Intre timp, lucram si cu owner-ul pe partea de produs si i-am facut un workflow cu business analistii bagati si ei in definirea a ce vrea sa faca mai departe. Sa fim siguri ca evolutia produsului e clara pentru toti si la developeri ajung taskuri reale cu designul aferent si nu idei pe jumatate schitate, ca inainte.

Abia dupa toate astea de fapt incepe munca de unit toate workflowurile, perfectionat cele facute pe genunchi ca sa fie liniste si ascultat ce vrea lumea si ce sugestii au.

Deci, nu stiu daca se deduce din cele de mai sus asa ca o sa o repet: am rezolvat o parte din probleme, facut proceduri, inlocuit oameni, pus pe cineva sa se ocupe, mers mai departe. Nu am ramas eu un mare sef peste toti, cum fac majoritatea, sa nu miste nimeni in deget fara mine. Aia nu e o solutie, e un haos organizat cu un fraier ca principal blocaj pe tot proiectul.

Se poate face treaba in firma si fara sa inspecteze managereul totul si seful lui sa il aprecieze in continuare. In ciuda unei credinte incetatenite ca daca nu esti indispensabil ca sef, te dau afara. Scopul final a ceea ce fac acolo este ca activitatile zilnice sa mearga pe niste tipare clare si doar ce iese din ele sa ajunga la mine. Apoi modificam tiparele conform problemelor ce apar si continuam. Si ascultam si ce spun cei implicati in ele, ca nu doar sefimea vede adevarul. Oamenii trebuiesc ajutati cum au ei nevoie in mod real, nu cum au sefii, sa le fie cald si sa nu schimbe lucruri, ca deranjeaza.

Si nu, nu le-am tinut discursuri motivationale, nu i-am mangaiat pe crestet, nu am fost tatal lor. Asta nu inseamna ca nu am avut rabdare, ca nu s-a detaliat si repetat de multe ori pana s-a inteles, ca nu au fost si erori si probleme. Si devi frustrati de concedieri. Si ca nu li s-a acordat o sansa celor ce au fost concediati pana la urma.

Pentru ca datul afara trebuie sa fie ultima solutie, mereu. Si nu a fost usor deloc, asta e o descriere extrem de generala a ceea ce am facut, fara detalierea celor 1001 de alte probleme.

Dar ca manager jobul tau e sa ii ajuti sa munceasca si cand nu se poate, sa aduci altii. Dupa ce asta merge bine te gandesti tu cum sa perfectionezi lucrurile, sa faci rapoarte colorate si powerpointuri si alte kkturi inutile. Dar nu inainte. Apropo, nu am simtit nevoia sa fac niciunul din documentele inutile de mai sus :))

Trebuie sa fii foarte incompetent, foarte degeaba sau foarte speriat ca iti pierzi jobul ca sa ramai implicat in toate workflowurile ca manager, sa vina toti sa ceara aprobari pentru orice rahat. Eu personal ma duc cu capul la faze din astea si incerc sa le evit pe cat posibil, cand se poate si altfel.

Asta nu inseamna ca nu stii ce iti fac oamenii, ci doar ca ii lasi sa faca singuri treaba cat timp merge bine si raporteaza imediat ce au probleme care ii depasesc. Nu am chef de ulcer, sedinte dupa 5-6 seara si SMS-uri in vacante, multumesc! Daca auzi vreun sefut ca zice “fara mine nu merge nimic aici” fugi cat poti de tare. Sau stai cu ochii pe el daca ii esti manager, omul ala e o problema.

Cam asa arata managementul real in domeniul meu si chiar daca nu am inglobat toate exceptiile posibile, sper ca a fost clar. De aia nu e nevoie de motivationale, carti de management, cursuri de leadership si altele. Ca nu vezi padurea de copaci cu mizeriile alea si incepi sa crezi ca toate rahaturile sunt super importante in jobul asta.