Bir Yazılım Şirketi Gibi Bakmak

 (seangoedecke.com)
27 puan yazan GN⁺ 2025-10-09 | 1 yorum | WhatsApp'ta paylaş
  • James C. Scott'un “Seeing Like A State(Devlet Gibi Görmek)” kitabının temel fikri, örgütlerin sistemin “okunabilirliğini (legibility)” artırarak her şeyi ölçülebilir ve raporlanabilir hale getirmeye çalışmasıdır
  • Ancak gerçekte, izlenemeyen ve öngörülemeyen “okunamaz işler” vazgeçilmezdir; yalnızca okunabilirliğe odaklanmak ise tersine verimliliği düşürebilir
  • Özellikle büyük şirketler çeyreklik planlar, OKR'ler, Jira gibi süreçlerle işi okunabilir hale getirir, fakat bu paradoksal biçimde verimliliği düşürür; küçük şirketler büyük şirketlerden 20 kat daha verimli olabilir
  • Kurumlar, acil durumlara yanıt verebilmek için "tiger team" gibi geçici okunamaz alanlara izin verir; mühendisler arasındaki backchannel üzerinden yürüyen gayriresmî iş birliği, resmî süreçler kadar önemli bir rol oynar
  • Teknoloji şirketlerinin başarısı, okunabilir süreçlerle okunamaz fiilî işleyiş arasındaki dengeyi korumaya bağlıdır; bu ikisinden yalnızca biriyle bir organizasyon sağlıklı çalışmaz

Giriş: “Seeing Like A State”in temel fikri

  • James C. Scott'un “Seeing Like A State(Devlet Gibi Görmek)” adlı eserinin özü üç noktada özetlenebilir
    • Modern örgütler sistemi, her parçası ölçülebilir ve raporlanabilir olacak şekilde “okunabilirliği (legibility)” en üst düzeye çıkarılmış bir yapıya dönüştürerek kontrol eder
    • Ancak bu örgütler, büyük ölçüde “okunamaz (illegible)” işlere dayanır. Yani izlenemeyen ya da planlanamayan ama zorunlu olan pek çok iş vardır
    • Okunabilirliğin artırılması çoğu zaman verimliliği düşürür; yine de bunun dışındaki faydalar (kontrol, planlama, şeffaflık vb.) büyük kazanç olarak görülür
  • Okunabilirlik; öngörülebilir, çıktısı izlenebilir ve belirli insan kaynaklarına bağımlı olmayan işlerdir. Örnek: takvim yönetimi, OKR, Jira vb.
  • Okunamazlık ise doğaçlama ya da örtük bilgiye dayanan işlerdir; yani yazıya dökülemeyen, resmileştirilemeyen iş birlikleri, ani değişiklikler veya insan ilişkilerine bağlı işlerdir

“Devlet gibi bakmak (Seeing like a state)” örneği

  • Scott, 19. yüzyıl Almanyası'ndaki “düzenli orman” örneğiyle, örgütlerin verimlilik adına kontrol ve standardizasyon arayışını açıklar
    • Ormandaki tüm ağaçları tek bakışta görülebilecek şekilde yönetmenin, planlama, ticaret ve kaynak dağıtımı verimliliğini artıracağı düşünülüyordu
    • Gerçekte ise ormanın çeşitliliği ve alt katmandaki bitkilerin rolü göz ardı edildi; üretkenlik düştü ve orman hastalıklar ile parazitlere daha açık hale geldi
  • Yani hem verimlilik hem de şeffaflık hedeflenmişti; fakat aşırı okunabilirlik arayışı, sonuçta verimliliği baltaladı

Yazılım şirketlerinde okunabilirlik ve okunamazlık

  • Yazılım şirketlerinde de benzer biçimde, küçük ekipler veya bireyler daha verimli olabilir
    • Tek bir mühendisin tek başına çalışırken, bir ekibin parçası olarak çalıştığından daha verimli olabilmesi, yazılım mühendisleri arasında neredeyse sağduyu düzeyinde kabul gören bir görüştür
    • Mühendislerin kendilerinin yön verdiği işler, üstten atanan işlere göre çok daha hızlı ilerler; çünkü bunları anlamlı bir biçime çevirmek ya da her yöne yoğun biçimde iletişim kurmak gerekmez
  • Küçük yazılım şirketlerinin büyük şirketlerden çok daha iyi yazılım teslim etmesinin nedeni, büyük şirket 10 kat fazla mühendis kullansa bile küçük şirket 20 kat daha verimliyse bunun sorun yaratmamasıdır
  • Büyük şirketlerde, mühendislerin yaptığı işi “okunabilir” hale getirmek için çeşitli prosedürler ve araçlar devreye alınır
    • Bu, işin planlanması, ölçülmesi ve raporlanması için faydalıdır; ancak gerçek yazılım üretkenliğini düşürebilir
  • Küçük şirketler sorunlara anında yanıt verebilir veya değişimi hızla benimseyebilir; bu da okunamaz bir yetenektir
  • Büyük şirketlerin bu verimlilik yerine karmaşık süreçleri sürdürmesinin nedeni büyük enterprise sözleşmeleriyle ilgilidir. Büyük müşteriler tedarikçilerden öngörülebilirlik ve güvenilirlik ister
  • Böyle müşterilerle çalışmak için uzun vadeli planlama, özellik taahhütleri ve ilerleme dokümantasyonu gibi okunabilirlik unsurları zorunludur
  • Süreçler, okunabilirliğin sağladığı değerin (dolar cinsinden) yazılımı daha verimli üretme becerisinden daha yüksek olması nedeniyle korunur

Büyük şirketlerin önem verdiği okunabilirliğin pratik değeri

  • Büyük ölçekli yazılım şirketlerinde okunabilirlik şunları sağlar
    • Bireysel mühendis düzeyine kadar şu anda yürüyen tüm projelerin görülebilmesi
    • Geçen çeyrekte tamamlanan projelerin listesinin anında çıkarılabilmesi
    • İşlerin en az bir çeyrek önceden (veya daha fazla) planlanabilmesi
    • Acil bir durumda departmanın tüm kaynaklarının seferber edilip hemen işe yönlendirilebilmesi
  • Küçük yazılım şirketleri, anında esnek tepki verebilme yeteneği dışında bu gerekliliklerin çoğunu pek karşılayamaz
  • Büyük şirketler kayıt tutma, sınıflandırma ve uzun vadeli planlama konusunda güçlüdür; ancak hızlı tepki verme kapasitesi (örgütsel kaynakları anında devreye alma) tersine zayıflayabilir
  • Bu okunabilirlik, özellikle enterprise müşterilerle güven, sözleşme ve uzun vadeli iş birliği açısından kritik rol oynar

Okunabilirlik sağlamak için yapılan varsayımlar ve sınırları

  • Büyük şirketler okunabilirlik arayışında şu basitleştirici varsayımları yapar
    • Aynı seviyedeki tüm mühendislerin aşağı yukarı aynı performansı göstereceği varsayılır
    • Mühendislerin yerinin değiştirilmesi veya yeniden organize edilmesinin üretkenlik kaybı yaratmayacağı varsayılır
    • Bir ekipteki mühendis sayısı aynıysa, zaman içinde üretkenliğin de korunacağı varsayılır
    • Projelerin önceden tahmin edilebilir olduğu ve bir hata payı bulunduğu varsayılır
  • Oysa gerçekte
    • Aynı seviyede bile beceri farkı büyüktür; uzmanlık alanları ve ilgi alanlarına göre proje üretkenliği ciddi biçimde değişir
    • Ekip büyüklüğü ile üretkenlik arasında ancak zayıf bir korelasyon vardır
    • Proje tahmini neredeyse bir yanılsamadır; hatta bazen iş yapma biçimi, tahmin edilen takvime uydurulmak için değiştirilir
  • Buna rağmen bu varsayımlar, şirket içi iletişimde, dışarıdaki büyük şirketlerle yapılan anlaşmalarda ve iş planlamasında işe yarar

Geçici olarak izin verilen okunamaz alanlar

  • Büyük şirketlerde okunabilirlik üreten süreçler ciddi gecikmelere yol açar
    • Ürün fikri → ürün organizasyonunun planlama aşaması → mühendislik organizasyonunun teknik incelemesi → VP'ler ve kıdemli yöneticiler arasında ekip ataması pazarlığı → ekip planlama backlog'una giriş → ekip ticket backlog'una giriş → sprint'e giriş → gerçek işe başlama
  • Bu yapı, hemen yapılması gereken işlerle hiç uyumlu değildir
  • Bu sorunu çözmek için "sanal ekip", "strike team", "tiger team" gibi geçici okunamaz alanlara izin verilir
    • Bunlar, organizasyonun güvendiği seçilmiş mühendislerden oluşur
    • Çoğu zaman hiç yönetici atanmaz ve projeyi çok kıdemli bir mühendis yürütür
    • Gevşek tanımlanmış bir görev alırlar ve hedefe ulaşmak için temelde gereken her şeyi yapmalarına izin verilir
  • Bu, tam okunamazlık ile tam okunabilirlik arasında akıllıca bir uzlaşmadır
  • Resmî süreçleri baypas eder ama kalıcı olarak değil, yalnızca geçici biçimde var olur
  • İzin verilmiş okunamazlık bile örgütün geri kalanıyla rahatsız bir biçimde bir arada yaşar; diğer mühendisler süreç yükü olmadan çalışma özgürlüğünü görüp kıskanabilir veya bunu riskli bulabilir

Kalıcı ve izinsiz okunamaz alanlar

  • A ekibindeki bir mühendisin B ekibinden iş istemesinin resmî yolu, "planning" backlog'unda bir issue açıp 12 adımlı sürecin ardından iş sprint'e girene kadar beklemektir; bu da haftalar hatta aylar sürer
  • Resmî çözüm, A ekibinin planlama sürecinde B ekibinin yapacağı işi önceden tahmin etmesi gerektiğini söyler; ancak kod yazılmadan aylar önce tüm değişiklikleri öngörebilmek saçmadır
  • Gerçek çözüm okunamaz backchannel'dır
    • A ekibindeki bir mühendis, B ekibindeki bir mühendise "Şu tek satırlık değişikliği yapabilir misin?" diye sorar
    • B ekibindeki mühendis bunu hemen yapar; ticket açılıp açılmaması ise isteğe bağlıdır
    • Bu süreç, mühendisler arası kişisel ilişkilere dayandığı için okunamazdır
  • Backchannel'lar şirketin her seviyesinde sürekli vardır
    • Mühendisler arası ekipler arası backchannel'lar, ekip içi backchannel'lar, yöneticiler arası, ürün yöneticileri arası
    • Resmî alanlarda bir soru gündeme geldiğinde, çoğu zaman yanıt çoktan özel olarak prova edilmiş ve gözden geçirilmiştir
  • Backchannel'lar yanlış kullanılabilir ve bazen saf mühendisleri feda ederek bir başkasına avantaj sağlamak için kullanılır

Sosyopatlar, clueless'lar ve losers'lar

  • Venkatesh Rao'nun "Gervais ilkesi", organizasyonları üç gruba ayırır
    • En üstteki "sosyopatlar", örgüt kurallarını kendi çıkarları için alaycı biçimde kullanır
    • Orta kademe yönetimdeki "clueless" kişiler, örgütün resmî kurallarına inanır ve bunun üstünde daha derin bir oyunun oynandığını fark etmez
    • Onların altındaki "losers", oyunun oynandığını fark eder ama buna katılmak istemez
  • Bu kategoriler okunabilirlik açısından da okunabilir
    • Sosyopatlar ve losers'lar, örgütün okunamaz dünyasıyla ilişki içindedir
    • "Clueless" kişiler ise yalnızca okunabilir süreçlerle ilgilenir; terfi istediklerinde resmî kariyer basamaklarına bakar ve bir sonraki seviyenin her değerini nasıl göstereceklerini planlar
  • Bu insanlara "clueless" demek aşırı derecede alaycı olabilir
    • Okunabilir süreçler hâlâ çok önemlidir ve organizasyonun yaptığı işin büyük bir bölümünü oluşturur
    • Resmî süreçleri iyileştirmek hâlâ etkisi çok yüksek bir iştir
  • İnsanları bu kategorilerle düşünmek, yazılım şirketlerindeki sık çatışma alanlarının bu gruplar arasındaki sürtüşmeden kaynaklandığını anlamaya yardımcı olur

Son düşünceler

  • Organizasyon içindeki okunamaz dünyayı fark etmek ve kullanmak önemlidir
  • Yazar, teknoloji şirketlerinde okunamazlığı fark etmek ve kullanmak üzerine çok yazmıştır
  • Okunamaz süreçlere dair tavsiyeler "tehlikeli tavsiye" kapsamına girer
    • Resmî süreçler yerine backchannel üzerinden iş tamamladığını açıkça ilan edersen, organizasyon tarafından cezalandırılırsın
    • Yönetim zinciri aslında bunu istese bile cezalandırılırsın
  • Yazar, resmî süreçlerin asla baypas edilmemesi gerektiğine dair çok sayıda olumsuz geri bildirim aldığını, ancak bu görüşü safça bulduğunu söylüyor
  • Her organizasyonun hem okunabilir hem de okunamaz bir yüzü vardır
    • Okunabilir yüz, belirli bir ölçeğin üstünde önemlidir; uzun vadeli planlamayı ve diğer büyük organizasyonlarla koordinasyonu mümkün kılar
    • Okunamaz yüz de aynı derecede önemlidir; yüksek verimli işi mümkün kılar, mevcut duruma uymayan süreçler için bir emniyet supabı sağlar ve dedikodu ile yumuşak uzlaşıya yönelik doğal insan ihtiyacını karşılar

İlgili okumalar

1 yorum

 
GN⁺ 2025-10-09
Hacker News görüşü

  • İçeriğin büyük kısmına katılıyorum, ancak liderliğin otomatik olarak legibility'nin her türlü maliyeti karşılayacak kadar değerli olduğunu varsaymasına itiraz etmek istiyorum. Eğer CEO'nun tüm ayrıntılı işlerle (ör. unit test paralelleştirmesi gibi) bizzat ilgilenmesi gerekiyorsa, bu beynin parmağını her oynattığında bunu bilinçli olarak fark etmesine benzer ve sonuçta hiçbir şey yapılamaz. Gerçekçi olarak CEO, yani bir şirketin başı, bütünün ancak yaklaşık %7'sini kontrol edebilir. Geri kalanını çalışanlar tamamlar; kendisi yalnızca beyin rolündedir, tüm beden değildir. Ama liderler kendilerinin en önemli kişi olduğu yanılgısına kolayca kapılır ve zamanlarının yetmediği ya da uzman olmadıkları alanları (ör. MIT mezunu çok iyi bir mühendis ile bootcamp çıkışlı ortalama bir mühendisin farkı gibi) geçiştirir. Google'ın başarısından söz edilirken de onlarca mükemmel uygulayıcı yerine çoğu zaman yalnızca iki kurucuya ya da CEO'ya paye verilir

    • "Beynin nefes alırken her an bilinçli olması" örneğinin biraz saman adam safsatası olduğunu düşünüyorum. Yetkin bir CEO, geliştirme ekibindeki unit test yönetimini doğrudan takip etmesi gerekmediğini bilir. Nitekim şirketlerin hedeflediği legibility seviyesi çok daha makul bir aralıktadır

  • Buradaki bazı şeyler doğru ama biraz fazla uç noktaya götürülmüş gibi. Yaklaşık 5000 kişilik bir şirkette çalışıyorum (küçük değil ama Amazon ölçeğinde de değil). Kuralların çoğunun gayet iyi sebepleri var. Örneğin iki code reviewer gerekmesi hataları önlemek içindir. Review reddi çok sık olmaz ama review olmadan deploy edilirse kesintiler muhtemelen daha sık yaşanır. Bu tür kurallar insanı zorla da olsa kontrol etmeye iter. Elbette bir gün kuralları bozmanın gerektiği durumlar olur (ör. ekip üyelerinin çoğu bir incident yüzünden acilen devre dışı kaldığında). O zaman kuralın amacına uygun biçimde istisna tanımak mantıklıdır. Ama anlam verilemeyen salt bürokratik kurallarla dolu yerlerde (birinin kendi sürecine takılıp sürekli "senin yöntemin yanlış" diye tutturduğu tip yerler) insan ayrılmak ister. Gerçek ilerleme ve çıktılardan çok süreç ya da kişisel egoyu önemseyen bir ortamdaysanız, çözüm iş değiştirmektir

  • TDD'den sonra "test edilemiyorsa uygulanmış da sayılmaz" düşüncesinin cazibesi güçlendi. Bunu açıklamak için legibility kelimesi gerçekten çok uygun. Tritium'da yüzlerce unit test vardı ama ancak gerçekten blog oluşturmaya başlayınca unit testlerin yakalayamadığı niteliksel hatalar (testle doğrulaması zor olanlar) ortaya çıktı; bkz. https://tritium.legal/blog/eat. Bağımsız oyun geliştirmenin piyasa mantığına bu kadar iyi direnmesinin nedeni de bu olabilir. Oyun geliştiricileri kendi ürünlerini bizzat kullanır (Food-dogging) ve bu da niteliksel iyileştirme sağlar. Büyük şirket yazılımlarındaki kadar aşırı bir legibility yüzeyine ihtiyaç duymazlar. Asıl nokta, hem niteliksel hem niceliksel göstergelerin gerekli olmasıdır

    • Testler, özellikle de unit testler, "sokak lambası etkisine" karşı savunmasızdır. Önemsiz ya da daha az önemli parçaları test etmek daha kolaydır; bu yüzden kolay olan şeyler test edilir. Organizasyon line coverage gibi ölçmesi kolay göstergilere takıntılı hale gelirse, gerçekten anlamlı (ama zor) doğrulamalar dışarıda kalabilir. Deneyimli bir mühendisin review'u gibi nitel değerlendirmeler de önemlidir

    • Oyun geliştirmede geri bildirim döngüsü diğer yazılım alanlarına göre çok daha kısadır. Örneğin bir memory leak oluşursa sorun hemen, saniyede yüzlerce kez görünür hale gelir. Yavaş kod görsel takılmalarla anında hissedilir; bu da cache coherence, GC kullanımı gibi performans konularına dikkat etmeyi zorunlu kılar

    • TDD'yi seviyorum ama sonuçta manuel test de mutlaka gerekli. Bizzat test etmezseniz beklenmedik sorunlar sık çıkar. Özellikle kullanıcı dostuluğu gibi şeyler ancak gerçekten kullanınca netleşir

  • Sean'ın yazılarını severim; bu yazıda da ürün alanının geneline dair çok şeye katılıyorum. Örneğin yaklaşık bir yıl önce, birkaç ürün sorumlusu ve mühendis başka ekiplerin de işine yarayacak bir şey yapmaya çalıştı. Resmî bir kanal (legible channel) üzerinden onay almak o dönemin yapısında gerçekçi değildi; bu yüzden güven ve saygıya dayalı gayriresmî bir (illegible channel) yolla ilerledik. Taban hareketi (Grassroots) gibi başladı ve hatta şirket içinde hızla ağızdan ağıza yayılarak traction kazandı. Sonunda yönetim bunu kendi başarı hikâyesi gibi kullanmaya başladı ama iş tersine dönüp tüm resmî süreçler (legible channel) ve sonradan gerekçe üretme aşaması başlayınca süreç epey sancılı oldu. Yine de başarısızlık riski büyük ölçüde düştüğü için daha katlanılabilir. Son yıllarda üzerinde çalıştığım en tatmin edici ve en keyifli projeydi

  • Şirket hayatında ve office politics içinde ne kadar uzun süre kalırsam, bunun geopolitics ya da diplomasiye ne kadar benzediğini o kadar düşünüyorum. Daha da ileri gidersek sosyal ilişkiler ve romantik ilişkilerle bile paralellikler görülebiliyor. Muhtemelen soyut model kurmayı seven matematikçi mizacımdan kaynaklanıyor

    • En sevdiğim konulardan biri zaten siyaset. Kitaplar, dergiler ve her türlü materyali keyifle takip ediyorum; açıkçası şirket içi siyasetten de çok rahatsız olmuyorum. Özünde mesele şu: insanlar, insan gibi davranır. Her bireyin (ve organizasyonların da) istediği şeyler (arzular) ve korktuğu şeyler vardır; bunları dengede tutmaya çalışmak da işin eğlenceli kısmıdır. Adeta bir mühendislik problemi çözmek gibidir, tek fark gereksinimlerin "insan" olmasıdır. Bu tür problemleri çözme sürecinin kendisi ilgi çekici

    • Bunu ancak yakın zamanda fark ettim. Başta diplomasiyi yüzlerce diplomatın oluşturduğu karmaşık bir sistemin sonucu sanıyordum ama aslında birkaç güçlü kişinin iç içe geçmiş insan ilişkilerinden ibaret. Kreşte olan şeylere benzer bir yaklaşımla da ele alınabilir

    • Bu içgüdüsel olarak gayet doğal bir olgu. Sosyal ilişkilerden (ör. romantik ilişkiler) çok, büyük şirketlerle hükümetler arasında daha belirgin benzerlikler var. Şirketler genelde çok daha otokratik ya da feodal yapılara yakındır. Elbette pek çok fark da var ama ölçek büyüdükçe giderek devletlere daha çok benzemeye başlarlar. Gelişmiş bürokrasiler de bunun bir parçasıdır

    • Game theory wiki

    • Modern siyasetçilerin önemli bir kısmının sıradan ofis işlerinden gelmiş olması düşünülürse, bu eğilim çok da şaşırtıcı değil

  • Ben IT security tarafında çalışıyorum ve burada bu durum daha da belirgin. "Ekibimizin doğrudan metriklerine katkı sağlamayan talepleri" kabul etmemiz gerektiğinde, back channel dışında bir alternatif olup olmadığını merak ediyorum. Bilen var mı?

    • Ekip mühendislerini karşı tarafın istediği işlere ya da roadmap maddelerine takas usulüyle ayırabilirsiniz; böylece iki taraf birbirinin istediğini değiş tokuş eder

  • Güzel bir yazı ama her zaman ele alınmayan bir noktayı söylemek istiyorum. Metin, software engineer'ı adeta ağacın yaprağı ya da montaj hattı işçisi gibi resmediyor; bu biraz eksik kalmış. Oysa "Legible assumptions" bölümünde de geçtiği gibi, mühendisler gerçekte organizasyon yapısına kod üzerinden bağlantılar ekleyen bir tür "yönetici rolü" de üstlenir. Sorunlar benzer, sadece uygulandığı nesneler farklıdır

    • Senior Engineer gibi IC seviyelerinde yükselmek istiyorsanız, fiilen yöneticinin yaptığı şeylerin de sizden beklenmesi gerekir. Sadece iyi kod yazmak yetmez. Proje yönetimi, mimarlık, ekip liderliği, ikna kabiliyeti gibi roller de gerekir ve bunları belgelerle desteklemeniz beklenir

  • Metindeki şu kısma katılan var mı: "Neden küçük şirketlerde gerekmeyen bu yetkinlikler büyük yazılım şirketlerinde zorunlu oluyor? Uzmanlık alanım değil ama muhtemelen büyük kurumsal projeler yüzünden." Görüşlerinizi merak ediyorum

    • Bunun kurumsal müşterilerle yapılan anlaşmalardan çok, içerideki communication at scale meselesiyle ilgili olduğunu düşünüyorum. m çalışanı olan bir organizasyonu m*m'lik bir iletişim matrisi gibi düşünebilirsiniz. İnsan sayısı azken neredeyse tüm hücreler 1'dir (yakın iletişim), ama ölçek büyüdükçe çoğu hücre 0'a (kopukluk) ya da 0.5'e (gayriresmî iletişim) dönüşür. Oysa bilgi sonuçta şirketin kendisidir. Bu yüzden bilgi "akışını" yöneticiler ve resmî süreçler üzerinden sahiplenen bir yapı zorunlu hale gelir. Planlama, terfi, inceleme gibi şeylerin hepsi bu legibility'yi sağlamak içindir

    • Küçük bir şirkette büyük kurumsal projeleri üstleniyoruz ama iç işleyişte katı bir legibility dayatmadan da anlaşma yapılabiliyor. Müşteri karşısında proje yönetiminin legibility'si gerekir, ama iç geliştirme biçimine kadar ayrıntılı müdahale şart değildir. Sonuç olarak büyük şirketlerin legibility'ye takıntılı olmasının sebebi, zaten büyük şirket olmaları ya da öyle olmayı istemeleridir

    • Uzun süre medikal görüntüleme alanında bulundum; işletme sahiplerinin çoğu aslında IT hizmeti/çözüm sektöründe olduklarını tam anlamıyor. Oysa başarıyı getiren asıl unsur IT hizmet kabiliyetiydi. Başarının, tanının kendisinden çok, radyoloji dışı personelin platformun kullanılabilirliğini ve verimliliğini artırmak için gösterdiği çabayla ilgisi vardı

    • Ne kadar büyük olursa olsun, bir organizasyon her zaman birden fazla iç ve dış audit'e hazır olmak zorundadır. Auditor'lar mümkün olduğunca çok süreç dokümanı görmek ister. En kötü durumda, örneğin bu vakada olduğu gibi, auditor müşterisini bile "kovabilir"

    • O kısım (bunun büyük kurumsal anlaşmalar yüzünden olduğu fikri) bana da biraz tuhaf geliyor. Startup geçmişi olan ve şu an orta ölçekli bir şirkette middle manager olarak çalışan biri olarak şunu söyleyebilirim: organizasyon büyüdükçe, işlerin nasıl yapılacağını anlatan asgari bir yapıya daha çok ihtiyaç duyulur. Süreçlerden ne kadar nefret ederseniz edin, Dunbar’s Number aşıldığında empati ve gayriresmî iletişim tek başına yetmez. Bunun uç örneklerinden biri Steam'dir; ama orada da çok belirli bir tür yetenek seçilir ve iç siyaset çok yoğundur

  • legibility kelimesinin seçimi başlı başına ilginç. Resmî ve gayriresmî süreçler arasında bir ikilik hissi veriyor. Şirket küçükken gayriresmî yöntemler iyi işler ama belli bir eşiği geçince resmî kurallar ve süreçler kaçınılmaz hale gelir. Uzun vadede ise kurallar katılaşır ve değişime ayak uyduramaz hale gelir. Giderek amaçtan çok sürecin kendisine takıntı oluşur. Böyle bir rutinin dışına çıkıp yenilikçiliği korumak kolay değil. Şirketlerde paranın kan gibi olduğu söylenir ama gerçekte para nadiren asıl motivasyon kaynağıdır. Para gerekli bir koşuldur ama varoluş nedeni değildir

  • Bu her zaman bir denge meselesi. 25 yıl boyunca engineering manager olarak çalıştım ve güçlü biçimde süreç odaklı bir şirkette bulundum. Bazen bunaltıcıydı ama dünya standartlarında donanımı istikrarlı biçimde üretmenin de avantajlarını gördüm (yazılım için aynı şeyi söyleyemem). Dokümantasyon gibi şeyler şart ama aşırı katılık projeyi kilitleyebilir. En ciddi sorun communication overhead. Bu yüzden az sayıda ama güçlü ekiplerin uzun süre birlikte çalıştığında inanılmaz üretken olabildiğini görüyoruz ve tribal knowledge da gerçekten çok önemli bir hızlandırıcı. Concrete Galoshes yazısını da bu yapısal ve katılık kaynaklı etmenleri ele almak için yazdım. En büyük ders şu: "Her projeye aynı kıyafeti giydiremezsiniz." Her proje farklı düzeyde yapı ve overhead gerektirir

    • Communication overhead gerçekten asıl sorun. Takıma yeni insanlar eklendikçe ekip içi iletişim ihtiyacı geometrik olarak artıyor; organizasyon genelinde takım sayısı arttığında da aynı şey geçerli. Son derece verimli bir ekibin sırrı güven ve karşılıklı anlayıştır. Zamanla herkes birbirinin güçlü ve zayıf yönlerini öğrenir, ekip içinde güven oluşur. Biriken bu tribal knowledge'ın ideal olarak dokümantasyon, mentorluk, sunumlar vb. yollarla iyi aktarılması gerekir