- Birçok CTO yönetime odaklı bir role geçse de, hâlâ doğrudan kod yazarak ürün geliştirme yaklaşımını sürdürüyor
- Deneysel projeler, acil müşteri talepleri ve hata düzeltmeleri gibi üç tür geliştirme işi üzerinden organizasyon içinde yüksek kaldıraç yaratıyor
- Kod yazmayı sürdürerek yapay zeka araçlarının gerçek faydasını ve sınırlarını bizzat deneyimliyor, teknik kararların gerçekçiliğini koruyor
- Yönetimden çok problem çözme ve ürün inşa etme konusunda güçlü ve tutkulu olduğunu, bunu mümkün kılan organizasyon yapısını tasarladığını söylüyor
- CTO rolü için kalıplaşmış tek bir model yok; önemli olan kişinin kendi güçlü yanlarına ve şirketin koşullarına uygun bir liderlik tarzı bulması
CTO olarak kod yazmayı sürdürmemin nedeni
- Birçok CTO zamanla kod yazmayı bıraksa da, ben hâlâ doğrudan özellik geliştirip dağıtma şeklinde çalışıyorum
- Son 12 ayda bana doğrudan bağlı ekip üyeleri olmadan birden fazla önemli özelliği yayına aldım
- Bu yalnızca bir hobi değil; gerçek ürüne giren çekirdek özellikleri geliştiren kişi rolünü üstleniyorum
- Bunu “teknoloji lideri olarak en yüksek kaldıraçlı faaliyetlerden biri” olarak görüyorum
Gerçekte geliştirdiğim üç proje türü
1. Uzun vadeli deneysel projeler (Long-horizon experimental projects)
- Organizasyon içinde gerçekten yeni bir ürün inşa edebilecek kişi sayısı çok sınırlı
- Çünkü çoğu organizasyon mevcut ürünü sürdürmeye ve ölçeklemeye odaklanıyor
- Yalnızca kurucular, bazı yöneticiler ve yüksek performanslı bireysel katkıcılar (IC) yeni ürün denemeye alan bulabiliyor
- Organizasyon yapısı, yol haritası teşvikleri ve sınırlı risk bütçesi nedeniyle mühendislerin çoğu aylar süren belirsiz projeleri yürütemiyor
- CTO, müşteri pain point'lerine ve mimariye dair derin anlayışı sayesinde belirsiz deneysel projeleri hızla ileri taşıyabilecek benzersiz bir konumda
- Başarısız denemeler de oldu, ama büyük başarılar da elde edildi
- Yapay zeka sohbet ürünü örneği: Ekip değerini kabul etse de zaman ve alan bulamadığı için ertelenen projeye Şükran Günü tatilinde prototip geliştirildi
- Ardından ekiple birlikte çalışılarak milyonlarca dolar ARR üreten bir ürüne dönüştürüldü
2. Kritik müşteri talepleri (Critical customer asks)
- Büyük müşterilerin acilen ihtiyaç duyduğu özellikler bazen büyük sözleşmelerin ya da yenilemelerin önündeki engel hâline geliyor
- Devam eden sprint'teki mühendisleri kaydırmak yerine, CTO hızlı karar alma ve sistemin tamamını anlama avantajıyla bunu doğrudan ele alıyor
- Gerçek örnek: Yıllık milyon dolarlık bir müşterinin uyumluluk ihtiyacı için veri redaksiyonu özelliği talebi
- Ekibin ilk değerlendirmesine göre müşterinin kendi API entegrasyonunu kurması ya da ürün, hukuk ve mühendislik arasında birden çok toplantı yapılması gerekecekti
- CTO bir gün içinde çalışan bir sürüm geliştirip dağıtarak müşteri ilişkisini korudu
3. Hata düzeltmeleri (Bugfixes)
- Birçok kişiye şaşırtıcı gelse de, hata düzeltmek kod tabanının zihinsel haritasını korumanın en sevdiğim yollarından biri
- Arama sonuçlarının 3. sayfasında sayfalamanın neden bozulduğunu ya da WebSocket bağlantısının neden tam 60 saniye sonra koptuğunu araştırırken tüm sistemi dolaşıyorum
- Bu sayede kod incelemesi veya mimari tartışmalarla elde edilmesi zor olan teknik borca dair sezgisel bir anlayış kazanıyorum
- Bu deneyim, teknik yatırım yönü ve önceliklerini belirlemek için gereken sezgiyi canlı tutuyor
Kod yazmayı sürdürmemin nedenleri
1. Gerçekte neyin işe yaradığını anlamak için
- Claude Code, Codex, Cursor gibi yapay zeka araçlarını her gün kullanma deneyimi sayesinde, araçlar ve işe alım stratejileri hakkında karar verirken gerçeği abartıdan ayırabiliyorum
- Yakın tarihli bir örnek: Karmaşık entegrasyonlara dokunan bir özelliği vibe-coding ile yapmayı denedim ama ilerleyemedim; elle yazınca çok daha hızlı ilerledi
- Kod miktarı fazla değildi ama doğru mantık gerekiyordu (LLM'lerin zayıf olduğu bir alan)
- Buna karşılık başka büyük bir özelliğin neredeyse tamamını Claude Code ile geliştirdim
- Yapay zekanın çok iyi olduğu alanları (CRUD, testler, boilerplate) ve başarısız olduğu alanları (hassasiyet, sistem nüansları) bilmek, Twitter abartısına göre karar vermekten çok daha iyi
- Kodun içinde olduğunuzda ne zaman zorlamak, ne zaman gevşetmek gerektiğini hissedebiliyorsunuz
- Mimarinin ne zaman gereğinden karmaşıklaştığını ya da teknik borcun ne zaman gerçekten sorun olmaya başladığını fark edebiliyorsunuz
- Yalnızca raporlara dayanan bir yönetici çok şeyi kaçırabilir
2. İyi olduğum ve keyif aldığım işe odaklanmak için
- Organizasyon kurma ve insan yönetiminden özel bir keyif almıyorum
- Mühendislik yönetimi, kişiler arası dinamikler, performans değerlendirmesi ve organizasyon tasarımı gerektiriyor
- Bu önemli bir işlev ama benim en güçlü olduğum alan değil
- Bu yüzden güçlü mühendislik yöneticileri ve liderler işe alıyorum
- Çünkü onlar bunu daha iyi yapıyor ve bundan daha çok keyif alıyor
- Böylece CTO olarak ben ürün geliştirme, teknik problem çözme ve kod yazmaya odaklanabiliyorum
- Startup'lar bir “sprint tipi maraton” gibidir; bu yüzden rolümü ilgimi canlı tutan ve uzun süre yüksek tempoda sürdürebileceğim işler etrafında tasarlıyorum
- Bu, yıllar boyunca sürdürülebilir bir yaklaşım ve şirket için çok önemli
3. Çünkü yapay zeka araçları kaldıraç etkisini büyüttü
- Birkaç yıl önce stratejik işleri yürütürken kod yazacak zaman bulmak zordu
- Şirket büyüdükçe tüm gün toplantılara gömülüyor ve güçlü olduğum alanların dışında çalışıyordum
- Bu, profesyonel hayatımdaki en zor dönemlerden biriydi
- Modern yapay zeka araçları bu denklemi kökten değiştirdi (özellikle son birkaç ayda)
- Verimliliğim eskisine göre 2-3 kat arttı
- Bu araçlar muhakeme gücünün ya da teknik bilginin yerini almıyor; aksine bu yetenekleri daha değerli hâle getiriyor
- Yapay zeka aracına “mevcut CSV dışa aktarma formatıyla uyumlu ama kullanıcı profil tablosundan üç ek alan içeren bir veri dışa aktarma özelliği oluştur” dediğimde, kodun büyük kısmını doğru şekilde üretebiliyor
- Çünkü tam olarak neye ihtiyaç olduğunu ve bunun nerede bulunacağını gösteren derin bağlama sahibim
- Kod tabanının o bölümüne aşina olmayan bir mühendisin ayrıntıları çözmesi ciddi zaman alabilir
- İş “her satır kodu yazmak”tan çıkıp “bağlam sağlama, karar verme ve çözümü değerlendirme”ye dönüştü
- Neyse ki bende çok fazla bağlam var
Kendinize uygun yolu bulmak
- CTO rolünü tanımlarken Greg Brockman'ın Stripe'taki CTO rolünü tanımlamaya dair blog yazısına başvurdum
- Birçok CTO ile konuştuktan sonra rolün nasıl şekillendiği konusunda çok büyük farklılıklar olduğunu fark ettim
- Bazı CTO'lar teknoloji vizyoneri, bazıları organizasyon kurucusu, bazıları ise altyapı odaklı
- Ortak nokta şu: Harika CTO'lar, kendi becerileri, ilgi alanları ve şirketlerinin durumu doğrultusunda en çok değeri nerede üretebileceklerini anlıyor
- Benim durumumda bu, çok fazla kod yazmak anlamına geliyor
- Organizasyon tasarlamaktan çok yazılım inşa etmeyi seviyorum
- Müşterilere ve kod tabanına dair derin bilgim sayesinde burada özellikle etkiliyim
- Güçlü mühendislik yöneticileri işe alıyorum
- Ancak bu kişisel bir yol, bir reçete değil
- CTO rolü son derece esnek
- Organizasyon kurmak, ürün stratejisi geliştirmek vb. - teknik liderlik güçlü yönlere, enerji kaynaklarına ve şirketin ihtiyaçlarına göre farklı şekiller alabilir
- Teknik liderliğin teknik işi bırakmak anlamına geldiğinden endişe duyan mühendislere: Birçok farklı yol var
- Önemli olan, sizi benzersiz biçimde güçlü kılan alanı bulmak
5 yorum
Şu anda CTO olarak çalışıyorum ve bu yazıya kesinlikle katılmıyorum.
Kod yazmayı bırakmamak gerektiğine %100 katılıyorum, ama bunun için şirketin ürünüyle ilgisi olmayan açık kaynakla uğraşmak yeterlidir. Bunun ancak erken aşama bir startup'ın teknik kurucusu olarak her işi üstlenmek gerektiği bakış açısından geçerli bir görüş olduğunu düşünüyorum.
Kendisi için iyi tabii… Peki şirket için?
Aldığı maaşa uygun bir iş yapmalı…
Deneysel bir projeyi CTO'nun doğrudan yürütmesi bana tuhaf geliyor. Uygulamadaki ekiplere yeterli zaman verilse gayet iyi başarabilirlerdi. Bana en tuhaf gelen şey, uzun soluklu deneysel projeyi yalnızca CTO'nun yürütmek zorunda olması. Eğer kendisinin kaynak kullanma yetkisi varsa, deneysel proje için ayrı kaynak ayarlayıp uygulamadaki ekiplere yeterli zamanı vermesi yeterli olurdu.
Kişisel bir yol... Organizasyon yönetimi tarafı daha da artmasın diye iyi yönetmek gerekecek sanırım..
Hacker News görüşleri
Başvuracağım şirketi düşünürken CTO’nun her hafta sonu kod commit ettiğini öven bir blog yazısı görsem, ben kaçmaya hazırlanırdım
Liderin görevi sağlıklı bir organizasyon kültürü kurmaktır; hafta sonu çalışmasını övmek ise bunun tam tersidir
Üstelik hukuki ya da mühendislik incelemesini atlayıp müşteri sorununu bir günde çözdüğünü açıkça söylemek de tehlikeli bir işarettir
Erken aşama startup’larda kültür tamamen farklıdır ve bu tür yazılar hatta uygun adayları eleyen bir filtre işlevi görür
Yazdığım kodun çoğu dahili DevEx iyileştirmeleri ya da teknik borç temizliği içindir
Hukuki incelemeyi atladığım bir durum olmaz ve prodüksiyon kodundan çok PoC seviyesinde ele alırım
Kurucu CTO’nun koda yakın olması önemlidir ama asıl mesele dengenin kaybolmamasıdır
CTO rolü şirketten şirkete değişir
Greg Brockman’ın Stripe örneğinde olduğu gibi bazı CTO’lar teknik vizyoner, bazıları organizasyon tasarımcısı, bazılarıysa altyapı odaklıdır
Benim durumumda kod yazmayı seviyorum ve müşterilerle kod tabanına derin biçimde dahilim; bu da benim en büyük değer üretme biçimim
“CTO” unvanının tanımı belirsizdir
Bazı CTO’lar kurucudur ve rahatça kod yazar; bazıları ise müşteri odaklı çalışırken kod erişimini kaybeder
Öte yandan buyurgan CTO’lar da vardır
Sonuçta nasıl bir CTO’dan söz edildiğini netleştirmek gerekir ki “neden kod yazıyor” sorusu anlam kazansın
Bu durumda CTO adı sadece rol ayrımı içindir
CTO strateji ve yön üzerine, VP ise günlük mühendislik yönetimine odaklanır
Bunun yolu organizasyon kurmak da olabilir, bizzat kod yazmak da
Yönetici pozisyonundaki biri doğrudan kod yazarsa kod review süreci bozulabilir ve ekipte kafa karışıklığı yaratabilir
Sonuçta o kişinin CTO’dan çok, zihnen hâlâ bir geliştirici olma ihtimali yüksektir
CTO’nun kod yazmasına tamamen karşı değilim ama bu örnekte CTO rolünün gereği yeterince yerine getirilmiyor gibi görünüyor
Fiilî teknik liderliği kurucu mühendis üstlenirken, çok daha düşük ücret alması sorunlu bir yapı
Hiyerarşik raporlama yapısı olmayan ve sadece kod yazan bir CTO, stratejiden çok kıdemli geliştirici rolüne yakın diye düşünüyorum
Bana da böyle teklifler geldi ama sonuçta sadece sembolik bir unvandı
Organizasyon büyüdüğünde rolün değişeceğini düşünüyorum
Küçük startup’larda ekiple birlikte sprint yürütmek, takvim sarktığında nedeni çözmek ve tükenmişlik yaşayanlarla ilgilenmek benim işim
Ama yazıya bakılırsa ekip popüler AI projelerini bile denemeye vakit bulamayan bir yapıdaysa, bu bir organizasyon sorunudur
CTO’nun bizzat kod yazması değil, bu tür sistemsel darboğazları çözmesi gerekir
Her şirkette “senior” ya da “head” rolü tamamen farklı olabilir
CTO’nun kod yazmaya fazla gömülmesiyle doğan sorunlar nettir
PR review sürecinin bozulması, asıl işin aksaması, rol karmaşası, ekibin özerkliğinin zedelenmesi gibi
“CTO kod yazmamalı, sadece strateji yapmalı” düşüncesi mekanik bir bakış açısıdır
Teknoloji şirketinin özü değer sunmaktır ve bazen CTO’nun bizzat büyük bir özelliği bir günde hayata geçirmesi en değerli iş olabilir
Bu, KPI toplantılarından çok daha üretken bir gün de olabilir
Bazen C-level yöneticilerin doğrudan sahadaki hissiyatı yeniden kazanması gerekir
Bazı insanlar CTO olmuştur çünkü sadece ortak kurucudur
Böyle bir yaklaşımla başka bir şirkete girerse staff engineer seviyesine bile ulaşamayabilir
Son olarak, şirket web sitesindeki fiyatlandırma sayfasında gerçek fiyatların olmaması kafa karıştırıcı olabilir; bunun düzeltilmesi gerekir