Spotlight'ı Göz Ardı Eden Bir Staff Mühendisiyim
(lalitm.com)- Büyük teknoloji şirketlerinde ürün odaklı kültür, kısa vadeli başarı ve görünürlüğe odaklanırken, altyapı ve geliştirici araçları alanında süreklilik ve sistem yönetimi ana değer olarak çalışır
- Yazı sahibi Google’da geliştirici araçları ve altyapı ekibinde yer almakta ve üst yönetimin dikkatinden çok mühendis müşteri güveni ve verimliliki öncelemektedir
- Uzun vadeli sistem yönetimi (stewardship) ile biriken bağlam ve deneyim, Bigtrace gibi büyük ölçekli bir projenin yenilikçi çıktısına dönüşmüştür
- Kısa vadeli gözle görünür projelerin peşinden koşmak yerine güven ve teknik etkiyi bir sermaye olarak edinip, gerektiğinde “hayır” diyebileceği siyasal sermayeyi kurar
- Teknoloji sektörünün hızlı rotasyonuna rağmen, derinlik ve sürekliliğe dayalı bir kariyer yolu vardır; bu yol uzun vadeli etki yaratan alternatif bir modeldir
Farklı Dünyalarda Mühendislik
- Ürün takımları dış müşterilere odaklanır ve performansları gelir·aktif kullanıcı sayısı (MAU) gibi kısa vadeli metriklerle ölçülür
- Bu ortamda üst yönetimin ilgisini almak için çeviklik ve görünürlük (spotlight) şarttır
- Altyapı ve geliştirici araçları takımları ise iç mühendisleri müşteri olarak alır ve ürünün performansını ve hata ayıklamasını destekleyen araçlar ve sistemler kurar
- Üst yönetimin ilgisi daha düşüktür; PM alımının zor olduğu bir yapı nedeniyle mühendis merkezli, yukarıdan aşağı değil aşağıdan yukarıya (bottom-up) bir çalışma şekli ortaya çıkar
- Takım, en büyük etkiyi üretebileceği sorunları kendisi tanımlar ve çözer; üst yönetim ise bu etkinin boyutunu doğrular
Yönetimin (stewardship) Bileşik Etkisi
- Ürün ortamında hız ana para birimi iken, altyapı ortamında bağlam (context) temel bir değerdir
- Bir mühendisi değiştirilebilir bir kaynak gibi görmek bağlamı yok eder ve sistemde örtük bilgi kaybına yol açar
- Uzun vadeli yönetimin ilk getiri noktası, desen tanımayla elde edilen verimliliktir
- Bir alanda uzun süre kalındığında yeni bir talep geçmiş örneklerle bağ kurularak hızla çözülebilir
- İkinci getiri, sistemsel yeniliktir
- Sadece uzun süreli gözlemle ortaya çıkan sorunlar çözülebilir ve bunun ürünü Bigtrace olmuştur
- 2023 başında Google’daki birçok ekip, performans izleme verisi (terabayt~petabayt ölçeğinde) işleyememe sorununu gözlemledi
- 1 yıllık prototip araştırması ve geri bildirim toplama sürecinden sonra 2024 başında Bigtrace inşa edildi
- Şu anda aylık olarak 20 milyarın üzerinde trace işlenmekte ve 100’ün üzerinde mühendis tarafından kullanılmaktadır
- Kısa vadeli proje rotasyonlarına geçmeyi seçmiş olsaydı Bigtrace olmayacaktı
- Sadece uzun süreli gözlemle ortaya çıkan sorunlar çözülebilir ve bunun ürünü Bigtrace olmuştur
“Hayır”ın Gücü
- Yüksek görünürlüklü projeler kaynak ve dikkat çekebilir, ancak aynı zamanda politik dalgalanma ve kalite düşüşü riski taşır
- Uzun vadeli yönetimle biriken güven sermayesi, spotlight’ın cazibesini reddetme gücü sağlar
- Örnek: AI dalgası sürerken de Perfetto’ya LLM entegrasyonu talep edildi, ancak ekip doğruluk (precision) değerini temel alıp dikkatli bir şekilde ilerledi
- Kernel hata ayıklama gibi alanlarda doğru zaman damgaları şarttır; halüsinasyon (hallucination) kabul edilemez
- Ancak bu yaklaşım “sonsuza dek hayır” demek değil, “doğru uygulanana kadar bekletme” yaklaşımını korumaktır
Etkinin Alternatif Para Birimi
- Spotlight’ın dışına çıkıldığında üst yönetim görünürlüğü azalır ama bunun yerine teknik güven ve fayda adlı başka bir para birimi elde edilir
- Shadow Hierarchy (Gölge Hiyerarşi)
- Altyapı organizasyonlarında, kendi yöneticinizden çok müşteri organizasyonunun yöneticisinden onay almak önemlidir
- Örneğin Pixel takımı “Perfetto olmadan hata ayıklama yapılamaz” dediğinde, bu etki üst yönetim hattı üzerinden iletilir
- Bu, politikanın değil teknik güvene dayalı savunuculuğun bir örneğidir ve terfi değerlendirmelerinde güçlü bir kanıt olur
- Utility Ledger (Fayda Defteri)
- Utility: Araç, hata düzeltmelerinde kullanıldığında saf faydasını kanıtlar
- Criticality: Ana ürün takımlarının başarısıyla doğrudan bağlantılıdır
- Ubiquity: Farklı organizasyonlar aynı trace’i paylaşıp birlikte çalışır
- Scale: Petabayt seviyesinde veri işleme ile mimarinin dayanıklılığı kanıtlanır
- Bu metriklerin birleşimi, organizasyonel yeniden yapılanmalara rağmen sarsılmaz sürekli etki sağlar
Staff Mühendisinin Türleri ve Seçimi
- Will Larson’ın 『Staff Engineer』 kitabına göre, staff mühendisi birçok tipe ayrılır: Solver/Right Hand ve Architect/Tech Lead
- İlki üst yönetimin iradesini uygulayan bir sorun çözücü, ikincisi belirli bir alanın uzun vadeli sahibi
- Yazar ikinci tipe dahildir ve derin teknik bağlam ile uzun vadeli sorumluluğu öne çıkarır
- Bu yaklaşım çoğunlukla yalnızca kârlı büyük şirketlerde mümkündür; hem tesadüf hem de seçim devrededir
- İyi bir ekip bulmak şansla olur, ancak uzun süre kalıp lider/yonetici olarak büyümek bir seçimdir
- Bu tür takımlar dışarıdan parlak görünmese de, sürekli misyon ve istikrarlı mühendislik kültürünü sürdürür
Sonuç
- Teknoloji endüstrisi “hızlı hareket et” sloganını öne çıkarır, ancak derinlik ve sabır yaklaşımı da mevcuttur
- Spotlight’ı kovalamadan da anlamlı ve etkili bir kariyer inşa etmek mümkündür
- Bir problem alanında uzun süre kalıp sürdürülebilir sistemler kurmak en iddialı tercihlerden biridir
1 yorum
Hacker News yorumu
25 yılı aşkın süredir çalışırken öğrendiğim şey şu: kendi hikâyene ve başarılarına doğrudan sahip çıkmazsan bir başkası onları sahiplenir
Özellikle büyük şirketlerde popüler insanlar çoğu zaman krediyi üzerine alır
Mutlaka spot ışıklarının altında olman gerekmez ama kayıt bırakmak önemlidir
İç dokümantasyon ya da dış sunumlar aracılığıyla katkılarını net biçimde görünür kılmalısın
Popüler değilsen beyzbol takımında da yedek kulübesinde kalırsın; lisansüstü başvurularda ya da ML topluluğunda da durum aynıdır
Dünya bir tür popülerlik yarışı sistemi gibi işliyor
Sadece çalışıp karşılığını almak yerine kendini pazarlamanın zorunlu olduğu bir düzende, işimi doğrudan sahiplenip kontrol etmenin daha iyi olduğunu düşünüyorum
Bence şirket içinde en önemli para birimi güvendir
Uzun süre boyunca birçok başarılı projede yer alırsan, sonunda liderlik bu ortak noktayı fark eder
Terfi yavaş olabilir ama itibar ve network birikerek istikrarlı bir büyümeye dönüşür
rest & vestdurumuna gelince insanlar bu meseleleri artık çok önemsemiyorZaten yeterince kazandıkları için krediye pek ilgi duymuyorlar
Şu an benim için denge kurulmuş durumda ama çoğu kişi için öyle görünmüyor
Bu gerçekten çok iyi yazılmış bir yazı
Sadece “politikadan hoşlanmıyorum” tonuna odaklanmak yerine, Infra ve DevEx'in politik yapısını anlamak gerekiyor
Ben Slack'te 5 yıl boyunca altyapı PM'i olarak çalıştım ve ürün lansmanı sürecini ancak 4. yılımda öğrendim
Esas mesele iç müşterilerin, yani ürün mühendislerinin başarısına yardımcı olmaktı ve ‘Shadow Hierarchy’ geri bildirimi terfinin kilit unsuruydu
Bu tür iç başarıları optimize edersen hem istikrar hem de kariyer açısından karşılığını alırsın
Yine de bu, işin özünü görmezden gelmeyi sağlayan bir cheat code değil
Yazar, ürün mühendisliği ile altyapı mühendisliğinin farklı değerlendirilmesini iyi yakalamış
Ama bunu Google gibi özel bir ortamdan genelleştirmesi biraz safça geliyor
Piyasa koşulları ya da liderliğin öncelikleri değiştiğinde, inşa ettiğin değeri de yeniden tanımlaman gerekir
Yazısının evrensel bir başarı rehberi olmadığını özellikle vurguladı ve başka ortamlarda başka stratejiler gerektiğini söyledi
Büyük şirketlerde popülerlik oylaması gibi işleyen değerlendirmeler yaygındır
İnsanlar sık sık “community leadership” gibi muğlak ölçütlerle değerlendiriliyor
Oysa sessizce iyi işler yapmak ve başkalarına yardım etmek bence gerçek değerdir
Mühendisler sağlam kod ile kendini pazarlama arasında seçim yapmak zorunda kaldıkları bir ikilemle karşı karşıya
Sonuçta doğru teşvik tasarımı organizasyon yönetiminin temelidir
25 yıllık kariyerimin büyük kısmında her 2 yılda bir şirket değiştirdim ama şu anki şirketimde 4. yılımdayım
İç platform kurarken gerçek müşteri sorunlarını çözüyorum ve politikadan bağımsız olarak beni her gün motive eden şey bu
Altyapı ve tooling mühendisi olarak uzun süre aynı takımda kaldım ve bu yazıda anlatılanlar gerçekle oldukça örtüşüyor
Bazen kolay kazanımlar oluyor ama çoğu zaman iş sakin, tatmin edici ve gündelik teknik çalışmadan ibaret
Ben de ürün takımındansa altyapı takımında çalışmayı tercih ediyorum
Liderliğin kaprislerinden daha bağımsız oluyorsun ve teknik mükemmelliğe odaklanabiliyorsun
Şu anda orta ölçekli bir şirkette sessizce başka ekiplerin altyapısını iyileştirme işinden keyif alıyorum
Böyle bir yazıyla kendi değerini savunmak zorunda kalman bile başlı başına iyiye işaret değil
Elbette kendini pazarlamak ve karizma terfide avantaj sağlar ama dünyayı daha kötü bir yere dönüştürme pahasına bunu yapmaya gerek yok
Wozniak gibi sessizce işini yapan insanlara da ihtiyaç var
Yazarın spot ışığından kaçınabilmiş olmasının nedeni zaten Staff Engineer olması
Startup döneminde güven kazandığı için kendini özellikle öne çıkarması gerekmemiş ama BigTech'te siyaset çok daha yoğundu
Benim kısa vadeli hedefim para kazanıp ayrılmaktı ama genç stajyerlerin hak ettiği takdiri almasına yardımcı olmak daha zordu
Şimdi ise projelerim zaten görünürlük sağladığı için ayrıca reklam yapmam gerekmiyor
Google'da L3 seviyesinden beri spot ışığını kovalamadan da mühendis arkadaşlarla paylaşım ve işbirliği sayesinde yeterince tanındığını söylüyor
Yeterli sermayen varsa — ister sosyal ister finansal — 3 yıl dayanabilirsin; 2. yılda sonuç gelirse ilk dönemdeki deneme-yanılmalar unutulur
Sorun, yanlış çıktığında oluşan risk
Hatasız bir sürüm için uğraşsan da sonunda övgüyü yine gece mesai yapıp sorunu çözen kişi alabiliyor
Elbette şansın da payı var ama fırsatın hazırlıklı olana geldiğine inanıyorum