Banyak yang telah ditulis tentang pentingnya pengembangan diri pendiri dalam perusahaan rintisan yang tumbuh cepat. Biasanya, teks tentang topik seperti itu dikhususkan untuk peran CEO. Kiat kepemimpinan umum juga dapat berguna untuk peran lain, tetapi saya belum dapat menemukan materi untuk membantu para pendiri teknologi. Setelah membaca sekumpulan formulir S-1, menjadi jelas bahwa sangat sulit untuk menemukan CTO dari awal yang telah beralih dari MVP ke IPO (sementara situasi dengan pendiri-CEO justru sebaliknya). Fakta ini menurut saya menarik - saya memutuskan untuk menggali lebih dalam. Saya ingin mendapatkan inti dan alasan dari keadaan ini. Itu juga sedikit mengganggu saya: bagaimana jika saya tidak dapat tumbuh dengan cepat? Saya harus mencari tahu sebelum masalah nyata muncul! Saya ingin menjadi CTO yang membuat RevenueCat menjadi perusahaan publik! (satu)
Apakah lebih sulit bagi pendiri non-CEO untuk tumbuh dengan cepat? Mungkinkah CEO biasanya memiliki dukungan yang signifikan? Bagaimanapun, semuanya memiliki alasannya sendiri. Mungkin pertanyaan saya salah. Setelah berbicara dengan banyak pendiri CTO, menjadi jelas bahwa tidak ada definisi standar tentang CTO. Tanggung jawab seseorang dalam posisi ini dapat berubah sepenuhnya tergantung pada perusahaan dan tahap perkembangannya. CTO mungkin membuat banyak masukan pribadi pada awalnya, tapi itu bisa segera berubah. Pengalaman orang yang berbeda bisa sangat berbeda. Sayangnya, saya tidak punya jawaban untuk pendiri non-CEO. Mungkin saya juga tidak punya jawaban untuk mereka yang menjadi CTO untuk pertama kalinya. Bagaimanapun, saya pikir akan membantu untuk merefleksikan apa yang telah saya pelajaridan bagaimana tanggung jawab saya berubah dalam 3 tahun di RevenueCat.
Dilema: CTO vs. Wakil Presiden Teknik
Sederhananya, peran CTO lebih dekat dengan arsitektur dan kode, sedangkan VPE akan bertanggung jawab atas proses dan manajemen. Analoginya adalah membandingkan jalur insinyur senior / penuh waktu dan manajer teknik.
Sejak awal, Anda membutuhkan CTO yang bisa mengumpulkan dan mengatur para pemain yang membuat MVP. Pada tahap ini, pendiri dapat sangat membantu karena diperlukan untuk menentukan visi produk dan budaya proses teknis. Idealnya, CTO harus memahami masalah yang akan diselesaikan oleh startupnya.
Bagaimana jika produk tersebut berhasil? Bagaimana jika produk mengambil tempatnya di pasar? Dalam hal ini, Anda perlu mempekerjakan lebih banyak teknisi untuk memenuhi permintaan dari konsumen. Ini adalah tantangan yang luar biasa. Mungkin Anda beruntung dan Anda akan menemukan pendanaan, atau Anda mungkin sudah menghasilkan keuntungan. Tetapi semakin besar staf Anda, semakin tinggi persyaratan untuk kesempurnaan proses. Momen pasti akan datang ketika seseorang harus menjadi VP Teknik. Permulaan momen ini akan menjadi jelas segera setelah proses yang ada (atau hilang) berhenti bekerja. Dalam situasi seperti itu, Anda memiliki beberapa opsi. CTO dapat mengambil alih peran VP of Engineering, atau perusahaan dapat mempekerjakan karyawan tambahan. Keputusan ini kemungkinan besar merupakan masalah preferensi pribadi dan pengalaman manajemen.Mengatasi jenis tantangan ini membutuhkan serangkaian keterampilan yang sama sekali berbeda, dan mungkin sulit untuk memperoleh keterampilan ini di lingkungan yang Anda perlu tumbuh dengan sangat cepat. Inilah sebabnya mengapa CTO biasanya dialihdayakan.
Pendirinya bisa fleksibel. Dia mungkin memiliki wewenang untuk menentukan jalan yang akan diambil perusahaan. Mungkin Anda benci mengelola orang dan ingin melanjutkan keterampilan dan pengetahuan Anda untuk bekerja langsung dengan teknologi. Atau mungkin Anda ingin meningkatkan keterampilan manajemen Anda. Jenis pertama umumnya lebih memaafkan kekurangan manajemen para pendiri. Mereka bergabung dengan tim karena mereka mempercayai para pendiri, percaya pada ide-ide mereka, dan yakin bahwa mereka memiliki niat baik. Pada awalnya, mereka mungkin lebih suka bekerja secara langsung dengan Anda daripada dengan orang luar. Bagaimanapun, di masa depan perusahaan akan memiliki beberapa tingkatan manajemen, jadi jika Anda ingin menempuh jalur ini dan Anda tidak memiliki pengalaman, maka Anda harus belajar, dan belajar dengan cepat.
Brian Helmig, salah satu pendiri dan CTO Zapier mengatakan Anda perlu menemukan apa yang dopamin berikan untuk Anda. Secara pribadi, selalu lebih mudah bagi saya untuk berkomunikasi dengan komputer daripada dengan orang. Saya tidak yakin tentang pilihan jalur pengembangan, tetapi saya lebih suka melakukan hal-hal yang berkaitan dengan komputer. Saya selalu senang bekerja dengan mereka dan saya dapat mengatakan bahwa saya lebih efisien sebagai insinyur daripada sebagai manajer. Setelah mengintegrasikan fitur baru, saya merasa lebih bersemangat daripada setelah bertemu langsung.
Namun, sebagai pendiri, saya mendapatkan dopamin dosis tinggi saat perusahaan berjalan baik. Saat pembeli merekomendasikan produk kami. Saat kami mencapai target pendapatan kami. Saat kami mempekerjakan teknisi lebih baik dari saya. Ketika para insinyur ini senang dengan segalanya dan berhasil menyelesaikan tugas-tugas ambisius. Ketika review kode melelahkan, tapi itu berjalan dalam suasana kolaborasi, bukan kemarahan.
Jadi, pada akhirnya, saya memutuskan tidak hanya untuk mengikuti preferensi saya, tetapi untuk melakukan apa yang lebih efektif bagi perusahaan pada berbagai tahap perkembangannya. Bagaimanapun, saya bisa menyelesaikan masalah. Beginilah cara saya berbicara tentang peranku. Kualitas saya sebagai pendiri lebih penting daripada posisi saya sebagai CTO. Dari perspektif jangka panjang, sebagai pemegang saham utama, saya harus melakukan apa pun yang terbaik untuk perusahaan.
Biasanya, patah tulang terjadi saat Anda memiliki 8 hingga 12 teknisi di tim Anda. Namun, itu bisa terjadi di lain waktu, semuanya tergantung pada produk dan lingkungannya. Sebagai perusahaan yang sepenuhnya terdistribusi, kami menghadapi beberapa titik kritis saat kami membangun zona waktu baru ke dalam alur kerja kami. Saat itu, banyak yang harus mengemban tugas sebagai CTO dan VP Teknik pada saat yang bersamaan. Saya mencoba untuk mengambil pekerjaan yang orang lain tidak memiliki sumber daya untuk itu (saya melakukannya sementara dan tidak terlalu baik). Ini membantu saya menemukan titik sakit, menetapkan proses, dan mempekerjakan seseorang yang dapat melakukan tugas ini.
Ketika saya belajar bagaimana pendiri lain mengatur waktu mereka di berbagai tahap pekerjaan, saya dapat menavigasi peran saya dengan lebih baik. Saya telah membuat buku harian sejak perusahaan didirikan. Berdasarkan catatan ini, saya akan berbicara tentang tugas yang saya fokuskan dan bagaimana peran saya telah berkembang.
2018: YC, MVP, dan karyawan pertama
Ketika kami datang ke YCombinator, hanya ada saya dan Jacob. Jacob mengerjakan SDK dan frontend, dan saya mengerjakan backend. Setelah YC, kami mempekerjakan dua insinyur pertama untuk mengambil alih tanggung jawab Jacob dan bekerja penuh waktu. Kami semua tinggal di San Francisco, dan kami sudah mengenal orang-orang ini. Kami memiliki kontrol yang sederhana (dan hampir lengkap). Tidak ada biaya tambahan, kami melakukan sprint mingguan, dan kami bergerak sangat cepat.
Hari-hari ini sangat intens tetapi sangat menyenangkan. Kami meletakkan dasar untuk budaya teknik dan melihat pelanggan datang satu per satu. Sebagian besar waktu saya habiskan untuk mengembangkan versi pertama dari fitur yang dibicarakan klien. Kami memenuhi permintaan mereka secepat kami bisa. Sebagian besar permintaan diproses pada hari yang sama.
Yang paling saya ragukan saat itu adalah bahwa kami menciptakan produk yang benar-benar dibutuhkan orang, dan dapat mengembangkan serta membenarkan putaran benih $ 1,5 juta kami.
Kesimpulan utama: terlalu banyak dari mereka, terlalu sulit untuk digeneralisasikan. Kami belajar banyak ketika kami melalui YCombinator. Mungkin, ada baiknya menyoroti komunikasi dengan klien, kemampuan untuk menciptakan apa yang membuat mereka bahagia dan memenuhi kebutuhan mereka. Ini dan pengiriman yang sangat cepat telah menjadi nilai inti kami.
2019: Kami mengimbangi klien dan mengembangkan teknologi
Sepertinya kami telah mengambil ceruk pasar kami. Klien mendatangi kami, permintaan dukungan mulai menumpuk, dan kinerja API kami tumbuh setiap hari. Insinyur jarak jauh pertama dari Taiwan bergabung dengan tim. Pada awalnya, perbedaan zona waktu menyebabkan kesulitan tertentu, maka proses kerja perlu disesuaikan. Namun, semuanya berhasil. Kami melakukan pekerjaan yang baik dengan pertanyaan dan pemantauan pelanggan.
Adaptasi adalah proses sederhana dan satu kali. Saya melakukan pertemuan tatap muka (tidak terlalu sering, sekitar sebulan sekali), tetapi pengelolaannya cukup mudah. Sebagian besar percakapan masih bersifat teknis. Saya masih berkontribusi sebagai pemain biasa. Saya juga menghadiri beberapa konferensi.
Saat itu, saya lebih banyak memiliki masalah teknis. Kebanyakan saya memikirkan tentang skalabilitas sistem kami. Semua teknisi kami memiliki pengalaman dengan produk dan kami memiliki poin kegagalan yang jelas. Saya terus berpikir untuk tidak merusak apa pun. Timbangan selalu keluar dari zona nyaman saya. Kami telah mengatasi dengan baik pengoptimalan skenario yang paling umum, migrasi infrastruktur, dan menghindari titik kritis. Kami juga melunasi hutang teknis yang terkumpul selama setahun terakhir.
Nyatanya, hingga kuartal keempat, saya adalah call engineer. Saya tidak ingin mengganggu anggota tim lain di luar jam kerja dan merasa sudah menjadi tanggung jawab saya sebagai pendiri departemen teknis untuk memberikan keandalan yang maksimal. Saya membawa laptop saya ke mana-mana. Akhirnya kami mengamankan rotasi. Melihat ke belakang, saya mengerti bahwa itu seharusnya dilakukan lebih awal.
Poin Penting: Jangan terpaku pada skalabilitas, tapi jangan lupakan pemantauan. Perhatikan potensi kemacetan dan titik kegagalan. Masalah-masalah ini membuat stres, tetapi menanganinya tidak terlalu buruk. Rekrut dan latih teknisi panggilan sesegera mungkin, dokumentasikan solusi untuk insiden yang diketahui. Andalkan tim Anda. Tidak ada yang salah dengan utang teknologi jika Anda mendekatinya secara bertanggung jawab dan mencoba menemukan produk yang akan diminati di pasar.
2020: Delegasi dan perencanaan organisasi masa depan
Pada tahun 2020, tim kami berlipat ganda sekali lagi. Kami mempekerjakan insinyur dari Eropa dan Amerika Latin. Pada akhir tahun, kami memiliki beberapa karyawan di setiap tim (SDK, frontend, frontend, ...). Kami berhasil mengerjakan beberapa proyek dan, akhirnya, kami mengambil tugas yang lebih ambisius. Namun, kami perlu meningkatkan koordinasi. Pada tahap ini, pengerjaan struktur tata kelola tidak dapat dihindari.
Selama kuartal pertama dan kedua, saya menghabiskan sebagian besar waktu saya melakukan tinjauan kode, memberikan pedoman arsitektur, dan menulis beberapa kode di sampingnya. Saya masih orang yang memahami sistem kami. Pada pertengahan tahun, terlihat jelas bahwa saya adalah hambatan dalam merilis fitur baru. Saya juga mengadakan one-on-one meeting, mengikuti diskusi brainstorming, dan tidak lagi punya waktu untuk menulis kode dan mengimplementasikannya tepat waktu.
Saya benar-benar telah menghentikan pemrograman. Sebaliknya, saya mempercayakan tugas saya kepada teknisi lain dan mulai menghabiskan lebih banyak waktu untuk mentransfer pengetahuan. Pada awalnya sepertinya butuh waktu lama, tetapi delegasi menyelesaikan banyak proyek dan memberi banyak insinyur rasa kepemilikan yang kuat. Sangat aneh untuk tidak menulis kode pada awalnya. Saya merasa seperti saya tidak melakukan pekerjaan saya (atau saya bekerja tidak produktif). Ini adalah perasaan yang sangat alami. Saya segera menyadari bahwa saya telah membebaskan diri dari pemrograman, dan sekarang saya dapat melihat gambaran besarnya. Saya bisa memikirkan masa depan struktur teknik.
Dalam hal manajemen, saya mulai menghabiskan lebih banyak waktu berbicara tentang pertumbuhan karier dan mulai bekerja dengan para insinyur untuk tumbuh dan berkembang. Di sisi produk, kami kekurangan sumber daya untuk memprioritaskan, merencanakan, dan mengoordinasikan sprint dengan benar. Saya melakukan yang terbaik untuk membebaskan orang dan membangun komunikasi.
Kami juga melalui Funding Round A dan mulai mengadakan rapat dewan. Saya juga mulai menghabiskan banyak waktu untuk perekrutan.
Poin Utama: Zona waktu baru menjadi lebih mudah diterapkan jika tumpang tindih. Penurunan faktor bus sangat penting untuk penskalaan tim teknik. Setelah Anda memverifikasi alur kerja Anda dan mereka bekerja, otomatiskan mereka sebanyak mungkin. Jika Anda tidak melihat hutan untuk pepohonan, berhenti memprogram dan mendelegasikan.
Masa depan
Tahun depan kami berencana menggandakan tim kami lagi. Tampaknya beralih dari 20 menjadi 40 karyawan lebih sulit daripada beralih dari 10 menjadi 20. Pada akhir 2021, perusahaan akan berubah secara signifikan.
Saya pikir saya akan berkonsentrasi pada skalabilitas tim. Jangan salah paham, tentu saja kami akan menghadapi masalah teknis yang serius, dan kami memiliki banyak tugas yang sangat ambisius dalam rencana kami. Selama beberapa tahun terakhir, kami telah belajar banyak tentang pelanggan, masalah, dan tumpukan teknis yang mendasari solusi kami. Bekerja dengan insinyur berbakat yang memiliki keterampilan dan antusiasme untuk memecahkan masalah adalah bagian besar bagi saya.
Saya ingin terus merekrut talenta terbaik dan mempertahankan budaya teknik yang sehat. Ini tidak akan mudah. Saya harus bekerja sama dengan manajer SDM untuk merampingkan dan mengotomatiskan proses sourcing, perekrutan, orientasi, dan komunikasi. Arahan membantu mempercepat pengembangan tim, tetapi inilah saatnya untuk fokus pada keragaman dalam tim. Saya pikir kami akan memiliki peluang untuk mempekerjakan junior, saya ingin membantu mereka mencapai potensi penuh mereka.
Kami perlu meningkatkan manajemen teknik kami untuk membuat teknisi senang dan memberdayakan mereka. Selain itu, jika kita ingin menangani tugas yang ambisius, kita perlu berinvestasi dalam proses perencanaan. pengembangan dan peluncuran produk.
Saya sangat senang dengan apa yang akan terjadi tahun depan. Tentu saja, selain masalah yang ada, masalah baru akan datang. Tapi itu tidak pernah terjadi sebaliknya. Ini tidak akan lebih mudah!
Saya harap teks ini menarik dan bermanfaat. Saya berencana untuk kembali ke posting ini dan melengkapinya dengan pengetahuan baru. Jika ini adalah pertama kalinya Anda sebagai CTO, saya akan dengan senang hati membantu sebisa saya. Jangan ragu untuk tweet atau email saya.
Terima kasih khusus kepada Alex Plugar, Calvin French-Owen, Xavi Santana, Adam Houghton, Sam Lown, Saul Diez dan Will Larson atas saran mereka dan meluangkan waktu untuk berbagi pengalaman mereka. Dan, tentu saja, kepada seluruh tim teknik RevenueCat yang mengizinkan saya bereksperimen dengan mereka, untuk menerima kekurangan saya dan umpan balik jujur mereka.
(1) Seiring waktu, saya belajar bahwa kecemasan dan ketakutan sebagian besar disebabkan oleh sindrom penipu dan tidak berdasar. Jika perusahaan melebihi Anda, belum tentu itu hal yang buruk. Faktanya, ini adalah masalah yang serius! Pendiri harus menghadapinya. Fokus pada perekrutan orang yang lebih baik dari Anda, yang akan membantu Anda tumbuh dan membuat perusahaan Anda lebih baik. Saya masih ingin membantu RevenueCat go public, dan jika berhasil, tanggung jawab dan posisi saya akan menjadi kurang penting.
- Diskusi di HackerNews
- Saluran Telegram "HackerNews in Russian"