Kelelahan Alat adalah Nyata: Tips untuk Engineering Manager
Engineering Manager mengelola terlalu banyak alat. Begini cara kerja kelelahan alat, biayanya, dan solusi tingkat sistem yang benar-benar membantu.
By Ellis Keane · 2026-03-31
Jam 9:47 pagi hari Selasa dan Engineering Manager belum menulis satu baris kode pun, belum meninjau satu pull request pun, dan belum berbicara dengan siapa pun di tim tentang pekerjaan rekayasa yang sesungguhnya. Ia telah memperbarui dokumen Notion dengan status dari Linear, mengecek-silang utas Slack untuk mencari tahu apakah sebuah keputusan dibuat atau hanya didiskusikan, dan mencoba mengingat apakah komentar Figma yang dilihatnya kemarin ada di mockup v2 atau v3, karena notifikasi tidak menyertakan konteks yang cukup untuk membedakannya.
Jika Anda seorang Engineering Manager, Anda mungkin mengenali pagi hari ini meskipun Anda belum pernah menyebutnya kelelahan alat.
Bentuk Masalah
Kelelahan alat bagi Engineering Manager sebenarnya bukan tentang memiliki terlalu banyak alat (meskipun begitulah biasanya diframekan). Ini tentang beban kognitif dalam mempertahankan model mental tentang di mana informasi berada, siapa yang menaruhnya di sana, dan apakah masih aktual. Setiap alat dalam tumpukan adalah sumber kebenaran yang terpisah, dan pekerjaan Engineering Manager secara diam-diam telah menjadi menjahit sumber-sumber tersebut menjadi sesuatu yang cukup koheren untuk membuat keputusan.
Begini tampilan nyatanya. Katakanlah Anda mengelola tim enam insinyur, dan perusahaan Anda menggunakan Linear untuk pelacakan proyek, GitHub untuk kode, Slack untuk komunikasi, Figma untuk desain, dan Notion untuk dokumentasi. Itu lima alat – jujur saja cukup sedikit untuk sebagian besar startup yang kami ajak bicara.
title: "Selasa Pagi Seorang Engineering Manager" 8:30 AM|ok|Membuka Linear, memindai sprint aktif. Tiga isu ditandai sebagai «sedang dikerjakan» tanpa pembaruan terbaru. 8:42 AM|amber|Beralih ke GitHub untuk memeriksa apakah PR ada untuk isu-isu tersebut. Dua ada. Satu tidak. 8:51 AM|ok|Memeriksa Slack untuk konteks PR yang hilang. Menemukan utas dari hari Jumat di mana insinyur menyebutkan hambatan. 9:03 AM|amber|Hambatan merujuk pada komentar Figma. Membuka Figma. Menggulir melalui utas komentar pada file desain. 9:14 AM|missed|Menemukan komentarnya, tetapi sudah diselesaikan tanpa memperbarui isu Linear. Insinyur mungkin tidak tahu hambatannya sudah diatasi. 9:22 AM|amber|Mengirim pesan langsung ke insinyur di Slack untuk mengecek. Menunggu balasan. 9:31 AM|ok|Memperbarui dokumen status Notion dengan apa yang telah dipelajari sejauh ini. Tiga paragraf, sebagian besar tentang apa yang belum diketahui. 9:47 AM|missed|Menyadari bahwa ia belum melakukan pekerjaan manajemen yang sesungguhnya. Hanya arkeologi informasi.
Di suatu titik, jabatan «Engineering Manager» menjadi sinonim sopan untuk «Perute API Manusia» – seseorang yang fungsi utamanya adalah mengangkut konteks antara sistem yang menolak untuk saling berbicara.
Ini bukan pagi yang luar biasa. Ini adalah batas acuan. Kelelahan alat bagi Engineering Manager berarti tugas memahami apa yang terjadi di seluruh tim secara diam-diam telah menjadi latihan integrasi data penuh waktu, dan tidak ada yang merencanakannya seperti itu.
stat: "77 menit" headline: "Rata-rata waktu harian untuk menyusun konteks" source: "Berdasarkan pelacakan waktu internal tim kami selama 4 minggu"
Mengapa Menjadi Lebih Buruk, Bukan Lebih Baik
Kelelahan alat semakin parah – saya mengatakan ini sebagai seseorang yang telah menyaksikannya terjadi di tim kami sendiri. Setiap alat baru yang Anda tambahkan tidak hanya menambahkan overhead-nya sendiri: ia melipatgandakan koneksi yang perlu Anda pertahankan antara alat-alat yang sudah ada.
Dengan 5 alat, Anda memiliki 10 koneksi berpasangan yang mungkin. Dengan 8, Anda memiliki 28. Dengan 12, Anda memiliki 66. Engineering Manager tidak perlu secara aktif menggunakan semua koneksi tersebut, tetapi mereka perlu mengetahui mana yang ada dan mana yang rusak, karena koneksi yang rusak adalah tempat informasi hilang.
Dan kehilangan informasi dalam manajemen rekayasa bukanlah sesuatu yang abstrak. Ini adalah seorang desainer yang tidak tahu hambatannya telah diselesaikan, sehingga menunggu dua hari sebelum memulai iterasi berikutnya. Ini adalah komitmen sprint yang mengasumsikan dependensi sudah selesai karena status Linear bertuliskan «selesai», tetapi PR sebenarnya masih dalam tinjauan. Ini adalah rapat sinkronisasi mingguan di mana lima belas menit pertama dihabiskan untuk menetapkan apa yang sudah diketahui semua orang secara individual tetapi tidak dibagikan, karena alat-alat tidak menghubungkan sinyal-sinyal tersebut.
Kelelahan alat bukan tentang jumlah alat. Ini tentang jumlah celah di antara mereka, dan fakta bahwa menutup celah-celah tersebut telah menjadi pekerjaan sampingan tidak resmi Engineering Manager.
Yang Tidak Berhasil
Tiga respons umum terhadap kelelahan alat yang sebenarnya tidak berhasil:
Konsolidasi demi konsolidasi. Instinknya dapat dimengerti: jika masalahnya adalah terlalu banyak alat, gunakan lebih sedikit alat. Tetapi tim rekayasa memiliki pendapat kuat tentang alat mereka karena alasan yang baik. Coba ganti Linear dengan «modul manajemen proyek di dalam [platform serba-bisa X]» dan saksikan pemberontakannya. Alat-alatnya bukan masalahnya, celah di antaranyalah yang masalah. Menukar satu set alat dengan set alat lain hanya memindahkan celah-celahnya.
Dasbor. Saya tahu, saya tahu. Daya tarik «satu dasbor untuk memerintah semuanya» hampir tidak tertahankan, dan setiap perusahaan SaaS enterprise memiliki presentasi tentangnya. Tetapi sebagian besar dasbor yang kami uji adalah cuplikan status hanya-baca – mereka menunjukkan di mana segala sesuatunya berada, tetapi bukan apa yang berubah sejak kemarin, mengapa berubah, atau apa yang harus Anda lakukan. Seorang Engineering Manager yang melihat dasbor masih harus pergi ke setiap alat untuk mendapatkan konteks sebenarnya di balik angka-angka.
Lebih banyak rapat. Inilah yang paling menyakitkan karena begitu umum. Ketika alat-alat tidak saling berbicara, tim mengkompensasi dengan komunikasi sinkron (standup harian, sinkronisasi mingguan, check-in ad hoc). Rapat tidak menyelesaikan masalah – ia menambal alur kerja informasi yang rusak dengan bandwidth manusia. Dan bandwidth manusia adalah sumber daya paling mahal di tim.
Yang dicoba orang
- Konsolidasi alat – mengganti 5 alat dengan 1. Para insinyur memberontak; yang serba-bisa melakukan 5 hal dengan biasa-biasa.
- Dasbor – cuplikan hanya-baca yang tetap memerlukan konteks dari alat-alat aslinya.
- Lebih banyak rapat – transfer informasi sinkron untuk mengkompensasi alur kerja asinkron yang rusak.
Yang benar-benar membantu
- Koneksi, bukan konsolidasi – pertahankan alat-alatnya, tutup celah di antara mereka.
- Perutean sinyal – tampilkan apa yang berubah dan apa yang perlu diperhatikan, bukan segalanya.
- Pengiriman konteks asinkron – informasi tiba di mana dan kapan Anda membutuhkannya, tanpa bertanya.
Yang Benar-benar Membantu
Perbaikan yang bertahan dalam kontak dengan tim rekayasa nyata cenderung memiliki ciri khas yang sama: mereka tidak meminta manusia untuk melakukan pekerjaan integrasi. Mereka membangun koneksi di tingkat sistem dan membiarkan Engineering Manager menghabiskan waktunya pada penilaian keputusan alih-alih pengumpulan informasi.
Perutean notifikasi yang disengaja. Sebagian besar kelelahan alat berasal dari informasi yang salah tiba di tempat yang salah. Saluran Slack yang mencampur pembaruan status dengan umpan balik desain. Notifikasi GitHub untuk repo yang tidak Anda kerjakan secara aktif. Perbaikannya bukan notifikasi yang lebih sedikit, melainkan yang lebih baik dirutekkan. Atur konvensi saluran (kami menggunakan #proj-[nama]-eng untuk sinyal rekayasa, #proj-[nama]-design untuk desain) dan potong secara agresif. Satu otomasi konkret yang langsung terbayar: atur webhook GitHub yang memposting perubahan status PR ke saluran Slack proyek dengan ID isu Linear dalam pesan. Itu saja menghilangkan pemeriksaan «apakah PR ada untuk isu ini?» dari ritual pagi. Ini bukan pekerjaan yang glamor, tetapi memangkas kebisingan secara berarti.
Anggaran mingguan untuk «arkeologi informasi». Terima bahwa sebagian perutean lintas alat tidak bisa dihindari saat ini, dan batasi waktunya. Kami mengalokasikan tiga puluh menit pada Senin pagi khusus untuk pemindaian «apa yang terjadi di semua alat sejak Jumat». Menjadwalkannya berarti tidak meluap ke setiap jam lain dalam seminggu, dan batas waktu berarti Anda berhenti ketika waktunya habis alih-alih jatuh ke lubang kelinci.
Perutean sinyal lintas alat. Di sinilah kategori ini menuju – dan ya, inilah yang kami bangun di Sugarbug. Alih-alih Engineering Manager secara manual memeriksa Linear, lalu GitHub, lalu Slack, lalu Figma untuk membangun keadaan dunia: sebuah lapisan yang terhubung ke semua alat tersebut melalui API mereka dan merutekkan perubahan, keputusan, dan hambatan yang relevan kepada Anda. Bukan dasbor – yang bersifat pasif –, tetapi sesuatu yang secara aktif memberi tahu Anda apa yang memerlukan perhatian Anda dan mengapa. Lebih mirip dengan bagaimana pemimpin tim berpengalaman akan memberi briefing kepada Anda, jika pemimpin tim itu telah membaca setiap utas Slack dan setiap komentar PR sejak kemarin.
Versi jujur dari posisi kami saat ini: dua perbaikan pertama bekerja hari ini, dan yang ketiga adalah yang sedang Sugarbug kerjakan. Kami belum selesai – kami belum memutuskan seberapa agresif penyaringan sinyal seharusnya, dan model peringkat masih menampilkan beberapa kebisingan yang ingin kami supresi. Tetapi arsitektur intinya bekerja: konektor API untuk setiap alat, klasifikasi sinyal berbasis LLM, dan grafik pengetahuan yang menghubungkan orang, tugas, dan diskusi lintas sumber. Ini menangani pemindaian «apa yang terjadi sejak Jumat» dalam hitungan detik alih-alih tujuh puluh tujuh menit – itulah bagian yang membuat kami terus melanjutkan.
Pekerjaan seorang Engineering Manager seharusnya bukan menjahit lima alat menjadi satu gambar yang koheren. Itu adalah pekerjaan mesin. Pekerjaan manusia adalah memutuskan apa yang harus dilakukan dengan gambarnya. attribution: Ellis Keane
Pertanyaan yang Sering Diajukan
Dapatkan intelijen sinyal yang dikirim langsung ke kotak masuk Anda.
Q: Apa itu kelelahan alat bagi Engineering Manager? A: Kelelahan alat adalah biaya kognitif dan operasional dari mengelola pekerjaan di terlalu banyak alat SaaS yang tidak terhubung. Bagi Engineering Manager, ini berarti menghabiskan lebih banyak waktu memindahkan informasi antara Linear, Slack, GitHub, Figma, dan Notion daripada benar-benar membuat keputusan berdasarkan informasi tersebut.
Q: Apakah Sugarbug membantu mengatasi kelelahan alat? A: Ya – terhubung ke alat-alat yang sudah Anda miliki melalui integrasi API native, mengklasifikasikan sinyal dari masing-masing, dan menampilkan hal yang penting di satu tempat. Alih-alih memeriksa lima dasbor sebelum kopi pertama Anda, Anda mendapatkan konteks yang dibutuhkan langsung kepada Anda. Kami masih melakukan iterasi tentang cara kerja penyaringan sinyal (jujur saja, ini adalah salah satu masalah desain yang lebih sulit yang kami tangani), tetapi pipeline utamanya sudah aktif.
Q: Berapa banyak alat yang digunakan tim rekayasa tipikal? A: Sebagian besar tim yang kami ajak bicara menggunakan antara 8 hingga 14 alat SaaS tergantung ukuran dan fungsi tim. Masalahnya bukan jumlahnya sendiri, melainkan seberapa banyak konteks yang hilang di celah di antara mereka. Kami telah melihat tim tiga orang dengan delapan alat dan tim lima puluh orang dengan sembilan. Angkanya kurang penting dibandingkan apakah alat-alatnya benar-benar berbagi informasi.
Q: Haruskah Engineering Manager mengkonsolidasikan tumpukan alat mereka? A: Kadang-kadang, tetapi biasanya itu adalah pendekatan yang salah. Mengganti lima alat yang dibuat untuk tujuan tertentu dengan satu alat serba-bisa yang melakukan lima hal dengan biasa-biasa saja tidak menyelesaikan masalah yang mendasarinya. Perbaikan yang sesungguhnya adalah menghubungkan alat-alat yang sudah Anda miliki sehingga informasi mengalir di antara mereka tanpa seseorang harus menyalin dan menempelkan konteks secara manual. Jika Anda bisa mengurangi redundansi yang nyata – dua pelacak proyek, misalnya –, lakukanlah. Tetapi jangan mengkonsolidasikan demi angka yang lebih kecil.