Son zamanlarda, benzer bir temayı paylaşan iki konu üzerinde düşünmeye devam ettim. İlk konu, California eyaletinin kamu altyapısı ve yıllar içinde ne kadar verimsiz hale geldiği ile ilgili. İkincisi, büyük teknoloji şirketlerinin yeni başlayanlardan daha hızlı yenilik yapma ve yürütme konusundaki başarısızlığıdır. Önce size düşünmeniz için iki örnek vererek, bu konuların neden birbiriyle ilişkili olduğuna dair bazı bakış açıları sunmama izin verin:

• Altyapı : Golden Gate Köprüsü'nün inşası yaklaşık dört yıl sürdü (1933–1937) ve bugünün parasıyla bize ~500 milyon dolara mal oldu. Buna karşılık, temelde köprünün çevresine bir ağ ekleyen SDS'nin ( İntihar Caydırma Sistemi ) tamamlanması beş yılımızı alacak (2017–2023) ve bize ~217 milyon dolara mal olacağı tahmin ediliyor. Kaliforniya'daki büyük altyapı projelerini incelerseniz, 1950'lerden önce tamamlanan projelerde, bugün olduğundan en az 5 kat daha hızlı, daha ucuz ve daha kaliteli bir iş yapıldığını görürsünüz. daha fazla sermayeye, daha iyi teknolojiye, daha iyi hammaddelere ve daha yüksek mutlak inşaat mühendisi ve mimar sayısına sahibiz.
• Teknoloji Şirketleri : Adobe, tüm finansal ve insan kaynaklarına rağmen, 20 milyar dolara bir rakip satın almak zorunda kalıyor. Adobe'nin Figma için fazla ödeme yapıp yapmadığı hala görülecek, ancak daha ilginç olan soru şu: 100x personeli, 100x tasarım araçları deneyimi derinliği ve 100x finansal sermayesi olan bir şirket neden kazanamadı?

Benzer şekilde, şirketlere bakarsanız, onlar büyüdükçe, süreçlerin ve şişkinliğin her şeye sızdığını ve gerçek iş ve yeniliği boğduğunu görebilirsiniz. Bu ortamda, bir şeyler yaratmaya en hevesli çalışanlar, yani yapımcılar, işlerinin gerçekleştirilebileceği bir çıkışın olduğu daha küçük bir yere gemi atlamayı daha çekici buluyorlar. Hem altyapı başarısızlıkları hem de şirket inovasyon başarısızlıkları en azından kısmen şişkinlik ve süreç sürünmesinden kaynaklanmaktadır.

Süreç kayması neden olur?

Her süreç iyi niyetle başlar.

• "Tüm paydaşların nihai çalışmaya katkı sağladığından emin olmak istiyoruz, bu nedenle sunulan tüm proje tekliflerinin hukuk, tasarım, ürün ve mühendislik ekipleri tarafından incelenmesi gerekiyor."
• "Büyük altyapı projelerinin zarar vermemesini sağlamak istiyoruz, bu nedenle herhangi bir işe başlamadan önce kapsamlı çevre çalışmaları yapmalıyız."
• "Veri ihlallerini en aza indirmek istiyoruz, bu nedenle herhangi bir veri talebinin BT ve Güvenlik ekipleri aracılığıyla yapılması gerekiyor."

mükemmeliyetçiliğe giden yol

İyi niyetli bir yöneticinin astlarına sanki 100 yıl sürecekmiş gibi yazılım yazmalarını söylediğini hatırlıyorum. Söz abartılı olsa da tavsiye, teknoloji endüstrisinde sık sık duyduğum bir şeyi "iki kez ölç ve bir kez yaz" veya "doğru yapmak için vaktin yoksa, yapmak için zamanın var mı?" gibi atasözleriyle yankılanıyor. iki kez mi? Bu kötü bir tavsiye değil. Bazı durumlarda 100 yıl sürecekmiş gibi kod yazmanız gerekir., ve planlama yapmadan doğrudan uygulamaya geçmek israftır. Bununla birlikte, planlamaya aşırı önem verilmesi, felce ve yineleme yoluyla öğrenmenin faydalarının fark edilmemesine yol açabilir. İşlerin " 50 yıllık kod tabanlarında " yürüdüğü bir dünya yerine, yazılımın her yıl yeniden yazıldığı bir dünyada yaşamayı tercih ederim çünkü mükemmelliğin var olmadığına ve evrim için ön koşulun değişim olduğuna dair güçlü bir kabul var .

çok fazla yapıştırıcı

Yıllar önce Tanya Reilly'nin Tutkal olmakla ilgili blog gönderisini okudum (okunması şiddetle tavsiye edilir, btw). Kariyerimin o noktasında içerik gerçekten yankı buldu çünkü teknik olarak yetkin olmalarına rağmen doğru şeyler üzerinde çalışmayan birkaç meslektaşımla uğraşıyordum. Tutkal insanları, ekipteki diğer insanları daha üretken kılmaya yol açan bir teknik liderlik ve akıl hocalığı sürecine girerler. Bir miktar yapıştırıcı gerekli, yine de çok fazla yapıştırıcının bir dizi başka sorun yarattığını gördüm:

• Yapıştırıcı işi yapan kişiler, diğer kişilerin teknik olmayan becerilerini geliştirmelerini engeller. Örneğin, ekibinin işleri hakkında konuşmasına izin vermeyen veya genellikle bir "tampon" görevi gören bir Teknik Lider, esasen IC'lerin mücadele etme ve sonunda iletişim becerilerini geliştirme fırsatlarını elinden alıyor.
• Yapıştırıcı davranışın aşırı ve zehirli çeşitleri, bazen diğer insanların çalışmaları için övgü almakta veya çok abartılı atıflarda bulunmakla kendini gösterir (“örneğin, ben aracı olarak hareket etmeseydim, proje başarılı olmazdı”). Tanya, Glue insanlarının genellikle kabul görmediği durumlardan bahsederken, benim deneyimim tamamen tersi. Tutkal insanları iyi iletişimciler olduklarından, işlerinin reklamını yapmayı ve siyaseti iyi oynamayı bilirler. Buna karşılık, daha yüksek görünürlük ve daha fazla terfi fırsatı elde ederken, uygulama ayrıntıları üzerinde çalışan mühendis genellikle belirteç onayı alır veya hiç kredi almaz.
• Son olarak, çok fazla yapıştırıcı çalışanı eklemek, bireysel mühendislerin sahipliğini ve sorumluluğunu azaltır. Teknik olarak yetkin bir ekibi yönetmek için yapıştırıcı insanları eklemek yerine, iş sezgisi olmayan, iletişim becerilerine sahip olmayan veya yaptıkları işin neden etkili olduğunu açıklayan bir paragrafı bir araya getiremeyen mühendisleri bırakırdım. Mühendisleri yönetmek için daha fazla yapıştırıcıya ihtiyacınız olduğunu önermek, teknik olarak parlak insanların aynı zamanda yüksek düzeyde genel zekaya sahip oldukları, çok okudukları, yaşam boyu öğrenenler oldukları ve sadece kod yazmakla kalmayıp işlerinde de çok iyi oldukları şeklindeki genel kalıbı reddetmekle sonuçlanır.

Novell'deyken "tutkalcı" dediğim insanların olduğunu öğrenmiştim. Yapıştırıcı insanlar, gruplar arasındaki ara sınırlarda oturan inanılmaz derecede iyi insanlardır ve aktiviteye yardımcı olurlar. Ve çok ama çok sadıklar ve insanlar onları seviyor ve sizin onlara hiç ihtiyacınız yok.

Novell'de bu yapışkan insanlardan kurtulmaya çalıştım çünkü yoluma çıkıyorlardı çünkü her şeyi yavaşlatıyorlardı. Ve bir grupta onlardan ne zaman kurtulsam, başka bir grupta ortaya çıkıyorlar ve transfer oluyorlar ve yeniden işe alınıyorlar falan.

Entropi

Kuruluşlar büyüdükçe kurumsal bilgi, paydaşların sayısı, kod tabanları ve entropi artar. Artan entropi, yüksek israfa, yüksek bilişsel yüke, düzensizliğe ve kaosa yol açar.

Yazılım mühendisleri olarak, karmaşıklığı yönetmede berbat bir iş çıkardığımızı düşünüyorum. Örneğin, yıllardır monolith'lerin şişirilmiş kod tabanları oluşturdukları, dağıtımları zorlaştırdıkları veya ölçeklenebilirlikle ilgili sorunlar oluşturdukları için kötü olduklarını duyduk. Yine de diğer uçta, mikro hizmetler dünyasında çalışmak zorunda olduğumuz yerde, temel şeyleri göndermek için farklı dillerde yazılmış, her biri kendi konuşlandırma tuhaflıklarına ve mimari modellerine sahip birden çok kod tabanında işlem yapmam gerektiğini görüyorum. paradigma lambda spagetti'ye dönüşüyor . Durup neyin önemli olduğuna yeniden odaklanmanın entropiyi azaltmada büyük etkisi vardır. Düşük, eylem odaklı bir seviyede, aşağıdaki gibi tezahür edebilir:

• Üretimde yürütülmeyen ölü kodun silinmesi. Kodun %50'sinden fazlasının ölü kod olduğu ve meslektaşlarım için bilişsel yük oluşturduğu pek çok kod tabanıyla etkileşim kurdum. Keşke dev üretkenlik alanında, üretimde yürütülen satırlara dayalı olarak kod kapsamı oluşturan bir şey olsaydı. Her üç ayda bir durup bu raporları inceler ve sıfır yürütmeye sahip dosyaları silersiniz.
• Ürün yöneticileri olarak, hangi özellikleri öldürmemiz veya geri döndürmemiz gerektiği konusunda yeterince kafa yormuyoruz. Yine de, silinmesi gerekenler üzerinde durup düşünmek, kullanıcı deneyimini basitleştirmek ve geliştirmek için çok anlamlı olabilir. Kendimi teknolojiden anlayan biri olarak görüyorum, ancak bugün oluşturulan ürünlerin birçoğunun mevcut bir dizi kullanıcı için aşırı optimize edildiğini ve yeni kullanıcılar için karmaşık ve kafa karıştırıcı bir UX deneyimine yol açtığını görüyorum. Çeyreğin sonunda "Hangi özelliği iptal edebiliriz?" dağınıklığı azaltmada faydalı olabilir.

Ego düşmandır

Ryan Holiday, Ego is the Enemy adlı kitabında, "herkes için var olan - eylemin yerini alacak konuşma ve abartı için güçlü bir ayartma" olduğunu öne sürüyor. Ego, birçok kurumda ilerleme ve yeniliğin cansız olabilmesinin büyük bir nedenidir. Ego kendini şu şekilde gösterir:

• Aynı insanların, fikirlerinin hiçbir marjinal değer katmadığı veya çok az değer kattığı halde, düşüncelerini bir grup sohbetine sokmak için can attığını görmek.
• Meslektaşlarına asla aktif olarak sponsorluk yapmayan veya görünürlük biriktirmeye çalışan insanlara sahip olmak. Bir yönetici veya yöneticilerin yöneticisiyseniz, bire bir görüşmelerinizde astınızın diğer insanların başarıları veya katkıları hakkında ne sıklıkta konuştuğunu görerek bunu fark edebilirsiniz. Başkalarının onaylanmaması veya özverili sponsorluğu, sağlıksız bir egonun işareti olabilir.
• Genel şirket veya kuruluş yerine ekip için optimizasyon yapmak. Diyagramı Tanya Reilly'nin Personel Mühendisinin Yolu'ndan ödünç aldım ve ekiplerin yerel maksimum için optimizasyon yaptığı bu sorunu mükemmel bir şekilde örnekliyor. Örneğin, kendi alanınızda bakım moduna giriyorsanız, ekibinizi dağıtmanıza ve çalışanları diğer ekiplere yeniden dağıtmanıza izin verir misiniz? Çoğu yönetici bunu asla yapmaz çünkü bu, şirket içindeki herhangi bir sosyal ve politik sermayeyi kaybetmek anlamına gelir.

• Rolünüze bağlı olarak, toplantıların değerini nasıl gördüğünüz konusunda çok güçlü bir ikilem vardır. " En güçlü insanlar yöneticinin programındadır ". Ne yazık ki, toplantıların değerine ilişkin algıları, bir sorun ve çözüm hakkında düşünmek için kesintisiz zamana sahip olmayı tercih eden insanları etkileyen kültürel bir baskınlık yaratıyor. Beyin fırtınası amaçları için bile, kanıtlar grup beyin fırtınasının zaman kaybı olduğunu gösteriyor . Yine de neden bu kadar çok şişirilmiş kuruluş, IC'lerin zamanının yarısını toplantılarda harcıyor?

Çözüm

İnovasyonun motoru evrimsel değişime dayanır. Nihayetinde, bir kurum katılaşırsa ve değişime uyum sağlamazsa, yavaş yavaş ölür. Deneyimlerime göre, bir süreci uygulamaya koymanın genellikle hızın düşmesine neden olan istenmeyen maliyetleri vardır. Bunun yerine, aşağıdakilere odaklanırdım:

• Mükemmeliyetçiliğe ulaşmaya çalışmak yerine yinelemeyi ve hatalardan öğrenmeyi tercih etmek.
• Yapıştırıcı insanlar gereklidir, ancak sayılarının bir sınırı olmalı ki yüksek kaldıraçla hareket edebilsinler. Hem teknik olarak yetkin hem de iyi bir iş sezgisine sahip kişileri işe almak, birleştirici roller için gereğinden fazla işe alma ihtiyacını çözebilir.
• Son olarak, sürekli olarak neyin atılabileceğini sorarak ve insanları basitliği artıran davranışlar için ödüllendirerek entropiyi azaltmaya odaklanacağım.