Restructurarea echipei de produse Braze

Cea mai importantă forță motrice din spatele oricărui produs software este grupul de oameni care îl construiesc și relațiile dintre ele. Prin urmare, este important să aranjați echipele într-un mod care să le permită să aibă cât mai multă pârghie și impact posibil.

La Braze, ne-am gândit mult la modul în care este proiectată organizația noastră de produse și inginerie și dorim să ne împărtășim învățăturile dintr-o reorganizare departamentală majoră care ne-a ajutat să îmbunătățim considerabil modul în care prioritizăm funcțiile, dezvoltăm expertiza echipei și ne construim produsul mai eficient.

Structura timpurie: se potrivește produsului/piață și nu numai

Găsirea unei potriviri de produs/piață – și valorificarea acesteia pentru a dezvolta o afacere – este un creuzet prin care trebuie să treacă toate startup-urile. Pe parcursul acestei etape de dezvoltare a unui startup, viteza de experimentare și capacitatea de a valorifica rapid oportunitățile sunt esențiale. În acest scop, structura noastră originală a echipei de produse arăta astfel:

Această structură, care ne-a împărțit echipa pe specialități funcționale, a funcționat bine din mai multe motive.

În primul rând, ne-a permis să abordăm în mod eficient schimbările transformaționale ale produselor pe calea spre potrivirea produsului/piață – experții puteau să dețină părți uriașe din baza noastră de cod și să folosească limbajele, cadrele și deciziile de proiectare cu care erau cel mai confortabil. Alimentate de cantități masive de cofeină, „echipele” de proiect „Army-of-one” au abordat în mod regulat eforturi uriașe. Acestea au inclus construirea API-ului nostru public orientat către clienți și revizuirea întregii noastre infrastructuri de trimitere a mesajelor, ocupând adesea rolul de unic inginer, manager de produs și designer. Aceste tipuri de măsuri extreme ar fi o nebunie la o companie mare, dar sunt necesare și aproape de rutină în timpul creșterii timpurii.

În plus, această structură ne-a ajutat să dobândim stăpânirea profundă a anumitor domenii tehnice cu doar o echipă de 10-15 persoane. Multe elemente ale produselor noastre de bază, de exemplu, stratul de control al modelului de vizualizare al front-end-ului nostru, API-urile și codul de trimitere a mesajelor de mare performanță, au fost pe deplin înțelese doar de câteva persoane.

La acea vreme, era simplu și tot ce aveam nevoie. Când viteza este totul, organizarea bazată pe linii directoare simple a ajutat la reducerea cheltuielilor cognitive și ne-a permis să concentrăm atenția acolo unde ar putea face cel mai bine.

Structura ulterioară: creștere și extindere

Cu toate acestea, pe măsură ce echipa noastră a trecut de 30 sau 40 de ani, această structură a început să se destrame. În cele din urmă, am identificat reorganizarea echipei noastre de produse ca o soluție la unele dintre cele mai mari provocări ale noastre. Depuneam efort nesustenabil pentru a jongla cu seturi de abilități și cronologie pentru a forma echipe pentru proiecte strategice. De asemenea, am petrecut o cantitate exagerată de timp pentru stabilirea priorităților și, de multe ori, ne-am trezit clasificând toate prioritățile de produs în cadrul afacerii, deoarece structura noastră de echipă bazată pe tehnologie nu s-a adaptat direct la cele mai esențiale nevoi de produs. Și, în sfârșit, am avut puține oportunități pentru membrii echipei de a dezvolta o experiență profundă cu anumite cazuri de utilizare ale clienților.

În cele din urmă, am trecut la o organizație structurată în jurul echipelor interfuncționale Agile similare cu modelul Squad/Tribe popularizat de Spotify. Noua noastră structură organizatorică arată astfel:

Majoritatea echipei noastre lucrează în „verticale de produs”, corespunzătoare unui domeniu cheie al produsului sau afacerii noastre. De exemplu:

• Echipa noastră de e-mail și întreprinderi rulează e-mail de sus în jos, precum și anumite domenii de produse, cum ar fi gestionarea permisiunilor, care sunt esențiale pentru mulți dintre cei mai mari clienți ai noștri.
• Echipa noastră de mesagerie și automatizare deține mai multe domenii de produse legate de segmentarea utilizatorilor, mesagerie și produsul nostru emblematic de orchestrare, Canvas.

În cadrul unei verticale, ne așteptăm ca prioritizarea să fie (relativ) simplă, deoarece fiecare verticală corespunde unui set specific de nevoi ale clienților. Anumite echipe, cum ar fi Visual Design, DevOps și grupurile noastre de Inginerie a Infrastructurii, acoperă întreaga platformă, creând coerență în domenii cheie.

Impacturi

Reorganizarea noastră a redus semnificativ dependențele între echipe. Anterior, ne-am confruntat cu problema de planificare asemănătoare Sudoku-ului de a împărți echilibrul potrivit de seturi de abilități specializate (inginerie, design, management de produs etc.) într-un anumit proiect la un moment dat. De asemenea, a aliniat stimulentele pe termen scurt – înainte de tranziție, echipele se trezeau adesea să se bazeze pe contrapărți care urmăreau obiective care nu au legătură. Cu noua noastră structură, echipele de produse sunt independente, au mult mai mult control asupra cronologiei și sunt pe deplin aliniate la obiective, crescând productivitatea și moralul.

Noul design organizațional a îmbunătățit, de asemenea, prioritizarea. De exemplu, echipa noastră de e-mail și întreprindere ar putea avea nevoie să decidă între actualizarea infrastructurii noastre de e-mail, construirea unei funcții de e-mail de bază sau remedierea unei probleme de utilizare a întreprinderii - o decizie simplă și ușor cuantificabilă, deoarece toate trei se referă la nevoile clienților noștri în moduri similare. .

O echipă care se luptă cu prea multe nevoi prioritare este, de asemenea, un indicator că zona de produse are nevoie de mai multe resurse. Acest lucru ne permite să reîncadram problemele dificile de prioritizare ca nevoi de personal, care sunt încă provocatoare, dar conceptual ușor de abordat.

În cele din urmă, concentrarea majorității echipelor pe o anumită zonă de produs a permis indivizilor să dezvolte o expertiză profundă și relații de lucru extrem de productive în timp. Inițial, în primii câțiva ani de construcție, oamenii puteau să aibă în cap în esență întregul produs și baza de cod, dar pe măsură ce am crescut, acest lucru a devenit imposibil. Problemele produselor sunt fractale: de fiecare dată când te uiți mai atent, găsești mai multă nuanță și profunzime. Ca rezultat, petrecerea multor ore într-o anumită zonă a unui produs sau a unei baze de cod și înțelegerea profundă a nevoilor sale de afaceri este una dintre cele mai bune modalități de a obține descoperiri reale ale produsului. În plus, crearea de echipe concentrate pe termen lung construiește proprietatea și relația și permite relațiile de lucru nerostite între un set consistent de colaboratori să se stabilească.

Desigur, niciun sistem nu este perfect. Cu accent pe pilonii orientați spre produs, am crescut potențialul echipelor de a optimiza pentru nevoile localizate în detrimentul priorităților holistice. De exemplu, s-ar putea concentra pe datoria tehnologică localizată („acest controler este greoi”) în loc de probleme globale („schimbarea cadrului nostru front-end ar crește viteza generală de inginerie”). În așteptarea acestei necesități, am luat măsuri pentru a stabili echipele transversale menționate mai sus și am folosit comitete dedicate pentru alte proiecte ample, de exemplu, un comitet pentru a construi un produs holistic/sistem de proiectare de componente front-end și modele de design .

Noua noastră structură aduce, de asemenea, o energie de activare mai mare pentru schimbări holistice, transformaționale ale produsului. Unele zone ale produsului nostru, cum ar fi API-urile noastre back-end, sunt deținute în comun de mai multe echipe. Pragul pentru efectuarea de modificări radicale în zonele largi, transversale ale bazei noastre de cod este mai mare, astfel încât acest tip de structură funcționează cel mai bine odată ce scheletul produsului dumneavoastră este în mare măsură format.

Concluzii

În general, am fost mulțumiți de structura noastră organizatorică de produse reproiectată: ne-am rezolvat sau ne-am îmbunătățit foarte mult provocările legate de dependențele de echipă, prioritizarea și construirea expertizei pe termen lung a produselor și, de asemenea, avem o foaie de parcurs utilă pentru modul în care ne vom scala. În special, am aflat că:

• Eliminarea dependențelor și alinierea stimulentelor duce la câștiguri uriașe de eficiență.
• Prioritizarea de la mere la mere este atât mai simplă, cât și mai eficientă.
• Expertiza profundă într-o anumită nevoie de client sau de afaceri duce la rezultate mai bune ale produsului.
• Lucrul cu aceiași membri ai echipei pe o perioadă lungă de timp este esențial pentru construirea unor relații de lucru excelente.

Aș recomanda această structură pentru orice echipă care împărtășește anumite caracteristici cheie: o organizație interfuncțională în care experții funcționali, cum ar fi managerii de produs, designerii și inginerii, sunt părți interesate egale; mai mult de aproximativ 15–20 de oameni în echipa combinată de dezvoltare a produselor; și, cel mai important, potrivirea fermă produs-piață. Și dacă acest tip de structură de echipă vă sună atrăgător, facem angajări!