Revize Edilmiş Mühendislik Liderliği Kuralları

• Yapay zeka araçlarına geçiş ve hızlı büyüme (hypergrowth) ortamında, son 1 yılda doğrulayıp yeniden tanımlanan mühendislik liderliğinin 5 temel kuralı ve bunları destekleyen gerçek proje örnekleri derleniyor
• Migrasyonlar artık ekipler değil bireyler tarafından %95 oranında yürütülebiliyor ve öncekinin %10’u kadar sürede tamamlanabiliyor; başlangıç maliyeti düştükçe bireysel muhakemenin etkisi büyüyor
• İlk sürüm kod neredeyse bedava, ancak düzgün çalışan kodun maliyeti test, CI/CD gibi geliştirme harness’i tarafından belirleniyor ve bedava değil
• Çoğu sürecin temel vakası ajanlarla tamamen otomatikleştirilebilir; kod incelemesinin ilk geçişinde de iyi bir harness, insandan daha hızlı ve daha etkili
• Yapay zekanın avantajlarını gerçekten elde etmek için alan bağlamına sahip kalıcı ekipler ile hızlı ve sağlam karar alma ön koşul

---

Arka plan

• 2014 başından 2020 sonuna kadar hypergrowth ortamında çalıştı; hypergrowth’un en büyük değeri, hataların gelecek yıl değil gelecek ay ortaya çıkması (hızlı hareket edilince sorunların büyük biçimde patlaması)
• Son dönemde hypergrowth’u yeniden düşünmesinin nedeni Imprint’in hızlı iş büyümesi, geçen yılki büyük ölçekli işe alımlar ve yapay zeka araçlarına geçiş ile iş yapma hızının değişmiş olması
• Bu yazı, yeniden tanımlanan liderlik kurallarını ve bu inancı kazandıran son 1 yıldaki somut projeleri birlikte derliyor

Revize edilen kurallar

1. Migrasyonlar ekipler değil bireyler tarafından yürütülebilir

• Karmaşık ve büyük değişikliklerde bile işi yöneten birey veya ekip %95 sahiplik alıyor ve işi eskisine kıyasla sürenin %10’unda tamamlıyor
• Başlangıç maliyeti düştükçe her migrasyonun kalitesine ilişkin ödül/ceza da büyüyor
  • Küçük kusurlar bile birlikte bakım yapan iş arkadaşlarının yazılıma dair zihinsel modelini bozuyor
• Şirket üzerinde bireysel muhakemenin etkisi hiç olmadığı kadar büyük

2. İlk sürüm kod neredeyse bedava, ama çalışan kodun maliyeti geliştirme harness’ine bağlı

• Herkesin kod yazması gereken bir çağda yaşıyoruz; ancak dağınık edge case’lerden kaçınarak iyi çalışan kod yazmak hâlâ zor
• Bu zorluk; testler, CI/CD, doğrulama ortamları, değişiklik önizlemeleri gibi geliştirme harness’i tarafından belirleniyor
• “Herkes kod yazıyor” denilen bir şirkette bile esas mesele pazarlama ekibinin sunucu tahsisini azaltması değil, onların güvenle katkı verebileceği sınırların var olup olmamasıdır (yazılım yazarak özelleştirmeye izin veren SaaS ürünlerine benzer)
• 2 yıl önce mühendislik hızını artırmak için en değerli olan şeyler, bugün de hâlâ en değerli şeyler

3. Süreçlerin temel vakasını ajanlara göre optimize et

• Uygun harness, kontrol, alan bağlamı ve tasarımcının doğru muhakemesi varsa çoğu sürecin temel vakası tamamen otomatikleştirilebilir
• İnsanların yaptığı kod incelemesinin temel vakası, iyi bir harness destekli kod incelemesinden daha yavaş ve daha az etkili
  • Harness de kaçırır, insan da kaçırır; çoğu alanda değişiklikler nispeten güvenlidir
  • Ancak bazı yüksek riskli alanlar istisnadır; bu ayrım doğru yakalanırsa risksiz biçimde daha hızlı olunur, başarısız olunursa sayısız sorun çıkar
• Bunun bir sonucu olarak, haftalık veya iki haftalık sprint gibi planlama süreçleri fazla düşük bir seviyede çalışıyor; insanların ortak planlaması daha yüksek seviyede yapılmalı

4. Alan bağlamına sahip kalıcı ve yüksek sahiplikli ekipler daha da önemli

• Uber’den çıkan ders: kalıcı ve sağlam ekipler, alan bağlamı biriktirerek, ekip ruhu oluşturarak ve güçlü sahiplik duygusuyla sihir gibi sonuçlar üretir
• Uygulama maliyetinin ucuzladığı bir çağda bile hâlâ doğru işi yapmak gerekir; bu biraz kolaylaşmıştır ama büyük ölçüde kolaylaşmamıştır
  • Örnek: üretim optimizasyonu için gereken veri hiç toplanmadığı için harness’in çözümü makul ama yanlıştı; tek çözüm eksik bilginin ölçümlenmesiydi
• Yapay zeka öncelikli şirketlerin birkaç dahi mühendisle işletileceği fikrine karşı çıkıyor; yüksek muhakemeli bireyler bile alan bağlamı eksikliği yüzünden sınıra çarpar, bu yüzden temel birim kalıcı ekiptir

5. Hızlı, iyi ve sağlam karar alma, yapay zekadan fayda görmenin ön koşulu

• Hukuk incelemesini otomasyonla değiştirmek için Legal ekibinin bu değişikliği taahhüt edebilmesi gerekir; bu da dikkatli tasarıma ve ekiplerin iş birliği isteğine bağlıdır
• Uygulama hızındaki artışın faydası ancak hızlı, sağlam ve iyi kararlar alınabildiğinde ortaya çıkar
• Ortalama CTO rolünün 1 yıl öncesine göre çok daha teknik ve daha az bürokratik hâle gelmesinin ana nedeni budur
  • Ekipler arası görüş ayrılıklarında bağlayıcı karar verebilen çoğu zaman tek kişi olduğu için, hızı korumak adına durmadan karar verir
  • Bu, yöneticilerin daha iyi karar verici olduğu iddiası değildir; ancak yöneticiler birbiriyle hizalı olup kararlara saygı gösterdiğinde bağlayıcı yönetici kararı eşsiz derecede güçlüdür

Gerçek uygulama örnekleri

Migrasyonlar

• 1 yıl önce haftada yaklaşık 6 manuel dağıtım varken bugün haftada 200~400 dağıtım yapılıyor; mühendis sayısı 2 katına çıksa da yıllık bazda 20~30 kat artış var ve dağıtım/migrasyon işletim biçiminin baştan sona yeniden kurulmasının %90’ını 2 kişilik altyapı ekibi iki ayda yaptı
• 1 Ocak’ta ekiplerin yaklaşık %25’i her gün Claude Code veya Cursor kullanıyordu; Şubat sonuna gelindiğinde bu oran %100 oldu. Yukarıdan aşağıya bir talimat olmadan, araç kalitesi iyileştirilip benimsemeyenlerle konuşularak sürtünme azaltıldı; bugün neredeyse tüm PR’lerin ilk taslağını harness hazırlıyor
• Farklı yapılandırma yöntemleri, iki yapılandırma mekanizmasında birleştirildi (neredeyse hiç değişmeyen istemci/sunucu sabitleri için biri, ürün bazlı ve sık değişen değerler için biri); bu işler bireysel mühendislerin bağımsız projeleri olarak yürütüldü
  • Bir kişi mimariyi toparladı → başka biri referans mimariyi uyguladı → birkaç kişi bunu başka alanlara taşıdı; eskiden yıllar sürecek bir proje iken bir çeyrekten kısa sürede tamamlandı ve mühendis ile mühendis olmayan ekiplerin değer yönetimi için iç araçlar da buna dahildi
• Multi-repo frontend yaklaşık bir ay içinde monorepo mimarisine birleştirildi; işin %95’ini tek bir frontend mühendisi yönetti, ortak bir frontend harness’i kazanıldı ve sürtünme kaynağı olan npm paket barındırmaya tamamen veda edildi
• Çoğunlukla typesız olan frontend kodu tamamen statik tiplemeye geçirildi; bir mühendis bunu birkaç hafta boyunca yüksek miktarda token kullanarak yaptı
• Daha iyi güvenlik varsayılanları ve daha hızlı dağıtım için npm’den pnpm’e geçildi; bir mühendis birkaç gün boyunca günde birkaç saat çalıştı

Çalışan kodun maliyeti geliştirme harness’ine bağlıdır

• Tasarım dokümanlarını veya PR’leri başka ekip mühendislerine “duvarın ötesine atmak” işe yaramıyor; kalitesiz (slop) PR’ler ve tasarım dokümanları ucuz olsa da aslında zararlı
  • Bunların düzenlenmesi ve düzeltilmesi gerekiyor; ayrıca taşıdıkları bağlam LLM’i kirleterek sıfırdan başlamaktan daha kötü sonuçlara yol açıyor
• Yönetici değişikliği bizzat doğrulayıp dağıtımdan sonra dashboard’ları kontrol ediyor ve çıkan sorunları çözüyor ise yöneticinin koda katkısı çok başarılı oluyor; aksi durumda olumlu bir etkisi olmuyor

Süreçlerin temel vakasını ajanlara göre optimize etmek

• Müşteri operasyon ekibine gelen tüm sorunlar; ekipleri ve açık ticket’ları bilen, veri ambarına sınırlı erişimle etkiyi hesaplayabilen bir harness tarafından triage ediliyor; karmaşık, yüksek beceri gerektiren ama ilginç olmayan emek daha hızlı işleniyor
  • Edge case’leri hâlâ insanlar triage ediyor ve insan iş akışı değiştirilmeden aynı akışta yalnızca bazı adımlar otomatikleştiriliyor
• Kod incelemesinin ilk geçişi, değişikliği uygulayan aynı harness tarafından, yazım bağlamı temizlenmiş şekilde yapılıyor; insanlar ise daha yüksek değerli geri bildirime odaklanıyor
• Geçen çeyrekte Claude Code ve Cowork şirket geneline dağıtıldı; özellikle fraud ekibi, elle yapılan işleri ilk aşama otomasyonla değiştirmekte çok agresif davrandı ve potansiyel saldırıların ilk incelemesini otomatikleştirdi (verinin kendisinden gelen attribution dahil)
• Jira’dan Linear’a geçildi; daha güçlü MCP ve daha iyi Slack entegrasyonu sayesinde ajan öncelikli iş akışı altyapısı güçlendirildi. Linear’dan issue çekip bunları otomatik çözen iç harness’in alfa testi neredeyse tamamlandı

Alan bağlamına sahip kalıcı ve yüksek sahiplikli ekipler

• Katıldığı dönemde yetenekli çalışanlar proje bazında alanlar arasında hızla dolaşıyor ve çok reaktif davranıyordu; bugün ise tüm önemli alanlara adanan küçük ekipler yerleştirilerek sürekli yatırım yapılıyor ve bu ekipler yeni yapay zeka tekniklerini doğrudan kullanıyor
• SierraAI yayımlandıktan sonra ekip onu sürekli iyileştirerek gerçekten olağanüstü bir seviyeye taşıdı; bu, adanmış ve odaklı ekipler olmadan mümkün olmayacak bir başarıydı

Hızlı, iyi ve sağlam karar alma

• Yapılandırma yöntemini değiştirmek tartışmalıydı; yaklaşım tekrar tekrar anlatıldı, çünkü etkiler ekipten ekibe değişiyordu ve fayda yalnızca ekosistem seviyesinde (bir kişinin tüm ekiplerin yapılandırmasını kurabilmesi) ortaya çıkıyordu; bu yüzden aşağıdan yukarıya ilerlemek zordu
• CI/CD pipeline’ının yeniden işlenmesi de dağıtım ve release’e dair zihinsel modeli değiştirdiği için tartışmalıydı; feature flagging ile dağıtım ve release’in açıkça ayrılması zorunlu kılındı
• Web monorepo birleşimi de görüş ayrılığı yaratan tartışmalı bir karardı ve birleştirilmiş kararın faydası büyüktü
• SierraAI’nin benimsenmesi, rakipler ve hiç benimsememe seçeneğiyle ilgili zorlu tartışmaları içeriyordu; çapraz fonksiyonel tartışmayı sonlandırmak için yönetici onayı gerekti

Sonuç

• Yukarıdaki örnekler yalnızca öne çıkan birkaç tanesi; bunun dışında da çok sayıda iş yapıldı ve mümkün olanların kapsamı her ay genişlemeye devam ediyor
• Ayağa dolanan etkenler büyük ölçüde değişmedi: örgütsel hizasızlık, netlik eksikliği, zayıf teknik mimari