Alat dan Tech Stack Engineering Manager: Panduan Pembelian Jujur 2026

Anda mengambil alih tim enam minggu lalu. Anda sekarang memiliki waktu untuk benar-benar melihat "tech stack" dan gambarannya tidak menyenangkan. Pelacak proyek adalah board Jira yang tidak dipercaya siapa pun karena tiga sprint lalu seseorang melakukan bulk-edit pada 200 tiket dan merusak prioritasnya. Slack memiliki 47 channel, setengahnya sudah diarsipkan-tapi-tidak-benar-benar. Notion adalah kuburan runbook setengah ditulis yang terakhir diedit oleh engineer yang pergi pada 2024. Ada Google Doc bernama "Goals_FINAL_v3" yang semua orang rujuk dan tidak ada yang bisa temukan. EM sebelumnya pergi, begitu pula konteksnya.

Terdengar familiar? Memang begitu. Inilah yang diwarisi setiap EM baru, dan keinginan untuk "memperbaiki stack" dengan membeli satu alat baru yang menawan adalah persis bagaimana keadaan ini menjadi seburuk ini.

Panduan ini adalah kebalikan dari itu. Ini adalah panduan pembelian yang sebagian besar memberi tahu Anda apa yang harus dipotong, apa yang harus dikonsolidasikan, dan enam kategori mana yang benar-benar penting. Harga nyata, trade-off nyata, dan rencana 30 hari yang bisa Anda jalankan mulai Senin.

Mengapa Sebagian Besar Stack EM Rusak

Stack yang Anda warisi tidak dirancang. Ia terakumulasi. Tiga manajer berbeda memilih alat satu per satu selama tiga tahun, masing-masing memecahkan masalah di depan mereka, tidak ada yang memikirkan keseluruhannya. Tidak ada yang memiliki stack sekarang. Tim menggunakan sekitar 30% dari yang Anda bayar. Bug pelanggan ada di tiga tempat (alat dukungan, DM Slack ke engineer, dan Apple Note pribadi di laptop seseorang). Catatan 1:1 tersebar di berbagai dokumen pribadi. Tanggal perpanjangan? Tidak diketahui. Auto-renewal tahunan akan menyala dan Anda akan mengetahui tagihan $14.000 setelah fakta.

Perbaikannya bukan lebih banyak alat. Perbaikannya adalah memutuskan apa yang harus dilakukan setiap alat, memilih satu alat per pekerjaan, dan menyingkirkan sisanya. Enam kategori sudah cukup. Itulah seluruh kerangkanya.

Inti 6: Apa yang Benar-Benar Dibutuhkan Stack EM

Lupakan daftar alat. Pikirkan jobs-to-be-done. Ada enam hal yang harus ditangani stack Anda. Pilih satu alat per kategori. Jika Anda memiliki dua, itulah duplikat yang menyebabkan pesan Slack "di mana menemukan itu?"

1. Manajemen Proyek: Tempat Pekerjaan Berada

Ini adalah satu-satunya yang tidak dipercaya siapa pun, yang merusak segalanya.

• Linear ($10/user/bulan Standard, $14 Plus) cepat, memiliki opini kuat, dan dibangun untuk tim product engineering di bawah 50 orang. Siklus alih-alih sprint, pintasan keyboard yang bekerja, dan alur kerja yang memiliki opini kuat yang menolak diubah menjadi klon Jira. Ini adalah pilihan default jika tim Anda men-ship perangkat lunak dan suka men-ship-nya.
• Jira Cloud Standard ($7,75/user/bulan) hingga Premium ($15,25/user/bulan) adalah pilihan aman untuk organisasi yang memerlukan kepatuhan, skema izin yang kompleks, atau integrasi dengan dunia Atlassian lainnya. Ini juga alat yang akan diam-diam dibenci tim Anda jika mereka adalah tim produk 12 orang yang tidak memerlukan semua itu.
• Shortcut (~$8,50/user/bulan) adalah alternatif yang lebih ringan (sebelumnya Clubhouse), kurang kaku dari Jira, kurang memiliki opini dari Linear. Baik jika Linear terasa terlalu startup-ish dan Jira terasa terlalu enterprise.

Jebakannya: memilih Jira "karena perusahaan sudah memilikinya." Jika tim Anda membenci alatnya, kualitas data Anda buruk, sprint review menjadi teater, dan Anda kembali pada kebenaran-di-Slack. Habiskan modal politik untuk beralih, atau terima bahwa kebersihan Jira sekarang merupakan bagian nyata dari pekerjaan Anda.

Aturan keputusan: di bawah 50 engineer yang men-ship produk, default ke Linear. Di atas 50 dengan kebutuhan audit/kepatuhan, Jira Premium. Di mana pun di antaranya, jalankan tim melalui uji coba satu minggu dan biarkan engineer memilih.

2. Kode dan Review: Tempat Engineer Berada Sepanjang Hari

Yang satu ini sebagian besar sudah terpecahkan, itulah mengapa saya akan singkat.

• GitHub Team ($4/user/bulan) adalah landasannya. GitHub Enterprise Cloud ($21/user/bulan) memberi Anda SAML/SSO, log audit, dan hal-hal yang pada akhirnya akan diminta tim keamanan Anda.
• GitLab Premium ($29/user/bulan) menang dalam tepat satu skenario: Anda benar-benar menginginkan satu alat untuk repo, CI, dan pemindaian keamanan, dan Anda bersedia membayar premium dan menerima UX review yang sedikit lebih canggung sebagai imbalan atas vendor yang lebih sedikit.
• Bitbucket adalah jawaban yang tepat hanya jika Anda sudah sangat dalam di Atlassian dan tim Anda menulis lebih banyak YAML daripada Markdown.

Pendapat jujurnya: GitHub adalah default karena alasan yang baik. Efek jaringannya nyata (setiap kontraktor dan rekrutan baru sudah memiliki akun, setiap dependensi OSS ada di sana), dan UX review masih yang terbaik dalam kategori ini. Jika seseorang di tim Anda mengusulkan beralih ke GitLab, tanyakan masalah spesifik apa yang mereka selesaikan. "Satu alat" bukan masalah. Itu preferensi.

Jika Anda merekrut Staff Engineer untuk memiliki infra, itu adalah orang yang harus mendorong keputusan tingkat platform apa pun di sini. Lihat JD Staff Software Engineer untuk apa yang harus dicari.

3. Insiden dan On-Call: Masalah Pukul 3 Pagi

Ini adalah kategori di mana pelit menghabiskan biaya paling mahal.

• PagerDuty Professional ($21/user/bulan) adalah incumbent. Integrasi matang, paging yang andal, alat rotasi yang masih dikejar vendor lain.
• Opsgenie Standard ($9/user/bulan) adalah alternatif Atlassian. Lebih murah, baik untuk tim yang lebih kecil, dan jelas merupakan jalur paling mudah jika Anda sudah membayar Atlassian.
• Incident.io ($16-$24/user/bulan tergantung tier) adalah pendatang baru yang berkembang pesat. Slack-native, sangat cepat untuk diatur, dan alur kerja postmortem dan incident-comms adalah yang terbaik dalam kategori ini. Jika tim Anda tinggal di Slack, ini adalah yang harus dievaluasi pertama.

Jebakannya: menaruh rotasi dalam Google Sheet "untuk sementara." Anda akan mendapat halaman pukul 3 pagi, rotasi akan diam-diam rusak enam minggu lalu ketika seseorang PTO, dan Anda akan menghabiskan waktu pemadaman untuk mencari tahu siapa yang sedang on-call alih-alih memperbaiki masalahnya. Bayar $21/kursi. Itu asuransi termurah yang pernah Anda beli.

Aturan keputusan: di bawah 8 engineer dalam rotasi dan budaya Slack-native, Incident.io. Tim yang lebih besar atau sudah di Atlassian, Opsgenie. Komitmen keandalan yang sangat diatur atau 24/7 untuk pelanggan, PagerDuty.

4. Kinerja, 1:1, dan Umpan Balik: Tempat Sebagian Besar EM Terlalu Banyak Mengeluarkan Uang

Jujurlah tentang apa yang sebenarnya Anda butuhkan di sini.

• Lattice (~$11/user/bulan untuk bundel Talent Management, lebih untuk suite HRIS penuh) adalah opsi yang dipoles. Tujuan, review, 1:1, umpan balik, semuanya dalam satu. Layak jika Anda memiliki lebih dari 30 engineer dan HR sudah ikut berkomitmen.
• 15Five ($10-$16/user/bulan tergantung bundel) adalah alternatif yang sedikit lebih berfokus pada manajemen kinerja. Kuat pada check-in mingguan dan OKR.
• Officevibe ($5/user/bulan) melakukan survei denyut dengan baik dan tidak banyak yang lain.

Pendapat jujurnya: jika Anda memiliki kurang dari 30 engineer, Anda tidak memerlukan semua ini. Template Notion bersama untuk catatan 1:1, formulir tinjauan kuartalan di Google Forms, dan pengingat kalender memberi Anda 80% nilai dengan 0% biaya. 20% sisanya sebagian besar adalah dasbor yang diinginkan VP Anda, dan VP Anda mungkin sebenarnya tidak melihatnya.

Jebakannya adalah membeli Lattice untuk "meningkatkan budaya umpan balik kami." Lattice tidak membuat orang memberikan umpan balik yang jujur. Anda yang memodelkannya dalam 1:1 Anda yang melakukannya. Alat memperkuat budaya; mereka tidak menciptakannya. Jika kadens 1:1 Anda rusak, perbaiki kadens 1:1 Anda sebelum Anda membeli apa pun.

5. Dok dan Runbook: Pilih Satu. Cukup Satu.

• Notion ($10/user/bulan Plus, $15 Business) adalah favorit tim untuk pengetahuan internal. Fleksibel, cepat untuk ditulis, model blok yang dipahami engineer dengan cepat.
• Confluence ($6,05/user/bulan Standard, $11,55 Premium) adalah default enterprise. Kontrol akses yang lebih baik, integrasi Jira native, kurang menyenangkan untuk ditulis.
• GitBook bagus untuk dok rekayasa yang menghadap publik (dokumentasi developer untuk API eksternal, misalnya) tapi berlebihan untuk runbook internal.

Jebakannya: menjalankan Notion DAN Confluence. Ini adalah sumber pesan Slack "di mana runbook-nya?" terbesar yang saya lihat dalam stack EM. Pilih satu. Jika perusahaan Anda memiliki lisensi Confluence dan Anda tidak bisa menghindarinya, taruh runbook di sana dan gunakan Notion hanya untuk coretan pribadi. Jika Anda bisa memilih bebas, Notion untuk tim produk, Confluence jika Anda harus berinterop dengan PM dan keuangan yang sudah tinggal di Atlassian.

6. CRM dan Loop Umpan Balik Bug Pelanggan: Kategori yang Diabaikan Sebagian Besar Stack EM

Sebagian besar artikel tech stack EM berhenti di lima kategori. Ini adalah celahnya.

Jika tim Anda men-ship perangkat lunak untuk pelanggan B2B yang membayar, bug pelanggan masuk berdasarkan nama: "Acme Corp mengatakan tombol ekspor rusak." Tanpa CRM dalam loop, bug-bug itu mati dalam DM ke dukungan, diketik ulang ke Jira tanpa konteks akun, dan engineer Anda memperbaikinya secara buta. Tim dukungan tidak bisa memberi tahu pelanggan kapan sudah diperbaiki karena koneksi antara tiket dan pekerjaan rekayasa adalah memori seseorang.

Rework ($12/user/bulan untuk CRM/Sales Ops, $6/user/bulan untuk Work Ops; lihat rework.com/pricing) menutup loop ini. Tiket dukungan, akun pelanggan, dan tugas rekayasa tinggal di workspace yang sama, jadi ketika engineer memperbaiki bug mereka bisa melihat akun mana yang melaporkannya dan tim dukungan mendapat notifikasi secara otomatis. Ini adalah satu-satunya alat kategori-6 yang benar-benar saya sebutkan namanya dalam panduan yang ditujukan untuk EM, karena alternatifnya (menjahit Zendesk ditambah Jira ditambah Salesforce sendiri dengan Zapier dan doa) menghabiskan lebih dari $12/user/bulan dalam waktu rekayasa yang hilang pertama kali eskalasi pelanggan P1 mendarat pada hari Jumat sore.

Framing jujur: jika tim Anda hanya men-ship alat internal, Anda tidak memerlukan kategori ini sama sekali. Lewati. Jika Anda men-ship ke pelanggan yang membayar dan bug dilaporkan berdasarkan nama perusahaan, Anda memerlukan jawaban di sini, dan pertanyaannya hanyalah apakah Anda membangunnya sendiri (Zendesk + Jira + Salesforce + perekat integrasi) atau membelinya (Rework, dalam satu workspace).

Audit Stack 30 Hari

Ini adalah deliverable sebenarnya dari panduan ini. Blokir empat minggu. Lakukan satu hal per minggu. Jangan mencoba melakukan semuanya dalam satu sore. Anda tidak akan mendapat jawaban yang jujur.

Minggu 1: Inventaris

Buka spreadsheet. Satu baris per alat. Kolom:

Isi untuk setiap alat berbayar yang disentuh tim. Tarik jumlah kursi dari setiap panel admin. Persentase pengguna aktif lebih penting dari jumlah kursi. Sebagian besar EM menemukan setidaknya 2-3 langganan zombie di minggu pertama (alat "kami mencoba 18 bulan lalu dan tidak pernah membatalkan"). Tanggal perpanjangan berasal dari penagihan atau tim pengadaan. Jika tidak ada yang mengetahui tanggal perpanjangan, itu adalah temuan.

Perkirakan ini membutuhkan sekitar 4 jam. Akan terasa seperti pekerjaan sia-sia. Lakukan saja.

Minggu 2: Petakan ke Inti 6

Telusuri inventaris Anda dan tandai setiap alat dengan salah satu dari enam kategori. Duplikat langsung terlihat: Notion DAN Confluence, Linear DAN Jira, DM Slack DAN sistem tiket nyata, tiga alat umpan balik yang berbeda, platform "metrik rekayasa" yang tumpang tindih dengan apa yang sudah dilakukan pelacak proyek Anda. Tandai setiap duplikat.

Apa pun yang tidak sesuai dengan enam kategori juga merupakan temuan. Mungkin hal ketujuh yang benar-benar dibutuhkan tim Anda (CI/CD yang tidak dibundel dengan platform kode Anda, misalnya, atau alat feature flag). Mungkin alat yang memecahkan masalah yang tidak lagi Anda miliki.

Minggu 3: Bicaralah dengan Tim

Dalam putaran 1:1 berikutnya, ajukan satu pertanyaan: "Alat apa yang Anda hindari, dan apa yang Anda gunakan sebagai gantinya?"

Shadow stack memberi tahu Anda apa yang sebenarnya rusak. Jika tiga engineer memberi tahu Anda mereka menghindari Jira dan menggunakan workspace Linear pribadi, itu bukan otonomi, itu fragmentasi data, dan Anda membayar keduanya. Jika dua engineer memberi tahu Anda mereka menghindari Notion perusahaan karena pencarian rusak dan mereka menyimpan catatan di Obsidian, jawabannya adalah memperbaiki Notion, bukan menambahkan Obsidian ke stack.

Skrip singkat yang berhasil:

"Saya melakukan audit stack. Tidak ada penilaian, tidak ada pelaporan. Alat apa yang Anda hindari, dan di mana Anda sebenarnya melakukan pekerjaan itu? Saya ingin tahu di mana kesenjangan antara apa yang kami bayar dan apa yang benar-benar Anda gunakan."

Anda akan mendapat jawaban yang lebih jujur dari yang Anda harapkan. Engineer suka memberi tahu Anda apa yang rusak jika mereka percaya Anda akan melakukan sesuatu tentangnya.

Minggu 4: Putuskan dan Konsolidasikan

Pilih satu alat per kategori. Setel pengingat kalender perpanjangan 60 hari sebelum setiap perpanjangan agar Anda memiliki waktu untuk mengevaluasi, bukan hanya auto-bayar. Batalkan duplikat. Tulis dokumen satu halaman "Ini Adalah Stack Kami" dengan enam kategori, alat yang dipilih untuk masing-masing, siapa yang memiliki perpanjangannya, dan apa JTBD-nya. Pin. Referensikan dalam orientasi.

Ini juga adalah minggu untuk mengirim email pembatalan. Jangan terlalu lambat. Vendor akan menawarkan diskon untuk bertahan; itu adalah alasan untuk pergi, bukan bertahan.

Kesalahan Umum

Daftar singkat dari kesalahan yang paling sering saya lihat:

• Membeli alat untuk memecahkan masalah budaya. Lattice tidak akan membuat tim Anda memberikan umpan balik yang jujur. Template dokumen 1:1 tidak akan membuat Anda menjadi pendengar yang lebih baik. Alat memperkuat budaya; mereka tidak menciptakannya.
• Membiarkan setiap engineer memilih alat mereka sendiri "untuk otonomi." Otonomi pada library dan editor, ya. Otonomi pada pelacak proyek, tidak. Biaya stack yang terfragmentasi jatuh pada EM berikutnya, rekrutan baru, dan rotasi piket.
• Memperbarui tahunan tanpa mengaudit penggunaan. Anda akan membayar untuk 12 kursi ketika Anda memiliki 7 engineer. Auto-renew adalah default karena alasan yang baik, mereka bertaruh Anda tidak akan memeriksa. Periksa.
• Memilih alat termurah di setiap kategori. Kadang PagerDuty $21/kursi itu layak karena alternatif $9/kursi melewatkan satu halaman. Biaya halaman yang terlewat bukan "$12/kursi yang dihemat per bulan."
• Terlalu mengutamakan integrasi. Jika Anda memerlukan grafik Zapier dengan 14 zap untuk membuat stack Anda berfungsi, stack Anda salah. Pilih alat yang bagus sendiri dan terintegrasi secara native dengan alat lain yang Anda pilih.

Template dan Alat

Tiga artefak yang layak disimpan dalam folder runbook tim:

1. Spreadsheet audit stack (tabel dari Minggu 1). Jalankan ulang setiap kuartal.
2. Dok satu halaman "Stack Rekayasa Kami": enam kategori, alat yang dipilih untuk masing-masing, biaya per kursi, JTBD, tanggal perpanjangan, pemilik. Pin di alat dok Anda.
3. Skrip shadow-stack 1:1 (pertanyaan dari Minggu 3). Tambahkan ke bank pertanyaan 1:1 bergulir Anda agar Anda menanyakannya setiap enam bulan.

Mengukur Keberhasilan

Dalam 90 hari setelah menjalankan audit ini, berikut adalah yang benar:

• Anda bisa menyebutkan setiap alat, biaya per kursi, pemiliknya, dan JTBD yang dilayaninya, dari ingatan.
• Tanggal perpanjangan ada di kalender bersama dengan pengingat 60 hari ke depan.
• Masing-masing dari enam kategori memiliki tepat satu alat. Shadow stack telah menyusut.
• Bug pelanggan (jika Anda men-ship ke pelanggan) memiliki satu jalur intake.
• Rekrutan baru bisa di-onboarding ke stack lengkap dalam waktu kurang dari sehari.

Jika bahkan tiga dari lima itu benar, Anda berada di depan 90% EM yang saya ajak bicara. Alat bukan pekerjaannya. Pekerjaannya adalah men-ship perangkat lunak dengan tim yang mempercayai Anda. Stack hanya menyingkir.

Pelajari Lebih Lanjut

• Kadens 1:1 Engineering Manager
• Sprint Planning untuk Tim Engineering Kecil
• Merekrut Staff Engineer Pertama Anda
• Orientasi Engineering Manager