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

LinkedIn’de her hafta aynı tartışma patlak veriyor. Bir tarafta “CTO kod yazıyorsa delegasyon yapamıyordur” diyen yönetim guruları, diğer tarafta “CTO kod yazmazsa teknik otoritesini kaybeder” diyen mühendislik puristi’leri. İki kamp arasında CommitStrip karikatürlerini paylaşarak pozisyon alan binlerce kişi. Herkes haklı, herkes emin, herkes kendi deneyimini evrensel gerçek sanıyor.

Bu tartışmayı her gördüğümde aklıma hep aynı şey geliyor: Sorunun kendisi yanlış.

“CTO kod yazmalı mı?” sorusu, “Doktor ameliyat yapmalı mı?” demek kadar anlamsız. Hangi doktor? Hangi hastane? Kaç kişilik ekip? Acil servis mi, araştırma merkezi mi? Bağlamı olmayan bir soruya evrensel bir cevap aramanın tek sonucu, LinkedIn’de birbirine küsen profesyoneller oluyor.

Bu yazıda o soruyu çöpe atacağız. Yerine daha doğru bir soru koyacağız: Hangi aşamada, hangi bağlamda, ne yazmalı? Ve bu sorunun cevabını ararken, CTO rolünün şirketin büyüklüğüne göre nasıl kökten değiştiğini birlikte keşfedeceğiz.

”CTO Nedir?” Sorusunun Tek Bir Cevabı Yok

CTO unvanı, yazılım dünyasının en esnek etiketlerinden biri. Aynı unvanı taşıyan iki kişinin günlük rutini birbirine hiç benzemeyebilir. Birisi sabah 9’da IDE açıp production kodu yazarken, diğeri board toplantısında beş yıllık teknoloji stratejisini sunuyor olabilir. İkisi de CTO. İkisi de doğru yapıyor.

Bunun sebebi basit: CTO rolü, şirketin DNA’sına göre şekilleniyor. Beş kişilik bir startup’ta CTO demek, baş mühendis demek. Elli kişilik bir şirkette orkestra şefi demek. Beş yüz kişilik bir yapıda ise haritacı, stratejist, vizyoner demek. Aynı unvan, tamamen farklı iş tanımları.

Vadim Kravcenko bunu çok güzel özetliyor: “Şirket ne kadar küçükse CTO o kadar az insanla uğraşır, şirket ne kadar büyükse CTO o kadar az teknolojiyle uğraşır.” Bu spektrumun bir ucunda tamamen kod var, diğer ucunda tamamen strateji. Ve çoğu CTO, kariyerinin farklı noktalarında bu spektrumun farklı yerlerinde duruyor.

Sorun şurada: LinkedIn’deki tartışmalar bu spektrumu görmezden geliyor. 5 kişilik startup’ın CTO’su ile 500 kişilik şirketin CTO’su aynı kefeye konuluyor. Sonra da “CTO kod yazmalı mı?” diye kavga ediliyor. Elma ile armut karşılaştırmasının teknoloji versiyonu.

Gelin bu spektrumu birlikte yürüyelim.

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

Dede Korkut hikayelerinde bir arketip vardır: Bilge kişi. Hem savaşçıdır, hem danışmandır, hem şifacıdır. Obanın en deneyimli insanı olarak tek başına birden fazla rolü üstlenir. Çünkü oba küçüktür, kaynak kısıtlıdır, lüks yoktur.

Küçük bir startup’taki CTO, o bilge kişidir.

Sabah MVP’nin backend’ini yazarsın. Öğleden sonra müşteri demosu yaparsın. Akşam deploy pipeline’ını kurar, gece yarısı production’daki bug’ı fixlersin. Ertesi gün yatırımcıya teknik mimariyi anlatırsın. Arada bir de “hangi stack’i seçelim?” sorusuna cevap verirsin, çünkü soran başka kimse yok.

Bu aşamada kod yazmamak gibi bir seçenek yok. Sen yazmazsan kim yazacak? Belki bir ya da iki mühendis daha var yanında, belki henüz hiç kimse yok. Startup’ın hayatta kalması senin klavyeye ne kadar hızlı dokunduğunla doğrudan ilişkili.

Ve sadece kod da değil. Build-vs-buy kararlarını sen veriyorsun. Tech stack seçimini sen yapıyorsun. İlk müşterinin teknik sorusunu sen cevaplıyorsun. Yatırımcının “bu ölçeklenir mi?” sorusuna ikna edici bir cevap vermen gerekiyor. CEO muhtemelen QA’yi de yapıyor, ama production’da patlayan şeyin hesabını soran yine sana bakıyor.

Steve Tauber’ın güzel bir tespiti var: Bu aşamada CTO aynı zamanda ilk mühendisleri işe alan kişi. Ve bu, sadece teknik mülakat yapmak değil, şirketin teknik kültürünün temellerini atmak demek. İlk beş mühendis, sonraki ellinin DNA’sını belirliyor. O DNA’yı sen yazıyorsun.

Ama burada tehlikeli bir tuzak var: Hız bağımlılığı.

Her şeyi kendin yapmaya o kadar alışırsın ki, ekip büyümeye başladığında bile “ben daha hızlı yaparım” diye düşünürsün. Bu düşünce, startup’ın ölçeklenmesinin önündeki en büyük engel. Çünkü evet, bugün daha hızlı yapıyorsun. Ama yarın da, öbür gün de, altı ay sonra da sen yapıyorsan, ekip neden var?

Bir restoran düşünün. Beş masalık küçük bir mekan. Şef hem yemekleri pişiriyor, hem menüyü tasarlıyor, hem kasada hesap kesiyor. Normal. Ama aynı şef yüz masalık bir restoranda hâlâ bizzat her tabağı hazırlamaya çalışırsa, müşteriler aç kalır.

Bu aşamadaki altın kural: Kod yaz, ama kodla evlenme. Her commit’in aynı zamanda bir öğretme fırsatı olsun. Pair programming yap. Mimari kararları belgelendir. Çünkü bir gün o klavyeyi bırakman gerekecek. O gün geldiğinde ekip senin kafandakileri bilmiyorsa, şirket seninle birlikte durur.

Küçük ekipte CTO’nun en kritik becerisi teknik uzmanlık. Framework seçimleri, mimari kararlar, build-vs-buy tartışmaları… Hepsinde son söz sende. Bu aşamada teknik derinliğin senin en büyük varlığın. Ama bir sonraki aşamaya geçtiğinde, bu varlık yük haline gelebilir.

50 Kişilik Ekipte CTO: Orkestra Şefi

Semah’ta bir güzellik vardır: Her dönüş eden kişi kendi ekseninde döner, ama bütün hareket birlikte ilerler. Bireysel ifade var, ama kolektif uyum da var. Kimse kendi başına dans etmiyor, kimse de başkasının hareketini taklit etmiyor. Herkes kendi rolünü biliyor, bütün ise hepsinin toplamından büyük.

Elli kişilik bir teknoloji ekibini yönetmek tam olarak bu. Ve bu noktada CTO’nun rolü kökten değişiyor.

Artık en kritik pull request’i sen atmıyorsun. Artık en karmaşık bug’ı sen çözmüyorsun. Hatta belki haftalardır IDE’ni açmamışsın. Ve bu tamamen normal.

Çünkü bu aşamada senin “ürünün” kod değil, ekip. Senin commit’lerin merge request’ler değil, kararlar. Senin deploy’ların feature’lar değil, süreçler.

Bir ajans kurduğum günleri düşünüyorum. Başlangıçta her projenin her satırına dokunurdum. Gece yarıları production hatalarını kovalardım. Sonra ekip büyüdü. Beş kişi olduk, on kişi olduk. Ve bir gün fark ettim: En çok değer kattığım anlar, kod yazdığım anlar değildi. Bir junior developer’a mimari bir kararın “neden”ini anlattığım, iki takım arasındaki teknik çatışmayı çözdüğüm, ya da müşteriye teknik borç kavramını iş diliyle tercüme ettiğim anlardı. Dağıtık sistemlerde veri bütünlüğü gibi derin teknik konuları iş diline çevirmeyi öğrenmek, bu aşamada kazanılan en değerli becerilerden biri.

Bu geçiş kolay değil. Özellikle “yaparak öğrenmiş” insanlar için. Klavyeden uzaklaşmak, kontrolü kaybetmek gibi hissedebilir. Ama gerçekte tam tersini yapıyorsun: Kontrolü çoğaltıyorsun. Senin bilgini taşıyan on kişi, senin bilginle sınırlı bir kişiden her zaman daha güçlü.

Bu aşamada günlük rutin nasıl görünüyor?

Sabah: Slack’teki mesajları tarayarak başlarsın. Blocker var mı? Takımlar arası bir bağımlılık mı tıkanmış? Bir mimari karar mı bekliyor? Kahveni alır, standup’a katılırsın. Ama artık “dün ne yaptım” anlatmak için değil, engelleri kaldırmak için.

Öğleden sonra: Müşteri toplantıları, bütçe planlamaları, sprint retrospective’leri. Bir takımla teknik borç stratejisini konuşur, diğer takımla yeni feature’ın mimari yaklaşımını tartışırsın. PR review yaparsın, ama her PR’ı değil, stratejik olanları. Mimariyi etkileyen, precedent oluşturan kararları.

Akşam: Roadmap. Gelecek çeyreğin teknoloji planı. Hangi yatırımlar yapılacak, hangi borçlar ödenecek, hangi yetenekler eklenecek.

Bu aşamadaki en büyük tuzak: Kod yazmayı özlemek. “Şu PR’ı ben hızlıca yapıversem” düşüncesi her gün gelecek. Ve bazen haklı olacak, gerçekten daha hızlı yapabilirsin. Ama her “ben yapayım” dediğinde, birine öğrenme fırsatı vermemiş oluyorsun. Ve altı ay sonra aynı şeyi söylüyorsun, çünkü o kişi hâlâ öğrenemedi.

Bu aşamada CTO’nun anahtar becerisi insan yönetimi. Doğru insanları doğru rollere koymak. Teknik ve yönetsel arasındaki dengeyi kurmak. Delegasyonu bir zafiyet değil, bir çarpan olarak görmek.

Bir şeyi daha eklemek gerekiyor: Bu geçiş sırasında CTO’nun en zor savaşı ekiple değil, kendiyle. Yıllarca “değerimi ürettiğim kodla ölçüyordum” diye düşünmüş biri için, bir gün sonunda hiçbir satır kod yazmamış olmak tuhaf bir boşluk yaratıyor. GitHub contribution grafiğin soluklaşıyor. Stack Overflow’da artık cevap yazmıyorsun. Ve içinden bir ses “artık üretmiyorum” diyor.

Ama üretiyorsun. Sadece ürünün değişti. Artık ürettiğin şey, üretebilen insanlar. Ve bu, herhangi bir pull request’ten daha değerli bir çıktı.

Avrupa’da bir enerji şirketinde CRM ekiplerini yönetirken bunu net gördüm. Ekipteki en genç mühendis, benim bir yıl önce pair programming’de gösterdiğim bir pattern’ı kullanarak, müşterinin en kritik entegrasyon sorununu çözmüştü. O an fark ettim: En iyi kodum, başkasının elinden çıkan koddu.

500+ Kişide CTO: Haritacı

Bu ölçekte CTO artık tamamen stratejik bir rol. Günlük hayatta tek satır kod yok. Hatta belki aylardır terminal açmamışsın. Ve bu tamamen doğru.

Çünkü bu aşamada senin görevin, şirketin teknoloji vizyonunu belirlemek ve bunu iş stratejisiyle hizalamak. Board toplantılarında beş yıllık teknoloji yol haritasını sunuyorsun. VP of Engineering’lerle organizasyon yapısını tasarlıyorsun. Büyük teknoloji yatırım kararlarını veriyorsun: cloud migration, platform değişiklikleri, build-vs-buy kararları.

Bu aşamada senin “kodun” farklı bir dilde yazılıyor: Strateji belgeleri, organizasyon şemaları, teknoloji radar’ları, vendor anlaşmaları. Çıktın artık commit değil, yön.

Ama burada da bir tuzak var: Teknik kopuş. Kod yazmayı bırakmak doğru, ama teknolojiyi takip etmeyi bırakmak felaket. Bu ölçekteki CTO’lar genellikle iki yoldan biriyle teknik zekalığını korur: Ya kişisel projelerde deneyler yapar, ya da ekipteki en teknik insanlarla düzenli deep-dive seansları düzenler. İkisi de geçerli. Hiçbirini yapmamak, üç yıl sonra board toplantısında teknik sorulara cevap veremeyen bir “eski mühendis” olmak demek.

Bu aşamada CTO’nun odak noktası: Şirketin kaynaklarını doğru yere yönlendirmek. On farklı takım, yüzlerce mühendis, düzinelerce proje var. Hangisi stratejik, hangisi taktik? Hangi teknik borç şimdi ödenmeli, hangisi bekleyebilir? Hangi teknoloji trendi gerçek, hangisi hype? Bu soruları cevaplayabilmek için hem iş tarafını hem teknoloji tarafını derinlemesine anlamak gerekiyor.

Ve burada ilginç bir paradoks ortaya çıkıyor: Bu ölçekte CTO’nun en güçlü silahı, teknik bilgisi değil, tercüme yeteneği. Board üyelerine teknik borcu anlatabilen, mühendislere iş stratejisini açıklayabilen, müşteri tarafındaki acıyı teknik roadmap’e çevirebilen bir tercüman. İki dünya arasında köprü kuran kişi. CFO’ya “neden bu refactoring’e yatırım yapmalıyız?” sorusunu müşteri kaybı rakamlarıyla cevaplayan, mühendislere “neden bu feature’ı erteliyoruz?” sorusunu pazar verisiyle açıklayan biri.

Gerald Weinberg’in bir sözü var: “Ne kadar teknik görünürse görünsün, sonuçta her şey bir insan problemidir.” Bu ölçekte bu söz altın değerinde. Teknoloji kararları artık sadece “hangi framework?” sorusu değil, “bu karar organizasyonu nasıl etkiler?” sorusu. Bir platform migration’ı sadece teknik bir proje değil, yüzlerce insanın iş yapış şeklini değiştiren bir dönüşüm. Mattermost’tan Matrix’e geçiş sürecimiz bile küçük bir ekipte ciddi bir karar süreciydi; yüzlerce kişilik bir yapıda bu kararların ağırlığını hayal edin.

AI Çağında CTO: Yeni Bir Denklem

Kurtuluş Savaşı’nda Anadolu’nun durumu şuydu: Sınırlı insan kaynağı, sınırlı cephane, sınırlı zaman. Ama bu kısıtlılıklar stratejik zekayı doğurdu. Her kaynağı on katı verimle kullanmak zorundaydılar. Ve başardılar.

AI çağında CTO’nun durumu buna benziyor. Elindeki kaynaklar aynı, ama her birinin çarpanı değişti. AI’ın yazılım dünyasını nasıl dönüştürdüğünü daha önce detaylıca yazmıştım, burada o dönüşümün CTO rolüne etkisine odaklanacağım.

Bir mühendis artık AI destekli araçlarla eskisinin iki-üç katı hızında kod üretebiliyor. Ama bu, daha az mühendise ihtiyaç var demek değil, daha farklı mühendislere ihtiyaç var demek. AI’ın ürettiği kodu değerlendirebilen, yönlendirebilen, entegre edebilen insanlara.

CTO için bu ne anlama geliyor?

Birincisi, “kod yazma” tanımı değişti. Artık her satırı elin yazmak zorunda değilsin. Ama hangi satırların yazılması gerektiğini bilmek, AI’ın ürettiği kodun kalitesini değerlendirebilmek, ve AI’ı doğru yönlendirebilmek… Bunlar yeni “teknik yetkinlik” tanımının parçaları.

İkincisi, ekip yapısı değişiyor. AI agent’lar artık basit görevleri üstlenebiliyor. Bu, CTO’nun ekip planlamasını tamamen yeniden düşünmesi gerektiği anlamına geliyor. Hangi görevler AI’a devredilecek? Hangi roller dönüşecek? Hangi yeni roller ortaya çıkacak?

Üçüncüsü, ve belki en önemlisi, karar verme hızı arttı. AI sayesinde prototipleme, test etme, iterasyon döngüleri kısaldı. Bu da CTO’nun daha hızlı karar vermesi, daha hızlı yön değiştirmesi, daha hızlı deneyler yapması anlamına geliyor. Stratejiyle taktik arasındaki mesafe daraldı.

Bir InsurTech ürünü geliştirirken bunu bizzat yaşıyorum. AI agent’ları mimari kararların hızlı prototiplenmesinde kullanıyorum. Bir fikir geldiğinde, eskiden “bunu iki haftalık sprint’e alalım” derdik. Şimdi birkaç saat içinde bir proof-of-concept çıkarabiliyoruz. Bu, CTO’nun “deneme maliyetini” dramatik olarak düşürdü.

Ama dikkat: AI bir araç, bir strateji değil. “Biz AI kullanıyoruz” demek, “biz bilgisayar kullanıyoruz” demek kadar boş bir ifade haline geliyor. Önemli olan AI’ı nerede ve nasıl kullandığın. Ve bu kararı verecek olan hâlâ insan, hâlâ CTO.

AI çağında CTO’nun yeni bir sorumluluğu daha var: Ekibini AI ile çalışmaya hazırlamak. Bu sadece “şu tool’u kullanın” demek değil. Mühendislerin AI çıktısını kritik gözle değerlendirebilmesini sağlamak. AI’ın hata yapabileceği alanları belirlemek. Ve en önemlisi, AI’ın “kolay görünen ama aslında karmaşık olan” işleri basitleştirmesine izin vermeyecek bir mühendislik kültürü oluşturmak. Çünkü AI, “çalışan kod” üretmekte harika. Ama “doğru kod” üretmek hâlâ insan kararı gerektiriyor.

Peki Ne Zaman Klavyeye Dokunmalı?

Buraya kadar bir spektrum çizdik: Küçük ekipte CTO kod yazar, büyük ekipte strateji yapar. Ama gerçek hayat bu kadar temiz değil. Elli kişilik bir ekibin CTO’su da bazen kod yazabilir. Beş yüz kişilik bir yapının CTO’su da bazen terminal açabilir.

Soru “yazmalı mı yazmamalı mı?” değil. Soru: “Neden yazıyorum?”

Kendi pratiğimden yola çıkarak birkaç “ne zaman evet, ne zaman hayır” kuralı geliştirdim:

Evet, klavyeye dokun:

• Kriz anlarında. Production çöktüyse ve sen o sistemin mimarisini en iyi bilen kişiysen, araya girmek sorumluluktur. Ama kriz bittikten sonra soru şu olmalı: “Bir dahaki sefere bensiz çözülebilir mi?”

• Prototip aşamasında. Yeni bir mimari yaklaşımı, yeni bir teknoloji entegrasyonunu kendi elinle denemek, karar kaliteni artırır. Bunu başkasına delege ettiğinde arada bir çeviri katmanı oluyor. Bazen direkt denemek daha hızlı ve daha doğru. Ama prototip ile ürün arasındaki ölümcül vadiyi unutma: prototip kanıtlamak içindir, ürün değildir.

• Öğretmek için. Pair programming seansında kod yazıyorsan, bu “ben yapayım daha hızlı olur” değil, bilgi transferi. Bu geçerli.

• Kendi ürünlerinde. Side project’lerde, indie maker projelerinde, kişisel deneylerde. Teknik kaslarını canlı tutmak için bu alan her zaman açık.

Hayır, klavyeyi bırak:

• “Ben daha hızlı yaparım” diye düşünüyorsan. Bu cümle, delege edemediğinin ve ekibine yatırım yapmadığının itirafıdır.

• Feature development yapıyorsan. CTO’nun sprint backlog’unda kendi task’ı varsa, ya kadro eksik ya da önceliklerin karışmış.

• Ego tatmini içinse. “Hâlâ kod yazabiliyorum” ispatı, ekibin seni saygıyla dinlemesi için gerekli bir şey değil. Ekip, doğru kararlar verdiğin için seni dinler. Son commit’in tarihi değil, son kararının kalitesi önemli.

• Bottleneck oluyorsan. Senin review’ın olmadan merge yapılamıyorsa, senin yazdığın kodu kimse anlayamıyorsa, senin approve’un olmadan deploy çıkamıyorsa… Sorun sensin.

Bu kuralların özeti şu: Kod yazmak bir araç, bir kimlik değil. CTO’nun kimliği “kod yazan kişi” değil, “doğru kararlar veren kişi” olmalı. Bazen doğru karar kod yazmak, çoğu zaman değil.

Bir de şunu eklemek istiyorum: Bu kurallar statik değil. Aynı kişi, aynı şirkette, farklı dönemlerde farklı cevaplar verebilir. Yeni bir ürün hattı açılıyorsa, CTO birkaç haftalığına prototip moduna geçebilir. Büyük bir organizasyon değişikliği yapılıyorsa, aylarca kod yazmayabilir. Esneklik, bu rolün doğasında var.

Jovan Cicmil’in bir makalesi var: Bir startup’ta CTO’nun aslında ChatGPT olduğunu keşfetme hikayesi. Hikaye şok edici ama öğretici: Teknik liderlik, unvanla ya da araçla değil, karar kalitesiyle ölçülür. Kararları kimin verdiği, hangi araçla verdiği değil, kararların doğruluğu ve zamanlaması önemli.

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

Bir şirketin teknoloji kültürü, CTO’nun en kalıcı kodu. Framework’ler değişir, diller evrilir, mimari kararlar refactor edilir. Ama ekibin nasıl karar verdiği, hataları nasıl karşıladığı, bilgiyi nasıl paylaştığı… Bu “kod” yıllarca çalışmaya devam eder.

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

• Blameless postmortem kültürü. Hata yapan kişi değil, hataya izin veren sistem sorgulanıyor.
• Teknik kararların şeffaf belgelenmesi. ADR’ler, RFC’ler, teknik blog yazıları.
• Junior’ların güvenle soru sorabildiği bir ortam. “Aptal soru yoktur” lafı duvarda değil, pratikte.
• Teknik borcun iş diline çevrilmesi. “Bunu refactor etmeliyiz” yerine “bu, müşteri şikayetlerinin %30’unun kaynağı.”
• Deney kültürü. Başarısızlığın cezalandırılmadığı, öğrenmenin ödüllendirildiği bir ortam.

Bunların hiçbiri tek satır kod gerektirmiyor. Ama hepsi mühendislik disiplini gerektiriyor. Empati gerektiriyor. Sabır gerektiriyor. Ve paradoks olarak, teknik derinlik gerektiriyor, çünkü bu kültürü kurabilmek için teknolojiyi, mühendisliği, yazılım geliştirme sürecini derinlemesine anlamış olmak lazım.

CTO’nun en iyi kodu, çalışanların fark etmediği kod gibidir. Altyapı gibi görünmez ama her şeyi ayakta tutar. Doğru insanları doğru yere koymak, doğru kararları doğru zamanda almak, doğru kültürü sessizce inşa etmek… Bunlar compile error vermeyen ama şirketi ayakta tutan commit’ler.

Kendi ajansımı kurduğum günlerden farklı sektörlerde ekipler yönettiğim zamanlara kadar, her geçişte bir şeyi daha net gördüm: En iyi teknoloji liderleri, en çok kod yazan değil, en iyi kararları veren kişiler. Ve en iyi kararlar, teknik derinlik ile iş anlayışının kesiştiği noktada doğuyor.

Bir güvenlik şirketinde yazılım ekibini yönetirken, teknik olarak en parlak mühendisimiz vardı. Her problemi tek başına çözebilirdi. Ama ekip büyüdüğünde, o “her şeyi ben yaparım” refleksi takımı felç etti. Hiç kimse inisiyatif alamıyordu çünkü “zaten o yapacak” beklentisi yerleşmişti. CTO’nun görevi, o kişiyi durdurmak değil, o kişinin bilgisini çoğaltacak mekanizmayı kurmaktı. Code review standartları, pair programming rutinleri, teknik dokümantasyon alışkanlıkları… Bunlar o “süper mühendis”in bilgisini on kişiye yaydı.

İşte CTO’nun asıl kodu bu: Bilgiyi çoğaltan, kararları hızlandıran, hataları öğrenmeye çeviren sistemler kurmak.

Yanlış Sorudan Doğru Cevaba

“CTO kod yazmalı mı?” sorusuyla başladık. Umarım bu noktada bu sorunun ne kadar eksik olduğu ortaya çıkmıştır.

Doğru soru tek bir soru değil, bir soru dizisi:

• Şirketin hangi aşamasındayım?
• Ekibimin bana en çok ihtiyaç duyduğu alan neresi?
• Kod yazarak mı yoksa başka bir şekilde mi daha fazla değer üretiyorum?
• Bugün yazdığım kod, yarın başka birinin yazabileceği bir kod mu?
• Kod yazma motivasyonum ekibin ihtiyacı mı, kendi ihtiyacım mı?

Bu soruların cevabı kişiden kişiye, şirketten şirkete, hatta aydan aya değişebilir. Ve bu tamamen normal.

CTO rolünün güzelliği de zaten burada. Sabit bir iş tanımı yok. Sabit bir “doğru” yok. Tek sabit olan şey, sürekli bir dönüşüm. Baş aşçıdan orkestra şefine, orkestra şefinden haritacıya. Ve bu dönüşümün her aşamasında, “doğru olan nedir?” sorusunu tekrar tekrar sormak.

LinkedIn’deki tartışmaya geri dönecek olursak: İki taraf da haklı, iki taraf da haksız. Çünkü sorunun kendisi bağlamsız. Bağlam olmadan cevap olmaz. Ve bağlamı en iyi bilen kişi, o koltuğa oturan CTO’nun kendisi.

Hakan Erdogan’ın startup dinamikleri üzerine yazdığı bir yazıda güzel bir tespit var: CTO rolü, şirketin büyüme aşamalarıyla birlikte sürekli yeniden tanımlanması gereken bir rol. Bugün doğru olan şey, altı ay sonra yanlış olabilir. Ve bu belirsizlikle barış içinde yaşayabilmek, belki de CTO’nun en önemli becerisi.

Umut Gökbayrak da benzer bir noktaya parmak basıyor: CTO’nun kod yazıp yazmaması, o kişinin kapasitesiyle değil, şirketin ihtiyaçlarıyla belirlenmeliydi. Ego’yu bir kenara bırakıp “şu an en büyük darboğaz nerede?” sorusunu sorabilmek, teknik zekadan daha kıymetli bir yetkinlik.

Sonuçta CTO’nun asıl görevi ne kod yazmak ne de kod yazmamak. Asıl görev, her gün “bugün en büyük etkiyi nerede yaratırım?” sorusunu dürüstçe cevaplayabilmek. Bazen cevap bir terminal penceresinde, çoğu zaman bir beyaz tahtanın önünde, ve her zaman insanların arasında.

Ve belki de en önemlisi: Bu soruyu sormayı hiç bırakmamak. Rahat bir rutine yerleşip “benim işim bu” demenin cazibesi büyük. Ama teknoloji durmuyor, şirket durmuyor, pazar durmuyor. Dolayısıyla CTO da durmamalı. Her çeyrekte, her büyük milestone’da, her kriz sonrasında bu soruyu yeniden sormak, “bugün en büyük etkiyi nerede yaratırım?”, CTO’nun kendine yazacağı en önemli unit test.

Görseller Nano Banana Pro ile üretilmiştir.