Merestrukturisasi Tim Produk Braze

Kekuatan pendorong terpenting di balik produk perangkat lunak apa pun adalah kelompok orang yang membangunnya—dan hubungan mereka satu sama lain. Oleh karena itu, penting untuk mengatur tim dengan cara yang memungkinkan mereka memiliki pengaruh dan pengaruh sebanyak mungkin.

Di Braze, kami telah memikirkan secara mendalam tentang bagaimana produk dan organisasi teknik kami dirancang, dan ingin berbagi pembelajaran kami dari reorganisasi departemen utama yang sangat membantu kami meningkatkan cara kami memprioritaskan fitur, mengembangkan keahlian tim, dan membangun produk kami dengan lebih efisien.

Struktur Awal: Produk/Pasar Fit and Beyond

Menemukan kecocokan produk/pasar—dan memanfaatkannya untuk mengembangkan bisnis—merupakan tantangan yang harus dilalui oleh semua startup. Sepanjang tahap ini dalam pengembangan startup, kecepatan eksperimen dan kemampuan untuk memanfaatkan peluang dengan cepat sangat penting. Untuk itu, struktur tim produk asli kami terlihat seperti ini:

Struktur ini, yang membagi tim kami berdasarkan spesialisasi fungsional, bekerja dengan baik karena beberapa alasan.

Pertama, ini memungkinkan kami untuk secara efisien menangani perubahan produk transformasional dalam perjalanan menuju kesesuaian produk/pasar—para ahli dapat memiliki sebagian besar basis kode kami dan menggunakan bahasa, kerangka kerja, dan keputusan desain yang paling nyaman bagi mereka. Dipicu oleh kafein dalam jumlah besar, "tim" proyek satu pasukan secara teratur menangani upaya besar. Ini termasuk membangun API publik kami yang menghadap pelanggan dan merombak seluruh infrastruktur pengiriman pesan kami, sering kali mengisi peran sebagai insinyur tunggal, manajer produk, dan desainer. Jenis tindakan ekstrem ini akan menjadi kegilaan di perusahaan besar, tetapi diperlukan dan hampir rutin selama pertumbuhan awal.

Selain itu, struktur ini membantu kami menguasai secara mendalam bidang teknis tertentu hanya dengan tim 10-15 orang. Banyak elemen dari produk inti kami—misalnya lapisan model-view-controller front end kami, API, dan kode pengiriman pesan throughput tinggi—hanya dipahami sepenuhnya oleh beberapa individu.

Pada saat itu, itu sederhana dan semua yang kami butuhkan. Ketika kecepatan adalah segalanya, pengorganisasian berdasarkan pedoman sederhana membantu mengurangi overhead kognitif dan memungkinkan kami untuk memusatkan perhatian di tempat yang paling baik.

Struktur Selanjutnya: Pertumbuhan dan Penskalaan

Namun, ketika tim kami tumbuh melewati usia 30 atau 40, struktur ini mulai rusak. Kami akhirnya mengidentifikasi reorganisasi tim produk kami sebagai solusi untuk beberapa tantangan terbesar kami. Kami mengeluarkan upaya yang tidak berkelanjutan untuk mengatur keterampilan dan jadwal waktu untuk menyusun tim untuk proyek-proyek strategis. Kami juga menghabiskan banyak waktu untuk memprioritaskan, dan sering mendapati diri kami memaksakan peringkat semua prioritas produk di seluruh bisnis karena struktur tim berbasis teknologi kami tidak memetakan langsung ke kebutuhan produk yang paling penting. Dan akhirnya, kami memiliki sedikit kesempatan bagi anggota tim untuk mengembangkan pengalaman mendalam dengan kasus penggunaan pelanggan tertentu.

Kami akhirnya beralih ke organisasi yang terstruktur di sekitar tim lintas fungsi Agile yang mirip dengan model Pasukan/Suku yang dipopulerkan oleh Spotify. Struktur organisasi baru kami terlihat seperti ini:

Sebagian besar tim kami bekerja dalam “vertikal produk”, yang sesuai dengan area utama produk atau bisnis kami. Sebagai contoh:

• Tim Email & Perusahaan kami menjalankan Email dari atas ke bawah, serta area produk tertentu seperti manajemen izin yang penting bagi banyak pelanggan terbesar kami.
• Tim Messaging & Automation kami memiliki beberapa area produk yang berkaitan dengan segmentasi pengguna, messaging, dan produk orkestrasi unggulan kami, Canvas.

Dalam vertikal, kami mengharapkan prioritas menjadi (relatif) langsung, karena setiap vertikal sesuai dengan serangkaian kebutuhan pelanggan tertentu. Tim tertentu seperti Desain Visual, DevOps, dan grup Teknik Infrastruktur kami menjangkau seluruh platform, membangun konsistensi di area utama.

Dampak

Reorganisasi kami secara signifikan mengurangi ketergantungan lintas tim. Sebelumnya, kami berjuang dengan masalah penjadwalan seperti Sudoku dalam menempatkan keseimbangan yang tepat dari keahlian khusus (teknik, desain, manajemen produk, dll.) ke dalam proyek tertentu pada waktu tertentu. Ini juga menyelaraskan insentif jangka pendek—sebelum transisi, tim sering mendapati diri mereka mengandalkan rekanan yang membidik tujuan yang tidak terkait. Dengan struktur baru kami, tim produk menjadi mandiri, memiliki kontrol yang jauh lebih besar atas jadwal, dan sepenuhnya selaras dengan tujuan, meningkatkan produktivitas dan moral.

Desain organisasi baru juga meningkatkan prioritas. Misalnya, tim Email & Perusahaan kami mungkin perlu memutuskan antara meningkatkan infrastruktur email kami, membangun fitur email inti, atau memperbaiki masalah kegunaan perusahaan—keputusan yang langsung dan mudah diukur, karena ketiganya berhubungan dengan kebutuhan pelanggan kami dengan cara yang sama .

Sebuah tim yang berjuang dengan terlalu banyak kebutuhan prioritas tinggi juga merupakan indikator bahwa area produk mereka membutuhkan lebih banyak sumber daya. Hal ini memungkinkan kami untuk membingkai ulang masalah prioritas yang sulit sebagai kebutuhan staf, yang masih menantang tetapi secara konseptual mudah untuk ditangani.

Akhirnya, memfokuskan sebagian besar tim pada area produk tertentu telah memungkinkan individu untuk membangun keahlian yang mendalam dan hubungan kerja yang sangat produktif dari waktu ke waktu. Awalnya, dalam beberapa tahun pertama pembangunan, individu pada dasarnya dapat memegang seluruh produk dan basis kode di kepala mereka, tetapi seiring pertumbuhan kami, hal ini menjadi tidak mungkin. Masalah produk bersifat fraktal: setiap kali Anda melihat lebih dekat, Anda menemukan lebih banyak nuansa dan kedalaman. Akibatnya, menghabiskan banyak waktu di area tertentu dari produk atau basis kode dan sangat memahami kebutuhan bisnisnya adalah salah satu cara terbaik untuk mencapai terobosan produk nyata. Selain itu, menciptakan tim jangka panjang yang terfokus membangun kepemilikan dan hubungan baik, dan memungkinkan hubungan kerja yang tak terucapkan antara sekumpulan kolaborator yang konsisten untuk menyatu.

Tentu saja, tidak ada sistem yang sempurna. Dengan fokus pada pilar berorientasi produk, kami meningkatkan potensi tim untuk mengoptimalkan kebutuhan lokal dengan mengorbankan prioritas holistik. Misalnya, seseorang mungkin berfokus pada utang teknologi lokal (“pengontrol ini tidak praktis”) daripada masalah global (“mengubah kerangka kerja front-end kami akan meningkatkan kecepatan teknis keseluruhan”). Untuk mengantisipasi kebutuhan ini, kami mengambil langkah-langkah untuk membentuk tim lintas sektor yang disebutkan di atas, dan telah menggunakan komite khusus untuk proyek besar lainnya—misalnya, komite untuk membangun sistem produk/desain holistik dari komponen front-end dan pola desain .

Struktur baru kami juga menghadirkan energi aktivasi yang lebih tinggi untuk perubahan produk transformasional yang holistik. Beberapa area produk kami, seperti API back-end kami, dimiliki bersama oleh beberapa tim. Ambang batas untuk membuat perubahan menyeluruh pada area lintas sektoral yang luas dari basis kode kami lebih tinggi, jadi jenis struktur ini berfungsi paling baik setelah kerangka produk Anda sebagian besar terbentuk.

Bawa pulang

Secara keseluruhan, kami puas dengan desain ulang struktur organisasi produk kami: Kami telah menyelesaikan atau sangat meningkatkan tantangan kami seputar ketergantungan tim, prioritas, dan membangun keahlian produk jangka panjang, dan juga memiliki peta jalan yang berguna untuk bagaimana kami akan menskalakan. Secara khusus, kami telah mempelajari bahwa:

• Menghapus ketergantungan dan menyelaraskan insentif menghasilkan keuntungan efisiensi yang besar.
• Prioritas apel-ke-apel lebih sederhana dan lebih efektif.
• Keahlian mendalam dalam kebutuhan pelanggan atau bisnis tertentu mengarah pada hasil produk yang lebih baik.
• Bekerja dengan anggota tim yang sama dalam waktu yang lama sangat penting untuk membangun hubungan kerja yang baik.

Saya akan merekomendasikan struktur ini untuk tim mana pun yang berbagi karakteristik utama tertentu: organisasi lintas fungsi di mana para ahli fungsional seperti manajer produk, perancang, dan insinyur adalah pemangku kepentingan yang setara; lebih dari sekitar 15-20 orang di tim pengembangan produk gabungan; dan, yang paling penting, kecocokan pasar produk yang kuat. Dan jika jenis struktur tim ini terdengar menarik bagi Anda, kami sedang merekrut!