Mühendislik Takımlarında Lewis Deep Democracy: Sahte Konsensüsün Ötesinde

Oybirliğiyle alınmış gibi görünen teknik kararların arkasında çoğu zaman gerçek bir mutabakat yoktur. Sebep çoğunlukla mühendislik yetersizliğinden çok rütbe farkları ve zayıf psikolojik güvenliktir. Arnold Mindell’in Deep Democracy yaklaşımı burada işe yarar bir varsayılan sunar: muhalefeti tasarım girdisi say, kararın yanına yaz ve azınlık endişesi haklı çıktığında devreye girecek inceleme tetikleyicileri tanımla.

Gölge Monolit#

Pek çok mimari incelemede herkes açıkça katılıyor görünür, sonra altı ay sonra kimse endişesini dile getirmediği için karar sessizce tersine döner. Sessizlik onay diye okunur ve bu okumanın doğruluğu neredeyse hiç sınanmaz.

Bir fintech şirketindeki mikroservis migrasyonunu ele alalım. Kıdemli mimarlar 47 servis, tam event-driven mimari, her yerde Kafka’ya karar verdiler. Junior mühendisler gülümseyip başlarını salladılar. Altı ay sonra takım, “Gölge Monolit” denilebilecek şeyi yaratmıştı: operasyonel karmaşıklık konusundaki endişelerini dile getiremedikleri için eski sistemi büyük ölçüde yeniden üreten gizli bir ortak kütüphane. Yeniden yazmanın maliyeti, kimsenin adını koymaya cesaret edemediği operasyonel karmaşıklığın maliyetini aştı.

Aynı kalıp daha küçük kararlarda da çıkıyor. Liderlik, data ekibinin ilişkisel gereksinim uyarılarına rağmen doküman depolarını tercih etti; ekip “karar çoktan verilmişti” diyerek MongoDB’yi seçti ve PostgreSQL’e başarısız migrasyon altı ay sonra geldi. O noktada uyarıyı yapan mühendisler çoktan ayrılmıştı. Güvenlik ekipleri kimlik doğrulama açıklarını incelemeye taşır, “bunu sonra ele alırız” cevabını alır ve erteleme açık dışarıdan bulunana kadar sürer. Dağıtık ekipler başkasının mesai saatine kurulmuş incelemeleri kaçırır, sonra yıllarca birinin bakımını üstlendiği paralel sistemler kurar. Bunların hiçbiri bilinmeyen risk değildi. Her biri yüksek sesle söylendi ve gidecek yeri yoktu.

Mühendislik Takımları İçin Deep Democracy#

Arnold Mindell, Deep Democracy kavramını 1980’lerin sonunda Süreç Odaklı Psikoloji çalışmalarından doğurdu. Myrna ve Greg Lewis daha sonra bunu, geleneksel konsensüs modellerinin çarpıcı şekilde başarısız olduğu apartheid sonrası Güney Afrika’da pratik bir kolaylaştırma yöntemine dönüştürdü. Temel kavrayış: azınlık sesi çoğunlukla çoğunluğun ihtiyaç duyduğu ama duymak istemediği bilgeliği taşır.

Mühendislik terimleriyle Deep Democracy şu anlama geliyor:

• Her rütbede bilgelik vardır: Junior mühendisler, kıdemlilerin görmezden gelmeyi öğrendiği sorunları görür
• Muhalefet veridir: “Hayır” oyları üretimde nelerin bozulacağını söyler
• Güç dinamikleri gerçektir: Kıdem, dil akıcılığı, zaman dilimi yakınlığı görünmez hiyerarşiler yaratır
• Konsensüs endişeleri içerir: Anlaşma “bununla yaşayabilirim ve endişelerim belgelendi” demek

Teknik Ekipler İçin Lewis Metodu#

Mindell’in çalışmasından geliştirilen Lewis Metodu, bu fikri kolaylaştırma hamlelerine dönüştürür. Bunlardan dördü mühendislik kararlarına doğrudan oturuyor.

Rütbe Haritası#

Bu dinamikleri görünür kılmak odayı okuma biçiminizi değiştirir. O “oybirliğiyle alınan” veritabanı kararı, konuşanların yalnızca tek bir zaman dilimindekiler olduğunu fark edince farklı görünür. Büyük bir teknik karardan önce çıkarılan rütbe haritası, sahadaki üç rütbe türünü sıralar:

Eşit Söz Hakkı Mekanizmaları#

Round-Robin Mimari İnceleme: Herkes ikinci bir endişe sunmadan önce birinci endişesini sunar. Kural basit, etkisi kimin duyulduğunu değiştirmesinde. Bir uygulamada bu kural, başarısız her istekte müşteriyi iki kez ücretlendirecek retry logic hakkında bir junior mühendisin endişesini ortaya çıkardı.

Beş Parmak Oylaması: Önerilerin ardından herkes parmak gösterir:

• 5 parmak: “Harika, hadi yapalım”
• 4 parmak: “Küçük endişelerle iyi”
• 3 parmak: “Tarafsız, desteklerim”
• 2 parmak: “Büyük endişeler, tartışma gerekli”
• 1 parmak: “Aktif olarak engellerim”

1-2 parmak gösteren herkes açıklama yapmak için kesintisiz zaman alır. Endişeleri ele alınmalı veya devam etmeden önce açıkça belgelenmelidir.

Devil’s Advocate Rotasyonu: Her mimari inceleme, öneriye karşı argüman üretecek birini atar. Bu rolü döndürmek “belirlenmiş karamsar” problemini önler ve muhalefetin meşru olmasını sağlar.

Async-First Karar Verme#

Senkron toplantılar belirli kişilikleri ve zaman dilimlerini kayırır. Async-first bir kurulum şöyle görünür:

interface AsyncDecisionProcess {
  proposal_period: "Minimum 48 saat";
  comment_threads: "Thread'li, doğrusal değil";
  voting_window: "Tartışma kapandıktan 24 saat sonra";
  minority_reports: "2-parmak oyları için gerekli";
  decision_record: "Öneri + endişeler + hafifletici tedbirleri yakalar";
}

Async-first’e geçmek, çalışma saatleri toplantı slotuyla hiç kesişmeyen mühendisleri sürece dahil eder. Onların yazılı yorumları genelde bir toplantıda hiç gündeme gelmeyen hata senaryolarına düşer: veri kaybı yolları, saklama sınır durumları, bölgesel kısıtlar.

ADR İçinde Muhalefet#

Geleneksel ADR’lar ne kararlaştırdığımızı yakalar. Deep Democracy ADR’ları buna neyin bizi endişelendirdiğini de ekler ve bunun değeri inceleme tetikleyicilerinde ortaya çıkar:

# ADR-042: Kubernetes'e Migrate Et

## Durum
Çekincelerle Kabul Edildi

## Bağlam
Container orkestasyonu için EC2'den Kubernetes'e geçiş...

## Karar
6 ayda EKS'e migrate edeceğiz...

## Sonuçlar
### Pozitif
- Auto-scaling iyileştirmeleri
- Daha iyi kaynak kullanımı
- Endüstri standardı tooling

### Negatif (Kabul Edilen Endişeler)
- **Operasyonel Karmaşıklık** (DevOps ekibi tarafından dile getirildi)
  - Mevcut ekip k8s uzmanlığından yoksun
  - Hafifletme: 3 aylık eğitim programı + dış danışmanlık
  
- **Maliyet Belirsizliği** (Finans irtibatı tarafından dile getirildi)
  - EKS fiyatlandırma modeli maliyetleri %40 artırabilir
  - Hafifletme: Otomatik geri alma tetikleyicileri ile aylık maliyet incelemeleri

- **Debugging Karmaşıklığı** (Junior mühendisler tarafından dile getirildi)
  - Yerel geliştirme önemli ölçüde zorlaşır
  - Hafifletme: Telepresence/Tilt tooling'e yatırım

## Azınlık Raporu
İki takım üyesi mevcut EC2 otomasyonumuzu iyileştirmemiz gerektiğini savunuyor.
Tam gerekçeleri `/decisions/minority-reports/adr-042-minority.md` içinde belgelendi

## İnceleme Tetikleyicileri
- 2. Ay'a kadar eğitim tamamlanmadıysa
- Maliyetler tahmini %20 aştıysa
- Deployment sıklığı azaldıysa

Bir tetikleyici devreye girdiğinde ilk bakılacak yer “azınlık endişeleri” bölümüdür, çünkü ne yapılacağını biri zaten yazmıştır.

Psikolojik Güvenliği Ölçmek#

Google’ın Project Aristotle araştırması, ölçtüğü beş takım dinamiği arasında psikolojik güvenliği en belirleyici olan olarak işaretledi; güvenilirlik, yapı ve netlik, anlam ve etki onun ardından geldi. Mühendislik terimleriyle psikolojik güvenlik şu demek:

• Mühendisler bilmediklerini söyleyebilir: kariyerlerine zarar gelmeden
• Junior’lar kıdemlilere itiraz edebilir: misilleme görmeden
• Hatalar postmortem malzemesi olur: suçlama oturumuna gerek kalmadan
• Muhalefet katkı sayılır: kayda geçirilerek

Psikolojik güvenliği ölçmek için bir örnek yaklaşım:

class PsychologicalSafetyMetrics {
    private metrics: {
        konusmaSuresiDagilimi: number[];
        soruSormaOrani: { junior: number; toplam: number };
        itirazOrani: number;
        hataKabulOrani: number;
        muhalefetIfadesi: number;
    };

    constructor() {
        this.metrics = {
            konusmaSuresiDagilimi: this.konusmaSuresiniOlc(),
            soruSormaOrani: this.kimSoruSoruyorTakipEt(),
            itirazOrani: this.teknikItirazlariTakipEt(),
            hataKabulOrani: this.hataSahiplenmesiniTakipEt(),
            muhalefetIfadesi: this.anlasmamaPaternleriniTakipEt()
        };
    }
    
    guvenlikSkoruHesapla(): {
        genelSkor: number;
        iyilestirmeAlanlari: string[];
        trend: number;
    } {
        // Kıdem seviyeleri arasında eşit konuşma süresi
        const konusmaEsitligi = this.giniKatsayisiHesapla(
            this.metrics.konusmaSuresiDagilimi
        );
        
        // Junior soru oranı yüksek olmalı
        const juniorKatilim = this.metrics.soruSormaOrani.junior / 
                             this.metrics.soruSormaOrani.toplam;
        
        // Rütbeler arasında sağlıklı itiraz oranı
        const itirazDagilimi = this.itirazPaternleriniAnalizEt();
        
        return {
            genelSkor: this.agirlikliOrtalama([konusmaEsitligi, juniorKatilim, itirazDagilimi]),
            iyilestirmeAlanlari: this.bosluklariBelirle(),
            trend: this.trendHesapla()
        };
    }
}

Mutlak skordan çok trend önemli. Bir çeyrek boyunca düzleşen konuşma süresi dağılımı, tek seferlik herhangi bir ölçümden fazlasını söyler.

Sürecin işleyip işlemediğini birkaç ölçüm gösterir:

SELECT 
  kidem_seviyesi,
  AVG(konusma_suresi_saniye) as ort_konusma_suresi,
  COUNT(DISTINCT katilimci_id) as benzersiz_katilimcilar,
  AVG(rfc_basina_yorum) as katilim_orani
FROM takim_katilimi
GROUP BY kidem_seviyesi;

-- Kıdem seviyelerini çeyrekten çeyreğe birbiriyle karşılaştırın

Üç ayda bir bakmaya değen iki sayı daha var: altı ay içinde tersine çevrilen teknik karar sayısı ve ekibin duyup bir kenara koyduğu bir endişeye dayanan incident sayısı. İkisi de süreç değişmeden önce alınmış bir baseline ister, yoksa çeyreği karşılaştıracak bir şey kalmaz. Junior mühendis ayrılıklarını genel turnover rakamından ayrı izlemek de işe yarar.

REST’ten GraphQL’e Geçiş Kararında Yöntemin İşleyişi#

Dört hamlenin bir arada nasıl çalıştığını, süreci hak edecek büyüklükte bir kararda görmek kolay: birkaç zaman dilimine yayılmış bir ekibin public API için REST ile GraphQL arasında seçim yapması. Geleneksel yol, mimari komitenin karar verip sonucu uygulayacak ekiplere devretmesidir.

Böyle bir kararda rütbe haritası genelde dört pozisyon çıkarır: REST’i tercih eden backend kıdemliler (yetkinlik rütbesi), GraphQL isteyen frontend junior’lar (kullanım rütbesi), kimsenin sormadığı GraphQL deneyimini taşıyan bir bölge ekibi (gizli rütbe) ve API kararlarından dışlandığını hisseden güvenlik ekibi (yapısal rütbe).

Girdi toplama bunun ardından async yürür: zorunlu endişe bölümleri olan bir RFC, imza atmanın riskli göründüğü her şey için anonim gönderim, her alt ekipten zorunlu görüş ve nöbet rotasyonunu temsil eden bir “boş sandalye”.

Tartışmanın kendisi fish bowl formatında ilerler. İç dairede beş koltuk, dışarıda yerini alabilen gözlemciler ve omzunuza dokunulduğunda bıraktığınız koltuk. Kalabalık toplantılarda hiç konuşmayanlar sandalyeye oturur ve konuşmak zorunda kalır.

Çıkan sonuç çekincelerle konsensüstür: müşteri karşısındaki servisler için GraphQL, yüksek performanslı iç servisler için REST, altı aylık inceleme kontrol noktası ve tanımlanmış otomatik geri alma tetikleyicileri. Azınlık raporu N+1 performans endişelerini, GraphQL’de yetkilendirme karmaşıklığını ve backend ekibinin öğrenme eğrisini taşır.

Altı aylık kontrol noktasında karşılığını veren belge azınlık raporudur. GraphQL müşteri karşısındaki servislerde tuttuysa rapor kapanır. N+1 sorunu production trafiğinde ortaya çıktıysa çözüm zaten yazılı ve tartışması yapılmıştır; ekip tartışmayı yeniden açmak yerine doğrudan uygular.

Performatif Demokrasi ve Diğer Başarısızlık Biçimleri#

En sık görülen başarısızlık, formatı yetkiyi hiç kıpırdatmadan uygulamaktır. Toplantıya kolaylaştırıcı atanır, oylar sayılır ve sonunda kararı yine aynı kişi verir. Ekipler bu kalıbı hızlı okur ve konuşmanın kendilerine zaman kaybettirdiğini, sonucu ise değiştirmediğini öğrenir. Kolaylaştırıcıyı döndürmek kalıbı yerinde bırakır, çünkü karar yetkisi rolle birlikte dönmüyor.

İki küçük başarısızlık tartışmanın kendisinden çıkıyor. Kusursuz konsensüs peşinde koşmak kararı kilitler; bu yüzden tartışma penceresinin daha açılmadan bir bitiş tarihi ve adı konmuş bir eskalasyon yolu olmalı. Canlı odada ses seviyesi hâlâ geçerlilik sayılıyor; bunu da sözlü turdan önceki yazılı tur büyük ölçüde çözüyor.

Sonuncusu daha sessiz. Az temsil edilen her görüşü temsil etmesi hep aynı üç kişiden istenir, ta ki o kişiler cevap vermeyi bırakana kadar. Katılım gönüllü olmalı ve sırayla dönmeli. Hiyerarşik kültürlerde çalışan ekiplerin aynı ilke için farklı bir biçime ihtiyacı olur ve ritüeli yerel normlara uyarlamak da işin bir parçası.

Kalıcı Olmasını Sağlayan Şeyler#

Takımlar konuşmadan önce odayı okur; bu yüzden liderlik önce kendi uygular. Bir organizasyonda CTO mimari incelemelerde belirsizliğini kabul etmeye başlayana kadar hiçbir şey değişmedi.

Kolaylaştırıcılık bir beceri ve tech lead’lerin bu konuda eğitime ihtiyacı var. Baseline metrikleri de aynı kurulum aşamasına ait; kimsenin iyi görünmek için bir sebebi olmadan toplanmalı.

Bu süreçte kararlar başta daha uzun sürüyor. Ekipler bu süreyi genelde uygulama aşamasında geri kazanıyor, çünkü itirazı olanlar itirazını çoktan kayda geçirmiş oluyor.

Yöntemin Sınırları#

Deep Democracy, deneyimin kıdemli mühendislere görmemeyi öğrettiği sorunları görünür kılar; çünkü mimariyi uygulayan junior’lar o sorunlara hâlâ çarpar. MongoDB vakasında junior data mühendisi yaklaşımın neden başarısız olacağını tam olarak belgelemişti; belge, bir junior’ın bunu bilemeyeceği varsayımıyla okunmadan kaldı.

Yöntem; geri dönüşü pahalı kararlara, rütbe ya da zaman dilimi farkı olan ekiplere ve iki-üç haftalık bir tartışma penceresini kaldırabilen takvimlere uyar. Bir incident sırasında yanlış araçtır; orada net bir geri alma planı olan tek karar verici daha hızlı ve daha güvenlidir.

Makul bir ilk deneme, önemli ama acil olmayan tek bir karardır: bir rütbe haritası, beş parmak oylaması ve ADR’nin içine yazılmış bir azınlık raporu. İnceleme kontrol noktası geldiğinde ekip ya o raporu kapatır ya da önceden yazdığı çözümü uygular.

Kaynaklar#

• Lewis Deep Democracy - Yöntemimiz (yeni sekmede açılır) - Myrna ve Greg Lewis tarafından Arnold Mindell’in çalışmalarına dayalı geliştirilen beş adımlı Lewis Deep Democracy kolaylaştırma yöntemine genel bakış
• Arnold Mindell - Wikipedia (yeni sekmede açılır) - Süreç Odaklı Psikoloji’nin kurucusu ve Deep Democracy ilkelerinin yaratıcısı Arnold Mindell hakkında arka plan bilgisi
• Deep Democracy - Perspectivity (yeni sekmede açılır) - Grup karar alma ve çatışma çözümü için Deep Democracy kolaylaştırmasına pratik rehber
• Takım etkinliğini anlamak - Google re:Work (yeni sekmede açılır) - Google’ın Project Aristotle araştırmasının psikolojik güvenliğin takım performansının en önemli belirleyicisi olduğuna dair bulguları
• Süreç odaklı psikoloji - Wikipedia (yeni sekmede açılır) - Deep Democracy ve grup kolaylaştırmasının arkasındaki teorik temelin açıklaması