- Staff Engineer ne zaman gerekir ve Engineering Manager ile arasındaki fark nedir?
- Pek çok mühendis ve yönetici bu iki rol arasında kafa karışıklığı yaşıyor
- İnsan yönetiminden kaçınıp teknolojiye odaklanmak isteyen EM'ler ile teknik liderlik üstlenmek isteyen Senior Engineer'lar bu konuda düşünüyor
- Her rolün sorumluluklarını ve kapsamını net biçimde anlamak önemli
Bana sorulan sorular
- EM: "İnsan yönetimi yerine teknolojiye odaklanmak istiyorum. Staff Engineer rolü bana uygun olur mu?"
- Senior EM: "Yönetim işleri çok fazla. Teknik işleri üstlenmesi için bir Staff Engineer işe almalı mıyım?"
- Staff Engineer: "Pratikte takım yöneticisi gibi çalışıyorum ve bu hoşuma gidiyor. EM'e geçmeli miyim?"
- Senior Engineer: "Staff Engineer'ın sorumlulukları neler? Sanki emekli olmuş bir geliştirici gibi görünüyor."
- New Staff Engineer: "'Dotted reporting lines' ne demek? Benim bir line manager'ım varken başka yöneticileri de önemsemem mi gerekiyor?"
Staff Engineer ne zaman gerekir?
- Mühendisler teknolojiyi inşa eder ve sürdürür, ancak teknoloji tek başına var olmaz
- O, bir probleme verilen çözümdür ve problem ürün tarafından tanımlanır
- Ürün, son kullanıcıya veya iç müşteriye hizmet sunar
- Ürün, kullanıcının problemini çözmeye yarayan bir araçtır; örneğin:
- Koşu mesafesini ölçen ve bunu diğer kullanıcılarla paylaşan bir uygulama
- Otel rezervasyon web sitesi
- Başka ekiplerin kullandığı bir altyapı platformu
- Mesai ve devam raporlama sistemi
- Bu tür ürünleri geliştiren mühendisler genellikle Engineering Manager (EM) liderliğindeki ekiplerde yer alır
- EM, ekip üyeleriyle (mühendislerle) ve onların ürettiği teknik çıktılardan (artifacts) hesap verebilirlik (accountability) açısından sorumludur
- Ancak şu durumlarda bu sorumluluğu bütünüyle yerine getirmek zorlaşır:
- Ekip çok büyük olduğunda
- Teknoloji aşırı karmaşık olduğunda
- Ya da bu ikisi aynı anda yaşandığında
- Böyle durumlarda EM'in zamanı ve enerjisi (bandwidth) yetersiz kalır; hem insan hem teknoloji tarafındaki sorumluluğu eksiksiz yerine getirmesi zorlaşır
- EM sorumluluğunu tam karşılayamıyorsa, iki devir stratejisi düşünülebilir:
- İdari işlerin devri:
- HR süreçleri ve araçlarını optimize ederek ya da
- İnsan yönetimi yükünü azaltmak için bir asistan işe alarak
- Tek bir ekip için özel bir asistan fazla gelebilir, ancak birden fazla ekibin aynı asistanı paylaştığı örnekler de vardır
- AI araçları kullanılarak takvim ayarlama, yönetsel sorulara yanıt verme, geri bildirim toplama gibi mekanik işler kısmen ikame edilebilir
- İyi bir HR sistemi, yönetsel yükü ciddi biçimde azaltır
- Teknik işlerin devri:
- Teknik yükü paylaşmak için bir Staff Engineer işe alınabilir
- Ancak asistanlar veya AI, EM'in temel sorumlulukları olan şu insan odaklı işleri üstlenemez:
- İyi bir ekip kurmak
- Mentorluk
- Performans değerlendirmeleri
- İşe alım vb.
- Öte yandan, bütün teknik işleri Staff Engineer'a devretmek bir anti-pattern sayılır
- Staff Engineer, EM'in teknik çevirmeni rolüne indirgenmemelidir
- EM teknik sorumluluk açısından da belli bir seviyenin üzerinde kalmalıdır
- Bu yüzden Engineering Manager'ın teknik sezgisini koruması şarttır
Staff Engineer'ın faydalı olduğu durumlar
- Aşağıdaki durumlarda Staff Engineer organizasyona gerçek değer katabilir:
- EM'in taşımasının zor olduğu teknik yük varsa
- Örnek: Çok sayıda legacy teknoloji bulunması ve sürekli bakım gerektirmesi
- Ekipler arası karmaşık çözümler olması veya derin teknik bilgi gerekmesi
- (Önerilmeyen bir model olsa da) EM'in teknik olmaması durumu
- Teknik işlerin bir kısmı için net bir hesap verebilirlik (accountability) verilebiliyorsa
- Teknolojinin kapsamı tek bir EM'in yönetebileceği sınırı aşıyorsa
- Staff Engineer insanlardan değil, teknolojiden sorumlu olmalıdır
- Ekip üyelerini yönetmek veya performans değerlendirmesi yapmak bu role dahil değildir
- Durumlar organizasyona, ürüne ve kişilere göre değiştiği için her koşula uyan evrensel bir kural yoktur
- Not: responsibility ile accountability birbirine yakın ama farklı kavramlardır
- Staff Engineer şu özelliklere sahip olmalıdır:
- Derin teknik anlayış ve yüksek teknik okuryazarlık
- Net bir teknik hesap verebilirlik (accountability)
- İnsan yönetimi sorumluluğu olmadığı için teknolojiye yatırım yapacak daha fazla zaman
- Buna karşılık EM de teknik sorumluluktan tamamen çekilmemelidir
- Hâlâ teknolojiye belli ölçüde dahil olması ve onu anlaması gerekir
- Staff Engineer'ın asıl değeri ekipler arası teknik liderlikten gelir
- Tek bir ekip içine Staff Engineer yerleştirmek şu sorunları doğurabilir:
- Teknik sorumlulukların çakışması
- Rol karmaşası oluşması ve sonunda tek bir rolün farklı unvanlara bölünmesiyle verimsizlik doğması
İstisnai olarak ekip düzeyinde çalışılabilecek durumlar
- Genel olarak Staff Engineer ekipler arası teknik liderliğe odaklanır; ancak aşağıdaki durumlarda ekip düzeyinde geçici olarak çalışabilir:
- Yeni bir EM'in legacy teknoloji yığınını hızla anlaması gerektiğinde
- Yeni bir Staff Engineer'ın daha küçük bir kapsamdan başlayarak onboarding sürecine girdiğinde
- Teknik borç çok arttığında ve sistem sağlığı göstergeleri kötüleştiğinde
- Teknik karmaşıklık nedeniyle bakım zorlaştığında
- Bu durumda ekip seviyesindeki Staff Engineer kurgusu geçici olmalıdır
-
Staff Engineer'ın gerçek değeri
- Ekipler arasında bağ kuran bir yapıştırıcı (glue) rolü üstlenmesi
- Diğer mühendislerle sahada birlikte çalışıp onların sesini yönetime taşıması
- Genelde mühendisler, maaş, izin ve değerlendirme yetkisi olan kişilerden ziyade mühendis meslektaşlarıyla daha açık konuşur
- Teknik olarak derin liderlik sağlaması
- EM'den farklı olarak daha az toplantı, 1:1 ve yönetim işi olduğu için mühendislik becerisini ve teknik derinliğini geliştirmeye odaklanabilir
-
En büyük risk unsuru: Ivory Tower Architect
- Gerçek problemlere veya koda uzak, soyut bir teorisyene dönüşmek
- Bu konu Ivory Tower Architect yazısında ayrıntılı ele alınıyor
Birden fazla ekibe yayılan sistemlerde Staff Engineer'ın rolü
- Staff Engineer, tek bir ekipten ziyade bütün sistemi kapsayan teknik liderlik için en uygun roldür
- Will Larson'un makalesi Staff Engineer için 4 archetype tanımlar:
- Tech Lead: Ekip içi teknik lider
- Architect: Sistem mimarisi tasarlayan kişi
- Solver: Karmaşık teknik sorunları çözen kişi
- Right Hand: Teknik organizasyon liderinin sağ kolu
- Diyagramda yer alan ekip içi Tech Lead'e Staff Engineer demek zorlayıcı olabilir
- Gerçek Staff Engineer değeri, ekipler arası koordinasyon ve teknik entegrasyondan doğar
- Introduction to Staff Engineering bağlantısına bakılabilir
- Staff Engineer yalnızca bir unvan değil, teknik liderliğe dayalı bir yaklaşımdır
- Bu rol, farklı ekipler ve ürünler genelinde teknik koordinasyon ve problem çözümünden sorumludur
- İnsanlar veya ürünler üzerinde resmi yetkisi olmadan da etki yaratır; organizasyonun teknik stratejisini ve yönünü şekillendirir
- Engineering Manager'dan farklı olarak değerini yönetimden değil, derin teknik uzmanlık ve organizasyonlar arası iş birliğinden üretir
- Ellerini kirletip işin pratiğine dahil olur ve diğer mühendislerin gelişimine yardımcı olan bir mentor görevi de üstlenir
- Gerçek organizasyonlarda teknik sistemler tek bir ekiple sınırlı kalmaz; birden fazla ekibe dağılır veya ekipler arasında sıkı biçimde bağlı olur
- Böyle durumlarda tüm sistemden sorumlu adanmış bir Staff Engineer gerekir
- Hangi ekibin hangi parçadan sorumlu olduğundan bağımsız olarak sistemin tamamına bakan bir perspektif ve sorumluluk duygusu gerekir
Staff Engineer sadece teknolojiden değil, insan ve üründen de geçmek zorundadır
- Temel nokta: Teknoloji (tech) diğer taraflarla konuşmaz veya onları dinlemez
- Teknoloji tek başına anlamlı olamaz; insanlar (mühendisler) ve ürün (problem) üzerinden anlam kazanır
- Staff Engineer'ın gerçek değer üretebilmesi için mutlaka şu kanallardan geçmesi gerekir:
- Mühendislerle iş birliği yapmak
- Ürün ekibiyle görüşmek
- Bu nedenle Staff Engineer'ların dotted reporting lines yapısı vardır
- Resmî olmayan ama önemli organizasyonlar arası iş birliği ve taahhüt bağlantılarıdır
- Dikkatli bazı kişiler, Staff'tan daha aşağı seviyelere neden ok çizildiğini sorar
- Neden 1: İyi liderlik otoriteye değil, iş birliğine dayanır
- Staff Engineer, ekip seviyesindeki EM veya PM'e teknik iyileştirme taleplerini iş birliği içinde iletir
- Bu, tepeden inen bir emir değil; mühendisleri ve ürün roadmap'ini dikkate alan ortak çalışma biçimi olmalıdır
- Neden 2: Staff Engineer bir IC (Individual Contributor) olduğu için resmî doğrudan bağlı çalışanları yoktur
- Eğer EM/PM ile düzenli bir görüşme kanalı varsa, bunun amacı sadece raporlama olmamalıdır; şu konularda da kullanılmalıdır:
- Teknolojinin mevcut durumu (status quo)
- Ürün problemlerini çözmeye yönelik teknik vizyon (vision)
- Bunun için gereken organizasyonel teknik strateji (strategy)
- İdeal olan, bu üç konuda çift yönlü bir diyalog kurulmasıdır
- Bu kadar iç içe geçmiş raporlama yapısını düzenlemek ve ekipler arası teknik/ürün hizalamasını desteklemek için
- Şirket genelinde strateji dokümanı (strategy document) çok faydalıdır
- Temelleri için Strategy basics bağlantısına bakılabilir
-
Teşhis (Diagnosis)
- Problem alanı incelenir, çözülmesi gereken temel meseleler ve bunun nedenleri belirlenir
- Stratejinin neden gerekli olduğunu açıklar
- Semptomları ve kök nedenleri tanımlar, bunların neden şu anda önemli olduğunu analiz eder
- Kötü stratejilerde bu bölüm genellikle atlanır ya da yalnızca mevcut durum anlatılır
- İyi bir teşhis nesnel inceleme ve dedektif gibi bir yaklaşım gerektirir
-
Yol gösterici politika (Guiding Policy)
- Tespit edilen problemi çözmek için üst seviye yaklaşımı ifade eder
- Çözüme odaklanır ve tüm organizasyonu hizalar
- Her taktik ayrıntıyı tekrar tekrar düşünmeye gerek bırakmadan yön verir
- Kötü stratejide bu politika (HOW) ile teşhis (WHY) arasındaki bağ kopuktur
-
Tutarlı eylemler (Coherent Actions)
- Politikaya uygun şekilde teşhis edilen sorunları çözmek için somut uygulama planıdır
- Kimin (WHO), neyi (WHAT), ne zaman (WHEN) yapacağını netleştirir
- Buradaki anahtar, “tutarlılık”tır; farklı ekipler uyum içinde aynı yöne ilerler
Teknik kapsamı tek ekibe indirmenin başka bir yolu: Kebab vs Cake modeli
- Organizasyon yapısı, teknolojinin birçok ekibe yayılmak yerine tek bir ekip içinde çözülebileceği şekilde de tasarlanabilir
- Bunun temsilî örneklerinden biri Kebab vs Cake modelidir
- Ekipleri tüketici yolculuğuna göre kurgulayan, teknik sorumluluk alanını daraltan yapısal bir yaklaşım
- Bu modele dair ayrıntılı açıklama için Kebab vs Cake organization bağlantısına bakılabilir
-
Kebab mimarisi
- Ekipler sundukları işlevler etrafında organize olur
- Kullanıcı yolculuğu birden fazla ekibin çıktılarının içinden geçer
- Avantaj: Özerklik ve gevşek bağlılık
- Dezavantaj: Handover riski
-
Cake mimarisi
- Ekipler kullanıcı yolculuğu etrafında organize olur
- Bilişsel yük, soyutlama katmanları üzerinden yönetilir
- Avantaj: Uçtan uca sahiplik ve daha az handover
- Dezavantaj: Bilişsel yükün artma riski
- Staff Engineer yalnızca teknik bir rol değildir; tüm sistemin sorumluluğunu taşıyan bir sahip (owner) olarak şu üç unsura sahip olmalıdır:
- Bilgi (Knowledge):
- Teknoloji yığını ve ürün problemi hakkında derin anlayış
- Gerektiğinde bunları açıklayabilmeli ve bizzat uygulayabilmeli
- Yetki (Mandate):
- Teknolojinin nasıl gelişeceği ve sürdürüleceği konusunda söz söyleyebilecek konum
- Sorumluluk (Responsibility):
- Sistemin sağlığına ilişkin sorumluluk; kesintiler, teknik borç, dokümantasyon, teknik kopukluklar vb.
- Staff Engineer salt teknik bir rol değildir; organizasyonu teknik olarak yönlendirmek için soft skill'ler zorunludur
- Etkili iletişim, iş birliği yeteneği, liderlik gibi özellikler gerekir
- Ancak yalnızca soft skill'lere ağırlık verilirse şu sorunlar doğabilir:
- Gerçeklikten kopuk idealler sunup fiilen kodlama veya problem çözmeye katılmamak
- Ivory Tower Architect'e dönüşme riski
Sonuç
- Her organizasyonun Staff Engineer'a ihtiyacı yoktur. Aşağıdaki durumlarda bu rol olmadan da devam edilebilir:
- EM yeterince teknik yetkinliğe sahipse ve ekibin teknolojisini doğrudan yönlendirebiliyorsa
- Teknoloji yığını sağlıklı ve bakımı kolay durumdaysa
- Teknoloji tek bir ekip içinde tamamlanıyorsa ve ekipler arası bağımlılık neredeyse yoksa (Cake organizasyon modeli buna bir örnektir)
- Organizasyon olgunlaştıysa ve belirli bir sahip olmasa bile tüm sistemi iyi işletebiliyorsa
- Buna karşılık Staff Engineer bulunan bir organizasyonda şu noktalar net olmalıdır:
- Teknik sahiplik (technical ownership) açık biçimde tanımlanmalı
- Bu sorumluluk için Staff Engineer'a net accountability verilmelidir
- Temel çıkarımlar:
- Ivory Tower Architect'ten kaçınılmalıdır (gerçeklikten kopuktur)
- Bir rolü birden çok unvana bölmek verimsizdir
- Teknik olmayan EM de verimsizdir
- Son olarak, bu yazı mutlak bir kural değil, başvuru niteliğinde bir deneme yazısıdır
- Organizasyonlar, teknoloji, ürün, operasyon ve insanlar farklı olduğu için duruma uygun esnek değerlendirme önemlidir
- Körü körüne taklitten (cargo culting) kaçınılmalıdır → ilgili yazı
4 yorum
CTO'nun eli ayağı oldukları hissini veriyor.
Staff engineer: Deneye deneye yine de olmayınca gidip uğraştıracağın kişi.
Ahahah, çok katılıyorum
Yazının içeriğiyle çok ilgili değil ama
accountabilityveresponsibilityüzerine kafa yoruyordum; bu yüzden aşağıdaki bağlantı bana gerçekten çok yardımcı olduhttps://blog.alexewerlof.com/p/accountable-vs-responsible