Saat Tim Menjadi Terlalu Besar

• Tim besar yang berpusat pada spesialis mengalami penurunan tajam dalam produktivitas dan efisiensi kolaborasi akibat ketergantungan internal, kesalahan penyampaian, bottleneck, dan penyebaran tanggung jawab
• Dalam rapat stand-up harian, sebagian besar isi pembicaraan menjadi tidak perlu atau membosankan; bertambahnya ukuran tim dan spesialisasi memicu putusnya komunikasi dan sikap tidak peduli
• Ada berbagai eksperimen seperti pemisahan berdasarkan teknologi (front-end/back-end), feature team sementara, dan penggunaan konsultan eksternal, tetapi pada akhirnya beralih ke peran generalis memberikan dampak paling nyata
• Kolaborasi kelompok seperti mob programming mendorong berbagi pengetahuan, kemandirian, rasa tanggung jawab, dan motivasi, serta lebih menguntungkan untuk kolaborasi dan pertumbuhan yang berfokus pada hasil dibanding terpaku pada satu bidang
• Namun, efek samping generalisasi (penurunan spesialisasi, risiko burnout) juga ada, sehingga eksperimen berkelanjutan dan perbaikan budaya tetap penting

---

Masalah saat tim terlalu besar

• Masalah yang muncul di tim besar beranggotakan 14 orang: sebagian besar percakapan dalam stand-up tidak diperlukan, dan sering terjadi informasi kerja yang tidak tersampaikan serta pekerjaan informal
• Bahkan setelah beralih ke stand-up asinkron (Slack, dll.), percakapan dan peluang kolaborasi yang penting justru hilang dan berubah menjadi sekadar laporan

Berbagai eksperimen pembagian dan operasional

• Pemisahan berdasarkan teknologi (Task Force): dibagi menjadi front-end/back-end, tetapi segera muncul masalah ketergantungan timbal balik dan waktu yang terpakai bertambah karena harus ikut stand-up tambahan
• Feature team sementara: personel dipindahkan sementara sesuai implementasi fitur tertentu, tetapi memunculkan isu pemeliharaan dan pengelolaan sumber daya
• Penempatan konsultan eksternal: tim sudah besar, tetapi tetap tidak efisien, sementara ada tekanan dari manajemen atas untuk memanfaatkan sumber daya

Solusi yang pada akhirnya paling efektif

• Menerapkan model generalis alih-alih spesialis
  • Tanpa memisahkan peran seperti front-end, back-end, QA, dan DevOps, seluruh skill set dibagi dengan berpusat pada satu tujuan/produk
  • Mewujudkan berbagi pengetahuan, berkurangnya penyebaran tanggung jawab, hilangnya bottleneck, serta delivery yang lebih cepat dan berkualitas lebih tinggi
  • Memperkuat komunikasi/otonomi/rasa memiliki melalui kolaborasi kelompok seperti mob programming

Mengapa generalis efektif

• Konteks dan tujuan bersama: sekalipun memasuki bidang baru, kurva belajar menjadi lebih ringan karena tetap berpatokan pada produk/tujuan yang sama
• Kebutuhan yang terbatas: cukup menguasai alat tertentu (CI/CD, dll.), dengan penekanan pada produktivitas dan maintainability dibanding keahlian yang sangat mendalam
• Memenuhi 3 elemen motivasi (otonomi, penguasaan, tujuan) sekaligus, sehingga mendukung rasa kepemilikan dan pertumbuhan tim
• Budaya egaliter: akses yang setara, perolehan pengetahuan secara mandiri, distribusi wewenang dan tanggung jawab, serta pembelajaran kolektif
• 3 elemen tanggung jawab (pengetahuan, wewenang, tanggung jawab) menjadi jelas, sehingga menghasilkan output yang cepat dan berkualitas tinggi berbasis ownership

Efek samping dan batasan

• Kepergian para spesialis: generalisasi tidak cocok untuk semua orang, dan dapat memicu burnout atau beban sumber daya berlebih pada sebagian anggota
• Kurangnya kedalaman spesialisasi: karena harus menangani berbagai stack secara dangkal, pendalaman keahlian pada satu bidang bisa terhambat

Kesimpulan dan pelajaran

• Tidak ada solusi yang seragam, dan budaya eksperimen serta perbaikan lebih penting
• Kekurangan model spesialis (bottleneck, putusnya komunikasi, fake work, putusnya konteks) dapat diatasi melalui generalis dan kolaborasi kolektif
• Pada akhirnya, model yang optimal bisa berbeda tergantung tujuan, SDM, anggaran, dan karakteristik produk
• Intinya adalah budaya eksperimen terbuka, feedback, dan perbaikan berkelanjutan

[codemasterkimc]

Saya seorang generalis, tetapi yang saya rasakan di lapangan adalah seperti ini.
Yang berguna memang generalis, tetapi yang benar-benar diakui "nilainya" ternyata adalah spesialis.
Bahkan jika lulus dari universitas yang sama, dengan IPK yang sama, pada akhirnya para spesialis menerima kompensasi 2–3 kali lebih tinggi.

[kandk]

Saya juga punya pemikiran yang mirip.
Tapi menurut saya, untuk software, kecuali deep tech AS, spesialis tampaknya tidak benar-benar terlalu spesial.

[roxie]

Boleh minta contohnya? Saya penasaran, secara praktis seberapa “spesial” seseorang sampai disebut spesialis...

[codemasterkimc]

Dari sudut pandang HR, sepertinya perusahaan besar atau perusahaan menengah-besar meminta pengalaman sekitar 3 tahun, dan menurut standar saya, specialist adalah orang yang, dari perspektif backend, bisa memanfaatkan LLM untuk merancang arsitektur yang mudah digunakan siapa pun sekaligus mempertimbangkan high availability.
Sebagai contoh, saya ini generalist, tetapi saya bisa merancang layanan domestik mana pun dengan trafik lebih dari 100 juta pengguna dengan sesederhana mungkin sampai anak SD pun bisa memahaminya.
Tapi karena saya juga seorang generalist, lamaran saya ke perusahaan besar langsung tersaring wkwkwk