Selama karier saya, saya sering bekerja dengan berbagai tim platform—beberapa di antaranya sangat baik, beberapa buruk, dan beberapa bahkan seharusnya tidak pernah dibentuk. Pengalaman ini mengajarkan saya bahwa tujuan utama sebuah tim platform bukanlah sekadar membangun produk, melainkan menjadi *multiplier*—yaitu sebuah tim yang amplifikasi dampaknya berbanding lurus dengan jumlah tim yang mereka dukung. Misalkan sebuah platform team melayani sepuluh tim pengembang; setiap upaya yang mereka lakukan harus berdampak pada sepuluh kali lipat hasil, bukan hanya untuk satu tim saja. Jika seorang anggota tim membangun sebuah fitur baru, fitur tersebut harus langsung berguna bagi seluruh ekosistem, bukan hanya untuk tim mereka sendiri. Jika tidak, keberadaan tim platform menjadi tidak efisien; dalam banyak kasus, lebih baik untuk mendistribusikan anggota tim tersebut ke dalam tim-tim lain, karena komunikasi yang dibutuhkan oleh sebuah tim platform tunggal cenderung bersifat kuadratik terhadap jumlah tim yang dilayani.
Salah satu fungsi kritis dari sebuah platform adalah mengurangi beban kognitif. Dengan menyediakan runner GitLab atau Azure Agent yang siap pakai, tim platform menghilangkan kebutuhan bagi setiap tim untuk memahami cara skalabilitas runner atau proses pembaruan agen. Dengan demikian, tim pengembang dapat fokus pada implementasi persyaratan bisnis tanpa harus menguasai detail teknis infrastruktur. Pendekatan ini tidak hanya menghemat waktu tetapi juga sumber daya manusia yang berharga.
Membangun sebuah komunitas adalah tantangan unik lain bagi tim platform. Platform yang dibangun oleh sebuah tim sering kali bisa ditiru atau bahkan diperbaiki oleh pengembang lain. Namun, beberapa tim platform merasa terancam atau menolak bantuan karena ego, tidak menyadari bahwa peran mereka adalah menciptakan sebuah *platform* di mana semua orang dapat berkembang, bukan sebuah produk proprietary. Prinsip Difusi Inovasi berlaku di sini: ada pengguna awal yang ingin membangun sendiri, ada early adopter yang memberikan masukan tetapi tidak membangun, dan ada kelompok mayoritas serta laggards yang menunggu. Tim platform harus melibatkan kedua kelompok pertama karena mereka mencari solusi optimal. Dengan memandu mereka untuk berkontribusi, platform dapat berkembang melampaui batasan tim aslinya. Upaya ini membutuhkan keterampilan berkomunikasi yang baik, tetapi saya melihatnya sebagai bagian integral dari pekerjaan. Bagi kelompok mayoritas, mereka akan mengikuti secara otomatis, sementara kelompok laggards memerlukan waktu lebih untuk diyakinkan. Sesekali, kritik dari kelompok terakhir ternyata benar, dan mengabaikannya bisa menjadi kerugian besar.
Tantangan terbesar berikutnya adalah reputasi, terutama bagi tim platform baru. Setiap tim sudah memiliki cara kerja yang mapan, terkadang bahkan solusi yang sempurna dan terintegrasi erat dengan produk mereka. Ketika tim platform baru muncul dan mulai mengambil alih, mereka dianggap sebagai pengganggu yang mengganggu alur kerja yang sudah ada. Untuk mengatasi hal ini, tim baru harus *melakukan pekerjaan kotor terlebih dahulu*. Misalnya, jika sebuah tim keamanan ingin mengurangi jumlah kerentanan kritis, mereka dapat membangun dashboard yang menunjukkan jumlah kerentanan yang ditemukan oleh setiap tim, lalu secara proaktif memperbaikinya untuk tim-tim tersebut. Setelah menunjukkan nilai nyata, mereka dapat memperkenalkan platform baru mereka. Ini mengirimkan sinyal yang jelas: “kami di sini untuk membantu Anda.”
Dukungan juga merupakan aspek penting. Saya telah melihat berbagai sistem tiket, tetapi sistem tersebut hanya diperlukan ketika pertanyaan dukungan sudah tidak terkendali. Jika pertanyaan menumpuk, cari tahu penyebab utamanya—biasanya karena pengembang tidak memiliki alat yang tepat untuk menyelesaikan masalah sendiri. Memiliki sistem tiket sering kali menciptakan penghalang yang tidak perlu, membuat tim platform terasa seperti entitas yang terpisah, atau bahkan lebih buruk, mencegah orang mengajukan pertanyaan. Solusi terbaik adalah saluran dukungan terbuka yang dapat diakses oleh semua orang, di mana pertanyaan sederhana maupun kompleks dapat diajukan dan jawaban ditampilkan secara publik. Dengan cara ini, seluruh komunitas dapat mencari solusi sebelumnya, dan bahkan model AI dapat dilatih pada saluran tersebut untuk memberikan bantuan langsung. Untuk menghindari kelelahan akibat beralih konteks yang terus-menerus, buat sistem giliran sehingga hanya satu orang yang bertanggung jawab atas saluran tersebut dalam periode waktu tertentu.
Terakhir, prinsip *non-blocking* harus menjadi pedoman. Sama seperti tim produk memiliki prioritas P1, P2, dan P3, tim platform juga harus memiliki tingkat kepentingan yang sama. Pengalaman saya menunjukkan bahwa tim platform yang enggan menangani permintaan dengan prioritas tinggi dapat menghambat kemajuan seluruh organisasi. Oleh karena itu, tim platform harus responsif, transparan, dan selalu berusaha untuk memberdayakan tim lain, bukan membatasi mereka.
Di Indonesia, di mana banyak perusahaan masih dalam tahap awal adopsi platform engineering, pelajaran-pelajaran ini sangat relevan. Membangun tim platform yang menjadi multiplier dapat mempercepat transformasi digital, mengurangi duplikasi upaya, dan meningkatkan kolaborasi antar tim. Dengan fokus pada pengurangan beban kognitif, membangun komunitas yang kuat, dan menjaga reputasi melalui dukungan yang proaktif, tim platform dapat menjadi katalisator yang mendorong inovasi berkelanjutan di ekosistem teknologi lokal.