Forem: Erwin Rahayu

5 Tanda Tim Engineering Anda Sehat (Meskipun Kodenya Tidak Sempurna)

Erwin Rahayu — Tue, 05 May 2026 19:12:09 +0000

🤔 Kode Sempurna Itu Mitos

Dulu, saya pikir tim engineering yang hebat adalah tim yang kodenya bersih, dokumentasi rapi, dan zero bugs.

Sekarang, setelah beberapa tahun menjadi CTO, saya berubah pikiran.

Tim yang sehat tidak selalu menghasilkan kode sempurna.

Karena kode sempurna hampir tidak pernah ada di dunia nyata.

Yang saya cari sekarang justru tanda-tanda lain. Tanda bahwa tim saya sehat secara manusiawi, bukan hanya teknis.

Berikut 5 tanda yang menurut saya paling penting.

1️⃣ Tim Berani Bilang "Saya Tidak Tahu"

Ini tanda pertama dan paling saya hargai.

Di tim yang tidak sehat, semua orang berpura-pura tahu. Takut terlihat bodoh. Takut dianggap kurang kompeten.

Di tim yang sehat, orang dengan nyaman berkata:

“Saya belum pernah handle ini sebelumnya. Tapi saya akan cari tahu.”

Atau:

“Saya tidak yakin ini cara terbaik. Ada ide lain?”

Keberanian untuk menunjukkan ketidaktahuan adalah fondasi dari belajar bersama. Tanpa ini, tim hanya akan diam-diam membuat kesalahan yang sama.

Saya lebih percaya engineer yang bilang "saya tidak tahu" daripada yang selalu punya jawaban instan.

2️⃣ Bug Baru Tidak Selalu Disalahkan ke Seseorang

Coba ingat: ketika ada bug di production, bagaimana reaksi tim Anda?

Tim tidak sehat akan langsung mencari siapa yang salah.

Tim sehat akan langsung mencari apa yang salah dengan proses.

Perbedaan ini sangat besar.

Di tim sehat, bug dianggap kegagalan sistem, bukan kegagalan individu. Lalu diskusi bergeser ke:

“Kenapa testing tidak menangkap ini?”
“Apakah requirement-nya kurang jelas?”
“Bagaimana kita mencegah ini terulang?”

Bukan ke: “Siapa yang commit kode ini?”

Budaya tanpa rasa takut akan kesalahan adalah salah satu investasi terbaik seorang CTO.

3️⃣ Mereka Bisa Menjelaskan Mengapa (Bukan Hanya Apa)

Coba tanya ke engineer di tim Anda:

“Kenapa kita pakai pendekatan ini untuk fitur X?”

Jika jawabannya hanya “Karena dulu sudah begini” atau “Karena saya suka framework ini” — hati-hati.

Tim yang sehat bisa menjelaskan alasan di balik keputusan teknis. Bukan hanya apa yang mereka kerjakan, tapi mengapa itu penting bagi bisnis.

Mereka paham bahwa kode adalah alat, bukan tujuan.

Engineer yang baik menulis kode. Engineer yang hebat tahu kapan kode tidak perlu ditulis.

4️⃣ Ada Waktu untuk "Membersihkan Meja" Tanpa Didesak

Salah satu sumber burnout terbesar adalah:

Tim hanya bergerak dari satu fitur ke fitur berikutnya, tanpa pernah diberi waktu untuk bernapas.

Tim yang sehat memiliki ritme pemeliharaan yang terjadwal. Ini bukan refactor besar-besaran yang memakan waktu berbulan-bulan. Tapi kegiatan kecil rutin seperti:

Memperbaiki test yang flaky
Menghapus kode mati (dead code)
Menulis ulang bagian yang membingungkan

Dan yang lebih penting: mereka tidak perlu memohon izin untuk melakukan ini.

Ini sudah menjadi bagian dari definition of done mereka.

Jika satu-satunya cara tim Anda bisa membersihkan utang teknis adalah dengan berhenti total dari fitur baru — Anda sudah terlambat.

5️⃣ Anggota Tim Tidak Takut Mengkritik Ide Saya (CTO)

Ini tanda yang paling jujur.

Jika tim saya hanya mengangguk setiap kali saya berbicara, itu pertanda buruk. Artinya mereka tidak merasa aman untuk tidak setuju.

Tim yang sehat justru sering berdebat secara sehat. Mereka mengajukan pertanyaan sulit:

“Kenapa kita pilih ini, padahal opsi lain lebih sederhana?”
“Bukankah ini akan bermasalah nanti kalau traffic naik?”
“Saya punya alternatif. Boleh saya coba?”

Saya tidak butuh tim yang selalu setuju. Saya butuh tim yang membuat keputusan saya lebih baik karena mereka berani mengkritik.

Kalau tim Anda takut bicara jujur, Anda bukan memimpin tim. Anda hanya mengelola sekelompok orang yang patuh.

🧠 Bonus: Satu Tanda yang Sering Terlupakan

Mereka masih terlihat bahagia pada hari Senin pagi.

Kedengarannya sepele. Tapi percayalah, ini metrik yang paling sulit direkayasa.

Tim yang sehat datang ke kerja (meskipun remote) dengan energi yang tidak dipaksakan. Mereka bercanda. Mereka membantu satu sama lain. Mereka tidak terlihat seperti sedang menahan beban.

Kode bisa diperbaiki. Tapi semangat tim yang mati sangat sulit dihidupkan kembali.

🪑 Penutup

Saya tidak pernah punya tim dengan kode sempurna.

Tapi saya beberapa kali punya tim yang sehat.

Dan dari pengalaman saya, tim yang sehat-lah yang akhirnya menghasilkan kode yang baik dalam jangka panjang. Bukan sebaliknya.

Jadi jika Anda CTO atau tech lead, mungkin sekarang saatnya bertanya:

“Dari 5 tanda ini, mana yang sudah ada di tim saya? Mana yang masih perlu dibangun?”

Bukan hanya: “Berapa persen test coverage kita?”

💬 Diskusi

“Dari 5 tanda di atas, mana yang paling sulit diwujudkan di tim engineering Anda? Atau ada tanda lain yang menurut Anda lebih penting?”

Saya tunggu cerita Anda di kolom komentar.

Bio Penulis

Erwin Rahayu. Bekerja di tim kepemimpinan teknologi. Menulis untuk merapikan pikiran tentang tantangan sehari-hari di persimpangan bisnis dan engineering.

Technical Debt Itu Bukan Masalah Teknis. Ini Masalah Bisnis.

Erwin Rahayu — Tue, 05 May 2026 19:07:03 +0000

🧠 Technical Debt = Utang Kartu Kredit

Saya suka menjelaskan technical debt seperti ini:

Utang teknis itu sama seperti utang kartu kredit.

Bisa membantu Anda scale cepat di awal. Tapi bunganya menumpuk.

Kalau dibiarkan terlalu lama, Anda bangkrut.

Setiap CTO tahu ini. Tapi masalahnya: CEO dan founder biasanya tidak paham.

Kenapa? Karena kita (para CTO) menjelaskannya dengan bahasa yang salah.

Kita bilang:

"Kode kita butuh refactor."
"Arsitektur ini tidak sustainable."
"Kita harus ganti framework."

CEO dengar itu, yang muncul di kepalanya adalah:

“Ini cuma alasan teknis biaya.” atau “Kok tim engineering saya lambat?”

💸 Coba Jelaskan Sebagai Biaya Bunga

Sekarang coba bayangkan jika saya menjelaskan technical debt seperti ini ke CEO:

“Pak, technical debt kita sekarang punya bunga tahunan sekitar 30%.

Setiap fitur baru butuh waktu 2x lebih lama dari seharusnya.

Setiap kali ada bug, butuh 3x waktu untuk memperbaikinya.

Ini mulai menggerogoti margin kita.”

Percayalah, CEO langsung denger.

Mengapa? Karena saya tidak lagi bicara tentang kode. Saya bicara tentang:

Waktu (time-to-market)
Biaya (cost of delay)
Risiko (risk of failure)

Ini bahasa yang mereka pahami.

📊 Metrik Sederhana untuk Mengukur Technical Debt (Tanpa Ngomongin Kode)

Saya tidak pakai metrik rumit seperti code churn atau cyclomatic complexity kalau bicara dengan tim bisnis. Saya pakai 3 metrik sederhana ini:

1. Feature Lead Time

Berapa lama dari ide hingga fitur rilis?

Jika dulu 2 minggu, sekarang 1 bulan — technical debt Anda sudah parah.

Setiap minggu tambahan adalah "bunga" yang Anda bayar.

2. Bug Fix Ratio

Berapa persen waktu tim engineering dihabiskan untuk memperbaiki bug (bukan fitur baru)?

Idealnya di bawah 20%. Kalau sudah 40-50%, utang teknis Anda sedang memakan tim dari dalam.

3. Deployment Anxiety (yang ini favorit saya)

Cukup tanya ke tim engineering: “Apakah Anda deg-degan setiap kali mau deploy?”

Jika jawabannya iya, technical debt sudah dalam tahap mengkhawatirkan.

Ini metrik tidak resmi tapi sangat jujur.

🛠️ 3 Strategi Mengelola Technical Debt (Tanpa Menghentikan Bisnis)

Anda tidak perlu stop semua fitur baru untuk "membersihkan utang". Bisnis tidak akan setuju. Ini yang saya lakukan:

1. Alokasikan 20% Waktu untuk "Pembayaran Bunga"

Setiap sprint, tim engineering saya wajib menghabiskan 20% waktu untuk hal-hal yang tidak menghasilkan fitur baru:

Refactor
Perbaikan otomatisasi testing
Peningkatan dokumentasi

Bisnis tidak suka dengar "tidak ada fitur". Tapi mereka akan terima jika saya bilang:

“Ini investasi supaya 2 bulan lagi kita tidak kehilangan 40% waktu gara-gara bug.”

2. Jadikan Technical Debt Sebagai Item di Backlog Bersama

Jangan sembunyikan utang teknis di dalam backlog engineering.

Tulis sebagai user story bisnis:

“Sebagai tim product, kami ingin waktu deploy berkurang dari 3 jam menjadi 30 menit, sehingga fitur baru bisa rilis lebih cepat dan revenue potensial tidak hilang.”

CEO bisa membaca itu dan memprioritaskannya sendiri.

3. Lakukan "Tech Debt Audit" Setiap Kuartal

Saya duduk bersama tim bisnis setiap 3 bulan, dan saya tunjukkan:

Feature lead time saat ini vs 6 bulan lalu
Bug fix ratio saat ini
1-2 cerita tentang deployment yang "deg-degan"

Lalu saya tanya:

“Kita mau bayar bunga ini terus, atau kurangi utangnya sedikit-sedikit?”

Biasanya mereka pilih opsi kedua.

🪙 Analogi Penutup: Pinjaman untuk Pertumbuhan

Technical debt bukan selalu jahat.

Di awal startup, Anda harus berutang teknis untuk bertahan dan tumbuh cepat. Sama seperti pinjaman modal usaha.

Yang berbahaya adalah ketika Anda lupa bahwa utang itu ada, dan bunganya terus berjalan tanpa Anda sadari.

Tugas saya sebagai CTO bukan menghilangkan technical debt.

Tugas saya adalah memastikan bahwa:

Kami tahu berapa utang kami.
Kami tahu bunganya berapa.
Kami membayarnya secara sadar, bukan karena pailit.

💬 Diskusi

“Di perusahaan Anda, apakah technical debt pernah jadi bahan diskusi di rapat bersama tim bisnis? Atau selalu jadi 'masalah teknis' yang tidak pernah dibahas di luar tim engineering?”

Silakan cerita di komentar. Saya penasaran.

Bio Penulis

Erwin Rahayu. Bekerja di tim kepemimpinan teknologi. Menulis untuk merapikan pikiran tentang tantangan sehari-hari di persimpangan bisnis dan engineering.

Startup Gagal Scale Bukan Karena Teknologi Jelek, Tapi Karena Bisnis dan Engineering Tak Satu Meja

Erwin Rahayu — Tue, 05 May 2026 19:02:24 +0000

🚀 Startup yang Gagal Scale

Bukan karena teknologinya jelek.

Tapi karena bisnis dan engineering tidak pernah duduk dalam satu meja.

Saya sudah melihat banyak startup bertumbuh cepat. Juga tidak sedikit yang mati perlahan.

Ketika startup gagal melewati fase scaling, orang paling mudah menyalahkan teknologi:

"Arsitektur kami tidak scalable."
"Tech debt-nya membunuh kami."
"Tim engineering lemah."

Tapi setelah bertahun-tahun menjadi jembatan antara ruang rapat CEO dan ruang teknis para engineer, saya sampai pada kesimpulan:

Penyebab utama startup gagal scale bukanlah kualitas kode atau pilihan framework.

Penyebab utamanya adalah ketidakselarasan (misalignment) antara bisnis dan engineering.

🧩 Gejala Awal: Dua Meja Terpisah

Di awal startup, ini mungkin tidak terasa. Tim kecil, komunikasi cepat, semua “serba darurat”.

Tapi saat startup tumbuh—klien bertambah, tim membesar, ekspektasi investor naik—celah ini melebar.

Dua gejala klasik:

Bisnis terus minta fitur baru tanpa evaluasi utang teknis

Sistem jadi rapuh. Downtime meningkat. Customer service kewalahan.

Tapi bisnis tetap melihat engineering sebagai bottleneck.
Engineering terlalu asyik dengan “arsitektur cantik” yang tidak diminta bisnis

Saya pernah lihat tim menghabiskan 3 bulan membangun microservice elegan, padahal traffic masih 100 pengguna/hari.

Bisnis merasa tidak mendapat nilai. Engineering merasa tidak dihargai.

🔧 3 Cara Sederhana Agar Bisnis dan Engineering Duduk di Meja yang Sama

1. Gunakan Metrik yang Sama untuk Semua Prioritas

Bisnis pakai OKR atau KPI bisnis. Engineering pakai uptime, latency, velocity.

Tidak salah, tapi harus diterjemahkan.

Yang saya lakukan: setiap usulan proyek teknis harus menjawab:

"Dampaknya ke [metrik bisnis tertentu] adalah …"

Sebaliknya, setiap usulan fitur dari bisnis harus menjawab:

"Tambahan beban teknis yang harus kami tanggung adalah …"

2. Buat “Dewan Jembatan” yang Bertemu Mingguan

1 jam per minggu, hanya dihadiri oleh:

1 orang dari bisnis (CEO/Head of Product)
1 orang dari engineering (lead engineer/CTO)
1 orang dari customer-facing team (CS/sales)

Tugas mereka: mendeteksi misalignment lebih awal.

Bukan memutuskan arsitektur atau harga, tapi menjawab:

"Kok permintaan minggu ini tidak sesuai kapasitas tim?"

"Kok bug keluhan customer 2 minggu tidak masuk prioritas?"

3. Ajari Tim Teknis Berbicara dengan Business Value

Saya selalu bilang ke tim saya:

“Jangan bilang ‘Ini sulit’ ke CEO. Bilang saja: ‘Ini butuh waktu 3 minggu, alternatifnya 1 minggu dengan konsekuensi X. Mana yang sesuai target revenue bulan ini?’”

Ini bukan sekadar soft skill. Ini disiplin berpikir.

Setiap engineer harus bisa menjawab: “Mengapa pekerjaanmu minggu ini penting bagi perusahaan?”

Jika tidak bisa, kita bekerja untuk ego teknis, bukan untuk bisnis.

🪑 Meja Itu Harus Dibangun, Bukan Ditunggu

Tidak akan ada CEO yang tiba-tiba paham codebase kita.

Tidak akan ada engineer yang otomatis mengerti tekanan cashflow investor.

Meja bersama harus sengaja dibangun.

Startup yang berhasil scale bukan yang punya kode terbersih atau framework terbaru.

Tapi startup di mana setiap kali bisnis bertanya, “Bisa rilis minggu depan?” — tim engineering tidak menggerutu, tapi menjawab, “Ini konsekuensinya. Mari pilih yang terbaik untuk bisnis kita.”

📌 Penutup

“Kalau di perusahaan Anda, siapa yang biasanya lebih dulu menyadari misalignment ini: tim bisnis atau engineering? Ceritakan pengalamannya di kolom komentar.”

Bio Penulis

Erwin Rahayu. Bekerja di tim kepemimpinan teknologi. Menulis untuk merapikan pikiran tentang tantangan sehari-hari di persimpangan bisnis dan engineering.