Tersesat di Slack: Bisa Dicari Bukan Berarti Bisa Ditemukan
Tim Anda punya terlalu banyak saluran Slack dan tidak menemukan apa-apa. Mengapa pencarian saja tidak cukup – dan apa yang benar-benar berhasil.
By Ellis Keane · 2026-03-17
Berapa banyak saluran Slack yang dimiliki tim Anda saat ini? Bukan angka di bilah samping, karena sebagian besar sudah Anda bisukan. Angka sebenarnya, termasuk saluran yang dibuat seseorang untuk proyek yang berakhir enam bulan lalu, saluran dengan nama yang begitu mirip sehingga Anda tidak pernah yakin mana yang benar, dan segelintir saluran tempat hal-hal penting benar-benar terjadi yang tidak akan pernah Anda temukan lagi karena Anda tidak tahu hal-hal itu sedang terjadi pada saat itu.
Saya menebak Anda tidak tahu angkanya. Kami pun sejujurnya tidak tahu. Dan itulah inti persoalannya.
Saran standar untuk kelebihan saluran Slack adalah: reorganisasi, buat konvensi penamaan, arsipkan yang tidak diperlukan, mungkin lakukan pembersihan triwulanan (jenis ritual yang terasa produktif selama sekitar satu sore, lalu perlahan-lahan hancur selama enam minggu berikutnya). Saran itu baik-baik saja, sejauh jangkauannya, tetapi ia menangani gejala, bukan mekanismenya. Alasan mengapa tim Anda memiliki terlalu banyak saluran Slack dan tidak dapat menemukan apa pun bukan karena Anda buruk dalam berorganisasi (mungkin sedikit), melainkan karena Slack dibangun untuk percakapan, bukan untuk pengetahuan, dan celah antara keduanya adalah tempat semua konteks penting Anda pergi untuk mati.
Bisa Dicari Bukan Berarti Bisa Ditemukan
Inilah yang membuat kebanyakan tim tersandung. Pencarian Slack sebenarnya cukup baik dalam apa yang dilakukannya. Anda mengetik sebuah kata, ia menemukan pesan yang berisi kata tersebut, bahkan mengurutkannya berdasarkan relevansi dan memungkinkan Anda memfilter berdasarkan saluran, orang, dan rentang tanggal. Jika Anda tahu apa yang Anda cari dan kira-kira kapan itu terjadi, pencarian Slack akan membawa Anda ke sana.
Masalahnya adalah "bisa ditemukan" dan "bisa dicari" menggambarkan kemampuan yang secara fundamental berbeda – dan Slack hanya menawarkan salah satunya.
"Bisa dicari dan bisa ditemukan menggambarkan kemampuan yang secara fundamental berbeda – dan Slack hanya menawarkan salah satunya." – Ellis Keane
Bisa dicari berarti: saya punya kata kunci tertentu, dan saya ingin melihat setiap pesan yang mengandungnya. Bisa ditemukan berarti: saya ingat sebuah percakapan terjadi, saya tahu kira-kira tentang apa itu, tetapi saya tidak ingat kata-kata persis yang digunakan siapapun, saluran mana yang digunakan, atau tepatnya kapan itu terjadi. Skenario kedua itu, menurut pengalaman kami, merupakan sekitar 80% cara orang sebenarnya mencoba mengambil informasi dari Slack.
Pikirkan terakhir kali Anda mencoba menemukan sesuatu di Slack. Apakah Anda mengetik kata kunci yang tepat, atau Anda mencoba berbagai variasi, menggulir saluran, memeriksa DM, dan akhirnya bertanya kepada seseorang: "hei, ingat di mana kita membicarakan tentang...?" Jika yang kedua (dan saya akan bertaruh uang sungguhan bahwa biasanya memang begitu), maka pencarian Slack tidak rusak. Ia hanya memecahkan masalah yang berbeda dari masalah yang sebenarnya Anda miliki.
Bagaimana Saluran Berlipat Ganda dan Konteks Terfragmentasi
Inilah yang sebenarnya terjadi di sebagian besar tim yang kami amati. Ini dimulai dengan cukup sederhana: Anda membuat saluran untuk tim (#engineering, #design, #product), saluran untuk proyek (#project-atlas, #project-beacon), saluran untuk fungsi (#standup, #deployments, #incidents), dan mungkin beberapa yang sosial (#random, #watercooler). Itu mungkin 15–20 saluran dan berfungsi dengan baik selama sekitar tiga bulan.
Kemudian batas-batasnya mulai kabur. Seseorang memulai percakapan di #engineering tentang masalah penerapan yang seharusnya ada di #incidents. Percakapan tinjauan desain mencakup #design, #project-atlas, dan sebuah utas DM. Seseorang membuat #project-atlas-design karena mereka menginginkan ruang khusus untuk umpan balik desain pada proyek itu, dan sekarang ada dua tempat di mana keputusan desain Atlas mungkin berada – Anda sebaiknya memeriksa keduanya jika ingin gambaran lengkap.
Jumlah saluran sebenarnya bukan masalahnya, meskipun terasa demikian (saya tidak dapat membuktikan ini untuk setiap tim, tetapi ini benar untuk setiap tim yang pernah saya ajak bicara tentang hal ini). Masalahnya adalah setiap saluran menjadi kantong konteks yang terisolasi tanpa koneksi ke kantong-kantong lainnya. Percakapan di #project-atlas merujuk dokumen Notion yang merujuk isu Linear yang dibahas di #engineering, dan tidak ada referensi tersebut yang merupakan tautan yang dapat dibaca mesin. Itu adalah singkatan manusiawi: "sebagaimana dibahas", "sesuai dokumen", "menindaklanjuti utas tersebut". Seseorang yang ada di semua percakapan itu dapat mengikuti jejaknya. Seseorang yang tidak ada (atau seseorang yang ada, enam bulan kemudian) sama sekali tidak bisa.
Apa yang Sebenarnya Diselesaikan Konvensi Penamaan (dan Apa yang Tidak)
Saya tidak ingin menolak konvensi penamaan sepenuhnya, karena konvensi itu memang membantu satu hal tertentu: membantu Anda menemukan saluran yang tepat untuk dilihat. Pola yang konsisten seperti team-engineering, proj-atlas, func-deploys membuat bilah samping dapat dinavigasi. Itu adalah nilai nyata, meskipun konvensi itu bertahan kira-kira hingga orang ketiga yang tidak membaca wiki membuat atlas-design-feedback daripada proj-atlas-design.
Tetapi konvensi penamaan tidak menyelesaikan masalah keterdapatan, karena keterdapatan bukan tentang mengetahui saluran mana yang harus dicari. Ini tentang percakapan yang Anda butuhkan tersebar di tiga saluran dan satu DM, dan tidak ada konvensi penamaan di dunia yang akan memberi tahu Anda itu. Arsitektur informasi Slack memang datar berdasarkan desain, dan kerataan itu sebenarnya salah satu kekuatannya untuk percakapan waktu nyata (Anda tidak ingin hierarki ketika perlu dengan cepat menghubungi seseorang tentang penerapan), tetapi itu adalah bencana untuk pengambilan informasi.
Masalah "terlalu banyak saluran" sebenarnya adalah masalah "konteks yang terjebak di saluran". Mengurangi jumlah saluran membantu navigasi tetapi tidak menyelesaikan fragmentasi yang mendasarinya.
Mengapa Anda Punya Terlalu Banyak Saluran Slack dan Tidak Dapat Menemukan Apa Pun
Katakanlah Anda mencoba menemukan percakapan di mana tim Anda memutuskan untuk beralih dari REST ke GraphQL untuk API internal. Inilah yang sebenarnya terlihat:
- Anda mencari "GraphQL" di Slack. Anda mendapatkan sekitar 250 hasil di selusin saluran. Sebagian besar dari #engineering, beberapa dari #random (seseorang berbagi posting blog), beberapa dari #project-beacon tempat seseorang bertanya apakah peralihan akan memengaruhi mereka.
- Anda mempersempit ke #engineering. Masih ada puluhan hasil. Keputusan itu sendiri tidak ada di salah satunya karena ketika insinyur utama Anda berkata "ayo lakukan", mereka hanya mengatakan "kedengarannya bagus, ayo lanjutkan" sebagai balasan dari pesan dua hari sebelumnya.
- Anda mencari "REST API" dengan harapan menemukan diskusi perbandingan. Kumpulan hasil yang berbeda, hanya tumpang tindih sebagian. Beberapa pesan terpenting dalam utas keputusan tidak mengandung "REST" atau "GraphQL" karena mereka mendiskusikan pengalaman pengembang dan keamanan tipe secara umum.
- Anda menyerah dan bertanya di #engineering: "apakah ada yang ingat ketika kita memutuskan untuk beralih ke GraphQL?" Seseorang membalas dengan tautan ke isu Linear. Isu Linear tertaut ke RFC Notion. RFC Notion merujuk utas Slack (tetapi tautannya mati karena saluran telah diarsipkan). Dan momen keputusan sebenarnya ada dalam sebuah huddle tanpa catatan tertulis sama sekali.
Itu bukan masalah pencarian. Itu adalah masalah grafik pengetahuan. Dan itulah alasan sebenarnya mengapa tim dengan terlalu banyak saluran Slack tidak dapat menemukan apa pun, tidak peduli seberapa bagus pencarian Slack nantinya.
Apa yang Benar-Benar Berhasil
Setelah mengamati pola ini di tim kami sendiri (dan mendengar cerita yang sangat mirip dari manajer rekayasa lainnya), kami menemukan beberapa hal yang benar-benar membantu:
Terima bahwa Slack adalah kotak masuk, bukan arsip. Pergeseran model mental yang paling berguna. Slack adalah tempat percakapan terjadi secara waktu nyata, bukan tempat keputusan disimpan. Jika sesuatu yang penting diputuskan di Slack, itu perlu ditangkap di suatu tempat yang tahan lama: isu Linear, dokumen Notion, ADR, bahkan pesan commit. Slack adalah percakapannya; alat-alat lain itu adalah catatannya.
Gunakan utas secara konsisten. Utas adalah fitur terbaik Slack untuk keterdapatan karena menjaga percakapan lengkap dalam satu unit yang dapat dialamatkan. Sebuah utas memiliki tautan permanen. Percakapan yang tersebar di lini waktu utama saluran tidak memilikinya. Jika budaya tim Anda secara bawaan membalas di saluran utama (dan banyak yang melakukannya, karena terasa lebih segera), Anda membuat pengambilan informasi menjadi jauh lebih sulit.
Buat saluran keputusan, bukan saluran proyek. Ini berlawanan dengan intuisi, tetapi dengarkan dulu. Alih-alih (atau selain) #project-atlas, coba #decisions atau #decisions-engineering. Satu saluran yang satu-satunya tujuannya adalah mencatat keputusan dengan konteks singkat. Itu tidak akan berisi diskusi lengkap (diskusi bisa berada di mana pun secara alami terjadi), tetapi memberi Anda catatan kronologis yang dapat dicari tentang apa yang diputuskan dan tautan ke tempat diskusi itu terjadi. Anggaplah itu sebagai log commit untuk pemikiran tim Anda. Mekanisme penegakan yang benar-benar berhasil (menurut pengalaman kami): jadikan itu bagian dari template PR Anda. Sebelum penggabungan, tautkan posting keputusan yang relevan. Itu ringan, dapat diperiksa dalam tinjauan, dan menciptakan jejak yang tidak bergantung pada ingatan atau disiplin siapa pun.
Hubungkan titik-titik secara otomatis. Inilah bagian di mana saya akan menyebutkan apa yang sedang kami bangun, karena ini sangat relevan. Sugarbug menyerap pesan Slack bersama isu Linear, PR GitHub, dokumen Notion, dan komentar Figma Anda, dan membangun grafik pengetahuan tentang bagaimana semua itu saling terkait. Ketika koneksi tersebut ada, Anda tidak perlu mengingat saluran mana tempat percakapan terjadi, karena Anda dapat mulai dari tugas atau dokumen dan mengikuti jejak ke setiap percakapan yang relevan, terlepas dari di mana percakapan itu berada. Kami masih mencari cara terbaik untuk menampilkan semua ini (jujur saja, UX untuk pengambilan lintas alat lebih sulit daripada penyerapannya), tetapi pendekatan intinya – menghubungkan konteks alih-alih mengorganisasikannya kembali – adalah yang menurut kami benar-benar menggerakkan jarum.
Berhenti mencari di lima saluran dan kembali dengan tangan kosong. Sugarbug menghubungkan Slack dengan sisa alur kerja Anda agar keputusan tetap bisa ditemukan.
Q: Berapa banyak saluran Slack yang terlalu banyak? A: Tidak ada angka ajaib, tetapi jika tim Anda secara rutin tidak dapat menemukan di mana percakapan terjadi, atau jika orang-orang beralih ke DM karena saluran terasa membebani, Anda mungkin sudah melampaui batasnya. Tim beranggotakan 10–20 orang dengan lebih dari 80–100 saluran aktif cenderung mencapai titik jenuh ini, meskipun sangat bergantung pada seberapa disiplin tim Anda dalam hal tujuan saluran dan pengarsipan.
Q: Apakah Sugarbug membantu mengelola kelebihan saluran Slack? A: Sugarbug tidak mengelola saluran Anda secara langsung, tetapi menyelesaikan masalah keterdapatan yang diciptakan oleh kelebihan saluran. Ia menyerap pesan Slack bersama isu Linear, PR GitHub, dokumen Notion, dan komentar Figma Anda ke dalam grafik pengetahuan, sehingga saat Anda mencari keputusan atau percakapan, Anda cukup mencari sekali dan menemukannya tanpa peduli di saluran (atau alat) mana hal itu terjadi.
Q: Mengapa saya tidak dapat menemukan apa pun di Slack meskipun dengan pencarian? A: Pencarian Slack menemukan pesan yang berisi kata kunci persis Anda, tetapi sebagian besar keputusan di tempat kerja menggunakan kata-kata berbeda di setiap tahap. Seseorang mungkin mengatakan "opsi Redis" di satu utas dan "BullMQ" di utas lain, merujuk ke keputusan yang sama, dan utas-utas tersebut tidak pernah saling merujuk. Pencarian menemukan kecocokan teks. Menemukan jejak keputusan memerlukan pemahaman koneksi antar percakapan, yang merupakan kemampuan yang secara fundamental berbeda.
Q: Bisakah Sugarbug menggantikan saluran Slack dengan sesuatu yang lebih baik? A: Tidak, dan seharusnya tidak mencoba. Slack sangat baik dalam percakapan waktu nyata, dan itu sungguh bernilai. Masalahnya bukan Slack itu sendiri, melainkan fakta bahwa konteks penting terjebak di dalam percakapan tanpa cara untuk menghubungkannya ke tugas, dokumen, dan kode terkait. Sugarbug membangun koneksi tersebut secara otomatis sehingga Anda tidak perlu mengingat di mana sesuatu dibahas.