Bir engineering organizasyonunda işler yolunda gitmediğinde ilk refleks genellikle teknik problemlere odaklanmak olur. Delivery target’ları kaçıyordur, sprint predictability düşüyordur, roadmap sürekli revize ediliyordur veya production incident sayısında belirgin bir artış yaşanıyordur. Bu tür durumlarda çözüm çoğu zaman yeni süreçler tanımlamakta, daha fazla metrik takip etmekte veya organizasyon yapısını değiştirmekte aranır.

Ancak engineering liderliği tarafında geçirilen zaman arttıkça ilginç bir gerçekle karşılaşılır. Birçok organizasyonda yaşanan problemlerin kök nedeni ne teknoloji seçimidir ne de süreç eksikliğidir. Hatta çoğu zaman problem doğrudan teknik bile değildir. Asıl sorun, ekip içerisindeki davranış kalıplarında ve insanların birlikte çalışma biçiminde ortaya çıkar.

Bu durum özellikle büyüme dönemindeki şirketlerde daha belirgin hale gelir. Beş kişilik bir ekipte doğal olarak çalışan iletişim mekanizmaları, ekip sayısı arttığında veya organizasyon birkaç farklı domain’e bölündüğünde aynı verimlilikle çalışmayabilir. Başlangıçta küçük görünen problemler zamanla delivery performansını, ekip motivasyonunu ve ürün kalitesini etkilemeye başlar.

Daha da ilginç olan taraf, bu problemlerin çoğunun bir gecede ortaya çıkmamasıdır. Genellikle sessiz şekilde büyürler. Design review toplantılarında insanlar daha az itiraz etmeye başlar. Riskler eskisi kadar açık şekilde konuşulmaz. Kararlar alınır ancak ekip içerisinde gerçek bir sahiplenme oluşmaz. Bir süre sonra herkes aynı toplantılara katılır, aynı araçları kullanır ve aynı sprint’lerde çalışır ancak ekip olma hissi giderek zayıflar.

Tam bu noktada Patrick Lencioni’nin Five Dysfunctions of a Team modeli devreye girer. Bu model, ekiplerin neden başarısız olduğunu açıklamaktan çok, başarısızlığın nasıl yavaş yavaş oluştuğunu anlamaya yardımcı olur. Özellikle engineering organizasyonlarında “teknik problem” olarak görünen birçok semptomun altında aslında davranışsal ve kültürel problemler bulunduğunu göstermesi açısından oldukça değerlidir.

Model beş temel dysfunction tanımlar. Güven eksikliği ile başlayan süreç, zamanla sağlıklı çatışmaların ortadan kalkmasına, kararlara bağlılığın azalmasına, hesap verebilirliğin kaybolmasına ve sonunda ekip sonuçlarının ikinci plana atılmasına kadar ilerler. Bu nedenle modeldeki her katman aslında bir sonraki problemin temelini oluşturur.

Yıllar içerisinde farklı ölçeklerde ekiplerle çalışırken bu modelin teoriden çok daha fazlası olduğunu gördüm. Çünkü burada anlatılan davranışların neredeyse tamamı modern yazılım organizasyonlarında günlük olarak karşımıza çıkıyor. Üstelik çoğu zaman insanlar yaşadıkları problemin tam olarak ne olduğunu anlayamıyor. Delivery yavaşlıyor, toplantılar uzuyor veya ekipler arasında sürtüşmeler oluşuyor ancak gerçek kök neden görünmez kalıyor.

Bu nedenle Five Dysfunctions of a Team’i yalnızca bir ekip çalışması teorisi olarak görmek yerine, engineering organizasyonlarının sağlığını değerlendirmek için kullanılabilecek pratik bir çerçeve olarak değerlendirmek gerekiyor.

1. Güven Eksikliği: Problemlerin Başlangıç Noktası

Lencioni’nin modelinde tüm problemlerin temelinde güven eksikliği yer alır. Ancak burada bahsedilen güven kavramı günlük hayatta kullandığımız anlamdan biraz farklıdır. Birçok kişi ekip içerisindeki güveni insanların iyi anlaşması veya birbirlerini sevmesi olarak yorumlar. Oysa yüksek performanslı ekiplerde güven, insanların profesyonel olarak savunmasız kalabilme cesaretine sahip olması anlamına gelir.

Bir engineer’ın bilmediği bir konuyu rahatlıkla söyleyebilmesi, yaptığı bir hatayı savunmaya çalışmak yerine sahiplenebilmesi veya yardıma ihtiyaç duyduğunu açıkça ifade edebilmesi gerekir. Eğer insanlar sürekli olarak uzman görünmeye çalışıyorsa veya hata yaptıklarında yargılanacaklarını düşünüyorsa, ekip içerisinde gerçek anlamda bir güven ortamı oluşmamış demektir.

Bu durum özellikle teknik ekiplerde sanıldığından daha yaygındır. Çünkü mühendislik kültürü doğal olarak uzmanlığa değer verir. İnsanlar belirli alanlarda bilgi sahibi olmak için yıllar harcarlar ve zamanla “her şeyi biliyor görünme” baskısı oluşabilir. Özellikle senior engineer veya tech lead pozisyonlarındaki kişilerde bu davranış daha sık görülür. İnsanlar yanlış karar verdiklerini kabul etmek yerine kararlarını savunmaya çalışır, bilmedikleri konularda soru sormak yerine sessiz kalmayı tercih ederler.

Bunun kısa vadede görünür bir etkisi olmayabilir. Ancak uzun vadede bilgi paylaşımı azalır, riskler erken aşamada tespit edilemez ve ekip içerisindeki öğrenme kültürü zarar görmeye başlar.

Birkaç yıl önce çalıştığım ekiplerden birinde bunun oldukça net bir örneğini yaşamıştık. Production ortamında belirli saatlerde ciddi performans problemleri yaşanıyordu. Monitoring dashboard’larında response time değerleri yükseliyor, açılan support ticket sayısı artıyordu. İlk etapta problemin altyapı kaynaklı olduğu düşünüldü. Database sorguları incelendi, cache stratejileri gözden geçirildi ve farklı sistem bileşenleri üzerinde analizler yapıldı.

Yaklaşık bir hafta süren çalışmaların ardından problemin kaynağı bulundu. Sorun aslında birkaç gün önce yapılan bir kod değişikliğinden kaynaklanıyordu. Daha sonra ilgili engineer ile yapılan görüşmede ilginç bir detay ortaya çıktı. Değişikliği yapan kişi ilk günden itibaren kendi commit’lerinden şüphelenmişti ancak yeterince emin olmadığı için bunu toplantılarda dile getirmemişti.

Buradaki problem teknik değildi. Kod değişiklikleri her zaman hata içerebilir. Asıl problem, kişinin şüphelerini rahatlıkla paylaşabileceği bir ortamın oluşmamış olmasıydı. Eğer ekip içerisinde güçlü bir güven kültürü bulunsaydı, ilk gün yapılacak basit bir konuşma günler süren investigation sürecini ortadan kaldırabilirdi.

Güven eksikliği zamanla farklı şekillerde de kendini göstermeye başlar. İnsanlar yardım istemekten kaçınır. Bilgi paylaşımı azalır. Design review’larda gerçek fikirler dile getirilmez. Retrospective toplantıları yüzeysel hale gelir. Ekip üyeleri birbirlerinin güçlü ve zayıf yönlerini öğrenemez çünkü herkes sürekli olarak en iyi versiyonunu göstermeye çalışır.

Yüksek performanslı engineering organizasyonlarında ise durum tam tersidir. İnsanlar hata yaptıklarında bunu gizlemeye çalışmazlar. Bilmedikleri konularda soru sormaktan çekinmezler. Bir tasarım kararının yanlış olduğunu düşündüklerinde bunu açıkça ifade ederler. Çünkü ekip üyeleri bilir ki amaç bireysel olarak haklı çıkmak değil, organizasyonun daha iyi kararlar almasını sağlamaktır.

Bu nedenle güven eksikliği yalnızca ekip içerisindeki ilişkileri etkileyen bir problem değildir. Aynı zamanda delivery performansını, teknik kararların kalitesini ve organizasyonun öğrenme hızını doğrudan etkileyen temel bir engineering problemidir.

2. Fear of Conflict: Sessiz Toplantılar Her Zaman Sağlıklı Değildir

Birçok yöneticinin kariyerinin bir noktasında düştüğü tuzaklardan biri, ekip içerisindeki uyumu ekip sağlığının göstergesi olarak değerlendirmektir. Toplantılar sakin geçiyordur, insanlar birbirlerinin sözünü kesmiyordur, kararlar hızlı alınabiliyordur ve görünürde herhangi bir anlaşmazlık yaşanmıyordur. İlk bakışta bu durum oldukça olumlu görünür.

Ancak engineering organizasyonlarında gerçek durum çoğu zaman farklıdır.

Özellikle güven seviyesinin düşük olduğu ekiplerde insanlar fikir ayrılıklarını açıkça dile getirmekten kaçınmaya başlar. Bir design review sırasında önerilen mimarinin riskli olduğunu düşünseler bile sessiz kalmayı tercih ederler. Sprint planning toplantısında hedeflerin gerçekçi olmadığını fark etseler bile bunu yüksek sesle söylemezler. Product tarafından gelen taleplerin teknik açıdan problem yaratacağını öngörseler bile tartışma çıkmasını istemedikleri için itiraz etmezler.

Bu noktada organizasyon içerisinde sağlıklı çatışma yerini yapay bir uyuma bırakır.

Oysa yüksek performanslı ekiplerde çatışma bir problem değil, doğru karar alma sürecinin doğal bir parçasıdır. Buradaki kritik ayrım kişisel çatışma ile profesyonel çatışma arasındaki farktır. Sağlıklı ekipler insanlarla değil, fikirlerle mücadele eder. Tartışmaların amacı karşı tarafı yenmek değil, daha iyi bir sonuca ulaşmaktır.

Engineering ekiplerinde bunun en sık görüldüğü alanlardan biri mimari karar süreçleridir.

Bir organizasyonda yeni bir notification sistemi geliştirildiğini düşünelim. Yapılan Architecture Review toplantısında ekip üyelerinden biri mevcut tasarımın ölçeklenebilirlik açısından problem yaratacağını düşünüyor olsun. Ancak toplantıda bu görüşünü paylaşmıyor. Bunun sebebi teknik yetersizlik değil; yanlış anlaşılma, tartışma yaratma veya süreci yavaşlatma korkusu.

Toplantı sonunda herkes aynı fikirdeymiş gibi görünür. Karar alınır ve geliştirme süreci başlar.

Birkaç ay sonra sistem production’a çıkar. Kullanıcı sayısı arttıkça beklenen problemler ortaya çıkmaya başlar. Message queue’lar dolmaya başlar, retry mekanizmaları beklenmedik yük oluşturur ve ekip acil çözüm üretmek zorunda kalır.

Bu noktada genellikle şu cümle duyulur:

“Ben aslında review sırasında bunun problem yaratabileceğini düşünmüştüm.”

Bu cümle teknik organizasyonlarda duyulabilecek en pahalı cümlelerden biridir.

Çünkü artık tartışma yapılabilecek en ucuz zaman geçmiş, problem çözülmesi gereken en pahalı aşamaya ulaşmıştır.

Engineering liderleri açısından burada önemli olan şey çatışmaları ortadan kaldırmak değil, sağlıklı çatışmaların oluşabileceği ortamı yaratmaktır. İnsanlar teknik konularda birbirlerine katılmak zorunda değildir. Hatta çoğu zaman farklı bakış açıları organizasyonun daha iyi kararlar almasını sağlar.

Amazon’un “Disagree and Commit” prensibi de aslında bu noktada değer kazanır. İnsanların fikir ayrılıklarını açık şekilde ortaya koymaları beklenir. Ancak karar alındıktan sonra herkes aynı hedef doğrultusunda hareket eder.

Sağlıklı çatışmaların olmadığı ekiplerde ise problemler genellikle toplantı odasında değil, toplantı sonrasında ortaya çıkar. Kararlar toplantıda oybirliğiyle alınır ancak koridorda, Slack kanallarında veya birebir görüşmelerde eleştirilmeye devam edilir. Bu durum zamanla güveni daha da zayıflatır ve organizasyonun karar alma mekanizmasını yavaşlatır.

Bu nedenle bir engineering liderinin kendisine sorması gereken sorulardan biri şudur:

“Ekipte gerçekten fikir birliği mi var, yoksa insanlar sadece itiraz etmekten mi kaçınıyor?”

Bu iki durum dışarıdan benzer görünse de organizasyon üzerindeki etkileri tamamen farklıdır.

3. Lack of Commitment: Karara Katılmayan İnsanlar Kararı Sahiplenmez

Güven eksikliği ve çatışma korkusu bir süre sonra üçüncü probleme dönüşmeye başlar: bağlılık eksikliği.

Bu noktada birçok lider yanlış bir varsayımda bulunur. İnsanların alınan kararlara bağlılık göstermemesinin sebebinin kararın kendisi olduğunu düşünürler. Oysa çoğu zaman problem kararın kalitesi değil, kararın nasıl alındığıdır.

Bir engineer’ın her kararı desteklemesi gerekmez. Ancak insanların büyük çoğunluğu, görüşlerinin duyulduğunu ve değerlendirildiğini hissettikleri kararlara çok daha fazla sahip çıkar.

Örneğin bir ekip yeni bir teknolojiye geçiş kararı alıyor olsun. Design review sürecinde farklı görüşler ortaya çıkmış, riskler tartışılmış ve herkes düşüncelerini açık şekilde paylaşmış olsun. Sonuçta ekip kendi tercih ettiği çözümü değil, başka bir yaklaşımı seçebilir.

İlginç olan nokta şudur: İnsanlar kendi önerileri kabul edilmese bile sürecin adil ilerlediğini düşündüklerinde alınan karara daha fazla bağlılık gösterirler.

Tam tersine, insanların görüşlerini paylaşmadığı veya paylaşamadığı ekiplerde farklı bir davranış ortaya çıkar. Karar alınmıştır ancak gerçek sahiplenme oluşmamıştır. Bu durum genellikle günlük konuşmalarda kullanılan ifadelerden anlaşılabilir.

“Bu karar Product’ın isteğiydi.”

“Leadership böyle istedi.”

“Bu benim tercih ettiğim çözüm değildi.”

“Zaten başından beri işe yaramayacağını düşünüyordum.”

Bu cümleler aslında bağlılık eksikliğinin erken sinyalleridir.

Bir süre önce çalıştığım organizasyonlardan birinde platform ekibi büyük bir altyapı dönüşümü planlıyordu. Teknik açıdan doğru görünen bu dönüşüm için kapsamlı bir roadmap hazırlanmıştı. Ancak birkaç ay sonra ilerleme beklenenden çok daha yavaş hale geldi.

İlk başta problem kapasite eksikliği olarak değerlendirildi. Daha sonra yapılan görüşmelerde farklı bir tablo ortaya çıktı. Ekip üyelerinin önemli bir kısmı dönüşümün gerekli olduğuna inanmıyordu. Toplantılarda açık şekilde itiraz etmemişlerdi ancak alınan karara da hiçbir zaman gerçek anlamda bağlanmamışlardı.

Sonuç olarak herkes görevlerini yerine getiriyordu ancak hiç kimse dönüşümün başarılı olması için ekstra çaba göstermiyordu.

Bu durum engineering organizasyonlarında sık görülen bir problemdir. İnsanlar görevlerini yaparlar ancak sonuçlara sahip çıkmazlar. Çünkü alınan kararları kendi kararları olarak görmezler.

Yüksek performanslı ekiplerde ise farklı bir yaklaşım vardır. Herkes aynı fikirde olmak zorunda değildir ancak karar alındıktan sonra ortak bir yön oluşur. İnsanlar artık hangi seçeneğin daha iyi olduğunu tartışmak yerine seçilen çözümün başarılı olması için çalışırlar.

Engineering liderliği açısından burada kritik olan şey mükemmel fikir birliği yaratmak değildir. Asıl amaç insanların sürece katılmasını ve alınan kararlara sahip çıkmasını sağlamaktır.

Çünkü bir organizasyon için en tehlikeli durum yanlış karar almak değildir. En tehlikeli durum, kimsenin gerçekten inanmadığı kararlarla ilerlemeye çalışmaktır.

4. Avoidance of Accountability: Performans Problemlerinin Normalleşmesi

Güven eksikliği, sağlıklı çatışmaların ortadan kalkması ve kararlara bağlılığın zayıflaması zamanla dördüncü probleme dönüşür: hesap verebilirlikten kaçınma.

Bu noktada organizasyon içerisinde ilginç bir durum ortaya çıkmaya başlar. Herkes teorik olarak aynı hedeflere çalışıyordur ancak ekip üyeleri birbirlerini sorumlu tutmak konusunda isteksiz hale gelirler. Çünkü ortak sahiplenme hissi zayıflamıştır.

Birçok lider hesap verebilirliği yöneticilerin sağladığını düşünür. Oysa yüksek performanslı ekiplerde hesap verebilirlik büyük ölçüde ekip içerisinden gelir. İnsanlar yalnızca yöneticilerine karşı değil, birlikte çalıştıkları takım arkadaşlarına karşı da sorumluluk hissederler.

Sağlıklı bir ekipte bir engineer başka bir engineer’a rahatlıkla şu soruyu sorabilir:

“Bu work item neden üç sprinttir ilerlemiyor?”

veya

“Bu dependency’nin delivery riskine dönüştüğünü görüyoruz. Yardıma ihtiyacın var mı?”

Bu tür konuşmaların gerçekleşebilmesi için güçlü bir güven kültürüne ihtiyaç vardır. Çünkü insanlar ancak birbirlerinin niyetlerinden emin olduklarında bu tür geri bildirimleri kişisel saldırı olarak algılamazlar.

Ancak birçok organizasyonda tam tersi bir tablo oluşur.

Bir engineer’ın performans problemi vardır ancak ekipte kimse bunu dile getirmez.

Bir takım sürekli olarak sprint commitment’larını kaçırıyordur ancak konu açık şekilde konuşulmaz.

Teknik kalite düşmeye başlamıştır ancak code review standartları sessizce gevşetilir.

Herkes problemin farkındadır ama kimse konuşmak istemez.

Bu noktada hesap verebilirlik tamamen yöneticilere devredilir.

Sonuç olarak Engineering Manager veya Tech Lead sürekli olarak aynı problemleri takip etmek zorunda kalır. Sprint hedefleri hatırlatılır, geciken task’lar takip edilir, kalite standartları yöneticiler tarafından korunmaya çalışılır.

Kısa vadede bu yaklaşım çalışıyor gibi görünebilir ancak organizasyon büyüdükçe sürdürülemez hale gelir.

Bir noktadan sonra ekip kendi kendini yönetemez hale gelir.

Bu durumun etkilerini özellikle ölçeklenme dönemlerinde görmek mümkündür. Beş kişilik bir ekipte liderin her detayı takip etmesi mümkün olabilir. Ancak organizasyon onlarca veya yüzlerce kişiye ulaştığında aynı yaklaşım çalışmaz. Bu nedenle yüksek performanslı ekiplerin ortak özelliklerinden biri, hesap verebilirliğin yöneticilerden çok ekip tarafından sahiplenilmesidir.

Birkaç yıl önce çalıştığım organizasyonlardan birinde bunun oldukça belirgin bir örneğini yaşamıştık.

Bir platform ekibi kritik bir servis üzerinde çalışıyordu. Teknik açıdan son derece güçlü mühendislerden oluşan bir ekipti ancak delivery performansı beklentilerin altında kalıyordu. Roadmap’teki işlerin önemli bir kısmı sürekli olarak sonraki quarter’a kayıyordu.

İlk incelemelerde kapasite planlaması, backlog yönetimi ve sprint süreçleri değerlendirildi. Ancak asıl problem farklıydı.

Ekip üyeleri birbirlerinin gecikmelerini sorgulamıyordu.

Bir task haftalarca ilerlemese bile konu gündeme getirilmiyordu.

Riskler herkes tarafından biliniyor ancak sahiplenilmiyordu.

Sonuç olarak her problem sonunda Engineering Manager’a eskale ediliyordu.

Bu durum organizasyon içerisinde görünmez bir darboğaz oluşturmuştu.

Problemin çözümü yeni süreçler tanımlamak olmadı. Bunun yerine ekip içerisinde açık geri bildirim kültürü oluşturulmaya çalışıldı. İnsanların birbirlerinden beklentilerini net ifade etmeleri teşvik edildi ve risklerin daha erken görünür hale gelmesi sağlandı.

Birkaç ay içerisinde delivery performansında gözle görülür bir iyileşme yaşandı.

İlginç olan nokta ise teknik tarafta neredeyse hiçbir değişiklik yapılmamış olmasıydı.

Değişen şey ekip davranışlarıydı.

Bu nedenle hesap verebilirlik eksikliği yalnızca performans yönetimi problemi olarak değerlendirilmemelidir. Aslında bu durum organizasyonun kendi kendini yönetebilme kapasitesini doğrudan etkileyen bir ekip sağlığı problemidir.

5. Inattention to Results: Ekip Başarısından Bireysel Başarıya Geçiş

Lencioni’nin modelindeki son dysfunction, diğer tüm problemlerin doğal sonucu olarak ortaya çıkar.

Güven eksikliği, çatışma korkusu, bağlılık eksikliği ve hesap verebilirlik problemleri zamanla ekip sonuçlarının ikinci plana atılmasına neden olur.

Bu aşamaya gelmiş organizasyonlarda insanlar hâlâ yoğun şekilde çalışıyor olabilir. Sprint’ler devam ediyordur, roadmap güncelleniyordur ve dashboard’lar raporlarla doludur. Ancak organizasyonun enerjisi ortak hedeflere değil, bireysel veya lokal hedeflere yönelmeye başlamıştır.

Engineering organizasyonlarında bunun farklı versiyonlarıyla karşılaşmak mümkündür.

Bir ekip kendi velocity metriklerini artırmaya odaklanır ancak müşteri deneyimi kötüleşmektedir.

Başka bir ekip teknik borcu azaltmaya çalışırken ürün tarafındaki kritik delivery hedefleri gecikmektedir.

Bir engineering manager kendi organizasyonunun KPI’larını iyileştirir ancak şirket seviyesindeki hedeflere katkı azalmaktadır.

Tüm bu örneklerde insanlar kötü niyetli değildir.

Problem odak noktasının değişmesidir.

Ortak başarı tanımı kaybolmaya başlamıştır.

Özellikle büyük organizasyonlarda bu durum daha sık görülür. Çünkü ekipler zamanla kendi hedeflerini optimize etmeye başlar. Bir noktadan sonra organizasyon içerisinde şu tür davranışlar ortaya çıkar:

“Bizim takım hedeflerini tamamladı.”

“Bu problem başka ekibin sorumluluğunda.”

“Biz üzerimize düşeni yaptık.”

Teknik olarak bu ifadeler doğru olabilir.

Ancak yüksek performanslı organizasyonlar yalnızca kendi sorumluluk alanlarına değil, ortaya çıkan sonuca odaklanırlar.

Bunun güzel bir örneğini büyük ölçekli bir platform dönüşümü sırasında yaşamıştım.

Birden fazla engineering ekibinin dahil olduğu kritik bir proje yürütülüyordu. Her ekip kendi backlog’una sahipti ve bireysel hedeflerini başarıyla tamamlıyordu. Dashboard’lara bakıldığında her takım planlanan işleri zamanında teslim ediyor gibi görünüyordu.

Buna rağmen proje sürekli gecikiyordu.

İlk başta bu durum mantıksız görünüyordu.

Eğer herkes kendi hedeflerini gerçekleştiriyorsa proje neden ilerlemiyordu?

Daha sonra yapılan analizlerde problem ortaya çıktı.

Takımlar kendi başarılarını optimize ediyordu ancak proje başarısını optimize etmiyordu.

Kimse cross-team dependency’leri sahiplenmiyor, ekipler arasındaki blokajları çözmek için ekstra çaba göstermiyordu. Sonuç olarak lokal optimizasyonlar yapılırken global hedefler zarar görüyordu.

Bu durum dağıtık sistemlerde görülen optimizasyon problemlerine oldukça benzer.

Bir bileşenin performansını artırmak sistemin tamamını hızlandırmayabilir.

Benzer şekilde tek bir ekibin performansını artırmak da organizasyonun tamamını daha başarılı hale getirmeyebilir.

Bu nedenle engineering liderlerinin dikkat etmesi gereken en önemli konulardan biri, ekiplerin hangi sonuçları optimize ettiğidir.

Eğer insanlar yalnızca bireysel başarılarını veya takım bazlı metriklerini takip ediyorsa organizasyon bir süre sonra parçalanmaya başlar.

Buna karşılık yüksek performanslı ekiplerde ortak hedefler ön plandadır. İnsanlar yalnızca kendi backlog’larından değil, ortaya çıkan sonuçtan da sorumluluk hissederler. Bu yaklaşım ownership kültürünün organizasyon geneline yayılmasını sağlar.

Özetle;

Five Dysfunctions of a Team modelinin en güçlü tarafı, ekip problemlerinin birbirinden bağımsız olmadığını göstermesidir.

Birçok organizasyon semptomları çözmeye çalışır.

Delivery performansı düşüyorsa yeni süreçler eklenir.

Sprint hedefleri kaçıyorsa daha fazla raporlama yapılır.

Production incident sayısı artıyorsa yeni araçlar satın alınır.

Bunların bazıları kısa vadede fayda sağlayabilir ancak çoğu zaman problemin kök nedenine dokunmaz.

Çünkü organizasyonun temelinde güven eksikliği varsa insanlar riskleri paylaşmaz.

Riskler paylaşılmazsa sağlıklı tartışmalar yapılamaz.

Tartışmalar yapılamazsa alınan kararlara gerçek anlamda bağlılık oluşmaz.

Bağlılık oluşmazsa hesap verebilirlik zayıflar.

Hesap verebilirlik zayıfladığında ise ekip sonuçları ikinci plana düşmeye başlar.

Bu nedenle Five Dysfunctions of a Team yalnızca bir ekip çalışması modeli değil, aynı zamanda engineering organizasyonlarının sağlığını değerlendirmek için kullanılabilecek güçlü bir teşhis aracıdır.

Bir Engineering Manager, Director of Engineering veya CTO için modelin en önemli mesajı şudur:

Yüksek performanslı ekipler yalnızca güçlü mühendislerden oluşmaz.

Yüksek performanslı ekipler, güvenin bulunduğu, fikir ayrılıklarının açıkça tartışılabildiği, alınan kararlara sahip çıkılan, insanların birbirlerini sorumlu tuttuğu ve ortak sonuçlara odaklandığı ekiplerdir.

Teknoloji değişir.

Framework’ler değişir.

Mimari yaklaşımlar değişir.

Ancak yüksek performanslı ekiplerin temel dinamikleri büyük ölçüde aynı kalır.

Bu nedenle engineering liderlerinin en önemli sorumluluklarından biri daha iyi süreçler tasarlamak değil, daha sağlıklı ekipler oluşturmaktır. Çünkü çoğu zaman organizasyonların önündeki en büyük ölçeklenme problemi teknik değil, insani olandır.