- 4 yıl Google’da yazılım geliştirici olarak çalıştıktan sonra 1 Şubat’ta ayrılmasının arkasında, terfi değerlendirme yapısı ve tekrar tekrar durdurulan projeler nedeniyle kariyeri üzerindeki kontrol hissinin zayıflaması vardı
- Terfi, doğrudan bağlı olunan yönetici tarafından değil; adayı tanımayan üst düzey mühendis ve yöneticilerden oluşan bir komitenin promo packet’ı incelemesiyle kararlaştırılıyordu
- Eski pipeline’ları iyileştirme, hata düzeltme, test, dokümantasyon ve ekibe destek verme pratikte faydalıydı; ancak ölçülebilir etki olarak kayda geçmesi zor olduğu için ilk terfi değerlendirmesinde dezavantaj yarattı
- Daha sonra yalnızca terfiye yardımcı olacak işleri seçince en yüksek performans notu olan Superb’i aldı; ancak proje iptalleri ve ekip yeniden yerleştirmeleri tekrarlanınca terfide yine başarısız oldu
- Indie Hackers aracılığıyla küçük, gelir getiren yazılım işleri alternatifini keşfetti ve KetoHub, Sia tabanlı bir iş ve yazıdan gelir elde etmeyi birkaçer ay denemeye karar verdi
Google’daki İlk 2 Yıl ve Terfi Beklentisi
- İşe girdikten sonraki ilk 2 yılda, şirkette uzun süre kalacağını düşünecek kadar memnundu
- Etrafında çok yetenekli mühendisler vardı; gelişmiş geliştirme araçları ve ücretsiz yemek de sağlanıyordu
- Son performans değerlendirmesi Strongly Exceeds Expectations olmuştu ve yöneticisi ona bir sonraki seviye olan Senior Software Engineer terfisine yaklaştığını söylemişti
- Yöneticisi, zaten kıdemli seviyede çalışma yetkinliğine sahip olduğunu düşünüyordu; ancak bunu terfi komitesine kanıtlayacak uygun bir projeye ihtiyaç olduğunu söyledi
Google Terfi Süreci Nasıl İşliyordu
- Google’da doğrudan bağlı olunan yönetici, çalışanını doğrudan terfi ettiremez ve oy hakkına da sahip değildir
- Terfi kararı, adayı o gün ilk kez gören üst seviye yazılım mühendisleri ve yöneticilerden oluşan küçük bir komite tarafından verilir
- Aday bir promo packet hazırlayıp sunar
- Ekip arkadaşlarından tavsiye mektupları
- Yazdığı tasarım dokümanları
- Yaptığı işin neden terfiye uygun olduğunu açıklayan kısa bir yazı
- Komite, birden fazla adayın paketini birlikte inceler ve gün içinde terfi kararını verir
- Başta bu yöntemin önyargıyı ve şirket içi siyaseti azaltacağını, kod kalitesiyle mühendislik muhakemesini adil biçimde değerlendireceğini düşünüyordu
Eski Pipeline İyileştirmesinin Değerlendirmede İz Bırakmamasının Nedeni
- Başlıca sorumluluk alanı eski bir legacy data pipeline idi
- Yıllardır bakım modundaydı, ancak yük arttıkça baskı altına giriyordu
- Sessizce ölmesi veya hatalı çıktı üretmesi sık görülüyordu
- İlk tasarım dokümanından sonra dokümantasyon olmadığı için arıza teşhisi günler sürüyordu
- Pipeline’ı sağlıklı hale getirmek için çeşitli iyileştirmeler yaptı
- Onlarca hatayı düzeltti
- Hataların tekrar etmesini önlemek için otomatik testler yazdı
- Ölü kodları ve modern kütüphanelerle değiştirilebilecek binlerce satır kodu sildi
- Öğrendiklerini dokümante ederek bilginin yalnızca kişilerin zihninde kalmasını engelledi
- Terfi değerlendirmesinde bu işler nicelleştirilemeyen bir sorun olarak geri döndü
- Hataları buldukça toplam hata sayısı sanki artmış gibi görünüyordu
- Anormallikleri sessizce geçmek yerine hızlıca başarısız olacak şekilde değiştirince arıza metrikleri de yükseldi
- Geliştiricilerin arızaları onarma süresi ciddi biçimde azaldı, ancak bunu izleyen bir metrik yoktu
- Ekip arkadaşlarının yayınlama riskini azaltmak için kendi projelerini haftalar ya da aylar boyunca ertelediği de oldu
- Ekip için doğru karardı, ancak promo packet içinde etkileyici görünmüyordu
- Komiteye, ekip arkadaşının projesi daha fazla koordinasyon gerektiren önemli bir iş gibi; kendi işi ise kolayca durdurulabilecek bir iş gibi görünüyordu
- İlk terfi değerlendirmesinin sonucu, teknik karmaşıklıkla başa çıkabildiğine ve Google’a etkisine dair kanıtların yetersiz olduğu yönündeydi
Ret Sonrası Çalışma Biçimindeki Değişim
- İlk ret kararından sonra, aynı iyi işleri yapıp yalnızca daha iyi kayıt tutmasının yeterli olacağını düşündü
- Ekip çok sayıda yanlış alarm niteliğinde e-posta bildirimi alırken bile bunları hemen düzeltmedi; önce geçmiş kaydı oluşturmak için bildirim sıklığı metriği yaratmaya çalıştı
- Çünkü terfi zamanı bildirimlerin azaldığını gösteren bir grafik sunabilecekti
- Sonrasında atandığı proje terfi açısından avantajlı görünüyordu
- Google için önemli bir alan olan makine öğrenmesine büyük ölçüde dayanıyordu
- Yüzlerce çalışanın elle yaptığı işi otomatikleştiriyordu
- Junior bir geliştiriciye liderlik etmesi gerekiyordu; bu da genellikle terfi değerlendirmesinde puan kazandıran bir unsurdu
Yıl Sonu Hediyesi Olayı ve “İş İlişkisi” Algısı
- Google, uzun süredir devam eden gösterişli yıl sonu hediyesi geleneğini sonlandırdı ve hediye bütçesiyle düşük gelirli öğrenciler için Chromebook satın alarak manşetlere çıktı
- Bununla ilgili çalışan sohbetinde bir çalışan, Google ile çalışanlar arasındaki ilişkinin iş ilişkisi olduğunu söyledi
- Bu konuşma, Google ile kendisinin tek bir topluluk olmaktan çok, para karşılığında hizmet sunulan bir ilişki içinde olduğunu fark etmesine yol açtı
- Terfi komitesi hata düzeltmeyi veya ekibe destek işlerini ödüllendirmiyorsa, bu işlere zaman ayırmanın nedeni de yeniden sorgulanır hale geldi
Terfi Optimizasyonu ve Kalite Standartlarındaki Değişim
- İlk terfi reddinden çıkardığı ders, sonradan yanlış görünmeye başladı
- Aynı işi daha iyi paketlemek yerine, terfi komitesinin istediği işleri münhasıran seçmeye yöneldi
- Yeni strateji, her işe başlamadan önce bunun terfiye yardımcı olup olmayacağını sormak; yardımcı olmayacaksa yapmamaktı
- Kod kalitesi standardı da düştü
- “Önümüzdeki 5 yıl boyunca bakımı yapılabilir mi?” sorusundan “Terfi edene kadar dayanır mı?” sorusuna kaydı
- Projenin yayınlanmasını tehdit etmeyen hataları kaydetmedi veya düzeltmedi
- Bakım sorumluluğundan çıktı
- Kampüs işe alım etkinliklerinde gönüllü olmayı bıraktı
- Haftada 1-2 kez yaptığı mülakatları 0’a indirdi
Tekrarlanan Proje İptalleri ve Kariyer Üzerindeki Kontrol Hissinin Kaybı
- Öncelikler değişince terfi açısından avantajlı görünen proje, Hindistan’daki kardeş ekibe devredildi
- Yerine verilen proje dokümante edilmemişti ve desteği sonlandırılmış bir altyapının üzerindeydi; buna rağmen production’daki kritik bir bileşendi
- Yeni iş, bu sistemi kardeş ekibin kodundan ayırıp yeni bir framework’e taşırken production operasyonlarını ve performans metriklerini korumaktı
- Terfi açısından bu, birkaç aylık geri gidişti
- İptal edilen proje yayınlanmadığı için iki aylık çalışma boşa gitti
- Yeni sistemi anlamak için haftalar gerekiyordu
- Operasyonu sürdürmek gibi tekrarlı işler ek zaman alabilirdi
- 6 ay içinde üçüncü kez proje ortasında yeniden görevlendirme yaşadı; her seferinde neden iş kalitesi değil, üst yönetim stratejisi veya ekip kadrosundaki değişikliklerdi
- Google, proje tamamlanmadan işi değerlendiremeyeceğini söylüyordu; ama aynı zamanda projeleri ortasında kesip yeni işler atayarak tamamlamayı zorlaştırıyordu
- Kariyeri, kendisini yaklaşık bir saat inceleyen anonim bir komiteye ve kendisinin dahil olmadığı yönetim kararlarına bağlı bir yapıya dönüşmüştü
Son Terfi Denemesi ve Ayrılık Kararı
- Google’da 3 yılını terfiye yatırdığı için, ayrılmadan önce son bir kez daha terfi başvurusu yapmaya karar verdi
- Performans dönemi bitmeden 6 hafta önce projesi yine iptal edildi; bu kez tüm ekip iptal edildi
- Google’da bu tür durumlar yeterince yaygındı ve bunun için defrag adlı bir örtmece vardı
- Ekibin projesi Hindistan’daki kardeş ekibe devredildi
- Ekip üyeleri şirket içinde başka alanlarda yeniden başlamak zorunda kaldı
- Yine de terfi başvurusu yaptı ve sonuç en yüksek performans notu olan Superb oldu
- Bu not her döngüde çalışanların yaklaşık %5’ine verilir
- Terfi komitesi, son 6 ayda kıdemli seviyede çalışmayı açıkça gösterdiğini düşündü
- O 6 ay, terfi optimizasyonu yaklaşımıyla çalıştığı dönemdi
- Ancak 6 ayın yeterince uzun bir performans geçmişi olmadığı gerekçesiyle terfi ettirilmedi
- Yöneticisi aynı seviyede 6 ay daha çalışırsa terfi olasılığının yüksek olduğunu söyledi; fakat 2 yıldır “6 ay sonra terfi ihtimali” sözünü duyduğu için ayrılmaya karar verdi
Indie Hackers ve Bağımsız Geliştirme Planı
- Benzer dönemde Indie Hackers’ı keşfetti
- Indie Hackers, küçük yazılım işletmelerinin kurucularından oluşan çevrim içi bir topluluktu
- Dev startup’lar hayal edenlerden çok, geçimini sağlayabilecek küçük ve kârlı işler kurmak isteyenler ağırlıktaydı
- Daha önce yazılım girişimcisi olmak için Silicon Valley tarzı startup yolunu izlemek gerektiğini düşünüyordu
- Bunu, zamanın çoğunu yatırım toplamaya harcamak ve sonraki 1 milyon kullanıcıyı nasıl çekeceğini dert etmek olarak anlıyordu
- Indie Hackers’ın yolu farklı bir alternatifti
- Üyelerin çoğu işi kendi birikimleriyle veya ana işlerinin yanında yürüttükleri yan projelerle başlatıyordu
- Yatırımcılara hesap vermeleri gerekmiyordu
- Anonim bir komiteye kendilerini kanıtlamaları da gerekmiyordu
- Dezavantajları da açıktı
- Gelir daha az istikrarlıydı
- Ölümcül riskler daha fazlaydı
- Google’da 10 milyon dolar kaybettiren bir hata yapsaydı bir postmortem yazar ve bu bir öğrenme fırsatı olarak görülebilirdi; küçük bir kurucu içinse bu, işin kapanması ve büyük borç anlamına gelebilirdi
- Yine de Indie Hackers kurucuları, işleri hızla büyüse de yıllarca yerinde saysa da kararları doğrudan kendileri verdikleri için çekiciydi
- Ayrıldıktan sonra birkaçer ay boyunca farklı projeleri deneyip tepkiyi görmeyi planlıyor
- KetoHub’ı geliştirmeye devam edip gelir elde etme olasılığını kontrol edecek
- Dağıtık depolama teknolojisi Sia üzerinde bir iş kuracak
- Yazmaya daha fazla zaman ayırıp gelir elde etme yolları arayacak
- Google iyi bir iş yeriydi ve değerli beceriler öğrendiği bir yerdi; ancak Google gibi işverenlerin gelecekte de var olacağını, buna karşılık kendi şirketini kurma özgürlüğünün her zaman bulunmayacağını düşündü
1 yorum
Hacker News yorumları
Aynı yazarın birden fazla yazılım işi kurmaya çalıştığı süreci özetleyen yıllık değerlendirme serisi de ilginç biçimde yayımlanmıştı; mali durumunu da oldukça açık sözlü ele alıyor.
Bir yazılım işini bootstrap ederek büyütmekle ilgileniyorsanız okumaya kesinlikle değer:
https://mtlynch.io/tags/annual-review/
https://mtlynch.io/i-sold-tinypilot/
Başarı hikâyelerini sık duyarız ve başarılı olunca bunu yüksek sesle anlatmak kolaydır; ama gerçekte şirketlerin çoğunun başarısız olduğunu hatırlamak gerekir. Bu yazar üçüncü yılında para kazandıran bir şey buldu, ancak çoğu kişinin gelir olmadan o kadar dayanacak imkânı yoktur.
Böylesine empati kurulabilir ve dürüst yazılar yazan insan az. Birkaç yıldır takip ediyorum; harika bir ilham kaynağı.
Her kariyerde en önemli ders şudur: “Müşteri, müşteri değildir.” Gerçek müşteriler maaş artışınızı, bonusunuzu ve terfinizi belirleyen kişilerdir.
Müşteri, değerli gördüğü bir ürün ya da hizmet için para ödeyen taraftır; genelde bu kişi yöneticinizdir ya da asıl yazıdaki örnekte olduğu gibi terfi komitesidir. Bu açıdan bakınca kariyeri bir iş gibi yönetip, parayı değerle takas edebilen tarafa daha hızlı değer sunacak şekilde hareket etmek gerekir. Müşterinin fikrini değiştirmesi, piyasanın ölçütleri değiştirmesi ve sizin yanlış şeye odaklandığınızı fark etmeniz iş dünyasında da sık görülür. Müşterinin istediğini veremezseniz müşteri kolayca başka birine gidebilir; bu yüzden stratejiyi sürekli değiştirmek ve müşteriye uyum sağlamak gerekir.
Sonunda gerçek müşteri insan bile değil, süreç olur. İnsanlara yardımcı olan harika fikirlerin peşinden tutkuyla gitmek hem kariyer hem de toplum için en iyi noktadır. Orijinal metindeki şu bölüm bunu iyi gösteriyor: “Kaderimin beni bir kez bile görmemiş gizemli bir komitenin elinde olmasını doğal buluyorum. Onlar kayırmacılığa ya da siyasete bulaşmamış olmalı; yüksek kaliteli kodumu ve keskin mühendislik kararlarımı fark edeceklerdir.”
Bu kalıp ürün kalitesinin düşmesine ve ekip dinamiklerinin kötüleşmesine yol açar. Bu kaçınılmaz akışı açıkça bastıran ya da henüz böyle bir akışın oluşmadığı şirketleri bulmak daha iyidir. İyi kalite üretildiğinde ve bunun karşılığı verildiğinde herkes kendini daha iyi hisseder.
Sipariş üzerine bir şey yaparken satın alan kişinin istediğiyle gerçekte ihtiyaç duyulan şey farklı olabilir ve sonuna kadar gidilse bile memnuniyetsizlik kalabilir. Patron için çalışıyorsanız patron engel de olabilir. Sadece müşterinin istediğini yapmak yetmez; patron “benim yöntemimle” yapılmasını isteyebilir ve bu yüzden müşteri istediğini alamayabilir. Müşterinin başkası için bir şey satın aldığı durumlarda da dolaylılık yüzünden başarısızlık yaşanabilir; bu, kurumsal özel yazılımlarda sık görülür.
Bu yazıya tamamen katılmak zor. Bir projenin tamamlanmadan dağılması çok sinir bozucu bir şey, ama yazarın orada yalnızca terfi için bulunuyormuş gibi göründüğü de oluyor.
Terfi iyi bir şey, fakat bunun neden ayrılacak kadar belirleyici olduğu yeterince açıklanmamış. Bir işte kalmanın tek nedeni daha iyi bir unvan beklentisiyse bu kötü bir işaret olabilir. Sonrasında Google’da 4 yılda ömür boyu yetecek kadar para kazandı ve bu finansal güvenceyle çoğu kişinin kaldıramayacağı yüksek riskli bir seçim yaptı. Her hâlükârda kendine uygun işi bulmasına sevindim; umarım bu güvenceye dayanarak faydalı ve etkili bir şeyler üretebilir.
Tüm bu unsurlar eskiden çok açıktı; sunumlar, slaytlar, dokümanlar vb. doluydu. Sizin hangi seviyede olduğunuz, konuştuğunuz kişinin hangi seviyede olduğu önemliydi. Amaç iyi bir mühendis olmak ya da iyi bir ürün yapmak değil, isimsiz bir komitenin o sihirli sayıyı artırmasını sağlayacak işleri yapmaktı. Google’a bu nedenle girmemiş olsanız bile sonunda sizden ne beklendiğini öğreniyorsunuz. Ne yazık ki bir yazılım mühendisi kuşağı bu dersi aldı.
Etki yaratma ya da şüpheli metrikleri iyileştirme baskısı hiç bitmiyor; bu sırada teknik borç birikiyor. Organizasyon değişiklikleri ve işten çıkarmalarla ilgili belirsizlik de her zaman var, bir sonraki değerlendirme döngüsüne dair kaygı da büyük. Birkaç yıl geçince asıl motivasyonun para olduğu anlaşılıyor. Ancak daha fazla stres istemediğim için terfi istemiyorum; başka bir yerde daha fazla kazanmak çok zor olacağı için de bu şirkette mümkün olduğunca uzun kalmak istiyorum.
İnsan psikolojisi böyle işlemiyor. Çevrendeki insanlarla rekabet ediyorsun; onlar terfi ederken sadece sen geride kalırsan mutlu olmak zor.
Staff altındaki seviyelerde uzun süre kalmak olumsuz işleyebiliyor; terfi edemezsen ilan edilen beklentileri karşılamadığın gerekçesiyle performans iyileştirme planına alınabiliyorsun. Google sonunda bu ifadeyi kaldırdı; çünkü 100 bin kişilik bir şirkette piramitte yeterince yer olmadığını ve kendini pazarlamayan ama sistemi çalışır tutan insanları kaybettiklerini öğrendi. Yanlış hatırlamıyorsam 2018’de bunu henüz bilmiyorlardı.
Yazarım. Bu yazının yeniden gündeme gelmesine sevindim.
Bu yazıyla ilgili merak ettiğiniz bir şey varsa yanıtlayabilirim.
Akıntıya bakıp içlerinden en iyi görünen su yolunu seçmişsin gibi geliyor, ama çoğu zaman başka seçenekler de oluyor. Baraj kurmak, yani araziyi değiştirmek gibi. İşi kimsenin denemediği ya da başaramadığı bir biçimde değiştirmeye çalışmak. Geriye dönüp bakınca, patronumun bana ilginç ve etkili işler vermesini beklediğim zamanlardan ziyade, ne yapacağımı patronuma söyleyebildiğim zamanlarda en mutlu ve başarılıydım. Böyle bir seçenek görünmüyorsa ayrılma zamanı gelmiş olabilir; ama önce denemeye değer olduğu çok olur. Bazen kendi kaderimi yaratma hakkını kazanmak için kirli işleri zorlamak gerekti; fakat yönetim mekanizması ve güven oluşunca bu sermayeyi büyük, yeni ve ilginç bir şey önermek için kullanabildim. Cesaretin ödüllendirildiğini her gördüğümde şaşırıyorum. Daha geçen hafta bir iş arkadaşım iddialı ve tartışmalı bir öneriyle finansman taşından kan çıkardı; bu hafta ise yeni bir ekibin teknik lideri oldu. Kendimi tıkanmış hissettiğim her seferinde boş bir belge açıp yeni bir tasarım yazmaya başlarım. O sırada terfiyi düşünmem ama sonunda bir yerlerde terfiye ya da daha büyük bir fırsata bağlandı.
Yeni bir proje üzerinde çalışıp çalışmadığını merak ediyorum. PDF parser fuzzing ile ilgili yazıyı gördüm ama bunun yeni bir projeyle bağlantılı olup olmadığına dair bağlamı görmedim ya da kaçırdım sanırım.
https://mtlynch.io/i-sold-tinypilot/
Açık şekilde yazıp yolculuğunu belgelediğin için teşekkürler; bundan faydalanan tek kişi ben değilimdir. Bu arada kullanıcı adını her gördüğümde hep Mount Lynch gibi okuyorum.
Bu yazıdan çıkardığım sonuç, terfi komitesine bağımlı bir yapının ne kadar duygusuz olduğu.
Google’ın mühendislik odaklı bir kültür oluşturmak istediği için böyle bir sistem kurmasını anlıyorum. Muhtemelen amaç, yöneticiniz takdir etmese bile harika mühendislik işi yaparsanız bunun tanınmasını sağlamaktı. Ancak ölçmesi zor kültür iyileştirmeleri gibi işlerde, bu tür komitelerin harika mühendisliği doğru şekilde fark ettiği pek inandırıcı gelmiyor. Getirdiğim değeri gören ve bu takdiri terfi kararıyla gösterebilen bir muhatapla, müşteriyle ya da liderle karşılaşınca hayat daha iyi oluyor. Paketlere bağımlı yüzsüz bir komite, gerçek takdirin oluşacağı ilişkileri yapısal olarak kuramaz. Liderliğin beni takdir etmediği bir şirkette neden zorla kalayım? Beni takdir edecek bir yer bulurum. Google kötü yönetim ya da süreçler yüzünden iyi insanları kaybetmekten kaçınamayacağını öğrenemiyorsa bu onların kaybı. Makul ölçüde iyi performans değerlendirmelerini kullanıp yavaş yavaş ayrılma planı yapılabilir. Samimi ve destekleyici profesyonel ilişkiler kurmayı aktif biçimde engelleyen bir organizasyonda çalışmak için hayat çok kısa.
Birçok insan için terfi, turta yeme yarışmasını kazanıp ödül olarak daha fazla turta almaya benziyor. Kendi çıkarlarınla işvereninin çıkarlarının ancak gevşek biçimde örtüştüğünü kabul edip şirketin istediği türden oyunu oynamayı reddetmekte sorun yok.
Terfi önemli değil; içsel motivasyon veren, yani anlamlı, ilham verici ve içine gömülebileceğim işler yapmak, geçimimi sürdürüp makul ölçüde birikim yapacak kadar kazanmak istiyorum.
Sorun üç yönlü. Birçok şirket o kadar kötü ücret veriyor ki biraz birikim yapabilmek için terfi gerekiyor; anlamlı işin kendisi de unicorn gibi; en sinir bozucu olanı da kendi rolünde istikrarlı biçimde sürekli iyi iş çıkaran çalışanların bile Amerikan şirketlerinde kaçınılmaz olarak “büyümeye” ve “kariyerini geliştirmeye” zorlanması ya da “geride kalmış” diye etiketlenmesi. Belirli bir seviyede tutarlı biçimde üstün performans göstermek durgunluk değil, bilinçli istikrar olabilir. Kişisel bağlamda sonsuz büyüme, ya da en azından sonsuz sallantı, Amerikan şirketlerinin anlaşılması güç çılgınlığı.
Yazarın şu cümlesi etkileyici: “Kariyerimi geliştirmeye devam etmek için daha geniş kapsamlı projeler ve daha fazla partner ekiple işbirliği gerekiyordu. Ama bu, projelerin kontrolüm dışındaki daha çok etken yüzünden başarısız olabileceği ve hayatımın aylarının ya da yıllarının boşa gidebileceği anlamına geliyordu.”
Geri dönüp düşündüğünde, startup başarısının da kontrol dışındaki 100’den fazla etkene bağlı olduğunu kabul edeceğini düşünüyorum. Bu, hayattan zaman kaybı değil. Dünyanın nasıl işlediğini öğrenmek.
Yüksek büyümeli, girişim sermayesi destekli bir startup’ta başarı için birçok yıldızın hizalanması gerekebilir. Ama bootstrapped bir işte başarı için temelde gereken tek şey var: ürün-pazar uyumu. İnsanların istediği bir ürün yaparsanız, başka pek çok hata yapsanız bile genel olarak başarılı olma olasılığınız yüksek. TinyPilot’a başladığımda donanımdan da fiziksel ürün satmaktan da hiç anlamıyordum ve sayısız hata yaptım. Ama insanların para ödemeye istekli olduğu bir ürün bulduğum ve onu müşterilerin önüne koymanın iyi bir yolunu bulduğum için şirket yürüdü. İyi yaptığım şeyler de vardı ama ilk yıl genel olarak gelir kendi kendine büyüyor, ben de yetişmeye çalışıyormuşum gibi hissediyordum. Ürün-pazar uyumunu bulmak için hâlâ şans gerekiyor; çünkü makul görünen pek çok fikir de başarısız oluyor. Yine de birçok şeyin aynı anda şans eseri denk gelmesini beklemiyorsunuz; bir kez şanslı olmanız yeterli.
Yine 2018 tarzı kötü şöhretli bir “Google’dan neden ayrıldım” yazısı daha.
Ve bu yazılar hep Google mühendislerinin dünyadaki en zeki insanlar olduğunu söyleyerek başlar. Gerçekten beyni yıkanmış insanlar.
Ben de bu yüzden Google’dan ayrılmayı düşünüyorum. Toplantılarda oturmak, yapılması gereken işleri başkalarına devretmeye çalışmak ve oyun oynamakla pek ilgilenmiyorum; oysa projemde bitirmem gereken yüzlerce küçük iş var.
İş değiştirirsem yılda 50 bin–100 bin dolar daha fazla kazanabilirim. Bir sonraki şirket deneyimime gerçekten değer verecek; üstelik teknik olarak bu deneyim Google için çok daha yararlı olmasına rağmen.
Şimdi 100 bin kişilik, her şeyi yapan bir şirket yerine odaklı bir proje yürüten küçük bir şirkette daha hızlı ve etkili çalışıyor, üstelik daha fazla para kazanıyorum.
Yapı şöyleydi: “Müdürünüz sizi terfi ettirmiyor mu?” “Hayır. Google müdürleri doğrudan raporladıkları kişileri terfi ettiremez. Oy hakları bile yoktur. Bunun yerine terfi kararını, sizi o gün ilk kez tanıyan üst seviye yazılım mühendisleri ve müdürlerden oluşan küçük bir komite verir.”
Bildiğim kadarıyla 2022’den sonra müdürün tek oya sahip olduğu bir sisteme geçmiş gibi görünüyor.
Terfi hâlâ terfi komitesine gidiyor. Sadece artık komiteyi adayı duymuş olacak kadar organizasyona yakın bir yerde tutmaya ve toplantıda müdür olmayan ama bağlamı yüksek değerlendiriciler bulundurmaya çalışıyorlar. Önceki sistemden devam eden ve bu tür yazıların sıkça kaçırdığı nokta şu: Her seviyede, o seviyedeki kişinin bağımsız olarak yürütebileceğine güvenilen faaliyetler için açık beklentiler var. Terfi kararı, mevcut işi iyi yapmanın ödülü değil; bir sonraki seviyenin işini yapabileceğinizi yeterince gösterip göstermediğinize dair bir karar. Bir kişi bir seviyede uzun süre kalıyorsa bunun nedeni genellikle bir sonraki seviye sinyallerini gösterememesidir. Elbette bir sonraki seviye sinyallerini gösterme fırsatı az olan bir ekipte olmak ya da bazı projelerde etkinin değerlendirilmesinin yıllar sürmesi, operasyonel etki değerlendirilene kadar işin tanınmaması gibi durumlar haksız hissettirebilir. Yine de çoğu zaman kulağa geldiği kadar keyfi değildir.
Her yıl değiştiği için kişisel deneyimimle 2024 Google’ını yargılamıyorum ama orada olduğum yıllardan birinde müdürüm yerimin nerede olduğunu bile neredeyse bilmiyordu. L5 ve L6 terfi paketlerimi akran komitesi değerlendirdi; onların müdür değerlendirmesini görüp görmediğini bile bilmiyorum. L5 terfi komitesinde bulunduğumda da müdür değerlendirmesine çok ağırlık vermedik. O dönemde müdürler L5 terfisine gerekçe olan alanlardan oldukça elini çekmiş durumdaydı; bu yüzden mantıklıydı.
Ama bu bir gizem değil; nihayetinde adayın neden terfi etmesi gerektiğini net biçimde ortaya koyan güçlü bir paket hazırlama sorumluluğu müdüre aittir. Terfi girişiminin kendisi müdürün oyudur; sonrasında da adayın terfisini ne kadar güçlü biçimde desteklediğine bağlıdır. Terfiler arasında tutarlılığı sağlamanın tek yolunun bu olduğunu düşünüyorum.