CTO kod yazmalı mı?

Öncelikle CTO denildiğinde ne anlaşıldığını tekrardan bir netleştirmemiz gerekiyor. Eğer şirketiniz henüz yolun çok başlarında bir startup ise, CTO denilen ünvan, genellikle ekipteki en kıdemli yazılımcıya verilen isimden ibarettir. Bu kişi, şirketin kurucu ortaklarından birisiyse tabii ki çok daha iyi olur.

Kurumsal bir şirketteyse durum oldukça farklıdır. CTO, genellikle profesyonel, beyaz yakalı bir çalışandır. Şirketin yaptığı işe bağlı olarak çoğunlukla yazılım kökenli olup, bazen de proje yönetimi veya sistem, nadiren de iş zekası, analiz disiplini kökenli olanlarına da rastlanır.

Şimdi sırasıyla bu iki durum için neler düşündüğümü aktarmaya çalışayım.

Startuplarda CTO kod yazmalı mı?

Bırakalım yazılım işlerini veya kod yazmayı da, hadi başka bir alandan örnek verelim. Mesela diyelim ki bir köfteci veya kebapçı açıyoruz. Dükkanı seçtik, masaları satın aldık dekorasyonu yaptık, sıra menüye geldi. Bu aşamada, “yemeğimin tadına bakamam, çünkü ben vejetarayanım” diyebilir misiniz? Ya da başka bir şekilde sormak gerekirse “vejetaryan köfteci” olur mu? Kulağa ne kadar saçma geliyor değil mi? Ürettiğiniz veya hizmetini sunduğunuz şeyin en alasıyla tadını almalı, eksiklerini bilmeli, yanınızda çalışan kişilere ilham olmanız gereken bir konumdayken, sunduğunuz hizmetin tüketicisi olmamak, hiç bir meslek için mantıklı değildir.

Yazılım işi için de durum farksız.

Startup, henüz pazarın dinamiklerine en uygun iş modelinin arayışında olan şirketlere verilen genel bir tanımdır. Bu kıvamdaki bir şirket, sürekli arayış içerisinde olmalıdır. Arayış demek, sürekli A/B testleri yapmak demek. Sürekli yeni kod yazmak ve sonuçlarını incelemek, duruma göre karar almak demek. Ya da belki, startup çok daha erken aşamadaysa ilk ürünü hazırlıyor da olabilirsiniz. Böyle bir durumda en kıdemli teknik kişi olan CTO’nun kod yazmaması düşünülemez.

Startup aşamasındaki bir şirkette, personel sayısı azdır. Örneğin CTO hariç 4–5 tane yazılımcının olduğu bir şirkette, ben kod yazmam diyerek kenarda oturan bir CTO’ya karşı ekip saygı beslemez. Yazılımcılar, çalıştıkları şirkette örnek alacakları lider profilleri görmek isterler. Çalışma motivasyonları para olduğu kadar, yeni bir şeyler öğrenmek, yani mesleki tatmindir. Bu tatmini de ekibine bu ebattaki bir şirkette ancak CTO sağlayabilir.

Bir startup CTO her zaman en güncel teknolojiye hakim olmayabilir ama yine de tedavülde olan belirli konularda bir konferans veya meetup’ta konuşma yapabilecek kıvamda uzmanlığı olmalıdır. Gerektiğinde ekibinden herhangi birisinin başladığı bir işi bitirebilecek, eksik kalan yerini kodlayabilecek bilgi birikimine de sahip olmalıdır.

CTO’lar her nedense genellikle arka plan (backend) yazılımcılarından olur. Bu kişiler ise nadiren önyüz (frontend) veya mobil teknolojilere tamamen hakimdir. Bir startup CTO’nun yine de “ben web veya mobil bilmiyorum” deme lüksü maalesef ki pek olmaz. En azından ekibindeki Swift veya Kotlin yazılımcısı ile muhabbet edebilecek kıvamda tecrübesi olması gereklidir.

Bir startup CTO’sunun sadece yazılımcı olması da genellikle yeterli gelmez. Biraz sistem ve ağ teknolojilerinden de anlaması gereklidir. NAT veya DMZ ne demek, SMTP protokolü nasıl çalışır, DNS nasıl konfigüre edilir, SSL sertifikaları nasıl alınır ve benzeri konularda bizzat mutfakta sahibi olmaları beklenecektir. Bunun yanısıra modern teknolojiler kullanan bir startup’ta CTO iseniz, Docker veya rkt gibi bir konteynır (container) teknolojisi kullanıyorsanız, Kubernetes gibi bir orkestrasyon ortamı kullanmayı düşünüyorsanız, mutlaka temel veya daha ileri seviyede işletim sistemi, sistem ve ağ bilgisine ihtiyaç duyacaksınız.

Bir startup CTO’nun, güvenlik konusunda da tecrübe sahibi olması beklenir. Hem yazdığı yazılımın güvenliği hem de temel seviyede de olsa sistem ve ağ güvenliği becerisinin olması gereklidir.

Sonuç olarak; bir startup CTO, sistem, güvenlik, network, veritabanları ve diğer becerilerinin yanısıra, hepsinden de önemlisi, kod yazabiliyor ve de “yazıyor” olmalıdır.

Elbette ki yazılımcı kökenli olmayan CTO’su olan istisnai startup’lar da vardır ama ben bu modelin uzun vadede işleyebileceğine tereddütle yaklaşıyorum.

Kurumsal şirketlerde CTO kod yazmalı mı?

Bu sorunun cevabını vermek, startup CTO’sundaki kadar kolay değil. Çünkü kurumsal şirketlerde CTO’lar tek tip olmuyor. Ürün kökenli olanları da var, proje veya sistem yönetimi kökenlisi de. Veritabanı yöneticilerinden tutun, iş zekası yöneticisi kökenli CTO’lar da gayet mümkün ve sıklıkla rastlanıyor. Bu durumda hepsi tek tipmiş gibi bir kesin yargıya varmak maalesef bizi yanıltır. Bunun yerine bir kaç varsayım ve genellemeye yer vermekle yetineceğim.

Kurumsal şirketlerde CTO’ların vazifesi, genellikle ekibinin icra kurulu ve/veya yönetim kurulu nezdinde temsili ve alınan kararların belirlenen bütçe çerçevesinde uygulanmasının bir şekilde sağlanması olacaktır. Bazı şirketler gördüm, CTO’nun gününün 8 saatinin 6’sı üst düzey toplantılar ile geçer. Bu tarz şirketlerde CTO, operasyonel vazifelerini delege edebileceği, vasıflı kişiler yetiştirmiş veya işe almış olmak zorundadır. Yaptığı toplantılarda alınan kararları bu kişiler aracılığıyla ekibine iletir ve uygulanmasını izler, denetler. Bu tarz şirketlerde CTO’nun kod yazması zaten pratikte mümkün değildir.

Eğer şirketiniz artık oturmuş bir ürün ve servis gamına sahipse, sıfırdan bir yazılım yazmak yerine, ağırlıklı olarak destek faaliyeti de sürdürülüyor olabilir. Ya da dışarıdan hazır alınmış bir paket yazılımın sürdürülmesinden sorumlu da olabilirsiniz. Bu iki durumda da gündelik hayatınızda kod yazmanın yer alması beklenemez.

Ben kurumsal şirketlerde CTO’ vazifesi yaparken kod yazmaya başladım mı derseniz? Evet denedim. Maalesef ki iyi sonuçlanmadı. Neden derseniz?

Takımı yavaşlatmak

Kurumsal bir şirketin CTO’sunun gününü daha önceden planlaması bazen mümkün olmaz. Her an beklenmeyen bir toplantı veya kriz ile mücadele etmek işimizin vazgeçilmez bir parçasıdır. Böyle bir durumda ekibiniz, işine devam edebilmek için Jira’da sizin üzerinize açılmış görevin bitmesini beklemek zorunda kalır. Bazen ben de 2 saatlik basit bir iş için tüm takımın Sprint’i kapatamamalarına yol açtım. Bu beni mahçup ettiği kadar, ekibi de mağdur etti ve onları yavaşlattı.

Karizmayı çizmek

Ekibinizde yer alan kişiler, ve özellikle yeni mezunlar, sizi bir idol olarak görme eğilimi gösterirler. Mesleğin 20. yılında da basit bir hata yapmanın ne kadar doğal olduğunu bazen de unuturlar. Yazdığınız koddaki hatayı 2 yıllık bir mühendisin bulması ekipte garip bir his bırakır. Açık konuşmak gerekirse bu konu, benim en az umursadıklarımdan bir tanesi. Evet tüm içtenliğimle itiraf ediyorum. “24 yıldır kod yazıyorum ve bu güne kadar hatasız tek bir program dahi yazmadım. Sorunsuzmuş gibi görünenler, sadece henüz hataları keşfedilmemiş olanlardır”. Ekibinizdeki insanların kıdemli veya değil, birbirini eleştirebilmesi ve daha ileriye götürebilmesi kadar güzel şey olmamasına rağmen, maalesef ki, takıma her yeni katılan kişiye CTO’nun da insan olduğu ve hata yapabileceği eğitimini vermek de oldukça can sıkıcı.

Ekibin kodunuzun üzerine kod yazmak istememesi

Karizmayı çizmeme epey uğraşıp bir kod yazdınız ve merkezi kod repo’suna kodu gönderdiniz. Aradan aylar geçti, bir kod gözden geçirme (code review) etkinliği esnasında aylar önce yazdığınız kodun çok benzerini aynı uygulamada bambaşka bir yerde gördünüz. Kodun neden tekrar edildiğini sordunuz, kimse mantıklı bir açıklama getiremedi.

İşin aslı; kodunuzun orada olduğunu biliyorlar ama CTO’nun kodunu değiştirmekten çekiniyorlar. Her ne kadar uğraştıysam bu önyargıyı kırmakta istediğim başarıyı gösteremedim. “Ben de hata yapabilirim, hatta sıklıkla yapıyorum” dedim olmadı. “O anda acelem olmuş olabilir, idareten yazmışımdır, alın siz daha iyisini yapın” dedim yine de olmadı. Bu sorun Türkiye gibi aile içi otoritenin halen baskın olduğu kültürlerde karşılaşılan bir sorun. Aile büyüklerine karşı olan saygının bir yansıması olarak, kodumun üzerine değişiklik yapmayı saygısızlık olarak algılıyorlar. Önüne geçilemez mi? Elbette ki geçilir. Ama emek vermeniz lazım.

Diğer vazifelerinizi ihmal etme riski

Kurumsal bir şirkette CTO’nun en önemli vazifelerinden bir tanesi, ekibinin şirket içinde pazarlamasını yapmaktır. Böyle söyleyince kulağa çok hoş gelmediğinin farkındayım ama gerçekten de icra kurulu ve yönetim kurulu nezdinde teknik ekiplerin pazarlamasını yapmak elbette ki sizin vazifeniz. Şirketin en çok bütçe harcayan ekiplerinden birisi olarak, işlerin yolunda olduğunu, harcanan paraların şirkete büyük katkılar yaptığını siz anlatmazsanız kim anlatacak? Siz bu pazarlama aktivitelerini ihmal eder ve tüm gün kod yazarsanız, ekibinizin üzerindeki baskı gün geçtikçe artacaktır. Siz de biliyorsunuz ki, kurumsal şirketlerde, teknoloji ekibinin müşteri ilişkisi içinde olduğu departmanlar oldukça talepkardır. Uzunca bir süre işlerin nasıl yürüdüğünü bilemediklerinde, endişelenecekler ve emin olun endişelerini siz yansıtmakta 1 dakika olsun tereddüt etmeyeceklerdir.

Uzun sözün kısası; ben az önce bahsettiğim dinamiklerin geçerli olduğu kurumsal şirketlerde artık kod yazmıyorum. Ama ekibin saygısını kazanabilmek adına da halen en az onlar kadar iyi kod yazabildiğimi de her fırsatta göstermekten çekinmiyorum. Bu nedenle arada sırada teknik oturumlarda IDE açıp kod yazıyorum veya kod gözden geçirme toplantılarında verdiğim örneklerle onların kalbini kazanıyorum. Güncel teknolojileri açık kaynak projelerimde takip ediyorum ve Github’da bunları cesurca sergiliyorum. Ekipteki arkadaşlarım kod yazabilen bir CTO’nun kendilerinin pazarlamasını hak ettikleri gibi yapmasından çok daha fazla memnun görünüyorlar.

Biliyorum ki işimin çok önemli bir kısmı, şirketin vizyonunu teknik olarak beslemek. Bunun için de gündelik operasyonel faaliyetlerden uzaklaşabildiğim ve “hayal kurabildiğim” zamanlara ihtiyacım var. Bu zamanları yaratabildiğim sürece, çok daha başarılı oluyorum.