Startup CTO's Handbook - Buku Pegangan untuk CTO Startup

• Menyediakan konten terbaru dari Startup CTO's Handbook, dan isi utamanya dapat dibaca dalam format Markdown
• Buku ini dapat dibeli di Amazon dan Audible
• Tautan untuk versi PDF yang dirender dari versi Markdown terbaru masih berstatus Coming Soon, dan naskah aslinya saat ini tersedia sebagai versi lama di Google doc
• Kontribusi berupa issue dan pull request untuk penambahan, perubahan, usulan, dan kritik agar dapat diterapkan pada edisi mendatang sangat dianjurkan
• Lisensinya mengizinkan penyalinan, perubahan, dan redistribusi dengan syarat tidak dijual kembali, tetap mencantumkan nama penulis dan atribusi hak cipta, serta merilis versi berikutnya dengan lisensi yang serupa atau sama

[GN⁺]

Komentar Hacker News

• Jelas ada hal-hal yang saya setujui. Misalnya, saya setuju dengan merekam semua rapat. Namun ada banyak hal yang secara pribadi tidak saya setujui, seperti bagian manajemen kinerja[0]
  Ini bukan semata-mata kritik; maksudnya pendekatan dan gaya kepemimpinan bisa berbeda untuk setiap ranah masalah. Saya harap panduan ini tidak diterima sebagai sesuatu yang sakral dan tak boleh diganggu gugat. Jika isi di sini tidak sesuai dengan pengalaman Anda, saya menyarankan untuk lebih memercayai pengalaman Anda sendiri
  [0] https://twitter.com/bcantrill/status/1216491216356823040

  • Kalau bentuknya seperti “matriks kompetensi untuk software engineer individual contributor bisa memiliki baris kecepatan coding/keluaran fitur, dan dalam sistem Level 1~Level 5, engineer Level 1 diharapkan membuat X pull request per minggu”, menurut saya itu jelas tidak benar
  • Secara pribadi, saya sama sekali tidak akan setuju dengan merekam semua rapat. Selain itu, meminta persetujuan orang lain juga terasa mengerikan
    Sebagai CTO, saya tidak tahu bagaimana permintaan itu bisa dilakukan tanpa paksaan
  • Saya tidak mengerti mengapa semua rapat harus direkam. Apakah benar-benar akan didengarkan lagi? Bagi saya itu terlihat seperti pemborosan waktu dan energi
  • Saya membaca thread Twitter tersebut, dan sangat berempati dengan sudut pandang ini. Saya sepenuhnya setuju bahwa pekerjaan manajer juga mencakup menciptakan kondisi agar motivasi intrinsik bisa tumbuh
    Namun dalam praktiknya sering kali memang ada kesenjangan teknis nyata, dan menurut saya jika manajer berperan sebagai coach, pertumbuhan dan kinerja seseorang bisa dipercepat
  • Sepertinya kalian tidak membandingkan hal yang sama
    Pihak sana berbicara tentang manajemen kinerja prospektif, yaitu bagaimana meningkatkan kinerja ke depan. Namun di sebagian besar perusahaan, penilaian kinerja lebih dekat dengan evaluasi retrospektif yang memberi peringkat pada kinerja masa lalu dalam proses alokasi kompensasi dan promosi
    Proses prospektif itu bagus, tetapi pada akhirnya tetap diperlukan penilaian tertentu atas kinerja masa lalu

• Saya pernah berkesempatan bekerja bersama penulis di dua perusahaan, dan sulit mengungkapkan dengan kata-kata seberapa besar perbedaan yang dihasilkan ketika hal-hal yang tertulis di sini benar-benar diterapkan
  Dampaknya tidak hanya berhenti pada produk atau engineering, tetapi menyebar ke seluruh organisasi. Sistem atau rekomendasi apa pun pada akhirnya harus disesuaikan dengan organisasi masing-masing, tetapi saya menyarankan untuk memanfaatkan cara Zach mengajar sebanyak mungkin

• Saya termasuk orang yang suka rekaman rapat. Bukan untuk dipakai sebagai bukti ketika tim mulai saling menyalahkan, melainkan karena sangat menyenangkan bisa menonton kembali rapat dan diskusi
  Jika saya harus memakai cukup banyak kapasitas saya dalam diskusi penting atau rapat penyelarasan, sulit untuk fokus pada topik sekaligus mencatat dan mengingat semuanya. Dengan mengetahui ada rekaman, selama rapat saya bisa sepenuhnya fokus, mengajukan pertanyaan yang baik, dan memvalidasi asumsi
  Keesokan harinya saya bisa mendengarkan ulang panggilan itu, menjeda, mendengarkannya pada kecepatan 2x atau 3x, membuat catatan pribadi, menulis notulen atau ringkasan internal, menemukan ketidakselarasan pemikiran, atau menjalankan alat pencatat AI sesuai jadwal saya
  Ini juga membantu ketika seseorang sakit, harus menjemput ibu mertua di bandara, memiliki rapat lain pada saat yang sama, atau bergabung seminggu setelah rapat penyelarasan penting. Jika rapatnya tidak penting, cukup abaikan saja, dan tetapkan aturan penghapusan otomatis yang masuk akal
  Saya tidak benar-benar berpikir orang menghabiskan waktu diam-diam mengorek-ngorek tempat yang tidak seharusnya mereka masuki, jadi menurut saya itu bukan masalah besar

  • Jika Anda harus menonton ulang rapat untuk menemukan ketidakselarasan, itu adalah masalah pada rapat sebagai medium. Satu ketidakselarasan pemikiran di awal bisa membuat seluruh rapat tidak valid, dan karena rapat harus berjalan cepat, kemungkinan ketidakselarasan seperti itu menyusup menjadi lebih besar
    Rapat tim juga cenderung membuat percakapan condong ke orang yang percaya diri berbicara. Ini khususnya merugikan orang yang baru bergabung atau orang yang bahasa utamanya berbeda
    Saya tidak menentang rapat itu sendiri. Ada juga orang yang jauh lebih suka berkomunikasi lewat suara daripada tulisan, dan tim yang baik harus bisa mengakomodasi cara kerja yang disukai masing-masing anggotanya
    Namun jika itu rapat tim yang penting sekaligus sangat menuntut kapasitas peserta, maka itu seharusnya bukan rapat. Rapat sebaiknya diadakan hanya ketika semua peserta menilai bahwa rapat adalah medium terbaik untuk percakapan tertentu
    Rapat itu seperti duduk di depan selang air, sehingga detail akan terlewat
  • Sepenuhnya setuju
    Kami pindah ke Google Workspace karena perekaman dan pencarian rapat mudah. Misalnya, rekaman tertanam di dalam event kalender
    Jika sebuah rapat tidak cukup penting untuk direkam, kemungkinan besar rapat itu memang tidak layak diadakan
    Secara pribadi, saya memasukkan lebih banyak jam dalam sehari daripada orang lain, tetapi itu tidak terjadi secara sinkron. Rapat penting bisa bertabrakan, dan jika hanya membaca notulen, banyak nuansa yang hilang. Selain itu, orang-orang juga sering tidak membaca notulen dengan baik
    Meski begitu, menyimpan rekaman rapat memungkinkan kita meninjau notulen dengan cepat dan tepat, sehingga sangat berguna. Karena itu saya cukup kuat mendorong perekaman rapat
  • Di perusahaan yang sukses, saling menyalahkan tidak punya tempat. Sebagai CTO, saya memimpin dengan menunjukkan tanggung jawab atas kegagalan saya dan kegagalan tim saya
    Semakin cepat kita memahami penyebab sebenarnya, semakin cepat pula kita bisa memperbaiki masalah. Untuk memahami konsep ini dan cara menerapkannya di perusahaan, saya sangat merekomendasikan Extreme Ownership dari mantan Navy SEAL Jocko Willink dan Leif Babin
    Partisipasi rapat secara asinkron sangat bagus karena alasan-alasan yang disebutkan di atas. Ini membuat informasi dalam rapat bisa dicari. Sekarang rapat bisa diberi subtitle dengan natural language processing, dan kontennya bisa ditemukan oleh LLM
    Saat ini kami sedang melatih chatbot internal dengan konten Confluence, dan berencana memperluasnya hingga ke konten rapat yang direkam
  • Saat ini penghematan waktu penting, jadi pasti ada berbagai alat yang bisa membantu hal ini
    Sedikit promosi: saya sedang membuat alat https://designpro.ai yang mengubah input dari berbagai sumber menjadi insight dan tugas. Saya sudah menggunakannya untuk mengambil insight dari transkripsi panggilan, dan saya tahu itu benar-benar bekerja
  • Yang penting pastikan saja pihak lain mengetahui dan menyetujui bahwa rapat direkam

• Saya baru-baru ini menjadi CTO, dan salah satu tantangan terbesar adalah komunikasi dengan CEO. Mungkin topik ini dibahas di buku, tapi saya baru membaca indeksnya saja
  Selama 8 bulan terakhir, CEO tidak mau ada rapat penyelarasan, tidak mau merencanakan apa pun, tidak mau memimpin visi, dan hanya ingin fokus pada fitur killer
  Ia juga tidak mau membuat mockup atau prototipe untuk diuji ke pengguna, dan kalaupun dibuat, katanya harus indah. Ia tidak mau mengerjakan sesuatu yang butuh lebih dari seminggu, dan juga menolak rapat yang efektif
  Yang ingin saya katakan, hal-hal yang tidak ada di buku justru hal-hal yang saya rindukan. Sebagai catatan, kami hanya 3 co-founder

  • Saya pernah melihat situasi seperti itu. Setidaknya dalam konteks yang saya alami, itu terjadi karena CEO hampir tidak melihat CTO sebagai orang yang setara
    CTO adalah “orang teknis” milik CEO, dan lebih tepatnya orang teknis paling hebat atau paling penting, sehingga diberi jabatan CTO
    Sedih mendengarnya, tapi Anda perlu mempertimbangkan kemungkinan bahwa CEO melihat Anda hanya sebagai karyawan lain dengan jabatan keren. Dengan pola pikir seperti itu, dari sudut pandang CEO, melibatkan Anda dalam keputusannya akan terasa seperti pemborosan
  • Dulu sekali, saat saya masih lebih muda, saya pergi ke YC Startup School, dan seseorang di antara audiens bertanya kepada Marc Andreessen bagaimana menentukan kapan harus berpisah dengan co-founder
    Saya masih ingat persis jawaban Marc. “Jika ada keraguan, maka tidak perlu ragu”
    Saya tahu ini keputusan yang terlalu besar untuk dipengaruhi oleh satu komentar di internet, tapi tetap saya katakan: sudah 8 bulan berlalu. Mungkin semua hal yang layak dicoba untuk memperbaikinya sudah Anda coba
    Apa lagi yang belum dicoba? Secara logis, apa yang Anda harapkan akan terjadi di sini? Anda perlu memikirkan berapa banyak lagi hidup Anda yang akan Anda investasikan dalam situasi seperti ini, padahal Anda bisa dengan mudah pindah ke tempat yang produktif
  • Mengutip kata ibu saya, “Ini membuatmu merasa tidak enak? Jangan khawatir. Ini hanya akan makin buruk! Hahaha!” lalu beliau menutup telepon
    Seriusnya, yang Anda hadapi sekarang adalah titik yang memang membuat pekerjaan ini sulit
    Pertama, ada baiknya menjadwalkan 1:1 dengan para eksekutif lain. Jika ada eksekutif selain CEO yang bekerja dengan Anda, Anda bisa mendapatkan lebih banyak konteks tentang situasi yang Anda masuki. Dengan memahami kebutuhan mereka, Anda juga akan melihat kebutuhan organisasi yang lebih luas
    Anda dipekerjakan untuk menghilangkan masalah CEO, meskipun CEO tidak memintanya. Kemampuan untuk menyatu dengan tim eksekutif adalah salah satu cara terbaik untuk membuktikan kapabilitas Anda, dan yang dibutuhkan adalah konsistensi, integritas, pikiran terbuka, serta kemauan untuk mengajukan pertanyaan yang benar-benar membantu
    Kedua, jika CEO dan tim eksekutif bertemu secara rutin, mintalah untuk ikut; jika belum ada, ada baiknya Anda merencanakannya sendiri. Idealnya, selaraskan dulu dengan eksekutif selain CEO. Walaupun CEO tidak bisa hadir di semua atau sebagian besar rapat, ia akan menghargai inisiatif itu dan kepercayaan juga akan terbangun
    Karena Anda sudah mengatakan CEO tidak menginginkan rapat seperti itu, mungkin Anda perlu bergerak lebih dulu secara tidak langsung melalui eksekutif lain yang punya pengaruh terhadap CEO
    Ketiga, sebagai CTO, kemungkinan besar CEO juga akan menginginkan 1:1 yang agak rutin, minimal untuk memastikan Anda tidak pergi. Cari ritme yang cocok dengan jadwal CEO, entah mingguan, dua mingguan, bulanan, dan sebagainya
    Tujuan rapat ini adalah menyelaraskan diri dengan CEO dan mendapatkan umpan balik tentang area yang sudah berjalan baik serta area yang perlu diperbaiki. Jika Anda tidak bisa menjadwalkan ini, saya sarankan menganggapnya sebagai lingkungan yang tidak memungkinkan Anda sukses dan pergi
    Jika menjadwalkan rapat ini sulit, sebaiknya dorong dulu dua pendekatan sebelumnya untuk membangun hubungan, lalu coba lagi. Jika Anda sama sekali tidak bisa mendapatkan waktu rutin dengan CEO dan eksekutif lain dalam frekuensi apa pun, Anda sebenarnya bukan CTO, dan sebaiknya mempertimbangkan untuk pergi
  • Seperti yang ditulis orang lain, sepertinya Anda diperlakukan lebih mirip founding engineer
    Saya pernah menulis tentang perbedaannya di sini: https://www.mooreds.com/wordpress/archives/2555
    Namun tidak adanya perencanaan dan tidak adanya dorongan visi itu mengkhawatirkan. Keduanya adalah inti dari peran CEO tahap awal. Apakah Anda tahu mengapa ia hanya fokus pada hal-hal jangka pendek seperti itu? Apakah ia mencoba mendorong MVP untuk penggalangan dana atau penjualan, atau memang tidak ada visi? Saya akan menggali bagian itu dan mencoba memahami alasannya. Atau, seperti yang dikatakan orang lain, pergi juga merupakan pilihan
  • Ini persis pekerjaan saya sebelumnya
    Apakah sudah sampai tahap ketika Anda merapikan langkah-langkah jangka pendek yang benar-benar diperlukan, lalu CEO berkata “oke bagus, inilah yang akan kita lakukan”?
    Atau sudah masuk tahap keren ketika Anda mendorong sertifikasi SOC2, CEO berkata “belum sekarang”, tetapi dalam pitch penjualan ia mengatakan “kami sedang menuju sertifikasi SOC2”?
    Tidak perlu khawatir. Yang skizofrenik bukan Anda

• Wikipedia menjelaskan DevOps sebagai praktik yang menggabungkan pengembangan perangkat lunak dan operasi IT, jadi menerjemahkannya sebagai “semua pekerjaan untuk memastikan perangkat lunak bisnis berjalan di tempat selain mesin developer” terasa seperti interpretasi yang agak aneh dan berbeda dari definisi aslinya
  Terutama bagian spesialis DevOps

  • Masukan yang bagus. Saya ingin menyampaikan gagasan bahwa DevOps itu luas, sering tidak terlihat, dan karena itu sering diremehkan atau tersisih dari prioritas
    Saya akan menulis ulang agar pesan itu tersampaikan dengan lebih baik

• Saya tidak mengenal satu pun perusahaan atau orang yang disebutkan di sini. Penasaran apakah orang lain mengenalnya
  Sebelum menghabiskan waktu untuk membaca, pada dasarnya saya punya kecurigaan naluriah terhadap orang-orang yang disebut “Chief Technology Officer”. Apakah ini layak dibaca?

  • Saya tidak melihat ada hal yang akan terasa baru bagi orang yang punya pengalaman industri dan sudah sampai level manajemen engineering pemula
    Target pembacanya tampak seperti orang yang mendapat gelar CTO karena menjadi co-founder teknis startup, dengan pengalaman profesional yang sedikit atau bahkan tidak ada
  • Reaksi pertama saya adalah “siapa penulisnya?” Akan bagus kalau ia punya rekam jejak CTO yang layak, tapi dari tulisannya saja saya tidak bisa tahu apa-apa
    Saya pernah menjadi CTO di tiga perusahaan selama 10 tahun terakhir, dan mungkin saya sekarang sudah tua serta makin kurang sabar, tapi seperti yang dikatakan orang lain, ini lebih terlihat seperti buku untuk orang-orang yang baru lulus dan baru menjadi CTO sebagai co-founder. Saya sedang memberi nasihat teknis kepada orang-orang seperti itu
    Dalam pengalaman saya, semakin lama Anda menjalani peran ini, semakin Anda mencari informasi yang lebih spesifik seperti dalam buku Accelerate

• Teknologi yang membosankan itu benar-benar penting. Startup sektor swasta pada dasarnya sudah merupakan entitas yang tidak stabil, jadi mengapa memperbesar risiko dengan teknologi yang belum terbukti?
  Misalnya, antara 2013 dan 2016 ada periode ketika MongoDB, entah bagaimana sulit dijelaskan, praktis menjadi database default. Tampaknya sekitar sepertiga startup pindah dari MySQL atau Postgres ke MongoDB. Itu benar-benar kekacauan total sekaligus bencana yang bodoh

  • Pelanggan yang saya temui selama beberapa bulan terakhir secara harfiah semuanya memakai MongoDB, padahal datanya relasional.
    Dalam kasus seperti itu, sulit membayangkan alasan memilih Mongo. Tidak ada selain sedikit mempercepat beberapa hari awal pengembangan karena tidak perlu membuat dan memperbarui skema.
    Masalahnya, begitu data menjadi kompleks dan hal seperti BI dibutuhkan, keuntungan awal itu harus dibayar kembali dengan bunga yang sangat besar.
    Bagaimanapun, bahkan jika datanya tidak relasional, JSON di Postgres bekerja lebih baik daripada Mongo
  • Benar. Mengejar teknologi baru yang berkilau bisa membuat perusahaan lebih fokus mempelajari teknologi itu dan masalah tahap awalnya daripada menyelesaikan masalah bisnis.
    Sebagian teknologi baru akan menghilang, sebagian lagi bertahan.
    Di awal karier saya, SQL adalah teknologi baru yang berkilau. Saya mendorong keras agar perusahaan meninggalkan database jaringan dan beralih ke SQL, dan hasilnya sangat baik.
    Pemrograman berorientasi objek dibandingkan C tradisional juga sama.
    Sebagian teknologi pada akhirnya tidak pernah naik setinggi yang dijanjikan, lalu menjadi belenggu bagi organisasi yang mengadopsinya.
    Pernah ada masa ketika masih terlalu dini untuk mengadopsi teknologi LLM secara bertanggung jawab. Namun tak lama lagi akan datang masa ketika dewan direksi bertanya mengapa belum mengadopsinya. Untuk use case eksternal mungkin saja, untuk use case internal hampir pasti begitu.
    Salah satu tugas sulit CTO adalah menilai kapan mengadopsi teknologi baru. Harus menilai kapan teknologi yang membosankan adalah yang terbaik bagi perusahaan, kapan tidak apa-apa memasukkan teknologi tahap awal, dan kapan teknologi baru menjadi akselerator yang terlalu besar sehingga wajib diadopsi
  • Saya ingat masa ketika Mongo atau NoSQL secara umum sedang tren. Sekarang semuanya tinggal meme

• Menarik bahwa CTO dibagi menjadi tiga tipe: berorientasi teknologi, berorientasi orang, dan berorientasi eksternal.
  Sebuah startup tahap sangat awal sedang menawarkan peran CTO. Belum ada produk, hanya beberapa demo dasar, dan sedang menyiapkan pendanaan pre-seed.
  Saya penasaran apa yang paling dibutuhkan dalam peran ini. CTO teknologi, atau CTO people? Awalnya sepertinya terutama peran teknis karena harus membangun produk. Namun saya juga penasaran kapan kira-kira perlu beralih menjadi CTO yang berfokus pada orang. Kalau ada insight atau pengalaman terkait, saya ingin mendengarnya

  • Pertanyaannya bisa saja kebalikannya. Pertama, Anda ingin menjadi apa? Pikirkan berdasarkan kondisi sekarang, lalu evaluasi ulang sekitar setahun lagi. Anda harus memutuskan apakah Anda penanggung jawab teknologi, penanggung jawab orang, atau sekadar orang itu.
    Jadilah terutama peran itu, sementara sisanya ditopang sekadarnya; lalu ketika pekerjaan itu menjadi terlalu banyak atau terlalu penting, rekrut orang untuk mengambil alih dua area lainnya atau lebih.
    Pertanyaan kedua yang lebih sulit dijawab adalah apa yang mereka—para CXO lain—inginkan dari Anda. Ini bisa menghalangi yang pertama. Dalam sebagian kasus, itu adalah CTO tanpa C: hanya penanggung jawab teknologi yang diberi instruksi apa yang harus dikerjakan, menjalankan demo untuk pamer, dan tidak pernah mendengar “mengapa” dari sisi bisnis.
    Saya punya beberapa tautan yang saya bookmark tentang “sebenarnya CTO itu apa”.
    http://www.startuplessonslearned.com/2008/09/what-does-start...
    https://www.allthingsdistributed.com/2007/07/the_different_c...
    Saya juga merekomendasikan The Manager’s Path karya Camille Fournier

• Disebutkan bahwa “membayar utang secara proaktif adalah investasi yang diperlukan untuk kesehatan engineering secara keseluruhan”, tetapi sebagian utang teknis kadang secara total lebih murah jika dibiarkan default daripada dilunasi.
  Asalkan product manager tidak mencoba menagihnya

  • Setuju. Jika proyeknya cukup kecil dan utangnya cukup besar, kadang menulis ulang adalah pilihan yang tepat.
    Namun proyek dengan skala dan kompleksitas tertentu hanya akan sampai pada kebangkrutan teknis jika tidak mengikuti saran buku ini. Jika utang teknis diabaikan demi merilis fitur, rilis akan makin sulit dan bug juga makin sering terjadi
  • Analogi itu hanya berlaku sampai batas tertentu, dan maksudnya di sini tidak jelas. Apa artinya mendefault utang teknis? Menulis ulang? Menyerah dan menerima saja biaya saat mengubah sistem?

• Selamat atas penerbitan bukunya.
  Berdasarkan pengalaman sebagai CTO di startup kecil dan VPoE di perusahaan publik, saya menulis Opinionated Launch(https://opinionatedlaunch.com) untuk berbagi ide praktis.
  Saat mulai menulis, saya menyadari topiknya terbagi menjadi dua jalur: manajemen/tim/orang dan teknis. Saya akhirnya fokus pada sisi teknis, yang lebih saya minati, dan senang ada seseorang yang mengerjakan bagian sisanya