Startup CTO's Handbook - Startup CTO'lar için El Kitabı
(github.com/ZachGoldberg)- Startup CTO's Handbook güncel kitap içeriğini sunuyor ve ana metin Markdown olarak görüntülenebiliyor
- Kitap Amazon ve Audible üzerinden satın alınabiliyor
- En güncel Markdown sürümünün PDF olarak render edilmiş bağlantısı şu anda Coming Soon durumunda; özgün taslak ise şu anda eski bir sürüm olarak Google doc üzerinde bulunuyor
- Eklemelerin, değişikliklerin, önerilerin ve eleştirilerin gelecekteki baskılara yansıtılması için issue ve pull request katkıları teşvik ediliyor
- Lisans; yeniden satış yapılmaması, yazar adı ve telif atfının korunması ve sonraki sürümlerin benzer veya aynı lisansla yayımlanması koşuluyla kopyalama, değiştirme ve yeniden dağıtıma izin veriyor
1 yorum
Hacker News yorumları
Katıldığım noktalar kesinlikle var. Örneğin tüm toplantıların kaydedilmesi fikrini destekliyorum. Ama performans yönetimi[0] gibi kısımlarda kişisel olarak katılmadığım çok şey de var
Bunu ille de bir eleştiri olarak söylemiyorum; daha çok, her problem alanında yaklaşımın ve liderlik tarzının farklı olabileceğini kastediyorum. Bu rehberin dokunulmaz bir şey gibi alınmamasını umarım. Buradaki içerik kendi deneyiminizle örtüşmüyorsa, kendi deneyiminize daha çok güvenmenizi öneririm
[0] https://twitter.com/bcantrill/status/1216491216356823040
CTO olarak bunu baskı oluşturmadan nasıl isteyebilirsiniz ki?
Yine de pratikte gerçek teknik seviye farkları sık görülüyor ve yöneticinin koçluk rolü üstlenmesinin birinin gelişimini ve performansını daha hızlı artırabileceğini düşünüyorum
Karşı taraf, performansın gelecekte nasıl iyileştirileceğine dair ileri dönük performans yönetiminden söz ediyor. Ama çoğu şirkette performans değerlendirmesi, ücret ve terfi dağıtımı sürecinde geçmiş performansın sıralandığı geriye dönük değerlendirmeye daha yakın
İleri dönük süreç harika ama sonuçta bir miktar geçmiş performans derecelendirmesi de gerekiyor
Yazarla iki şirkette birlikte çalışma fırsatım oldu ve burada yazanların gerçekten hayata geçirildiğinde ne kadar büyük fark yarattığını anlatmak zor
Etkisi yalnızca ürün veya mühendislikle sınırlı kalmıyor, tüm organizasyona yayılıyor. Her sistem ya da öneri eninde sonunda kendi organizasyonunuza uyarlanmalı elbette ama Zach’in öğrettiği yaklaşımı mümkün olduğunca çok kullanmanızı tavsiye ederim
Toplantı kaydını seven taraftayım. Ekip karşılıklı suçlama moduna girdiğinde kanıt olsun diye değil; toplantıları ve tartışmaları tekrar izleyebilmek gerçekten çok iyi
Önemli tartışmalarda veya hizalanma toplantılarında ciddi zihinsel kapasite harcamam gerekiyorsa, konuya odaklanırken aynı anda not almak ve her şeyi hatırlamak zor oluyor. Kayıt olduğunu bilmek, toplantı sırasında tamamen odaklanmama, iyi sorular sormama ve varsayımları test etmeme imkân veriyor
Ertesi gün görüşmeyi tekrar dinleyip durdurabiliyor, 2x veya 3x hızda izleyebiliyor, kişisel notlar çıkarabiliyor, toplantı notları ya da kurum içi özet yazabiliyor, düşünce ayrılıklarını fark edebiliyor ya da kendi programıma göre AI not alma araçlarını çalıştırabiliyorum
Birinin hasta olması, kayınvalidesini havaalanından alması gerekmesi, aynı anda başka bir toplantısının olması ya da önemli bir hizalanma toplantısından bir hafta sonra ekibe katılması gibi durumlarda da yardımcı oluyor. Toplantı önemsizse zaten görmezden gelirsiniz; makul bir otomatik silme politikası koyarsınız, olur biter
İnsanların gerçekten girilmemesi gereken yerleri gizlice kurcalamak için zaman harcadığını da sanmıyorum; bu yüzden bunu büyük bir sorun olarak görmüyorum
Ekip toplantıları ayrıca konuşma konusunda daha özgüvenli olan kişilere doğru kayabilir. Bu da özellikle yeni katılanlar veya ana dili farklı olan kişiler için dezavantaj yaratır
Toplantılara karşı değilim. Yazıdan ziyade sesli iletişimi çok daha fazla tercih eden insanlar var ve iyi ekipler her üyenin tercih ettiği çalışma biçimini barındırabilmeli
Ama önemli ve aynı zamanda katılımcıların yetkinliğine yüksek talep yükleyen bir ekip toplantısı varsa, bu bir toplantı olmamalı. Toplantı ancak tüm katılımcılar belirli bir konuşma için en iyi mecranın toplantı olduğuna karar verdiğinde yapılmalı
Toplantı, yangın hortumunun önünde oturmak gibidir; ayrıntıları kaçırırsınız
Toplantı kaydı ve arama kolaylığı nedeniyle Google Workspace’e geçtim. Örneğin kayıt doğrudan takvim etkinliğinin içine gömülü
Kaydedilecek kadar önemli olmayan bir toplantı muhtemelen yapılmaya da değmeyen bir toplantıdır
Ben şahsen başkalarından daha fazla saat çalışıyorum ama bu motivasyonel bir mesele değil. Önemli toplantılar çakışabiliyor ve yalnızca toplantı notlarını okumak birçok nüansı kaçırıyor. Üstelik insanlar toplantı notlarını da pek okumuyor
Ama toplantılar kaydedildiğinde, notları hızlıca ve düzgün biçimde gözden geçirmek çok daha kolay oluyor; bu yüzden toplantı kaydını oldukça güçlü şekilde savunuyorum
Gerçek nedeni ne kadar hızlı anlarsanız, sorunu da o kadar hızlı düzeltirsiniz. Bu kavramı ve şirkete nasıl uygulandığını anlamak için eski Navy SEAL üyeleri Jocko Willink ve Leif Babin’in Extreme Ownership kitabını şiddetle tavsiye ederim
Asenkron toplantı katılımı, yukarıda söylenen nedenlerle harika. Toplantıdaki bilgiyi aranabilir hâle getiriyor. Artık toplantılara doğal dil işleme ile altyazı eklenebiliyor ve içerik LLM’ler tarafından bulunabilir oluyor
Şu anda kurum içi chatbot’u Confluence içeriğiyle eğitiyoruz ve bunu kaydedilmiş toplantı içeriklerine doğru genişletmeye çalışıyoruz
Biraz reklam yapayım: farklı kaynaklardan gelen girdileri içgörü ve görevlere dönüştüren bir araç olan https://designpro.ai geliştiriyorum. Bunu görüşme dökümlerinden içgörü çıkarmak için kullandım ve gerçekten işe yaradığını biliyorum
Kısa süre önce CTO oldum ve en büyük zorluklardan biri CEO ile iletişim kurmak. Belki kitapta ele alınıyordur ama ben sadece dizine baktım
Son 8 aydır CEO bir hizalama toplantısı istemiyor, hiçbir şeyi planlamak istemiyor, vizyona liderlik etmek istemiyor ve sadece killer feature'lara odaklanmak istiyor
Kullanıcılarla test edilecek mockup ya da prototipler yapmayı da istemiyor; yapılacaksa da güzel olmaları gerektiğini söylüyor. Bir haftadan uzun süren işleri yapmak istemiyor ve verimli toplantıları da reddetti
Demek istediğim şu: kitapta olmayan şeyler tam da benim eksikliğini hissettiğim şeyler. Bu arada biz sadece 3 kurucu ortağız
CTO, CEO'nun “teknik sorumlusu”ydu; hatta CTO unvanını almasının nedeni, sadece onların içindeki en iyi ya da en önemli teknik kişi olmasıydı
Bunu duymak üzücü ama CEO'nun sizi havalı bir unvanı olan başka bir çalışan olarak görüyor olma ihtimalini düşünmeniz gerekiyor. Böyle bir zihniyette CEO açısından sizi kararlarına dahil etmek zaman kaybı gibi görünecektir
Marc'ın cevabını hâlâ kelimesi kelimesine hatırlıyorum. “Şüphen varsa, aslında şüphe etmene gerek yoktur”
Bunun internetteki rastgele bir yorumla ikna olunabilecek kadar küçük bir karar olmadığını biliyorum ama yine de söyleyeceğim: 8 ay geçmiş bile. Muhtemelen düzeltmek için denenebilecek her şeyi denemişsinizdir
Hâlâ denenmemiş ne kaldı? Mantıken burada ne olmasını bekliyorsunuz? Daha verimli bir yere kolayca geçebilecekken, hayatınızın ne kadarını daha buna yatırmayı planladığınızı düşünmeniz gerek
Ciddi konuşursak, şu an çarptığınız nokta bu işi zor yapan şeyin ta kendisi
Birincisi, diğer yöneticilerle 1:1 görüşmeler ayarlamayı deneyin. CEO dışında birlikte çalıştığınız başka yöneticiler varsa, içine girdiğiniz durum hakkında daha fazla bağlam edinebilirsiniz. İhtiyaçlarını anlarsanız daha geniş organizasyonun ihtiyaçlarını da görürsünüz
CEO istemese bile CEO'nun problemlerini ortadan kaldırmanız için işe alındınız. Yönetici ekibine uyum sağlama becerisi, yetkinliğinizi göstermenin en iyi yollarından biridir; bunun için gerekenler de tutarlılık, özen, açık fikirlilik ve gerçekten yardımcı olacak sorular sorma isteğidir
İkincisi, CEO ve yönetici ekibi düzenli olarak buluşuyorsa katılmayı isteyin; buluşmuyorlarsa bunu kendiniz planlamayı düşünün. İdeal olarak önce CEO dışındaki yöneticilerle hizalanmak daha iyi olur. CEO tüm toplantılara ya da çoğuna katılamasa bile, bu inisiyatifi takdir edecek ve size güven de oluşacaktır
Bunu zaten istemediğini söylediğiniz için, CEO üzerinde etkisi olan başka bir yönetici üzerinden dolaylı yoldan harekete geçmeniz gerekebilir
Üçüncüsü, CTO iseniz CEO'nun en azından ayrılmayı düşünüp düşünmediğinizi anlamak için bile sizinle belli ölçüde düzenli 1:1 görüşmeler isteme ihtimali yüksektir. Haftalık, iki haftada bir ya da aylık; CEO'nun takvimine uyan bir ritim bulun yeter
Bu görüşmenin amacı CEO ile hizalanmak ve iyi gittiğiniz alanlar ile geliştirmeniz gereken alanlar hakkında geri bildirim almaktır. Bunu ayarlayamıyorsanız, bunu başarılı olabileceğiniz bir ortam olarak görmüyorum ve ayrılmanızı tavsiye ederim
Bu görüşmeyi ayarlamak zorsa önce ilk iki yaklaşımı zorlayıp ilişki kurduktan sonra tekrar deneyin. Hangi sıklıkta olursa olsun, CEO ve diğer yöneticilerle düzenli zaman ayarlayamıyorsanız, fiilen CTO değilsinizdir ve ayrılmayı düşünmelisiniz
Bu fark hakkında burada yazmıştım: https://www.mooreds.com/wordpress/archives/2555
Ama plan eksikliği ve vizyonu ileri götürme eksikliği endişe verici. İkisi de erken aşama CEO rolünün temel parçalarıdır. Neden sadece bu kadar kısa vadeli şeylere odaklandığını biliyor musunuz? Yatırım toplamak ya da satış yapmak için bir MVP'yi zorla öne mi itiyor, yoksa gerçekten vizyonu mu yok? Ben olsam bunu eşeleyip nedeni anlamaya çalışırdım. Ya da başkalarının dediği gibi, ayrılmak da bir seçenek
CEO'ya gerekli kısa vadeli adımları netleştirip “tamam harika, yapacağımız şey bu” dediği aşamaya kadar gelebildiniz mi?
Yoksa siz SOC2 sertifikasını ilerletmeye çalışınca CEO'nun “daha değil” dediği ama satış sunumlarında “biz SOC2 sertifikası yolundayız” deme havalı aşamasında mısınız?
Merak etmeyin. Şizofren olan siz değilsiniz
Wikipedia, DevOps'u yazılım geliştirme ile BT operasyonlarını birleştiren bir uygulama pratiği olarak tanımlıyor; bunu “iş yazılımının geliştirici makinesi dışında da çalışmasını sağlamak için gereken her şey” diye çevirmek, özgün tanımdan biraz tuhaf biçimde farklı bir yorum gibi görünüyor
Özellikle DevOps uzmanı kısmı öyle
Bunu daha iyi aktaracak şekilde yeniden yazacağım
Burada adı geçen şirketlerin ya da kişilerin hiçbirini tanımıyorum. Başkaları biliyor mu merak ediyorum
Okumaya zaman ayırmadan önce söyleyeyim, zaten “CTO” denen kişilere karşı içgüdüsel bir şüphem var. Okumaya değer mi?
Hedef kitlenin, profesyonel deneyimi çok az ya da hiç yokken startup'ta teknik kurucu ortak olup CTO unvanını üstlenmiş kişiler olduğu anlaşılıyor
Son 10 yılda üç şirkette CTO oldum; belki artık yaşlandım ve sabrım azaldı ama başkalarının da dediği gibi, bu daha çok kurucu ortak olarak yeni CTO olmuş, üniversiteden yeni mezun kişilere yönelik bir kitap gibi görünüyor. Ben de böyle kişilere teknik danışmanlık veriyorum
Benim deneyimime göre bu rolde ne kadar uzun kalırsanız, Accelerate gibi kitaplardaki daha somut bilgileri o kadar çok arıyorsunuz
Sıkıcı teknoloji gerçekten önemlidir. Özel sektördeki startup’lar zaten başlı başına istikrarsız yapılarken, doğrulanmamış teknolojiyle riski neden daha da büyütesiniz?
Örneğin 2013 ile 2016 arasında, MongoDB’nin açıklaması zor bir şekilde fiilen varsayılan veritabanı haline geldiği bir dönem vardı. Startup’ların yaklaşık üçte birinin MySQL ya da Postgres’ten MongoDB’ye geçmiş gibi göründüğü bir dönemdi. Bu tam anlamıyla büyük bir kargaşa ve aptalca bir felaketti
Böyle bir durumda neden Mongo seçildiğini hayal etmek zor. Şema oluşturup güncellemek zorunda olmamak dışında, geliştirme sürecinin ilk birkaç gününü biraz hızlandırmasından başka bir faydası yok
Sorun şu ki veri karmaşıklaştığı ve BI gibi şeylere ihtiyaç duyulduğu anda, o ilk avantajı çok ağır bir faizle geri ödüyorsunuz
Zaten veri ilişkisel olmasa bile, Postgres’in JSON desteği Mongo’dan daha iyi çalışıyor
Bazı yeni teknolojiler kaybolur, bazıları kalır
Kariyerimin başlarında SQL parlak yeni teknolojiydi. Şirketin ağ veritabanlarını bırakıp SQL’e geçmesi için güçlü biçimde bastırdım ve sonuçlar çok iyiydi
Geleneksel C’ye kıyasla nesne yönelimli programlama için de aynı şey geçerliydi
Bazı teknolojiler ise sonunda vaat ettikleri seviyeye hiç ulaşamaz ve onları benimseyen organizasyonların ayağına pranga olur
LLM teknolojisini sorumlu biçimde devreye almak için fazla erken olan bir dönem de vardı. Ama yakında yönetim kurulunun neden devreye almadığınızı soracağı bir dönem gelecek. Harici kullanım senaryolarında belki, dahili kullanım senaryolarında ise kesinlikle böyle olabilir
CTO’nun zor görevlerinden biri de yeni teknolojiyi ne zaman devreye alacağına karar vermektir. Ne zaman sıkıcı teknolojinin şirket için en iyisi olduğunu, ne zaman erken aşama bir teknolojiyi içeri almanın makul olduğunu ve ne zaman yeni teknolojinin o kadar büyük bir hızlandırıcı haline geldiğini, bu yüzden mutlaka benimsenmesi gerektiğini değerlendirmek gerekir
CTO’yu teknoloji odaklı, insan odaklı ve dışa dönük olmak üzere üç türe ayırması ilginç
Çok erken aşamadaki bir startup bana CTO rolü öneriyor. Henüz bir ürün yok, sadece birkaç temel demo var ve pre-seed yatırım hazırlığındalar
Bu rolde en çok neyin gerekli olacağını merak ediyorum. Teknik CTO mu, insan odaklı CTO mu? İlk başta ürün geliştirmek gerekeceği için ağırlıkla teknik bir rol gibi geliyor. Ama ne zaman insan merkezli CTO’ya geçileceğini merak ediyorum. Konuya dair içgörüsü ya da deneyimi olan varsa duymak isterim
Esas olarak o rolü üstlenir, geri kalanını idare edersin; sonra o işler çok artar ya da yeterince önemli hale gelirse, diğer iki alandan birini veya daha fazlasını üstlenecek birini işe alırsın
Cevaplaması daha zor olan ikinci soru ise onların, yani diğer CXO’ların, senin ne olmanı istedikleri. Bu, ilk sorunun önüne geçebilir. Bazı durumlarda C’siz bir CTO olursun; yani ne yapacağı söylenen, gösteriş amaçlı demolara bakan ve işin “neden” kısmını duymayan bir teknik sorumludan ibaret kalırsın
“CTO tam olarak nedir” konusunda yer imlerime eklediğim birkaç bağlantı var
http://www.startuplessonslearned.com/2008/09/what-does-start...
https://www.allthingsdistributed.com/2007/07/the_different_c...
Ayrıca Camille Fournier’nin The Manager’s Path kitabını da tavsiye ederim
“Borcu proaktif şekilde geri ödemek, genel mühendislik sağlığı için gerekli bir yatırımdır” denmiş ama bazı teknik borçlar için geri ödemek yerine temerrüde düşmek toplamda daha ucuz olabilir
Tabii ürün yöneticisi tahsilata kalkışmadığı sürece
Ama belli bir ölçek ve karmaşıklığa sahip bir projenin teknik iflasa sürüklenmesi, ancak kitaptaki tavsiyelere uyulmadığında olur. Özellik çıkarmak uğruna teknik borç görmezden gelinirse, sürümler giderek zorlaşır ve hatalar da giderek sıklaşır
Kitabın yayımlanması kutlu olsun
Küçük startup CTO’luğu ve halka açık bir şirkette VPoE deneyimime dayanarak pratik fikirler paylaşmak için Opinionated Launch(https://opinionatedlaunch.com) yazıyorum
Yazmaya başlayınca konuların iki kola ayrıldığını fark ettim: yönetim-ekip-insan tarafı ve teknik taraf. Ben daha çok tutkuyla bağlı olduğum teknik tarafa odaklandım; kalan kısmı bir başkasının ele almasına sevindim