- Banyak CTO beralih ke fokus manajemen, tetapi tetap mempertahankan pendekatan mengembangkan produk dengan menulis kode secara langsung
- Menciptakan leverage tinggi di dalam organisasi melalui tiga jenis pekerjaan pengembangan: proyek eksperimental, permintaan pelanggan mendesak, dan perbaikan bug
- Dengan terus menulis kode, bisa merasakan langsung manfaat nyata dan batasan alat AI, serta memastikan keputusan teknis tetap realistis
- Menempatkan kekuatan dan passion pada pemecahan masalah dan membangun produk dibanding manajemen, lalu merancang struktur organisasi yang memungkinkan hal itu
- Tidak ada kerangka baku untuk peran CTO; yang terpenting adalah menemukan gaya kepemimpinan yang sesuai dengan kekuatan masing-masing dan situasi perusahaan
Alasan Terus Menulis Kode sebagai CTO
- Banyak CTO berhenti coding seiring waktu, tetapi saya tetap mempertahankan cara kerja mengembangkan dan merilis fitur secara langsung
- Dalam 12 bulan terakhir, saya meluncurkan beberapa fitur utama tanpa anggota tim yang melapor langsung kepada saya
- Ini bukan sekadar hobi, melainkan menjalankan peran sebagai pengembang fitur inti yang benar-benar masuk ke produk
- Saya mendefinisikan ini sebagai “salah satu aktivitas dengan leverage tertinggi sebagai pemimpin teknis”
Tiga Jenis Proyek yang Benar-Benar Saya Bangun
1. Proyek eksperimental jangka panjang (Long-horizon experimental projects)
- Di dalam organisasi, jumlah orang yang benar-benar bisa membangun produk baru sangat terbatas
- Kebanyakan organisasi berfokus pada pemeliharaan dan perluasan produk yang sudah ada
- Hanya pendiri, sebagian eksekutif, dan individual contributor (IC) berkinerja tinggi yang punya ruang untuk mencoba produk baru
- Karena struktur organisasi, insentif roadmap, dan anggaran risiko yang terbatas, sebagian besar engineer tidak bisa mendorong proyek yang tidak pasti selama berbulan-bulan
- CTO berada pada posisi unik untuk mendorong proyek eksperimental yang penuh ketidakpastian dengan cepat, berbekal pemahaman mendalam tentang pain point pelanggan dan arsitektur
- Ada kegagalan, tetapi juga keberhasilan besar
- Contoh produk AI chat: tim mengakui nilainya, tetapi proyek itu tertunda karena tidak ada waktu dan kelonggaran; saya lalu membuat prototipenya saat libur Thanksgiving
- Setelah itu, saya bekerja sama dengan tim untuk mengomersialkannya menjadi produk dengan ARR jutaan dolar
2. Menangani permintaan pelanggan yang kritis (Critical customer asks)
- Ada situasi ketika fitur yang sangat dibutuhkan pelanggan utama menjadi penghambat kontrak besar atau perpanjangan kontrak
- Alih-alih menarik engineer yang sedang menjalankan sprint, CTO menanganinya langsung dengan pengambilan keputusan cepat dan pemahaman menyeluruh atas sistem
- Contoh nyata: permintaan fitur data reduction untuk memenuhi compliance pelanggan bernilai satu juta dolar per tahun
- Tinjauan awal tim memperkirakan pelanggan harus membangun integrasi API sendiri, atau perlu beberapa rapat antara produk, legal, dan engineering
- CTO membangun dan merilis versi yang berfungsi hanya dalam satu hari sehingga hubungan dengan pelanggan tetap terjaga
3. Perbaikan bug (Bugfixes)
- Banyak orang terkejut, tetapi memperbaiki bug adalah salah satu cara favorit untuk menjaga peta mental atas codebase
- Saat melacak kenapa pagination rusak di halaman 3 hasil pencarian, atau kenapa koneksi WebSocket terputus tepat setelah 60 detik, saya harus menyusuri seluruh sistem
- Ini memberi pemahaman intuitif tentang utang teknis yang sulit didapat hanya dari code review atau diskusi arsitektur
- Melalui pengalaman seperti ini, saya menjaga intuisi yang dibutuhkan untuk menentukan arah dan prioritas investasi teknis
Alasan Saya Terus Coding
1. Untuk memahami teknologi yang benar-benar bekerja
- Dengan pengalaman menggunakan alat AI setiap hari seperti Claude Code, Codex, dan Cursor, saya bisa membedakan realitas dari hype saat membuat keputusan strategis tentang alat maupun perekrutan
- Contoh terbaru: saya mencoba mengerjakan fitur yang menyentuh integrasi kompleks dengan vibe-coding, tetapi tidak ada kemajuan; saat saya tulis sendiri secara manual, hasilnya jauh lebih cepat
- Jumlah kodenya tidak banyak, tetapi membutuhkan logika yang tepat (area yang lemah untuk LLM)
- Sebaliknya, fitur besar lain hampir seluruhnya saya kembangkan dengan Claude Code
- Memahami area di mana AI unggul (CRUD, testing, boilerplate) dan area di mana AI gagal (presisi, nuansa sistem) jauh lebih baik daripada membuat keputusan berdasarkan hype di Twitter
- Ketika berada langsung di dalam kode, saya bisa merasakan kapan harus menekan dan kapan harus melonggarkan
- Bisa mendeteksi saat arsitektur menjadi terlalu kompleks atau ketika utang teknis benar-benar mulai menjadi masalah
- Manajer yang hanya bergantung pada laporan bisa melewatkan banyak hal
2. Untuk fokus pada hal yang saya kuasai dan nikmati
- Saya tidak terlalu menikmati membangun organisasi dan mengelola orang
- Manajemen engineering membutuhkan dinamika antarpribadi, evaluasi kinerja, dan desain organisasi
- Itu fungsi yang penting, tetapi bukan area kekuatan saya
- Karena itu saya merekrut engineering manager dan leader yang hebat
- Mereka lebih unggul dan lebih menikmati pekerjaan itu
- Dengan begitu, CTO bisa fokus pada pengembangan produk, pemecahan masalah teknis, dan coding
- Startup itu seperti “maraton bergaya sprint”, jadi saya merancang peran saya di sekitar pekerjaan yang membuat saya tetap tertarik dan memungkinkan saya berlari cepat dalam jangka panjang
- Ini adalah cara yang berkelanjutan selama bertahun-tahun dan sangat penting bagi perusahaan
3. Karena alat AI telah memperluas leverage
- Beberapa tahun lalu, sulit menemukan waktu untuk coding sambil tetap menangani pekerjaan strategis
- Seiring pertumbuhan perusahaan, saya terjebak rapat sepanjang hari dan bekerja di area yang bukan kekuatan utama saya
- Itu adalah salah satu periode paling berat dalam karier profesional saya
- Alat AI modern mengubah persamaan ini secara mendasar (terutama dalam beberapa bulan terakhir)
- Produktivitas meningkat 2–3x dibanding sebelumnya
- Alat ini tidak menggantikan penilaian atau pengetahuan teknis, justru membuat kemampuan itu semakin bernilai
- Jika saya memberi instruksi ke alat AI seperti "bangun ekspor data yang cocok dengan format ekspor CSV yang ada, tetapi tambahkan tiga field tambahan dari tabel profil pengguna", alat tersebut dapat menghasilkan sebagian besar kodenya dengan benar
- Saya memiliki konteks mendalam tentang apa yang dibutuhkan dan di mana harus menemukannya
- Engineer yang tidak akrab dengan bagian codebase itu akan menghabiskan waktu cukup lama untuk memahami detailnya
- Pekerjaan bergeser dari "menulis setiap baris kode" menjadi "memberikan konteks, mengambil keputusan, dan mengevaluasi solusi"
- Untungnya, saya punya banyak konteks untuk itu
Menemukan Cara yang Cocok untuk Diri Sendiri
- Saat mendefinisikan peran CTO, saya merujuk ke postingan blog Greg Brockman tentang mendefinisikan peran CTO di Stripe
- Setelah berbicara dengan banyak CTO, saya menyadari ada variasi yang sangat besar dalam bentuk peran ini
- Ada CTO yang menjadi visioner teknologi, ada yang pembangun organisasi, ada pula yang berfokus pada infrastruktur
- Kesamaannya adalah CTO yang hebat memahami di mana mereka bisa menciptakan nilai paling besar dengan mempertimbangkan keahlian spesifik, minat, dan situasi perusahaan
- Dalam kasus saya, itu berarti menulis banyak kode
- Saya lebih menikmati membangun software daripada mendesain organisasi
- Dengan pengetahuan mendalam tentang pelanggan dan codebase, saya sangat efektif di sana
- Saya merekrut engineering manager yang kuat
- Namun ini adalah jalur pribadi, bukan resep universal
- Peran CTO sangat fleksibel
- Mulai dari membangun organisasi hingga mengembangkan strategi produk — kepemimpinan teknis bisa sangat beragam tergantung kekuatan, sumber energi, dan kebutuhan perusahaan
- Bagi engineer yang khawatir kepemimpinan berarti harus meninggalkan pekerjaan teknis: ada banyak jalur yang mungkin
- Kuncinya adalah memahami area di mana Anda punya keunggulan yang benar-benar unik
5 komentar
Saya adalah CTO aktif, dan sangat tidak setuju dengan tulisan ini.
Saya 100% setuju bahwa kita tidak boleh berhenti ngoding, tetapi itu bisa dilakukan dengan mengerjakan open source yang tidak terkait dengan produk perusahaan. Menurut saya, ini hanya valid jika dilihat dari sudut pandang bahwa sebagai technical founder di startup tahap awal, kita harus bekerja sebagai all-rounder.
Buat dirinya sendiri sih enak… tapi perusahaannya?
Harus mengerjakan pekerjaan yang sepadan dengan gaji yang diterima…
Agak aneh rasanya CTO yang langsung menangani proyek eksperimental. Kalau tim pelaksana diberi waktu yang cukup, mereka seharusnya bisa mengerjakannya dengan baik. Yang paling membingungkan adalah anggapan bahwa proyek eksperimental jangka panjang harus dijalankan hanya oleh CTO. Jika dia punya wewenang untuk menggunakan sumber daya, mestinya tinggal mengalokasikan sumber daya khusus untuk proyek eksperimental dan memberi tim pelaksana waktu yang cukup.
Jalur pribadi.. Sepertinya saya harus mengelolanya dengan baik agar bagian pengelolaan organisasi tidak terus bertambah, ya..
Opini Hacker News
Jika sedang mempertimbangkan perusahaan untuk dilamar lalu melihat tulisan blog yang membanggakan CTO yang melakukan commit kode setiap akhir pekan, saya akan bersiap kabur
Peran pemimpin adalah membangun budaya organisasi yang sehat, dan membanggakan kerja akhir pekan adalah kebalikannya
Selain itu, secara terbuka mengatakan bahwa masalah pelanggan diselesaikan dalam satu hari sambil melewati tinjauan hukum atau engineering adalah sinyal bahaya
Di startup tahap awal, budayanya sepenuhnya berbeda, dan tulisan seperti ini justru berfungsi sebagai filter untuk menyaring talenta yang cocok
Kode yang saya tulis sebagian besar untuk peningkatan internal DevEx atau membereskan utang teknis
Saya tidak pernah melewati tinjauan legal, dan lebih banyak menanganinya di tingkat PoC daripada kode produksi
Bagi CTO pendiri, tetap dekat dengan kode itu penting, tetapi kuncinya adalah tidak kehilangan keseimbangan
Peran CTO berbeda di setiap perusahaan
Seperti kasus Greg Brockman di Stripe, ada CTO yang merupakan visioner teknologi, ada yang perancang organisasi, dan ada juga yang berfokus pada infrastruktur
Dalam kasus saya, saya menikmati coding dan terlibat sangat dalam dengan pelanggan serta codebase, jadi itulah cara terbesar saya menciptakan nilai
Jabatan “CTO” sendiri definisinya kabur
Ada CTO yang berasal dari kalangan pendiri dan bebas coding, ada juga CTO yang bekerja sangat berpusat pada pelanggan lalu kehilangan akses ke kode
Di sisi lain, ada pula CTO yang otoriter
Pada akhirnya, pertanyaan “mengapa coding?” baru bermakna jika terlebih dahulu jelas CTO tipe apa yang dimaksud
Dalam kasus ini, nama CTO hanyalah pembeda peran
CTO berfokus pada strategi dan arah, sementara VP berfokus pada manajemen engineering sehari-hari
Entah caranya dengan membangun organisasi atau coding langsung, itu tidak masalah
Jika manajer langsung menulis kode, code review bisa terdistorsi dan tim bisa menjadi bingung
Pada akhirnya orang itu mungkin bukan benar-benar CTO, melainkan hatinya masih seorang developer
Saya tidak sepenuhnya menentang CTO coding, tetapi dalam kasus ini tampak ada kekurangan dalam menjalankan peran CTO
Kepemimpinan teknis yang sesungguhnya justru ditangani engineer pendiri, sementara struktur kompensasinya jauh lebih kecil, dan itulah masalahnya
CTO yang tidak punya jalur pelaporan dan hanya coding rasanya lebih dekat ke peran developer senior daripada strategi
Saya juga pernah mendapat tawaran seperti itu, tetapi pada akhirnya itu hanya gelar formalitas
Jika organisasi membesar, perannya kemungkinan akan berubah
Di startup kecil, tugas saya adalah menjalankan sprint bersama tim, menyelesaikan penyebab ketika jadwal molor, dan memperhatikan orang yang kelelahan atau burnout
Namun, jika melihat tulisannya, bila tim bahkan tidak punya ruang untuk mencoba proyek AI yang sedang panas, maka itu adalah masalah organisasi
CTO seharusnya bukan turun langsung coding, melainkan menyelesaikan bottleneck sistemik seperti ini
Di tiap perusahaan, peran “senior” atau “head” bisa sepenuhnya berbeda
Masalah yang muncul ketika CTO terlalu tenggelam dalam coding cukup jelas
Distorsi review PR, pengabaian pekerjaan utama, kebingungan peran, hingga pelanggaran terhadap otonomi tim
Gagasan bahwa “CTO tidak boleh coding dan hanya boleh fokus pada strategi” adalah cara berpikir mekanistis
Hakikat perusahaan teknologi adalah mengirimkan nilai, dan kadang-kadang hal paling bernilai adalah ketika CTO sendiri mengimplementasikan fitur besar dalam satu hari
Itu bisa menjadi hari yang jauh lebih produktif dibanding rapat KPI
Terkadang C-level memang perlu mendapatkan kembali sense lapangan secara langsung
Ada orang yang menjadi CTO hanya karena dia adalah co-founder
Jika pendekatan seperti ini dibawa masuk ke perusahaan lain, mungkin saja ia bahkan belum mencapai level staff engineer
Terakhir, fakta bahwa halaman harga di situs web perusahaan tidak menampilkan harga yang sebenarnya bisa membingungkan, jadi perlu diperbaiki