- Kıdemli mühendisler ‘haklı olmaktan’ çok ‘etkili davranışa’ önem verir, bu yüzden yanlış giden her projeyi durdurmaya çalışmaz
- ‘Kötü proje’; teknik, politik ve UX kaynaklı sorunları kapsar ve çoğu zaman öznel değerlendirmeye göre değişir
- Etkinin bir banka hesabı gibi yönetilmesi gerekir; sık sık karşı çıkmak güven kaybına yol açabilir ve kişiyi ‘politik iflas’ durumuna sürükleyebilir
- Müdahale edip etmeme kararı; projenin yakınlığı, ekip üzerindeki etkisi ve şirket geneline vereceği zarara göre verilir
- Her sorunu çözmeye çalışmak yerine müdahale zamanını stratejik olarak seçmek, geri kalanında ise gözlem ve hazırlıkla hareket etmek gerekir
Kötü projenin tanımı ve örnekleri
- ‘Kötü proje’; gereksiz sorunları çözme, karmaşık tasarım, politik motivasyon gibi farklı biçimlerde ortaya çıkar
- UX açısından, var olmayan bir sorunu çözmeye çalışmak ya da mevcut akışı bozmak buna örnek olabilir
- Teknik olarak ise aşırı karmaşıklık, yanlış kütüphane seçimi, verimsiz mimari öne çıkar
- Politik olarak ise terfi almak ya da akımları takip etmek için başlatılan projeler buna girer
- Bir projenin iyi mi kötü mü olduğu, çoğu zaman ancak zaman geçtikçe ortaya çıkan öznel bir değerlendirmedir; başlangıçta net olmayabilir
- Google’daki bir örnekte, platform ekibinin çekirdek kullanıcı akışını başka bir ekibe devretmeye çalıştığı proje politik nedenlerle başarısız oldu
- Teknik açıdan çok iyi olmasına rağmen, ekipler arası yetki sorunu nedeniyle 2 yıl sonra rafa kaldırıldı
- Buradan çıkan ders şu oldu: Politika ve problemin doğru tanımlanması, teknik yetkinlik kadar önemlidir
Neden tüm kötü projeler engellenemez?
- Yazılım şirketlerinde ‘hızlı hareket etme’ önyargısı güçlüdür; bu nedenle kaygı dile getirmek çoğu zaman hızı yavaşlatan bir davranış olarak görülür
- Bu yüzden büyük bir sorun olarak algılanmıyorsa, itirazların göz ardı edilme ihtimali yüksektir
- Sürekli karşı çıkmak, kişiyi ‘negatif biri’ olarak damgalar; ayrıca önlenmiş başarısızlıklar genelde takdir görmez
- İtiraz etmek, başkalarının terfisini ya da üst düzey yöneticilerin projelerini etkileyebileceği için politik risk taşır
- Tek bir mühendisin taşıyabileceği dikkat kapasitesi sınırlıdır; her soruna müdahale etmek zamanla kişiyi alaycı ve yıpranmış hale getirir
Etkiyi bir ‘banka hesabı’ gibi yönetmek
- Etki, başarılar ve iş birliğiyle biriken bir varlıktır; her itirazda bu hesaptan çekim yapılır
- $5 çek: kod incelemesi düzeyinde küçük bir uyarı
- $500 çek: mimari karar ya da takvime yönelik itiraz
- $50,000 çek: yönetici düzeyindeki bir projeyi durdurmaya çalışma
- Küçük sorunlara tekrar tekrar müdahale etmek, büyük meselelerde harekete geçecek gücü ortadan kaldırır
- Etki tükendiğinde kişi, toplantı davetlerinden dışlanma, görüşlerinin yok sayılması gibi bir ‘politik iflas’ durumuna düşebilir
Ne zaman müdahale edileceğine karar verme ölçütleri
- Uzmanlığı doğrulama: Kendi yargınızın yeterince sağlam temellere dayanıp dayanmadığını kontrol edin
- Sözün sınırlarını bilme: Fikir belirtmek bir ‘emir vermek’ değil, bir ‘bakış açısı paylaşmak’tır
- Üç değerlendirme unsuru
- Yakınlık (Proximity): Proje kendi ekibinize ne kadar yakınsa, müdahale maliyeti o kadar düşüktür
- Ekip Etkisi (Team Impact): Başarısızlık doğrudan ekibe zarar verecekse, müdahalenin değeri artar
- Şirket Ölçeği (Company Scale): Başarısızlığın tüm organizasyona etkisi büyükse, müdahale gerekli olabilir
Kötü projelere yaklaşım biçimleri
- Doğrudan müdahale: Projenin durdurulmasını istemek ya da güçlü kaygılar içeren bir belge sunmak
- Bunun için hem yüksek güven hem de risk alma isteği gerekir
- Kısmi müdahale: Tasarım yönünü ayarlamak ya da daha iyi bir çözüme yönlendirmek
- İş birliğine açık bir tutumla yaklaşıldığında ‘yardımcı olan kişi’ olarak görülmek mümkündür
- Müdahale etmeme: Politik atalet veya etki sınırı nedeniyle müdahalenin değerli olmadığı durumlar
- Ekip ilgiliyse, bağımlılığı azaltmak ya da alternatifler kurmak gibi önlemler hazırlanabilir
- İlgili değilse, sessizce gözlemleyip yalnızca kurum içinde görüş paylaşmak daha uygun olabilir
- Ekip yönetimi: Gerçeği ekip üyeleriyle dürüstçe paylaşın, ancak gereksiz politik ayrıntılardan kaçının
Sonuç
- Temel fikir şudur: “Haklı olmakla etkili olmak aynı şey değildir.”
- Büyük şirketlerde mantıktan çok politika ve bağlam işler; bu yüzden her yanlışı düzeltmek mümkün değildir
- Etkiyi ve güveni stratejik biçimde kullanarak, gerçekten değişim yaratılabilecek anlara odaklanmak gerekir
- Diğer durumlarda ise ekiple paylaşmak, hazırlık yapmak ve gözlem yoluyla öğrenmek önemlidir
- Her şey kusursuz biçimde çözülemese de, sürdürülebilir yaklaşım budur
1 yorum
Hacker News görüşleri
Eskiden bir yöneticinin “bazen insanların başarısız olmasına izin vermen gerekir” dediğini hatırlıyorum
Bazı insanları sürekli ayakta tutmak için fazla enerji harcanıyordu. Bir noktada kendi başlarına yüzmeyi öğrenmelerini umuyordum, ama bazen o çabanın daha iyi bir yerde kullanılması gerekiyordu
Benim katılımım olmadan yürütülen bir proje vardı ve benim bilgim olmadan asla başarılı olamazdı. O ekip o kadar yetersizdi ki soruları adeta işin arasına serpiştirerek çalışıyordu
Üstelik yönetimin benim ekibimi küçümsediğini ve onları övdüğünü öğrendiğimde gerçekten aşağılanmış hissettim. Yaptıkları uygulama berbattı
Bazı yöneticiler fikirlerinin işe yaramadığının söylenmesinden hoşlanmaz. İtiraz edersen, başarısızlığın sebebi ilan edilirsin
Bu yüzden işi ilerletirim ama onlarla sık sık durum paylaşırım. Böylece beklenen başarısızlığı bizzat görürler ve beni o başarısızlıktan ayrı tutar
Bireysel başarısızlık düşük maliyetlidir ve öğreticidir. Hatta bazen onların yaklaşımı işe yarar ve kurum yeni bir bilgi varlığı kazanır
Başarısız olup hiçbir şey öğrenmeyebilirler. Ama elinden geleni yaptıysan en azından vicdan rahatlığına sahip olabilirsin
Bir projenin “kötü” olması, yaşam döngüsünün büyük bölümünde çoğunlukla özneldir
Dışarıdan birinin karşı çıkıp durdurmaya çalıştığı bir proje olmuştu; sonunda yayına alındı ve başarılı olunca o kişinin itibarı sarsıldı
İtibarını nerede kullanacağını dikkatle seçmelisin
Dünyanın her zaman güneşli ve gökkuşağı dolu olmadığını biliyorum ama o an gerçekten hayal kırıklığıydı
“Benim maymunum değil, benim sirkim değil” sözündeki gibi, sorumluluğum olmayan işlere karışmam
Mimar olarak çalışırken de benim alanım olmayan UI ya da iş mantığı konusunda gereksiz tavsiye vermedim
Üst düzey yöneticinin karar verdiği şeyleri olduğu gibi takip ederim. Danışman olarak çalışırken de aynı ilkeye bağlı kaldım
Yalnızca kendi uzmanlık alanımda dikkatli biçimde devreye girerim. Onu da ancak C-suite onayı varsa yaparım
Bu tavsiye KOBİ’ler için oldukça yerinde. Ama büyük şirketlerde bir projeye karşı çıkmanın neredeyse hiçbir anlamı yok
Başarılı olursa aptal gibi görünürsün, başarısız olursa da kimse hatırlamaz
Asıl ROI, başarısızlıktan sonra çözüm sunduğunda ortaya çıkar. İnsanlar “sorun çözücüleri” sever
Bir zamanlar otomatik E2E testleri önermiştim ve reddedilmişti; sonra sorun patlayınca o framework’ü çıkarıp getirdim ve kahraman gibi karşılandım
Açıkçası alt kademede daha az stresle yaşamak daha akıllıca geliyor
Buna karşılık büyük şirketler politika yüzünden yılları ve milyonlarca doları harcar
“Sorunları görmezden gelmemek gerekir” diyen taraftayım
Yardım edebileceğin bir konumdaysan, sessizce de olsa başka bir yaklaşım önermelisin. Bunu yapmak için duygusal tepki vermek gerekmez
Küçük organizasyonlarda iyi fikirler kolayca hayata geçer, ama büyük organizasyonlarda politik risk çok daha yüksektir
Gerçekte yardım etme olasılığın, itibar kaybetme olasılığından daha düşüktür. Bu yüzden hangi mücadeleyi seçeceğini bilmek önemlidir
Ama büyük organizasyonlarda zaten yürüyen bir projeyi değiştirmek muazzam zaman ve enerji ister
Aslında çoğu zaman o proje üzerinde kontrolümüz yoktur. “Başka bir ekibin bunu neden böyle yaptığını bilmiyorum” daha doğru bir başlık olurdu
Profesyonellik, konuşman gereken anda konuşmaktır. Ama tecrübeme göre bir şeyin değiştiği çok nadir olur
Şu anda gerçekten buna benzer bir durum görüyorum
İş sahibi maliyet ve hız nedeniyle bir low-code platform seçti, ama sonunda devasa boyutta hackvari özelleştirmeler gerekti
Benim ekibim TypeScript ile günde birkaç kez deploy yaparken, o ekip ayda bir kez deploy ediyor ve curl ile tuhaf işler çeviriyor
Bu tavsiye büyük teknolojideki politik gerçeklik açısından harika, ama sonuçta biraz kurumsal pasifizm gibi
Başka ortamlarda para ve motivasyonu yakıp kül edecek kadar alan yok
(Yine de Lalit, karmaşık organizasyon dinamiklerini kısa bir yazıya iyi sığdırıyor)
Sürekli kusur bulan kişiler sonunda negatif biri diye damgalanıyor
Sonuçta asıl tavsiye, önemli anlar için enerjini saklaman gerektiği. Her problem şirketin varlığını tehdit etmiyor
Mühendislerin politik olarak kötü projeleri “başarısız olmaya bırakma” yetkisi yoktur
Bu, yönetimin sorumluluğudur. Mühendis yalnızca teknik tavsiye vermelidir
Ama kariyerinin etkilenmemesi için bu dinamikleri anlaması gerekir
Ürün ekibiyle platform ekibi arasındaki alan kavgası, net liderliğin yokluğundan kaynaklanır
Bunun neden bu kadar sık yaşandığını merak ediyorsanız, Google ile ilgili yazıya bakmaya değer
Bu düşünce tarzı büyük organizasyonlarda, özellikle kamu kurumlarında yaygındır
Maliyeti başka bir departman üstlenir ve güç, yönetilen kişi sayısıyla ölçülür
Bu tür örgütsel nekrozu önlemek için liderlerin net ölçüm ve önleme mekanizmaları kurması gerekir
Politik sermayeyi yok sayınca ortadan kalkmış olmaz
İyi bir benzetme
Liderlik ve güven inşa ettiğinde, “yanılıyorsun” diyebileceğin bir alan oluşur
Ama liderlerin mühendislere her zaman güvenmemesinin sebebi, bazen mühendislerin de yanılıyor olmasıdır
Mühendisler kusur bulmakta çok iyidir ama iş bağlamını anlamakta zayıf kalabilir
Bu yüzden “aptalca görünen bir fikri” bile bağlamını anladıktan sonra değerlendirmek gerekir
Gerçekten öldürülmesi gereken fikirle yalnızca kusurlu olan fikri ayırt edebildiğinde, organizasyon içinde güven kazanırsın