Holakrasi'den Team Topologies'e: Gerçek Otonomi için Teknik Takımların Tasarımı

Liderliğin “takımlara daha çok otonomi veriyoruz” açıklaması her zaman karışık tepkilerle karşılanır. Sınırları olmayan otonomi genelde çözdüğünden çok problem yaratır.

Yaygın senaryo: matriks proje takımlarından ürün moduna, akışa-hizalanmış takımlara geçiş hız açısından gerçek kazanımlar üretir; ancak istenmeyen sonuçları da beraberinde getirir: daha fazla defekt, tekrarlanan çaba, takımların birbirinin ayağına basması. Temel içgörü şudur: etkili otonomi kısıtlamaları kaldırmak değil, doğru olanları tasarlamaktır.

Bu yazı Holakrasi, Spotify modeli ve Team Topologies’den seçerek yararlanmayı ele alıyor. Bağlam değişir; ancak bu pattern’ler ve korumalar deneme-yanılma maliyetini anlamlı ölçüde düşürür.

Otonominin Gerçekte Ne Anlama Geldiği

Başarılı otonomi girişimleri genelde şu temelleri doğru yapar:

• Karar hakları: Takım bağımsız olarak neye karar verebilir, nerede girdi veya onay alması gerekir? (Bu netlik “ben senin hallettiğini sanıyordum” durumlarını önlüyor)
• Net domain sahipliği: Bir takım problem alanını uçtan uca sahiplenir - yol haritası, kod, altyapı, on-call ve maliyet. Ortak sahiplik genelde sahipsizlik demek
• İnce, güvenilir arayüzler: Koordinasyon toplantıları yerine versiyonlanmış API’ler, event’ler ve kontratlarla etkileşim. Daha az konuşma, daha çok inşa etme
• Görevlerden ziyade sonuçlar: Bilet hızına değil sonuçlara ve SLO’lara taahhüt. Ne teslim edildiği herkesin ne kadar meşgul göründüğünden daha önemli

Bu sınırlar olmadan, organizasyonların “otonomi” dediği şey genelde takımların lokal optimizasyon yapması, genel sistemin zarar görmesi anlamına gelir. Başarılı otonomi net sınırlar içinde özgürlük sunar; doğru guardrail’lar olmadan otonomi sadece kâğıt üzerinde kalır.

Modellerden Nasıl Yararlanılır

Holakrasi (seçici parçalar)

• İşe yarayan: Rol tüzükleri (amaç, sorumluluklar, domainler) ve kısa “taktik” toplantılar gerginlikleri hızla yüzeye çıkarır. Sağlanan netlik değerlidir.
• Atlanabilecek: Tam yönetişim törenleri ve anayasa; düzenli feature ship eden takımlar için çok ağırdır.
• Dikkat: Roller hızla çoğalabilir. Canlı rol kataloğu tutun, her ay kullanılmayan rolleri kapatın.

Spotify Modeli (dil ve topluluklar)

• İşe yarayan: Squad’lar (çapraz fonksiyonel takımlar) ve guild’ler (uygulama toplulukları). Chapter’lar yalnızca koordinasyon gerektiren gerçek zanaat standartları varsa değer üretir.
• Atlanabilecek: Org şemasını olduğu gibi kopyalamak. Spotify bile “modelin” zamana bağlı bir anlık görüntü olduğunu, evrensel şablon olmadığını vurgular.
• Dikkat: Chapter lead’ler gölge yöneticiye dönüşebilir. Performans yönetimini açıkça squad liderinde tutun.

Team Topologies (temel çerçeve)

• İşe yarayan: Dört takım tipi ve üç etkileşim modu ortak dil sağlar:
  • Stream-aligned, Platform, Enabling, Complicated-Subsystem
  • Collaboration, X-as-a-Service, Facilitating
• Neden işe yarıyor: Conway Yasası ile örgüt tasarımını hizalar, bağımlılıkları görünür kılar. Ters Conway manevrası (mimariyi istenen takım sınırlarına göre şekillendirmek) özellikle güçlüdür.
• Dikkat: Platform takımları ürün takımı gibi davranmalı; SLA’lar ve “paved road” yayınlamalı; bilet fabrikası ya da bekçi olmamalıdır.

Otonomiyi Güvenli Kılan Korumalar

Sınırları olmayan otonomi kaosa dönüşme eğilimindedir. Aşağıdaki korumalar tutarlı biçimde işe yarar:

• Sahiplik haritası: Her domain, servis ve yetenek tam olarak bir takıma atanır. Ortak velayet pratikte nadiren işe yarıyor.

• SLO ve hata bütçeleri: Takımlar servis güvenilirliğinin sahibi; liderliğin işi bu hata bütçelerini erken optimizasyondan korumak.

• Değişim taksonomisi: Geri döndürülebilir değişiklikler etkilenen takımlardan tavsiye gerektirir; geri döndürülemez olanlar açık onay gerektirir. Jeff Bezos’un “tek yön vs iki yön kapı” kavramı org tasarımına uyarlanabilir.

• Karar kayıtları (ADR): Hafif, aranabilir; PR’lara linkli.

• Paved road: CI, deploy, gözlemlenebilirlik, kimlik vb. için görüş sahibi varsayılanlar. Olgunluk seviyeleri ve kaldırma takvimi yayınlayın.

• Etkileşim kontratları: Her çapraz bağımlılık için hedef etkileşim modu ve beklentiler yazılı.

• Metrikler: DORA (lead time, deploy sıklığı, MTTR, değişim hata oranı), takım sağlığı, platform NPS.

Geçiş Oyun Kitabı (12-24 Hafta)

1. Değer akışlarını haritalayın, 3-5 akışa-hizalanmış aday takım ilan edin; sahip oldukları sonuçları isimlendirin. Her takımın net bir müşterisi ve başarı kriteri olsun.
2. Mevcut bağımlılık grafiğini çizin; bekleme, yeniden iş, belirsiz sahiplik sıcak noktalarını işaretleyin. Bu harita genelde ilk “oh” anını yaratır.
3. Etkileşim modlarını tanımlayın; “toplantıyla koordinasyon”u öldürün. Her bağımlılık için Collaboration, X-as-a-Service veya Facilitating kararı verin.
4. Bir enabling takım kurun (8-12 hafta) test, gözlemlenebilirlik ve trunk-based development koçluğu için. Bu ekip kalıcı değil; sonunda squad’lara dağılır.
5. Platform = ürün: CI/CD, logging, auth, deney için golden path RFC yayınlayın. Opinionated varsayılanlar sunun; takımlar yolu bilmeli.
6. Servis sınırları: Repoları ve runtime sahipliğini takımlara hizalayın. Kod, on-call ve bütçeyi eş konumlayın.
7. Kadans: Haftalık taktik (squad), iki haftada bir guild, aylık mimari forum, üç aylık iş gözden geçirme.
8. Ölçün: DORA + incident + merge süresi baz çizgisi; 6/12/24. haftalarda tekrar ölçün. Metrikler olmadan gerçek ilerleme görülmez.

Yaygın Anti-Pattern’ler

Bu pattern’ler iyi niyetli otonomi çabalarını sabote eder:

• Otonomi tiyatrosu: Takımlar backlog’a “sahip” ama aslında deploy edemiyor, kadro alamıyor veya roadmap’i etkileyemiyor. Sahiplik hissi var ama anlamlı parçalar yok. Gerçek karar hakları olmadan otonomi sadece görünüşte kalır.

• Platform polisi: Paved road yerine sert onay kapıları. Yaratıcı engineer’lar bu kapıları atlatacak yol bulur; genelde işleri daha kırılgan hale getirir. Gatekeeper yaklaşımı işbirliğini bozar.

• Gölge yönetim: Chapter’lar veya guild’ler hiyerarşiyi yanlışlıkla geri getirir ve kararları yavaşlatır. Bunlar karar vermeyi kolaylaştırmak için vardı; bazen tam tersi olur.

• Matriks sızıntısı: Çift raporlama yapıları belirsiz karar hakları yaratır. Değer akışı başına tek iplikli lider daha iyi çalışır, “adil” hissetmese bile.

• Araç > sonuç: Karar hakları veya sınırlar değişmeden yeni törenler ve araçlar eklemek. Overhead artar ama problemler kalır.

Çalışan Şablonlar

Takım Tüzüğü (kopyala-yapıştır)

• Amaç: Takım neden var? Müşteri kim?
• Sonuçlar (12 ay): 3-5 ölçülebilir sonuç ve öncül göstergeler.
• Kapsam & sınırlar: Neler dahil/dahil değil? Hangi servisler ve domainler?
• Karar hakları: Tek başımıza neye karar veririz? Ne öneri/onay ister?
• Arayüzler: Sahiplendiğimiz API/event’ler; SLA/SLO’lar.
• İşletim modeli: Kadans, on-call, incident, release süreci.
• Metrikler: DORA, SLO, müşteri memnuniyeti, maliyet sınırları (ör. $/1000 istek).

Etkileşim Modu Kontrol Listesi

• Collaboration: Süre kutulu mu? Çıkış kriterleri net mi? Tek sahip var mı?
• X-as-a-Service: SLO’lar yayınlı mı? Runbook? Backlog girişi ve görünürlük?
• Facilitating: Koçluk hedefleri, yetenek transfer planı, bitiş tarihi?

Hafif Karar Akışı

• Küçük, geri döndürülebilir: Takım karar verir; ADR yazar.
• Çapraz takım, geri döndürülebilir: Etkilenen sahiplerden tavsiye al; gerekçeli itiraz yoksa ilerle.
• Geri döndürülemez/yüksek etki: Sahip liderlerden onay; risk ve geri alma planı yazılı.

Tasarımı ikame etmeyen ama yardım eden araçlar

• ADR repo + şablonlar ve arama. Kararlar aranabilir, PR’lara linkli kalır.
• Paved road skor kartları takım bazında. Olgunluk seviyeleri ve kaldırma takvimleri.
• Golden path iskeletleri (gözlemlenebilirlik ve auth gömülü). Yeni servisler doğru varsayılanlarla başlar.
• Org bağımlılık haritası wiki’de; üç ayda bir gözden geçirme. Bekleme ve belirsiz sahiplik sıcak noktaları görünür olur.

SSS: Otonomiyi Ne Zaman Zorlamamalı?

Bazen daha fazla yapı, daha az otonomiden daha iyidir. Ürün/pazar uyumu belirsizse daha sıkı hizalama ve daha az takım mantıklıdır. Güvenlik veya düzenleyici kritik alanlarda daha fazla onay ve izlenebilirlik gerekir. Çok küçük organizasyonlarda (<15 mühendis) yapı icat etmeyin; güçlü varsayılanlar ve net sahiplik genelde yeter.

Retrospektif

Tekrarlanan otonomi girişimlerinde tutarlı biçimde değerli çıkan pattern’ler şunlardır:

• Value stream ve sınırlardan başla, törenlerden değil: Yapı süreçten önemlidir. Önce sahiplik netleşsin, sonra toplantılar gelsin.
• Platformu ürün gibi erken yönet: Enabling takımlar ve bakımlı platform servisleri getiri sağlar; ancak olgunlaşması zaman alır. Platform takımlarına ürün sahibi atanmalı; bilet alıcı değil yol açıcı olmalılar.
• Yazıya dök: Tüzükler, SLO’lar, ADR’ler, etkileşim modları. Sözlü bilgi ölçeklenmez.
• Sonuçları önce ölç: Organizasyonel yapıyı metriklere göre ayarlayın, hissiyata göre değil. DORA metrikleri, incident süreleri ve merge zamanları nesnel sinyal verir.

Sonuçlar organizasyon kültürüne, büyüklüğüne ve teknik olgunluğa göre değişir. En önemli olan, değiş tokuşlar konusunda bilinçli olmaktır.

Kaynaklar

• Team Topologies - Resmi Kitap Sayfası - Skelton ve Pais; bu yazıda açıklanan dört ekip türü ve üç etkileşim modunun temel çerçevesi.
• Holacracy - Öz-Yönetim İşletim Sistemi - HolacracyOne’ın resmi sitesi; Brian Robertson’ın rol tüzüğü ve rıza yönetişimi modeli.
• Spotify Mühendislik Kültürü Bölüm 1 - Henrik Kniberg - Takım, kabile, bölüm ve lonca kavramlarını tanıtan 2014 tarihli özgün Spotify yazısı.
• DORA Accelerate State of DevOps Report 2024 - Yazı boyunca kullanılan DORA metriklerinin (öncü süre, dağıtım sıklığı, MTTR, değişiklik hata oranı) araştırma temeli.
• Conway Yasası - Melvin Conway (1968) - Özgün formülasyon; burada ele alınan Ters Conway Manevrası bu makaleden türemiştir.
• Martin Fowler - Conway Yasası (bliki) - Conway Yasası ve Ters Conway Manevrası’nın mikro servisler ve ekip tasarımı bağlamında pratik açıklaması.
• Drive - Daniel Pink - Otonomi, ustalık ve amaç çerçevesi; ekip özerkliğinin neden önemli olduğunun motivasyonel temeli.