Ana sayfa → Ekip Yönetimi
Squad, Tribe, Chapter, Guild: Bir Haftada Organizasyon Modeli Seçmek
İşe başladığım ilk hafta, CEO ile tanışma toplantısı. Yarım saatlik, kahveli, “hoş geldin” toplantısı. Son beş dakikasında bana ilk hedefimi verdi: “Bir hafta sonra gel, bu şirketi nasıl yöneteceğimizi anlat.”
- İlk refleks yanlıştı: hazır bir model getirip sunmak. Doğrusu önce teşhis koymaktı.
- Bir hafta boyunca model çizmedim, konuştum. 52 görüşme, 4 sabit soru.
- Teşhis netleşince model kendiliğinden geldi: problem hız değil, sahipsizlikti.
- Kopyalamadık, kırptık. İlk gün 3 tribe, 3 squad, 3 chapter kurduk; Guild aylar sonra kendiliğinden geldi, agile coach kadrosu hiç gelmedi.
Beklediğim soru bu değildi
Tanışma toplantısına gitmeden önce hazırladığım şeyler klasikti: teknoloji yığını hakkında sorular, yol haritası, ekip büyüklüğü. Konuşmanın son beş dakikasında geldi o cümle ve elimdeki bloknota tek satır not düştüm: “1 hafta — şirket nasıl yönetilecek?”
Odadan çıkarken kafamda iki his vardı. Birincisi heyecan — kimse sana ilk hafta bu kadar büyük bir alan açmaz. İkincisi de tedirginlik: bu soruyu yanlış cevaplarsan sadece bir sunum batmıyor, önümüzdeki iki yılın çalışma biçimi batıyor.
İlk refleksim yanlıştı
Dürüst olayım: ilk aklıma gelen şey bir çerçeve seçip onu sunmaktı. Kafamda hazır bir liste vardı — SAFe, LeSS, Spotify modeli, klasik matris. Bir tanesini seçer, güzel bir sunum yapar, “bunu uygulayalım” derdim.
İlk iki gün görüşmeleri yaparken bir yandan da çerçeve seçmeye çalışıyordum. İkinci günün akşamı bunun neden yanlış olduğunu fark ettim: henüz neyin bozuk olduğunu bilmiyordum. Model seçmek reçete yazmaktır ve hasta muayene edilmeden reçete yazılmaz. Çerçeve listesini kapattım; haftanın kalanını model çizerek değil, teşhis koyarak geçirecektim.
O hafta ne yaptım: 52 görüşme, 4 soru
Beş gün boyunca takvimimi tek bir işe ayırdım: konuşmak. Şirket bir e-ticaret uygulaması geliştiriyordu, 40 kişiydi ve hepsiyle oturdum: geliştiriciler, test ekibi, ürün tarafı, destek, satış. On iki kişiyle de ikinci kez oturdum, çünkü ilk görüşmede söyledikleri başka görüşmelerde doğrulanmamıştı. Toplam 52 görüşme, çoğu yarım saat; günde on görüşme.
Her görüşmede aynı dört soruyu sordum. Sabit tutmak önemliydi — farklı sorularla farklı cevaplar alırsan karşılaştıramıyorsun:
- Bu hafta zamanının en çok nereye gittiğini söyle. Ne yaptığını değil, zamanın nereye aktığını soruyorum.
- Son bir ayda seni en çok bekleten şey neydi? Engelleri buradan buluyorsun.
- Bir şeyin bozuk olduğunu fark ettin, kime söylersin? Bu soru organizasyon şemasının gerçeğini gösteriyor.
- Elinde sihirli değnek olsa neyi değiştirirdin? İnsanlar bu soruda savunmayı bırakıyor.
Üçüncü soru en çok işe yarayanıydı. Kırk çalışandan yalnızca 12’si net bir isim verdi; geri kalanın cevabı şuydu: “Valla kime söyleyeceğimi bilmiyorum, genelde söylemiyorum.” Bir organizasyonda bundan daha net bir teşhis işareti yok.
Duyduklarım
- “Bu ay dört farklı projeye dokundum, hiçbirini bitiremedim.”
- “Ödeme tarafını kim biliyor? Kimse. Yazan arkadaş ayrıldı.”
- “Toplantıda konuşuluyor ama karar çıkmıyor, sonra kimse hatırlamıyor.”
- “Bir iş için kime gideceğimi bilmiyorum, en son kimi bulursam ona söylüyorum.”
- “Acil deyip araya sokuyoruz, çünkü acil demezsen hiç yapılmıyor.”
- “Üç aydır aynı şeyi soruyorum, her seferinde başka biri bakıyor.”
Teşhis: problem hız değil, sahipsizlik
Beşinci günün akşamı notları yan yana koyduğumda tablo netti. Şirket proje bazlı çalışıyordu: bir iş geliyor, o iş için insanlar toplanıyor, iş bitince dağılıyorlardı. Kulağa esnek geliyor, pratikte şunu üretiyordu:
- Hiçbir şeyin sahibi yoktu. Ödeme sistemi kimseye ait değildi; ona dokunan son kişi sorumlusu sayılıyordu.
- Bağlam her seferinde sıfırlanıyordu. Aynı modülü üçüncü kez açan kişi, ilk kez açıyormuş gibi başlıyordu.
- Kimse uzun vadeli bir şey düşünmüyordu. İki ay sonra o kodla uğraşmayacaksan teknik borcu neden düşünesin?
- Karar mercii belirsizdi. Herkes her işe bakıyordu, dolayısıyla kimse hiçbir işe karar veremiyordu.
İlginç olan şuydu: kimse tembel değildi, herkes çok çalışıyordu. Sorun efor değildi, eforun dağılma biçimiydi.
Neden Squad?
Teşhis “sahipsizlik” olunca aday model listesi kendiliğinden kısaldı. Aradığım şey belliydi: uzun ömürlü, bir alanın sahibi olan, kendi kararını verebilen takımlar. Bu tarif zaten bir şeyin tarifiydi.
| Aday | Değerlendirme |
|---|---|
| Mevcut proje bazlı yapı | Sorunun kaynağı zaten buydu |
| SAFe | 40 kişilik bir şirkete 300 kişilik bir tören getiriyordu. Zaten karar veremeyen bir yapıya üç katman daha eklemek |
| LeSS | Bu ölçekte en makul aday; ama tek ürün, tek backlog varsayar. Bizde üç ayrı iş alanı vardı ve derdimiz sprint mekaniği değil, sahiplikti |
| Klasik fonksiyonel yapı (backend ekibi, frontend ekibi, QA ekibi) | Sahiplik yine ortada kalıyor; her iş üç ekibin arasında dolaşıyor |
| Klasik matris (proje yöneticisi + fonksiyon yöneticisi) | Aslında seçtiğimiz şey de bir matris: iş squad’da, hat yöneticisi chapter lead. Fark tek: klasik matriste proje biter, ekip dağılır; squad kalıcı |
| Squad modeli | Tam olarak eksik olan şeyi veriyordu: bir alanın kalıcı sahibi olan çapraz fonksiyonlu takım |
Bir de kültürel uyum vardı ve asıl belirleyici oydu. Bu şirkette insanlar karar vermeye istekliydi; sorun yetkisizlik değil, kimin karar vereceğinin belirsizliğiydi. Özerkliği zaten isteyen bir ekibe özerklik temelli bir model oturur. Aynı modeli, karar vermekten kaçınan bir kültüre koysanız çalışmaz — squad’lar kurulur, kimse karar vermez, siz yine ortada kalırsınız.
- Squad — 6–12 kişilik, çapraz fonksiyonlu, bir alanın kalıcı sahibi olan takım. Mini bir şirket gibi.
- Tribe — ilişkili alanlarda çalışan squad topluluğu.
- Chapter — aynı yetkinlikteki insanlar (tüm backend’ciler gibi). Chapter lead hat yöneticisi: kariyer ve gelişim onda.
- Guild — şirket geneline açık, gönüllü ilgi topluluğu.
Modelin kalbi Chapter’da: işin yönetimi ile insanın yönetimi ayrılıyor. Squad ne yapılacağına karar veriyor, chapter lead kişinin gelişiminden sorumlu oluyor.
Ama kopyalamadık
Modeli okurken en çok dikkatimi çeken şey, 2012’deki makalenin kendi uyarısıydı: yazarlar daha o gün bunun bir reçete değil, anlık fotoğraf olduğunu söylemişti — model son bir yılda kademeli gelmişti, insanlar hâlâ alışıyordu, bugünün çözümleri yarının problemlerini doğuracaktı. Yıllar sonra eski çalışanlar devamını anlattı: Spotify bu modeli hiçbir zaman anlatıldığı gibi tam uygulamadı. Sektörde dolaşan laf boşuna değil: “Spotify, Spotify modelini kullanmıyor.”
Bu uyarı beni rahatlattı, çünkü kopyalama baskısını kaldırdı. Modeli bir menü gibi kullandık: ihtiyacımız olanı aldık, olmayanı almadık.
- Squad: 3 tane kurduk, her biri bir iş alanının sahibi. 26 mühendis: 9 + 9 + 8
- Tribe: 3 tane, her birinde tek squad. Tribe iş alanının adı ve sınırı, squad o alanın takımı. Orijinalde tribe birden çok squad toplar; 40 kişide toplayacak squad yoktu, ama alanın sınırını en baştan çizmek istedim
- Chapter: 3 tane — backend, frontend, QA. Orijinalden farklı olarak şirket geneli; tribe içinde kalsaydı üç kişilik chapter’lar çıkardı
- Chapter lead = hat yöneticisi ayrımı
- Guild: zorla kurulmaz. İlk guild 4. ayda kendiliğinden çıktı
- Agile coach kadrosu: o ölçekte lüks
Squad’ları neye göre böldük? Bu en kritik karardı ve iki seçenek vardı: teknolojiye göre (backend squad, mobil squad) ya da iş alanına göre. İkincisini seçtik, çünkü birincisi zaten var olan sorunu isim değiştirerek korumak olurdu. Bir squad bir işi baştan sona bitirebilmeliydi — başka bir takıma bağımlı kalmadan.
Neden 3? Boyut da bu kararın parçasıydı: 26 mühendis, üç iş alanı. 3 squad, 9 + 9 + 8. Dördüncü bir squad’ı düşündüm ve vazgeçtim: 26’yı dörde bölmek iki tane 4 kişilik squad demekti ve 4 kişi, modelin 6–12 tanımının altında. Bir kişi izne çıkınca üç kişi kalır; üç kişilik squad, squad değil. Tanıma uymayan squad kurmaktansa daha az squad kurduk.
En zor kısım: Chapter
Squad kurmak kolaydı; herkes heyecanlandı. Zorluk chapter tarafındaydı ve iki yerde takıldık.
İlk refleks buydu: chapter lead, squad’lardaki teknik kararlara karışmaya başladı. “Backend chapter lead’i olarak bu mimariyi onaylamam” cümlesi ilk ayda üç kez duyuldu.
Oysa rolün tanımı bu değildi. Netleştirmek zorunda kaldık ve tek cümleye indirdik: “Chapter lead kişiyi yönetir, işi değil.” Teknik karar squad’ın. Chapter lead standardı belirler, kalite çıtasını korur, insanı geliştirir — ama squad’ın kararını veto etmez.
İkinci hafta gelen soru. Bir geliştirici squad’da çalışıyor ama performans değerlendirmesini chapter lead yapıyor. İnsanların haklı olarak kafası karıştı.
Bu, modelin en bilinen zayıf noktası. Eski bir Spotify çalışanının 2020’de yazdığı eleştirinin merkezinde tam olarak bu var: matrisin kimseye hesap vermeyen özerkliğe dönüşmesi ve chapter lead’in işin içinden kopması. Aynı şeyi küçük ölçekte biz de yaşadık. Bunu bir tabloyla çözdük ve o tablo bugün hâlâ duruyor:
| Konu | Kim |
|---|---|
| Ne yapacağım, hangi sırayla | Squad (ürün sahibiyle birlikte) |
| Nasıl yapacağım, hangi teknoloji | Squad |
| Kod standardı, kalite çıtası | Chapter |
| Kariyer, terfi, performans | Chapter lead |
| İzin, bire birler | Chapter lead |
| Squad değiştirmek | Chapter lead + iki squad birlikte |
Bu tablo bir slaytta durmuyor; ekibin ortak alanında asılı ve yeni gelen herkese ilk gün gösteriliyor. Belirsizliğin maliyeti, bir tabloyu asmanın maliyetinden çok daha yüksek.
CEO’ya sunduğum şey
Bir hafta sonraki toplantıya tek sayfayla gittim. Slayt destesi hazırlamadım, çünkü asıl ikna edici olan model değil teşhisti.
- Ne duydum: 52 görüşmeden çıkan 4 cümle, olduğu gibi alıntı.
- Teşhis: tek cümle — “Hiçbir şeyin sahibi yok.”
- Öneri: 3 tribe, 3 squad, 3 chapter, alan bazlı bölünme. Bir sayfalık şema.
- Neyi ölçeceğiz: üç sayı (aşağıda).
- Ne zaman geri döneceğim: 3 ay sonra, sayılarla.
Toplantı 20 dakika sürdü. En çok konuşulan kısım model değil, birinci maddeydi — alıntılar. CEO’nun kendi şirketi hakkında duymadığı cümlelerdi. Model o alıntılardan sonra zaten kaçınılmaz göründü.
İlk aylar: neler kırıldı
Güzel taraflarını anlattım, şimdi dürüst kısım. İlk aylar pürüzsüz geçmedi ve geçmesini de beklemiyordum — zaten bu tür geçişlerde ilk dönem hep karışıktır.
- Squad’lar arası bağımlılık. “Bir squad işi baştan sona bitirsin” hedefi ilk gün tutmadı; ortak bir kimlik doğrulama servisi vardı ve herkes ona muhtaçtı. İki ay sonra o servisi de bir squad’ın sahipliğine verdik ve diğerleri için net bir arayüz tanımladık.
- Sahiplik “benim toprağım”a dönüştü. Üçüncü ayda bir squad başka bir squad’ın koduna dokunmayı reddetti. Kuralı netleştirdik: her koda herkes dokunabilir, ama sahibinin incelemesinden geçer.
- İlk işe alım üçüncü ayda geldi. İki yazılımcı, iki test mühendisi; mühendislik 26’dan 30’a çıktı. Yeni gelenleri dördüncü bir squad açmak için biriktirmedik, mevcut üç squad’a dağıttık. Dört kişi bir squad etmez; üç squad’ı doldurur.
Ne ölçtük
CEO’ya söz verdiğim üç sayı. Bilerek az tuttum; on metrik takip edilmiyor.
- Bir işin başlangıcından canlıya çıkışına kadar geçen süre. Sahiplik gerçekten oluştuysa bu süre kısalır. Medyan aldık, ortalama değil; birkaç çok uzun iş ortalamayı bozuyor. Üç ayda medyan 19 günden 11 güne indi.
- Bir işin kaç farklı kişiye atandığı. Bağımlılığın en dürüst ölçüsü ve squad’dan önce de ölçülebiliyor: ticket’ın atanan geçmişine bakıyorsun. Başlangıçta ortalama 2,4 kişiydi; hedefimiz 1’e yaklaşmaktı. Üç ayda 1,5’e indi.
- “Kime söyleyeceğimi biliyorum” oranı. Üç ayda bir tek soruluk anket — ilk haftaki üçüncü sorunun aynısı. İlk hafta 40 kişiden 12’si (%30) net bir isim vermişti; üç ay sonra 31 kişi (%78). Bu sayı en çok gurur duyduğum sayı oldu.
Kendi şirketine uyarlayacaksan
- Modeli seçmeden önce teşhis koydun mu? Yazılı mı?
- Squad’lar iş alanına göre mi bölündü, teknolojiye göre mi?
- Bir squad bir işi baştan sona bitirebiliyor mu, yoksa hep birine mi muhtaç?
- Squad’lar kalıcı mı, yoksa proje bitince dağılıyor mu?
- “İşi kim yönetir, kişiyi kim yönetir” ayrımı yazılı mı?
- Chapter lead teknik kararları veto ediyor mu? (Etmemeli.)
- Her squad için bir ürün sahibin var mı? (Yoksa kaç squad kurabileceğin buradan belli.)
- Guild’i zorla mı kurdun, kendiliğinden mi çıktı?
- Üç ay sonra bakacağın üç sayı belli mi?
Sonuç
O bir hafta, kariyerimdeki en keyifli haftalardan biriydi. Sebebi model bulmak değildi — model zaten ortada duruyordu, isteyen okuyup uygular. Keyifli olan kısım, bir şirketi 52 görüşmede kendi çalışanlarının ağzından dinlemek ve dağınık cümlelerin bir noktada tek bir teşhise oturmasıydı.
Ve o haftadan kalan asıl ders şu: bir organizasyon modelini seçmek, teşhis koyduktan sonra zaten kolay. Zor olan, model heyecanına kapılıp teşhisi atlamamak. Squad, tribe, chapter, guild — bunlar cevap. Önce sorunun ne olduğunu bulmak gerekiyor.
Chapter lead’in en zor işi olan performans ve gelişim konusu Performans OKR ile Ölçülür mü? yazısında; squad’ın kendi kararını verebilmesi için gereken liderlik davranışı ise Yeni Nesil Liderlik yazısında.
Modelin aslı: Henrik Kniberg ve Anders Ivarsson, Scaling Agile @ Spotify (2012); “anlık fotoğraf” uyarısı bu makalenin kendi son bölümünde. Modelin uygulanmadığına dair eleştiri: Jeremiah Lee, Spotify’s Failed #SquadGoals (2020).