CTO Kod Yazmalı mı? Yanlış Soruyu Sormayı Bırakın

Aynı tartışma her hafta yeniden alevleniyor. Bir yanda “kod yazan CTO, delege etmeyi beceremeyen CTO’dur” diyenler. Öbür yanda “klavyeden uzaklaşan CTO, otoritesini de bırakır” diyenler. Aralarında karikatür paylaşıp saf tutan binlerce insan. Herkes emin, herkes kendi hikâyesini herkesin hikâyesi sanıyor.

Ben bu kavgaya her denk geldiğimde tek bir şey düşünüyorum: yanlış soruyu tartışıyorlar.

“CTO kod yazmalı mı?” sorusu, “doktor ameliyat yapmalı mı?” demek kadar boş. Hangi doktor? Acil servis hekimi mi, radyolog mu, başhekim mi? Bağlamı sökülmüş bir soruya evrensel cevap aramanın tek ürünü, birbirine küsmüş profesyoneller oluyor.

O yüzden soruyu olduğu gibi çöpe atalım. Yerine işe yarar bir tane koyalım: hangi aşamada, hangi bağlamda, neyi yazmalı? Cevabı ararken göreceğiz ki CTO diye tek bir iş yok; şirket büyüdükçe rol da kabuk değiştiriyor.

”CTO Nedir?” Sorusunun Tek Bir Cevabı Yok

CTO, yazılım dünyasının en gevşek etiketi. Aynı kartviziti taşıyan iki insanın günü hiç benzemeyebilir. Biri sabah IDE’yi açıp production’a kod gönderiyordur, öteki o saatte board odasında beş yıllık teknoloji bütçesini savunuyordur. İkisi de CTO, ikisi de işini doğru yapıyor.

Sebebi basit. Rol, şirketin boyuna göre dikiliyor. Beş kişilik bir startup’ta CTO baş mühendistir. Elli kişide orkestra şefidir. Beş yüz kişide haritacıdır. Tek unvan, üç ayrı meslek.

Vadim Kravcenko meseleyi tek cümlede topluyor: şirket küçüldükçe CTO daha az insanla, büyüdükçe daha az teknolojiyle uğraşır. Spektrumun bir ucu saf kod, öteki ucu saf strateji. Ve çoğumuz kariyerimiz boyunca bu çizgi üzerinde sağa sola kayıp duruyoruz.

Tartışmaların hatası tam burada. Beş kişilik startup’ın CTO’suyla beş yüz kişilik şirketin CTO’sunu aynı teraziye koyuyorlar, sonra “kod yazmalı mı?” diye dövüşüyorlar. Elmayla armudu tartmanın teknoloji hâli.

Gelin çizgiyi baştan sona birlikte yürüyelim.

5 Kişilik Ekipte CTO: Baş Aşçı

Dede Korkut’ta bir tip vardır: obanın bilge kişisi. Aynı anda savaşçı, danışman ve şifacıdır. Tek başına birkaç işi birden taşır, çünkü oba küçüktür, kaynak dardır, işbölümü lüksü yoktur.

Küçük startup’ın CTO’su işte o bilge kişidir.

Sabah MVP’nin backend’ini yazarsın. Öğlen müşteriye demo geçersin. Akşam deploy hattını kurarsın, gece production’da patlayan bug’ın peşine düşersin. Ertesi sabah yatırımcıya mimariyi anlatırsın. “Hangi stack?” sorusunu da sen cevaplarsın, çünkü soracak başka kimse yok.

Burada “kod yazmasam mı?” diye bir lüks yok. Sen yazmazsan kim yazacak? Yanında bir iki mühendis vardır, belki o da yoktur. Startup’ın nefes alıp alamaması, senin klavyeye ne kadar çabuk dokunduğuna bağlı.

Üstelik iş koddan ibaret değil. Build mı yoksa satın al mı, kararı sende. Stack seçimi sende. İlk müşterinin teknik sorusu, yatırımcının “ölçeklenir mi?” kaygısı, production çökünce kimin yakasına yapışılacağı, hepsi sende.

İşin sinsi tarafı şurada: bu dönemde aldığın ilk mühendisler şirketin teknik karakterini kuruyor. İlk beş kişi, gelecek ellinin huyunu belirliyor. O huyu sen yazıyorsun, hem de yazdığın hiçbir production kodundan daha kalıcı biçimde.

Ama bir tuzak pusuda bekliyor: hıza bağımlılık.

Her işi kendin görmeye öyle alışırsın ki, ekip büyüdükten sonra bile “ben yapsam daha çabuk olur” dersin. Bu cümle, startup’ı yerinde saydıran şeyin ta kendisi. Çünkü evet, bugün gerçekten daha hızlısın. Ama yarın da, altı ay sonra da işi sen görüyorsan, ekip orada neden duruyor?

Bir lokanta düşün. Beş masalık. Şef hem ocakta, hem menüde, hem kasada. Gayet normal. Ama aynı şef yüz masalık salonda her tabağı kendi eliyle çıkarmaya kalkarsa, masadaki herkes aç kalır.

Bu dönemin tek kuralı şu: kod yaz, ama koda âşık olma. Her commit aynı zamanda bir ders olsun. Pair programming yap, mimari kararı yaz, kafandakini dışarı çıkar. Çünkü o klavyeyi bir gün bırakacaksın. O gün ekip senin kafandakini bilmiyorsa, şirket de seninle birlikte duruverir.

Bu aşamada en kıymetli silahın teknik derinliğin. Framework, mimari, build-vs-buy, hepsinde son söz sende. Ne var ki bir üst basamağa çıktığında, aynı silah elinde ağırlaşmaya başlar.

50 Kişilik Ekipte CTO: Orkestra Şefi

Semahta ince bir denge vardır: herkes kendi ekseninde döner, ama dönüş ortaktır. Tek tek hareketler var, hepsinin üstünde bir bütün var. Kimse yalnız dönmüyor, kimse de komşusunu taklit etmiyor. Herkes yerini biliyor, ortaya çıkan şey toplamdan büyük.

Elli kişilik bir ekibi yönetmek tam da bu. Ve rol burada kökten değişiyor.

En kritik pull request artık senden çıkmıyor. En çetrefil bug’ı artık sen çözmüyorsun. Belki IDE’yi açmayalı haftalar oldu. Hepsi normal.

Çünkü artık senin ürünün kod değil, ekip. Commit’lerin merge değil, karar. Deploy’ların feature değil, süreç.

Kendi ajansımı kurduğum günleri hatırlıyorum. Başlarda her projenin her satırına dokunurdum, geceleri production hatalarını kovalardım. Sonra beş kişi olduk, on kişi olduk. Bir gün fark ettim ki en çok değer kattığım anlar kod yazdığım anlar değildi. Bir junior’a bir kararın “neden”ini anlattığım, iki takımın teknik kavgasını çözdüğüm, müşteriye teknik borcu para diliyle tercüme ettiğim anlardı. Dağıtık sistemlerde veri bütünlüğü gibi derin bir konuyu masadaki herkesin anlayacağı dile çevirebilmek, bu aşamanın en pahalı becerisi.

Bu geçiş kolay değil, hele “yaparak öğrenmiş” biriysen. Klavyeden uzaklaşmak, kontrolü kaybetmek gibi gelir. Oysa tam tersini yapıyorsun: kontrolü çoğaltıyorsun. Bilgini taşıyan on kişi, bilginle sınırlı tek kişiden her zaman güçlüdür.

Gün de başka türlü akıyor artık. Standup’a “dün ne yaptım” demek için değil, önündeki taşları kaldırmak için giriyorsun. Tıkanan bir bağımlılık var mı, bekleyen bir mimari karar var mı? Öğleden sonra müşteri, retrospektif, teknik borç pazarlığı. PR’lara bakıyorsun ama hepsine değil; sadece emsal oluşturanlara, mimariyi eğip büken kararlara. Akşam ise gelecek çeyreğin haritası: hangi yatırım, hangi borç, hangi yetenek.

Bu dönemin en büyük tuzağı kodu özlemek. “Şu PR’ı ben çıkıversem” düşüncesi her gün kapını çalacak. Bazen de haklı çıkacak, gerçekten daha hızlı yaparsın. Ama her “ben yapayım” deyişinde birinin öğrenme sırasını çalıyorsun. Altı ay sonra yine sen yapıyorsun, çünkü o kişi öğrenemedi.

İşin en zor kavgası ekiple değil, kendinledir. Yıllarca değerini yazdığı satırla ölçmüş biri için, günün sonunda tek satır kod yazmamış olmak garip bir boşluk bırakır. Katkı grafiğin soluklaşır, içinden bir ses “artık üretmiyorum” der.

Üretiyorsun aslında. Sadece ürünün değişti. Artık ürettiğin şey, üretebilen insanlar. Avrupa’da enerji sektöründe CRM ekipleri yönetirken bunu çıplak gözle gördüm: ekibin en genç mühendisi, bir yıl önce pair programming’de gösterdiğim bir kalıbı kullanıp müşterinin en kritik entegrasyon sorununu çözmüştü. O an anladım, en iyi kodum başkasının elinden çıkmıştı.

500+ Kişide CTO: Haritacı

Bu ölçekte rol tümüyle stratejik. Günlük hayatta kod yok, belki aylardır terminal bile açmadın. Ve bu doğru.

Çünkü artık işin şirketin teknoloji yönünü belirlemek ve onu iş stratejisiyle aynı hizaya getirmek. Board’da beş yıllık haritayı sunuyorsun. VP of Engineering’lerle organizasyonu tasarlıyorsun. Cloud migration, platform değişimi, büyük build-vs-buy kararları senin masandan geçiyor.

Senin “kodun” başka bir dilde yazılıyor: strateji belgesi, organizasyon şeması, teknoloji radarı. Çıktın commit değil, yön.

Burada da bir uçurum var: teknik kopuş. Kod yazmayı bırakmak doğru, teknolojiyi takip etmeyi bırakmak felaket. Bu ölçekteki iyi CTO’lar zekâlarını ya kişisel projelerde deney yaparak ya da en teknik insanlarla düzenli derin dalış oturumları kurarak diri tutuyor. Hiçbirini yapmayan, üç yıl sonra board’da teknik soruya cevap veremeyen “eski mühendis” oluyor.

Ve burada güzel bir paradoks çıkıyor karşına: bu ölçekte en güçlü silahın teknik bilgin değil, tercüme yeteneğin. CFO’ya “neden bu refactoring’e para koyalım?” sorusunu müşteri kaybı rakamıyla cevaplayan; mühendise “neden bu feature erteleniyor?” sorusunu pazar verisiyle açıklayan biri. İki dünyanın arasında duran köprü.

Gerald Weinberg’in dediği gibi, ne kadar teknik görünürse görünsün her şey aslında bir insan meselesidir. Bir platform göçü yalnızca teknik bir proje değil, yüzlerce insanın iş yapma biçimini değiştiren bir dönüşümdür. Mattermost’tan Matrix’e taşınma küçük bir ekipte bile ciddi bir karardı; yüzlerce kişilik bir yapıda o kararın ağırlığını düşün.

AI Çağında CTO: Yeni Bir Denklem

Az insan, az cephane, az zaman. Bir kurtuluş mücadelesinin koşulları çoğu zaman böyledir, ve işte o darlık stratejik zekâyı doğurur. Elindeki her kaynağı katlayarak kullanmak zorunda kalırsın.

AI çağında CTO’nun durumu buna benziyor. Kaynaklar aynı, ama her birinin çarpanı değişti. AI’ın yazılımı nasıl dönüştürdüğünü daha önce uzun uzun yazmıştım; burada o dalganın doğrudan CTO rolüne çarpan tarafına bakacağım.

Bir mühendis bugün AI destekli araçlarla eskinin iki üç katı hızda kod üretiyor. Ama bu, daha az mühendis değil, daha başka mühendis demek. AI’ın kustuğu kodu tartabilen, yönlendirebilen, yerine oturtabilen insanlar.

Bunun CTO için üç sonucu var.

Birincisi, “kod yazmak” yeniden tanımlandı. Her satırı elin yazmak zorunda değilsin. Ama hangi satırın yazılması gerektiğini bilmek, çıkan kodun kalitesini görmek, aracı doğru yöne kışkırtmak, işte yeni teknik yetkinlik bunlar.

İkincisi, ekibin şekli oynuyor. Basit işleri artık agent’lar üstleniyor. Bu da ekip planını sıfırdan düşünmek demek. Hangi iş AI’a gider, hangi rol dönüşür, hangi yeni rol doğar?

Üçüncüsü, ve en mühimi, karar hızı arttı. Prototip, test, iterasyon döngüsü kısaldı. Eskiden “iki haftalık sprint’e alalım” dediğimiz bir fikri, bugün birkaç saatte çalışan bir prototipe çeviriyoruz. Denemenin maliyeti düştükçe, strateji ile taktik arasındaki mesafe de daralıyor.

Ama dikkat: AI bir araç, strateji değil. “Biz AI kullanıyoruz” demek, “biz bilgisayar kullanıyoruz” demek kadar içi boş bir cümleye dönüşüyor. Mesele aracı nerede ve nasıl kullandığın. O kararı verecek olan hâlâ insan.

Bu çağda CTO’nun bir yeni borcu daha var: ekibini AI ile çalışmaya hazırlamak. “Şu tool’u kurun” demekle bitmez bu. Mühendisin AI çıktısını eleştirel gözle süzebilmesini sağlamak, aracın nerede tökezlediğini öğretmek, “çalışan kod” ile “doğru kod” arasındaki çizgiyi koruyan bir kültür kurmak gerek. AI çalışan kodu kolay üretiyor. Doğru kod hâlâ insan kararı istiyor.

Peki Ne Zaman Klavyeye Dokunmalı?

Buraya kadar bir çizgi çektik: küçük ekipte kod, büyük ekipte strateji. Gerçek hayat bu kadar temiz değil tabii. Elli kişilik ekibin CTO’su da ara sıra kod yazar, beş yüz kişilik yapının CTO’su da ara sıra terminal açar.

Soru “yazmalı mı, yazmamalı mı?” değil. Soru şu: neden yazıyorum?

Yıllar içinde kendime birkaç pusula edindim.

Evet, dokun:

• Kriz anında. Production yandıysa ve o sistemin mimarisini en iyi sen biliyorsan, araya girmek sorumluluktur. Ama yangın söndükten sonra şunu sor: bir dahakine bensiz söndürülebilir mi?
• Prototip anında. Yeni bir yaklaşımı kendi elinle denemek, kararının kalitesini yükseltir. Bazen doğrudan denemek, delege edip arada bir çeviri katmanı oluşturmaktan hızlı ve isabetli olur. Yalnız prototip ile ürün arasındaki ölümcül vadiyi unutma: prototip bir şeyi kanıtlamak içindir, ürünün kendisi değil.
• Öğretmek için. Pair programming’de yazdığın kod “ben yapayım çabuk olsun” değil, bilgi aktarımıdır. Bu makbul.
• Kendi bahçende. Yan projelerde, kişisel deneylerde teknik kasları diri tutmak için kapı hep açık.

Hayır, bırak:

• “Ben daha hızlı yaparım” diyorsan. Bu cümle, delege edemediğinin ve ekibine yatırım yapmadığının itirafıdır.
• Feature geliştiriyorsan. CTO’nun sprint backlog’unda kendi task’ı varsa, ya kadro eksiktir ya öncelik karışmıştır.
• Ego için yazıyorsan. “Hâlâ kod yazabiliyorum” ispatına ihtiyacın yok. Ekip seni son commit’inin tarihine değil, son kararının kalitesine bakarak dinler.
• Darboğaz olduysan. Senin onayın olmadan merge çıkmıyorsa, yazdığını kimse anlamıyorsa, sen yoksan deploy duruyorsa, sorun kodda değil, sende.

Hepsinin özü tek cümle: kod yazmak bir araçtır, bir kimlik değil. CTO’nun kimliği “kod yazan kişi” değil, “doğru kararı veren kişi” olmalı. Bazen doğru karar kod yazmaktır, çoğu zaman değildir. Ve bu pusula sabit de değil; aynı insan, aynı şirkette, farklı dönemde farklı yöne döner. Yeni bir ürün hattı açılırken birkaç hafta prototip moduna geçebilirsin; büyük bir organizasyon değişiminde aylarca satır yazmayabilirsin.

CTO’nun Asıl Kodu: Kültür Mühendisliği

Bir şirketin teknoloji kültürü, CTO’nun en uzun ömürlü kodudur. Framework değişir, dil evrilir, mimari refactor edilir. Ama ekibin nasıl karar verdiği, hatayı nasıl karşıladığı, bilgiyi nasıl paylaştığı yıllarca çalışmaya devam eder.

Gerçek CTO çıktısını düşününce aklıma yazılan satırlar değil, kurulan mekanizmalar geliyor:

• Suçlamayan postmortem. Hata yapan kişi değil, hataya izin veren sistem masaya yatırılır.
• Şeffaf karar kaydı. ADR’ler, RFC’ler, içeride dolaşan teknik yazılar.
• Junior’ın çekinmeden soru sorabildiği ortam. “Aptal soru yoktur” lafı duvarda değil, koridorda yaşar.
• Teknik borcun para diline çevrilmesi. “Bunu refactor etmeliyiz” değil, “bu, şikâyetlerin üçte birinin kaynağı.”
• Deney kültürü. Başarısızlığın cezalandırılmadığı, öğrenmenin ödüllendirildiği bir iklim.

Bunların hiçbiri tek satır kod istemiyor. Ama hepsi mühendislik disiplini, sabır ve empati istiyor. Ve işin paradoksu, teknik derinlik de istiyor; çünkü bu kültürü ancak yazılımın nasıl yapıldığını iliklerine kadar bilen biri kurabilir.

Bir güvenlik şirketinde yazılım ekibini yönetirken, teknik olarak en parlak mühendisimiz vardı. Her problemi tek başına çözerdi. Ekip büyüyünce o “her şeyi ben hallederim” refleksi takımı felç etti. Kimse inisiyatif almıyordu, çünkü “nasılsa o yapar” beklentisi yerleşmişti. Benim işim o kişiyi durdurmak değil, bilgisini çoğaltacak mekanizmayı kurmaktı. Code review standardı, pair programming rutini, dokümantasyon alışkanlığı. Bunlar tek kişinin kafasındakini on kişiye yaydı.

İşte CTO’nun asıl kodu bu: bilgiyi çoğaltan, kararı hızlandıran, hatayı derse çeviren sistemler kurmak. En iyi kod, kimsenin fark etmediği koddur; altyapı gibi görünmez ama her şeyi ayakta tutar.

Yanlış Sorudan Doğru Cevaba

Yola “CTO kod yazmalı mı?” diye çıktık. Umarım buraya geldiğimizde bu sorunun ne kadar eksik olduğu ortadadır.

Doğru olan tek bir soru değil, bir dizi soru:

• Şirketin hangi aşamasındayım?
• Ekibimin bana en çok ihtiyaç duyduğu yer neresi?
• Kod yazarak mı, başka türlü mü daha çok değer üretiyorum?
• Bugün yazdığım kodu yarın başkası yazabilir mi?
• Yazma sebebim ekibin ihtiyacı mı, benim ihtiyacım mı?

Cevap kişiden kişiye, şirketten şirkete, hatta aydan aya değişir. Rolün güzelliği de burada zaten: sabit bir iş tanımı yok, sabit bir “doğru” yok. Tek sabit, sürekli kabuk değiştirmek. Baş aşçıdan orkestra şefine, oradan haritacıya. Her basamakta da “şimdi doğru olan ne?” diye yeniden sormak.

Baştaki kavgaya dönelim: iki taraf da haklı, iki taraf da haksız. Çünkü sorunun kendisi bağlamsız, bağlamsız soruya da cevap olmaz. Bağlamı en iyi bilen kişi, o koltukta oturanın ta kendisi. Ego’yu bir yana bırakıp “şu an en büyük darboğaz nerede?” diye sorabilmek, teknik zekâdan kıymetli bir yetenektir.

Sonuçta CTO’nun asıl işi ne kod yazmak ne de yazmamak. Asıl iş, her gün “bugün en büyük etkiyi nerede yaratırım?” sorusunu dürüstçe cevaplayabilmek. Cevap kimi gün bir terminal penceresinde, çoğu gün bir beyaz tahtanın önünde, her gün insanların arasında. Ve belki en önemlisi: bu soruyu sormayı hiç bırakmamak. Teknoloji durmuyor, şirket durmuyor, pazar durmuyor; o yüzden CTO da durmamalı. Bu soru, CTO’nun kendine her çeyrek yeniden yazdığı en kritik unit test.