Staff Engineer Solver Arketipi: Bir Operasyon Modeli

Mühendislik organizasyonlarında kendiliğinden oluşan gayri resmi hızlı şerit#

Belirli bir ölçeği aşan mühendislik organizasyonlarının çoğunda, standart SDLC’nin yanına sessizce ikinci bir şerit kurulur: beklemeye fazla stratejik, planlamaya fazla belirsiz, tam ekip ayırmaya fazla dar işler için. Bu örüntü sektörden bağımsız tekrarlar: yönetici sponsorluğu, bir veya iki kıdemli mühendis, aylarla ölçülen bir süre ve tanınabilir küçük bir sonuç kümesi. Bu şeritlerin çoğu uygulama nedeniyle değil, ilk proje şeride girmeden önce operasyon modelini kimse yazmadığı için başarısız olur.

Bu örüntünün literatürde bir adı var; ancak çoğu organizasyon bu adı duymadan rolü kuruyor. Will Larson’ın StaffEng çalışmasında bu şeridin merkezindeki rol Solver olarak adlandırılıyor: yönetici sponsorluğuyla zor problemler arasında dolaşan, sabit takımı olmayan kıdemli mühendis. Larson’ın arketipi başlangıç noktası; şeridin asıl eksiği ise yazılı bir operasyon modeli ve şeridin hiç kurulmaması gereken durumların açıkça belirlenmesi.

Larson’ın dört arketipi ve Solver’ın nadirliği#

Larson’ın StaffEng taksonomisi Staff-plus rollerinin dört yaygın arketipini adlandırır: Tech Lead, Architect, Solver ve Right Hand. Her biri kendi operasyon modelini ima eder: farklı sponsorluk, farklı kapsam, farklı çıkış. Sana önerilen rol buysa (yönetici sponsorluğunda, tek proje, sabit takım yok, tanımlı çıkış), devam etmeden önce yazıya dökmen gereken biçim aşağıda.

Tech Lead “belirli bir takımın yaklaşımına ve uygulamasına yön verir,” odaklı bir alanda bir ila üç yöneticiyle yakın çalışır. Architect “kritik bir alanın yönü, kalitesi ve yaklaşımından sorumludur” ve teknik kısıtları, kullanıcı ihtiyaçlarını ve organizasyon düzeyinde liderliği birleştirir. Solver “keyfi karmaşıklıktaki problemlere derin dalar ve uygun bir yol bulur”; bazen aynı alanda yıllarca kalır, bazen liderliğin yönlendirmesiyle sıcak noktadan sıcak noktaya hareket eder. Right Hand ise “bir yöneticinin dikkatini genişletir, özellikle karmaşık organizasyonları işletmek için onun kapsamını ve yetkisini ödünç alır.”

Larson’ın Solver hakkında öne çıkarılmaya değer iki gözlemi daha var. Rol “planlamanın ve sahipliğin atomik birimi olarak takımları değil bireyleri düşünen şirketlerde en yaygın olanıdır”; bu çerçeve, rolün neden ortaya çıktığını açıklıyor. Ve Solver’lar “bir problem kontrol altına alındığında çalışmayı bırakma eğilimindedir; bu durum geçicilik hissi yaratabilir ve ‘çözülmüş’ problemi sürdürmek için geride bırakılan takımları kızdırmamak için ince bir dokunuş gerektirir.”

Solver dörtlü içinde en nadiridir çünkü kalıcı takım üyeliği olmadan sürekli yönetici sponsorluğu gerektirir; çoğu organizasyon bu şekli uzun süre tutamaz. En sık yanlış uygulanan rol olmasının nedeni ise hata modlarının ancak altı ay sonra görünür hale gelmesi; o noktada rol çoktan kemikleşmiştir.

Adı konulması gereken bir karma durum da var. Ödemelerde, kimlikte ya da ML platformunda iki yıl boyunca kalan bir Solver, raporlama hattı dışında bir Architect’ten operasyonel olarak ayırt edilemez. Pragmatic Engineer’da Gergely Orosz pratikte aynı kişinin bu arketipler arasında sıklıkla geçiş yaptığını söylüyor. Taksonomi onları ayrı tutuyor çünkü operasyon modelleri gerçekten farklı; aralarındaki ayrımı çoğunlukla raporlama yapısı ve zaman sınırı yapıyor.

Kuralları yazılmamış hızlı şeritlerin üç hata modu#

İkili Mod Tuzağı. Gartner’ın 2014 Bimodal IT çerçevesi teslimatı Mode 1 (öngörülebilir) ve Mode 2 (keşifsel) olarak ikiye böldü; 2018-2020 sektör post-mortemleri tahmin edilebilir başarısızlığı belgeledi ve Simon Wardley çerçeveyi kaçınılmaz bir karışıklığa davetiye olarak nitelendirdi. Bunun küçük ölçekli hali doğrudan seni etkiliyor: şeridin “teslim eden havalı takım”, standart SDLC “sürdüren takım” olarak görülmeye başlanıyor; bu algı hem seni hem mühendisliğin geri kalanını aşındırıyor ve zamanla şeridin dışındaki mühendislerin gözünde akran olmaktan çıkıyorsun.

Vazgeçilmezlik Tuzağı. Aynı anda üç stratejik projeyi anlayan tek kişi sen oluyorsun. Seni herhangi birinden çekmek kabul edilemez risk taşıyor. Terfi konuşmaları duruyor ve genellikle “şu an yaptığın işi yapmaya devam etmen lazım” şeklinde geliyor. Ücret tempoya yetişebilir ama kapsam ve unvan genelde geride kalır. Solver tipik olarak on iki ila on sekiz ay içinde ayrılır ve stratejik iş de onunla birlikte gider.

Patron Projesi Şeridi. Yazılı giriş kriterleri olmadan işin, sponsor yöneticinin keyfine göre kayıyor. Şirket birleşmesi entegrasyon mimarisinden CEO’nun fiyatlama denemesine, oradan kurula gösterilecek yapay zekâ demosuna geçiyorsun; hiçbiri bir alan takımına devredilmiyor. Şeridin dışından bakınca işin hesap verebilir görünmüyor, içinden bakınca ise sınırsız görünüyor.

Üçü de aynı boşluğa çıkıyor. Giriş kriterleri, karar yetkisi, gözden geçirme süreci, bilgi çıktıları ve çıkış koşulları hiç belirlenmemişti; şerit de o çeyrek sponsor yönetici ne istiyorsa ona göre şekillendi.

El kitabı: sekiz bölümlük bir operasyon modeli#

Çare cazip değil. Aşağıdaki sekiz bölüm, devam etmeyi kabul etmeden ya da bir sonraki proje şeride girmeden önce sponsoruna sunduğun çerçeve. Her biri bitmiş bir belgede kasıtlı olarak yarımşar sayfa. Kırk sayfalık bir el kitabı okunmaz; doğru yüzey alanını kapsayan sekiz kısa bölüm okunur. Bunu yazıya dökmek asıl karşılığını, sponsorla belirli bir kararda ilk anlaşmazlığa düştüğünüzde veriyor: konuyu rolü baştan müzakere etmeden kapatabiliyorsunuz.

Rol tanımı#

Solver, tanımlı bir sponsordan (VP Engineering ve CTO, ya da yerel karşılığı) tek proje görevleri alan, projenin süresi boyunca takım tahsisi dışında çalışan ve projeyi tanımlı bir alıcı takıma ya da bir sonraki göreve devrederek çıkan, Staff ya da Principal düzeyinde bireysel katkı sağlayan bir roldür. Kalıcı bir raporlama yapısı ya da başıboş bir iç danışmanlık değildir, çünkü rol başladıktan sonra ne proje süresi ne de görev tanımı üzerinde pazarlık yapılabilir.

Giriş kriterleri#

Şeride herhangi bir proje girmeden önce organizasyonun değer, süre ve belirsizlik olmak üzere nicel eşiklerde anlaşması gerekir ve bir proje ancak üçünü birden karşılarsa şeride girmeye hak kazanır. Yerel bağlama uyarlanacak makul varsayılanlar: belirtilen bir çıtanın üzerinde iş değeri (örneğin, yıllık iki milyon avronun üzerinde etki ya da şirketin planlama belgelerinde stratejik öncelik düzeyinde bir bağımlılık) ve sınırlı süre (altı ay hedef, dokuz ay kesin tavan). Üçüncü eşik belirsizlik: standart SDLC’de keşiften spesifikasyona geçiş zaman çizelgesinin yüzde kırkından fazlasını yiyecekse, belirsizlik bu şerit için yeterince yüksektir. Değer çıtasının altındaki iş standart şeride gider. Süre tavanının üstündeki iş için Solver görevi uzatılmaz, takım kurulur. Düşük belirsizlikteki iş de standart şeride aittir.

Karar yetkisi#

Yazıya dökülmüş; böylece Solver ve sponsor her pazartesi sınırları yeniden müzakere etmek zorunda kalmaz.

Matris en yaygın Solver sürtüşmesini ortadan kaldırır: hangi kararı Solver tek başına alabilir, hangisi yukarı taşınmak zorundadır belirsizliği. Şeritler adlandırıldığında iki taraf belirli bir kararda anlaşmazlığa düşse bile sürecin nasıl işleyeceğinde anlaşmaya varmış olur.

Kalite çerçevesi#

Geri alınamaz her karar, Michael Nygard biçiminde bir Architecture Decision Record alır: başlık, bağlam, karar, durum, sonuçlar. Alıcı takımdan ya da platform takımından atanmış bir gözden geçiren, her pull request’i onaylar. Solver yazar; gözden geçiren onaylar; Solver merge eder. AI destekli ilk geçiş incelemesine, gözden geçiren kişinin işini hızlandırmak için izin verilir; onayı yine atanmış gözden geçiren verir. Regülasyona tabi bağlamlarda bu bölüm diğerlerinden daha çok okunur; o duruma ayrılmış başlık aşağıda geliyor.

Bilgi çıktıları#

Proje çıkışında Solver, projenin tamamlanmış sayılması için gereken üç çıktıyı devreder: geri alınamaz her kararı kapsayan bir ADR seti, alıcı takımın elinde tutabileceği bir operasyonel runbook (nasıl deploy edilir, nasıl rollback alınır, gözlemlenebilirlikte neye bakılır, bilinen hata modları ve ilk müdahaleleri) ve sistemin neden bu şekilde göründüğünü anlatan, Solver’ın iş sırasında kafasında taşıdığı modeli yüzeye çıkaran bir alan dokümanı.

Devir protokolü#

Alıcı takım temsilcisi birinci haftadan itibaren işin içindedir. Desen gömülü gözlemcidir: takvim zamanı ayrılmış, atanmış bir mühendis; tasarım tartışmalarına katılır, pull request’leri inceler, operasyonel kararları gölgeden takip eder. Sahiplik, üç çıktının sunulduğu ve teslim alındığının kabul edildiği resmi bir devir etkinliğiyle aktarılır. Tipik olarak otuz günlük takvim sınırlı bir destek penceresi izler; bu süre boyunca Solver düşük öncelikle sorulara erişilebilir kalır. Pencere kapandığında Solver tamamen serbest bırakılır.

Başarı ölçütleri#

Teslimat ve etki iki eksendir, hiçbiri tek başına yeterli değildir: teslimat, projenin süre ve değer kriterlerini karşılayıp karşılamadığını sorar; etki ise çıktıların ve desenlerin yayılıp yayılmadığını sorar. Teslim eden ama etki üretmeyen bir Solver de, desenleri yayılan ama hiç teslim etmeyen bir Solver de rolde başarısız demektir. Etki ekseni somut ölçülür: sonraki projeler tarafından atıf yapılan ADR’ler, alıcı takımın değişiklik yapmadan benimsediği runbook’lar, başka takımların aldığı desenler. Teslimat ekseni, projenin kabul ettiği giriş kriterlerine göre ölçülür.

Kariyer yolu#

Solver, daha uzun bir yolun üzerindeki bir duraktır. Varsayılan rotasyon bir buçuk ila üç yıl içinde iki ila dört proje, ardından çıkıştır: alan derinliği için Architect’e, yönetici kapsamı için Right Hand’e ya da Tech Lead olarak bir takıma geri dönüş. Çıkış koşulları giriş öncesinde yazılır. Halef yetiştirme, adı konmuş bir yükümlülüktür: görev süresi boyunca Solver, Staff kapsamına doğru en az bir mühendise mentorluk yapar.

Özel durum: regülasyona tabi sektörler#

Sponsorunun şeride duyduğu hevesin içinde “daha hızlı hareket edebilirsin çünkü sana güveniyoruz” varsa, bu bölümü iki kez oku. SOC 2, BaFin ya da HIPAA bağlamlarında Solver şeridi, güveni kontrolün yerine koyamıyor. Kıdem ne olursa olsun kendi kodunu incele-ve-merge edemezsin; aşağıdaki talepler, rolü kabul etmeden önce el kitabına girmesi gerekenler.

SOC 2 CC8.1 (değişiklik yönetimi), yetkilendirilmiş değişiklikleri belgelenmiş gözden geçirme ve onayla zorunlu kılar; kendi değişikliğini gözden geçiren bir Solver, denetçilerin bulgu olarak işaretlediği bir öz onay yapıyor demektir. BaFin’in MaRisk AT 7.2’si regüle işi destekleyen sistemlerde geliştirme ile onay arasında görev ayrılığını (Funktionstrennung) zorunlu kılar; BAIT genelgesi aynı beklentiyi özellikle IT’ye genişletir. HIPAA’nın §164.308(a)(3) çalışan güvenliği standardı uygun erişim, denetim ve yetkilendirme sağlayan politika ve prosedürleri zorunlu kılar; kendi üretim değişikliklerini tek başına yetkilendiren bir Solver bunu karşılamaz.

El kitabı konuşmasına somut talepler getir. Proje şartnamesinde adı geçen, atanmış bir dış gözden geçiren (alıcı takımın tech lead’i ya da bir platform veya güvenlik mühendisi) her pull request’i onaylar. Risk katmanlı gözden geçirme maliyeti yönetilebilir tutar: düşük riskli değişiklikler (config, doküman, iç araçlar) standart tek gözden geçiren akışını izler; yüksek riskli değişiklikler (veri katmanı, kimlik doğrulama sınırı, para yolu) iki gözden geçiren ister, biri proje dışından olur. Merge sonrası denetim kaçınılmaz aciliyetleri karşılar: sen merge edersin, atanmış gözden geçiren yirmi dört saat içinde denetler, sapma değişiklik kaydında loglanır. Son desen kullanılmadan önce uyum biriminden açık onay almak gerekir; denetim onu CC8.1’den loglanmış bir sapma olarak okur.

Solver şeridinin yanlış cevap olduğu durumlar#

Rolü kabul etmeden önce işin kendisi üzerinde bu ayrıştırmayı çalıştır. Pratik soru tek cümle: bu iş gelecek yıl farklı bir biçimde tekrar mı edecek, yoksa tanımlı bir sonu olan tekil bir proje mi? Tekrar, Architect’i işaret eder: alana bağlı, sürekli sahiplik, bir yol haritası ve takım ile birlikte. Tekillik, Solver’ı işaret eder: projeye bağlı, alıcı takıma devredilir. Solver görevi kılığına sokulmuş bir Architect rolü vazgeçilmezlik tuzağına dönüşür çünkü iş gerçekten tekrarlayan iştir; proje sandığın şey aslında bir alandı. İşin birincisiyse geri it ve Architect çerçevesini iste.

Doğrudan reddedilmesi gereken desenler var; önerinin gerçek nedeni bunlardan biriyse doğru hamle onu reddetmektir. Elde tutma aracı olarak Solver: rol, kılık değiştirmiş bir karşı teklif; amaç senin ayrılmanı engellemek. İş zaten esas mesele olmadığı için hata modları hızlanıyor. Kapsam kararsızlığının park yeri olarak Solver: liderlik bir problemin hangi takımda olacağına karar veremiyor ve problem süresiz olarak sende kalıyor. Akran şirket taklidi olarak Solver: benzer bir şirkette bu rol var, seninki de operasyon modelini yazmadan aynı şekle uzanıyor.

Staff yolundakiler için kariyer notları#

El kitabını yazmak başlı başına Staff ya da Principal kapsamda bir iştir. Daha önce gayri resmi yürüyen bir rol için operasyon modelini sabitlemek; organizasyon çapında, çok paydaşlı, kalıcı çıktı üreten bir katkıdır. Terfi komiteleri L7, E6, Staff ya da eşdeğer seviyelerde bu şekildeki katkıyı tanır. El kitabını bir kaldıraç aracına dönüştüren şey bu gerçeklik; gelişigüzel yayınlanmasını riskli yapan da yine bu.

Risk yapısal: el kitabını yazıyorsun, yayınlıyorsun, tasarladığın role başkasının alındığını izliyorsun. Önlem, sıralamada. El kitabı konuşması ile unvan-kapsam-ücret konuşması birlikte kapanmak zorunda. İşleyen bir sıralama şöyle görünür. İlk olarak, operasyon modelini organizasyonun çözmesi gereken bir problem olarak VP Engineering ile CTO’ya götür. İkinci olarak, işin gerçek olduğu ve rolün tanım gerektirdiği konusunda sözlü hizalanma sağla. Üçüncü olarak, aynı konuşmada hem el kitabını yazmayı hem de el kitabı içindeki rolünü öner. Dördüncü olarak, el kitabı taslağı ile rol-ve-ücret mektubunu aynı hafta içinde sonuçlandır.

Liderlik bu sıralamayı reddediyorsa, el kitabı konuşmasına “unvan ve kapsamına bu projeyi teslim ettikten sonra geliriz” cevabı geliyorsa, bu ret vazgeçilmezlik tuzağının gerçek zamanlı oluşumudur. Doğru hamle, konuşma sıralanana kadar el kitabını yazmayı reddetmek. Sonra konuşulacağı sözüyle, unvan-kapsam-ücret konuşmasının önünde operasyon modelini taslaklamak, elindeki tek kaldıracı ortadan kaldırır.

Ücret konuşmasının da doğru yüzey alanını kapsaması gerekir. Kapsam ve unvan da taban maaşla birlikte işin temposuna ayak uydurmak zorunda. Hisse yenilemesi ve rotasyon takvimi aynı konuşmaya dahildir: rol bir buçuk ila üç yıl içinde iki ila dört projeyse, yenileme ve hak ediş eşiği bu yaya oturmak zorunda. Çıkış koşulları, ilk projeden önce üzerinde anlaşılan yazılı bir önkoşuldur. Rotasyon deseni, tipik olarak iki ila dört proje ve ardından Architect, Right Hand ya da Tech Lead’e çıkış, el kitabında imzadan önce adlandırılır; erken çıkış için tetikleyici koşullar (sponsor değişikliği, projenin sonlandırılması, vazgeçilmezlik sinyali) açıkça listelenir.

Halef yetiştirme, tarihi belli olan yakın vadeli bir yükümlülüktür. Görev süren boyunca en az bir mühendise Staff kapsamına doğru mentorluk yaparsın; el kitabında adıyla yazılı ve takvimde zamanı ayrılmış olarak. Bu kısmen şeridin senin nihai çıkışından sonra hayatta kalmasının yolu; kısmen de biçimi tutan tek kişi olmaktan kaçınmanın yolu.

El kitabının değeri yayınlanmadan önce ortaya çıkar. Organizasyonun operasyon modeli olarak yayınlandığında ve başka insanlar onun içinde çalışmaya başladığında yazarın o model içindeki rolü kararlaşır. El kitabını yazmak yazarına rolü hak ettirmez. Yayınlanmadan önce o rol için müzakere edebileceği güvenilir bir konum verir; bu, daha sağlam ve farklı bir avantaj biçimidir.

Gayri resmi hızlı şeritten yazılı bir operasyon modeline#

Sekiz bölüm, her biri yarımşar sayfa, adı belgede yer alan VP seviyesinde bir sponsorla birlikte yazılmış ve unvan-kapsam-ücret mektubuyla aynı hafta kapanmış. Bunun için doğru zaman, bir sonraki proje şeride girmeden ve müzakere kaldıracın hâlâ elindeyken.

Bir üst basamaktaki soru açıkta kalıyor. El kitabı yönetici sponsorluğu yaratmaz ve rolü hak ettiren stratejik düzeydeki işi üretemez. O iş olmadan operasyon modelinin üzerinde çalışacak bir şey yoktur.

Kaynaklar#

• StaffEng: Staff Archetypes (Will Larson) (yeni sekmede açılır). Dört arketipli taksonominin (Tech Lead, Architect, Solver, Right Hand) birincil kaynağı; her arketipin Larson’a ait birebir tanımını içerir.
• Lethain.com: Staff Engineer kitap dizini (Will Larson) (yeni sekmede açılır). Larson’ın kitaba dönüşen makalelerini indeksleyen kişisel sitesi; StaffEng sayfalarını tamamlar.
• StaffEng: Staff Engineer kitap sayfası (Will Larson) (yeni sekmede açılır). Arketiplerin ve kariyer yolu tartışmasının kitap biçimindeki ele alınışı.
• Pragmatic Engineer: Staff+ Engineer Nedir? (Gergely Orosz) (yeni sekmede açılır). Orosz’un Staff+ rollerine genel bakışı; aynı kişinin pratikte arketipler arasında nasıl geçiş yaptığını da anlatıyor.
• Pragmatic Engineer: Software Architect Arketipleri (Gergely Orosz) (yeni sekmede açılır). Architect tipi rollerin paralel ele alınışı; bir Architect görevini Solver görevinden ayırmak için yararlı.
• Michael Nygard: Mimari Kararları Belgelemek (2011) (yeni sekmede açılır). ADR biçiminin kök makalesi; beş başlığıyla birlikte: Title, Context, Decision, Status, Consequences.
• Joel Parker Henderson: ADR şablonları (GitHub) (yeni sekmede açılır). Nygard biçimini genişleten kanonik şablonlar; kalite çerçevesi bölümü için pratik referans.
• Simon Wardley: Bimodal IT, eski havalı şeyin yeni versiyonu (Bits or pieces?) (yeni sekmede açılır). Wardley’in Gartner’ın Bimodal IT çerçevesine eleştirisi ve çerçeveye bağladığı organizasyonel hasar.
• Simon Wardley: İki hızlı IT, daha çok baktıkça daha kötüye gidiyor (yeni sekmede açılır). Wardley’in bimodal eleştirisini bir yıllık ek gözlemle genişleten devam yazısı.
• Gartner sözlük: Bimodal (yeni sekmede açılır). Gartner’ın Bimodal IT (Mode 1 / Mode 2) tanımı; çerçeveyi kendi terimleriyle okumak isteyenler için.
• BaFin Genelge 06/2024 (BA): MaRisk (Almanca) (yeni sekmede açılır). Güncel MaRisk genelgesi; AT 7.2 risk yönetiminde IT’yi kapsar ve geliştirme ile onay arasında görev ayrılığını içerir.
• BaFin Genelge 10/2021 (BA): MaRisk (İngilizce) (yeni sekmede açılır). Önceki MaRisk sürümünün İngilizce versiyonu; AT 7.2 IT görev ayrılığı maddelerini içerir. Regülasyona tabi okurlar güncel Almanca sürümü işletme dili olarak takip etmelidir.
• BaFin Genelge 10/2017 BAIT: Finansal Kurumlarda IT için Denetim Gereksinimleri (İngilizce PDF) (yeni sekmede açılır). MaRisk AT 7.2’yi IT’ye özel gereksinimlerle genişleten BAIT genelgesi; IT görev ayrılığı için daha kesin referans.
• eCFR: 45 CFR 164.308 İdari güvenlik önlemleri (yeni sekmede açılır). HIPAA §164.308’in yetkili güncel metni; erişim, denetim ve yetkilendirmeyi düzenleyen (a)(3) Workforce Security standardını içerir.
• AICPA: SOC 2 için Trust Services Criteria (yeni sekmede açılır). AICPA SOC 2 TSC açılış sayfası; CC8.1 (Değişiklik Yönetimi) maddesi, yetkilendirilmiş değişikliklerin belgelenmiş gözden geçirilmesini ve onaylanmasını kapsar.