- Mühendislerin teknoloji şirketlerinde organizasyon politikasına etkili biçimde katılabilmesi için pratik stratejiler sunan bu yazı, birçok mühendisin yaşadığı politik güçsüzlük hissini nasıl aşabileceğini ele alıyor
- Mühendisler politik oyunun oyuncuları değil araçlarıdır; ancak üst düzey görünürlüğe sahip projelerin başarısını aktif olarak destekleyerek veya organizasyonun öncelik değişimlerine uygun teknik fikirler önererek politik etki yaratabilirler
- Organizasyonun ilgi alanları dalgalar gibi değiştiği için, kararlılık, geliştirici deneyimi, performans iyileştirmeleri gibi farklı yönlerde teknik programları önceden hazırlamak ve doğru zamanda önermek temel stratejidir
- Politik ihtiyaçlarla iyi fikirlerin yokluğu çakıştığında en kötü teknik kararlar alınır; kıdemli mühendislerin doğru zamanda doğru fikirleri sunma sorumluluğu vardır
- Buna alaycı bir bakışla güç mücadelesinin aracı olmak denebilir; iyimser bir bakışla ise yönetimin öncelik belirleme rolüne saygı gösterirken kendi teknik hedeflerine ulaşmanın bir yolu olarak görülebilir
Mühendislerin Politik Güçsüzlüğüne Dair Yaygın İnanç
- Birçok yazılım mühendisi şirket politikalarına karşı kaderci bir tutum taşır ve katılımın anlamsız olduğuna inanır
- Teknik kararlar çoğu zaman tamamen bencil nedenlerle alındığı için iyi niyetli mühendislerin etkide bulunamayacağı düşünülür
- Güçlü paydaşlar o kadar yetersiz ve işlevsizdir ki, ne istediklerini anlayıp çözüm üretmek pratikte imkansızdır
- Politik oyun, mühendislerin sahip olmadığı gizli bilgilere dayanır; bu yüzden katılma girişimleri sadece boş yere çırpınmaya yol açar
- Yöneticiler ve üst düzey yöneticiler zamanlarının çoğunu politikaya ayırırken mühendisler mühendisliğe ayırır; bu nedenle mühendisler baştan ciddi bir politik dezavantajla başlar
- Yazılım mühendislerinin gerçek politik operatörlerle aynı seviyede oyun oynayamayacağı doğrudur
- Mühendislerin Game of Thrones tarzı entrikalar çevirmeye başlaması korkunç bir hatadır ve bu tür manevralar hemen fark edilip aleyhlerine kullanılır
- Entrika kurmak pratik ve güç gerektirir; yazılım mühendislerinde ise genellikle ikisi de yoktur
Politikaya Katılmanın Pratik Yolları
- Büyük şirketlerde yazılım mühendislerinin politik oyunun oyuncuları değil araçları olması basit bir gerçektir; ancak entrikaya başvurmadan da politikaya katılmanın birçok yolu vardır
- En kolay yöntem, yüksek profilli bir projenin başarısı için aktif biçimde çalışmaktır
- Bu, normal iş kapsamında zaten yapılacak şeylere oldukça benzer
- Şirket yeni bir projeye (bugünlerde büyük olasılıkla bir yapay zeka projesine) ciddi yatırım yapıyorsa, mühendislik becerilerini kullanarak onu başarılı kılmak, projeyi yöneten VP ya da yönetici için politik olarak avantajlı bir hamledir
- Karşılığında prim, terfi desteği veya gelecekte başka yüksek profilli projelerde pozisyon gibi, yöneticilerin teknoloji şirketinde verebileceği ödüller alınır
Teknik Fikirleri Politik Kampanyalarda Kullanmak
- Biraz daha zor ama daha fazla kontrol sağlayan yöntem, tercih ettiğiniz fikirleri mevcut politik kampanyalarda kullanılabilir hale getirmektir
- Mevcut bir özelliği ayrı bir servise ayırmak istediğinizi varsayalım; bunun için iki yol vardır
- Zor yol: Kendi politik sermayenizi harcayıp destek toplamak, yöneticinize önemini anlatmak ve şüphecileri yavaş yavaş ikna ederek projeyi onaylatmak
- Kolay yol: Bir yöneticinin (çok daha büyük) politik sermayesini bu projede kullanmasına imkan vermek
- Projeyle uyumlu bir hedef hakkında şirket çapında bir yönlendirme gelene kadar beklemek (örneğin büyük bir olaydan sonra kararlılığa odaklanılması)
- Sonra yöneticinize projenizin buna uygun olabileceğini önermek
- Eğer doğru değerlendirdiyseniz organizasyon projeyi destekler ve politik sermaye harcamak yerine hatta artırmış olursunuz
Organizasyonun İlgi Dalgalarına Uyum Sağlamak
- Organizasyonun ilgisi dalgalar halinde gelir
- Kararlılık dönemi geldiğinde VP'ler bir şeyler yapma konusunda çaresiz hale gelir; üstlerine gösterebilecekleri makul bir kararlılık projesi ararlar ama bunu kendileri üretecek yetkinliğe sahip değildirler
- Bu durumda genellikle mühendislik ekiplerinin önerdiği hemen her şeyi fonlamaya isteklidirler
- Buna karşılık organizasyonun dikkati başka bir yere kaydığında (örneğin büyük bir yeni ürün lansmanına), mühendislerin müşteri tarafından görülmeyen iç kararlılık odaklı refactoring çalışmalarına zaman ayırmasını istemezler
- Teknoloji şirketlerinde teknik işleri gerçekleştirebilmek için doğru dalgayı beklemek gerekir
- Farklı yönlere giden birkaç teknik programı önceden hazırlamak iyi bir fikirdir
- Güçlü mühendisler bunları normal çalışma akışı içinde zaten doğal olarak fark eder
- Örnek planlar:
- Faturalama kodunu, cache'lenmiş API çağrıları yerine webhook ile güncellenen saklanan veriye taşımak
- Eski, el yapımı build pipeline'ını kaldırıp yerine Vite kullanmak
- Trafiği yüksek, dağınık bir Python servisini Golang ile yeniden yazmak
- Açık dokümantasyonu destekleyen yavaş bir CMS frontend'ini hızlı bir statik site ile değiştirmek
Doğru Zamanda Öneride Bulunmanın Önemi
- Yöneticiler faturalama konusunda endişeliyken faturalama refactoring'ini kararlılık iyileştirmesi olarak önerebilirsiniz
- Geliştirici deneyimi konusunda endişeliyken build pipeline değişimini önerebilirsiniz
- Müşteriler performanstan şikayet ederken Golang ile yeniden yazımı iyi bir seçenek olarak sunabilirsiniz
- CEO açık dokümantasyonun durumunu görüp paniğe kapıldığında, bunun statik site olarak yeniden inşa edilebileceğini savunabilirsiniz
- Önemli olan, o ayın gündemi her neyse ona hemen uygulanabilecek ayrıntılı ve etkili bir iş programını hazır tutmaktır
En Kötü Teknik Kararların Alındığı An
- Bu yaklaşımı izlemeseniz de bazı programlar fon alır; ancak bunu yapmazsanız hangi programların fon alacağını kontrol edemezsiniz
- Şirketlerin en kötü teknik kararları aldığı yer tam da burasıdır: bir şey yapılmasına yönelik politik ihtiyaç ile iyi fikirlerin yokluğu çakıştığında
- İyi fikir yoksa kötü fikirler devreye girer; ama bu sonuç kimsenin tercih ettiği bir şey değildir
- Yönetici için kötüdür: hayal kırıklığı yaratan teknik sonucu başarı gibi pazarlamak zorunda kalır
- Mühendis için kötüdür: zamanı ve emeği yanlış bir fikri inşa etmeye harcamak zorunda kalır
- Eğer çok kıdemli bir mühendisseniz VP'lerin bunu sessizce size yükleyeceğini fark edersiniz; üstelik bunda haklıdırlar
- Doğru zamanda doğru fikirleri hazır bulundurmak sizin sorumluluğunuzdur
İki Bakış Açısı
- Alaycı bakış açısı: Bu, şirketi yöneten sosyopatların bitmek bilmeyen iç güç mücadelelerinde kullanacağı kullanışlı bir araç olmanızı öneriyor gibi okunabilir
- İyimser bakış açısı: Bu, yöneticilerin şirketin genel önceliklerini belirlemesine izin verip (zaten işleri bu), kendi teknik planlarınızı buna göre hizalamanızı öneriyor gibi okunabilir
- Hangi açıdan bakarsanız bakın, doğru planı doğru zamanda ilerletirseniz daha fazla teknik hedefe ulaşabilirsiniz
Hacker News Tepkileri ve İlgili Alıntı
- Bu yazı Hacker News'ta dikkat çekti ve politika üzerine diğer yazılara kıyasla çok daha olumlu tepki aldı
- Bir yorum, Milton Friedman'dan bir alıntıya değinerek yazıdaki fikri genel siyasi politikalara uyguladı
- "Yalnızca kriz (gerçek olsun ya da algılanmış olsun) gerçek değişimi yaratır. O kriz ortaya çıktığında, atılan adımlar etrafta bulunan fikirlere bağlıdır. Bizim temel işlevimiz budur: mevcut politikalara alternatifler geliştirmek, onları hayatta ve kullanılabilir tutmak; ta ki politik olarak imkansız olan şey politik olarak kaçınılmaz hale gelene kadar"
- Bazı yorumlar bu yaklaşımı fazla oyunlaştırılmış ve bencil bulsa da, yazar bunun hedefe bağlı olduğunu düşünüyor
- Bir yorum yazının özünü iyi özetliyor: "Talimat bekleyip ortada boşluk olduğunda kötü fikirlere alaycı yaklaşarak hiçbir şey yapmamak yerine, yazar önemli biri bir şeyin öncelik olduğunu söylediğinde gündeme getirmek için iyi ve önemli fikirlerden oluşan bir backlog tutuyor. Zamanlama konusunda taviz vererek istediğini hayata geçiriyor"
1 yorum
Hacker News görüşü
Bu yazının özeti şu:
İlk nokta bariz gelebilir ama kariyerinin başındaki birçok kişiye defalarca koçluk yaptığım bir konu Zorluk yaşayan ya da PIP'e doğru giden birçok kişi için aşağıdaki döngüyü düzgün uygulamak bir dönüm noktası oldu
Eklemek istediğim bir şey daha var: Yöneticimden daha güçlü siyasi etkisi olan kişilerin karşı çıktığı işleri pervasızca yapmamak. Tabii senden daha güçlü biri bunu açıkça emrederse istisna Onların istediklerini ille de yap demiyorum, ama onları gereksiz yere kızdırmamaya dikkat etmek önemli Düşman edinmeye neredeyse hiç değmez ve çoğu yönetici kriz anında kendini korumak için beni kolayca günah keçisi yapabilir
Ben yöneticime doğrudan "ne yapılması gerektiğini" önermeyi tercih ediyorum. Önemli meseleleri masaya koyup nedenlerini anlatıyorum Uzmanlığımla yöneticimin fayda sağlaması için proaktif davranmak gerekiyor Benim de çok fazla deneyimim yok ama birkaç başarılı örneğim oldu
Bu tavsiye yukarı çıktıkça daha da önemli hale geliyor. Engineering manager için de geçerli, CTO'ya doğrudan rapor verdiğim dönemde director olarak da bu ilkeyi uygulamaya çalışıyordum
En sevdiğim alıntılardan biri şu: "Gerçek ya da algılanan kriz, gerçek değişimi yaratan tek şeydir. O anda atılan adımlar, etrafta dolaşan fikirlere bağlıdır. Temel işlevimiz alternatif politikalar geliştirmek, onları canlı tutmak ve siyasi olarak imkansız görünen şeyi siyasi olarak kaçınılmaz hale getirmektir" - Milton Friedman 1 Pager ve teknik dokümanlar yazıp önceden paylaşmak, sonra kriz geldiğinde bunlara yeniden atıf yapmak fikirlerimi öne çıkarmakta etkili oldu İstediğim mimari yönünü kademeli olarak ittirip hedefe giderek yaklaştığım oldu ve fikir birikimi oluşturmak önemli Elbette benden daha iyi politik becerileri olan VP'lere ya da director'lara kaybettiğim de çok oldu Ama bir 1 Pager kütüphanesi hazırlayıp bunları usulca paylaşmak, ortamda dolaşmasını sağlamak ve uygulamak için motivasyon doğana kadar beklemek çok daha etkiliydi
"Politik kavgayı kaybettim" kısmına katılıyorum. Middle manager seviyesinin üstüne çıkınca şaşırtıcı biçimde fark ettiğim şey, alt seviyelerdeki çalışanların politik manevralarının ne kadar görünür olduğuydu Birçok IC ya da 1. seviye EM, kendi politik sezgisini ya da sosyal IQ'sunu olduğundan fazla görüyor Ayrıca organizasyon içindeki iletişimin derinliği ve kapsamı farklı olduğu için, biri bir paydaşı ikna ettiğini sanırken o paydaş görüşme bittikten sonra yöneticisine gidip durumu usulca aktarıyor Yönetim ekibi olarak acemice politik oyunları sessizce kontrol altına almaya çalışırken buna birçok kez tanık olduk
"1 Pager ve teknik dokümanları dolaşıma sokmak" derken pratikte tam olarak neyi kastediyorsun, merak ettim
Bu alıntıya katılıyorum ve yöntemin etkili olabileceğini düşünüyorum. Ama pratikte zaman ölçeği insanı çıldırtacak kadar uzun olabiliyor, o yüzden yıpratıcı Bir de krizler bazen tamamen görmezden geliniyor; dolayısıyla genel olarak kriz olarak algılanmıyor ya da normalleşiyor
1 Pager sayesinde takdir gördün ve kariyerinde terfi alabildin mi, yoksa daha çok fikirlerin gerçekten hayata geçmesine mi yardımcı oldu, merak ediyorum
Bence en iyi yöntem şu
Sık sık production'a deploy et (teorik işlerden çok gerçek teslimat odaklı)
Anlamlı sonuçlar elde et (
wins) (üzerinde anlaşılmış metriklerle)Yönetimden ya da PM tarafında başarılarını iyi pazarlayacak bir "satışçı"n olsun Ama yine de sorun çıkıyor. Her zaman yeni bir VP ya da lider gelip yenilik göstermek istiyor. Mevcut sistemi bakımda tutan ekip bir anda yanlış tarafta damgalanıyor ve yeni VP, AI gibi ilerici fikirlerle kendi çizgisini vurguluyor. Benim kodum deploy edildiği andan itibaren "legacy" muamelesi görüyor Sonra VP parlak bir gelecek vaadi satıyor ama mevcut gerçekliği ayakta tutan benim rolüm bununla asla yarışamıyor. Gerçeklik seksi değil, eğlenceli de değil. Böylece eski düzenin temsilcisine dönüşüyorsun Sonuçta işin özü patronaj ilişkileri; yani üstündeki VP'yi başarılı kılmak ve o kişi başka yere geçtiğinde onunla birlikte gidebileceğin bir pozisyon yaratmak
Buna gerçekten katılıyorum. Bir adım daha ileri gidersek, staff engineer olarak "ben kodun kendisi değilim" algısını net biçimde vermek önemli. Kod, deploy edildiği andan itibaren borç/legacy'dir Benim "kodun savunucusu" olmak yerine liderlik, ürün, karar vericiler vb. ile EQUAL PARTNER olarak konumlanmam en iyisi. Bu tamamen bakış açısı/frame meselesi. Aynı davranışları sergilesem bile eğer "işin ortağı" gibi görünürsem liderler beni proaktif bir yardımcı olarak görür; aksi halde zorla ikna edilmesi gereken bir engel gibi algılanırım ve aradaki fark büyük olur
"PM tarafında başarılarımı iyi satan biri olmalı" kısmına çok katılıyorum. Geriye dönüp baktığımda kariyerimde en büyük farkı yaratan şey muhtemelen kötü PM'lerden hızla uzaklaşabilmekti İyi bir PM her şeyi iyileştiriyor ama bulması zor. Tersine, PM yönü yanlış belirlediğinde her şey bozuluyor ve o PM ortadan kalktığında atmosfer aniden değişebiliyor
"Gelecek vaadiyle rekabet edememek" ifadesi harikaydı. Bu durum çok sık yaşanıyor. Hatta o vaat daha önce 26 kez bile tutulmamış olsa, "görkemli gelecek" her zaman etkileyici oluyor
Gerçek işte sık deploy etme fikri (rep=uygulama odaklı, teori yok) iyi ama VP'lerin havada uçuşan gelecek vaatleri neden uygulanabilirlikten daha değerli görülüyor, anlamıyorum
"Teorik çalışma" diye bir ifade duymadım ama her gün deploy yapan yerler kesinlikle var. Yine de sık deploy etmenin ideal olduğunu düşünmüyorum. Bir günde gerçekten anlamlı ne deploy edilebilir, emin değilim. Benim üzerinde çalıştığım ve şirkete ek gelir getiren projeler bir günde tamamlanamaz. Eğer işler bir günde bitebiliyorsa yılda dört kez mühendise ihtiyaç var demektir. Bu yüzden böyle "sık deploy" yaklaşımı bence bir Vanity Metric
Ben de hiç dysfunctional bir şirkette çalışmadığım için, yazının ilk kısmıyla hiç bağ kuramıyorum Benim deneyimimde top-down iletişim her zaman güçlüydü ve katılmadığım bir yönde geliştirme yapıyor olsak bile önceden yeterince tartışılıyor, dolayısıyla zeki bir iş arkadaşımın neden benden farklı düşündüğünü görmek ilginç oluyordu Bunun sebebi sadece mühendislerin kurduğu şirketlerde çalışmış olmam mı, yoksa sadece şanslı olmam mı bilmiyorum
Büyük şirketlerde üst düzey VP'lerin hedefleri de araç anlayışları da daha geniş olur. Bu ille de kötü bir şey değil. Belirli bir teknolojiye ya da metodolojiye saplanmadan önce çeşitli yolları deneme alanı sağlar. Elbette israf da olur ama sektördeki sarsıntılara hızla tepki verip yönetimin görevini yerine getirmekte verimli de olabilir
Ne büyüklükte şirketlerde çalıştığını merak ettim
"Biraz daha zor ama daha fazla kontrol sağlayan yol, kendi fikirlerimi mevcut siyasi kampanyalara eklemlemek" VP'nin sahip çıktığı projelere iyi yapışma becerisi geliştirdim. Acı ama etkili olduğu kesin
Bu kampta sık duyulan hayal kırıklığı şu: "Tüm kodu mükemmel şekilde refactor ettim ama kimse fark etmiyor" Eskiden tanıdığım biri, veri hattını aylarca uğraşıp kusursuzca temizlediğini ama kimsenin bunun değerini anlamadığını anlatmıştı; bu bana çok şey düşündürdü Bir mühendis olarak bunun değerli olduğunu biliyorum ama PM/EM açısından bakınca, sanki bir PM bir ay boyunca şirket içindeki tüm mühendislik dokümanlarındaki noktalama işaretlerini düzeltip sıralamış ve sonra da "peki bunun şirkete etkisi ne?" cevabını almış gibi PM açısından, etkili bir mühendisle sadece "biçim düzenleme işi" yapan bir mühendisi nasıl ayırt edeceği belirsiz hale geliyor Sonuç olarak, yapmayı planladığın işi teknik olmayan bir kitleye uygun formatta önceden net biçimde anlatabilmek önemli Geçmişte unit test ve integration test'i zorlamıştım ama yeterli politik irade olmadığı için bir türlü öncelik kazanamadı. Sonra büyük bir SEV yaşanınca "bunu önlemek için test gerekli" dedim ve ancak o zaman herkes bunun değerini kabul etti. Artık testin neden gerekli olduğunu herkes anlıyor
Kesinlikle katılıyorum. Eğer bir eylemi önceliklendirmeye çalışıyorsam, bunu öncelikleri belirleyen kişinin mantığı ve diliyle anlatmam gerekir ki etkili olsun Mesela PM'ler genelde parasal birimlerle düşünür. Test kapsamını genişletmek gibi teknik hedeflerim yılda 200 dev hour gerektiriyor ama yılda 400 dev hour tasarruf sağlayabiliyor, destek ticket'larını %15 azaltabiliyor, gelecekteki iş senaryolarını mümkün kılıyor vb. şekilde sunarsam ikna etmek çok daha kolay oluyor Benim sevdiğim numara, tech debt işini "teknik iş" diye değil, net iş etkisi olan bir konu gibi paketleyip PM'in bunu bizzat roadmap'e koymasını sağlamak Bu yaklaşım kariyer ilerledikçe kolaylaşıyor. Başta şüpheyle yaklaşılsan da zamanla tahminlerin ve sonuçların güven kazanıyor; eskiden birkaç toplantı gerektiren işler artık 10 dakikalık bir konuşmayla halloluyor
Bu görüşe de katılıyorum. Ama ters taraftan da bakılabilir gibi geliyor Örneğin bir inşaat sahasında biri güvenlik sistemlerini titizlikle denetleyip koruduğu için kaza önlenmiş olsa, yönetim çoğu zaman bunun değerini tanımaz ve ödüllendirmez Nicel olarak ROI ile ifade edilmeyen hiçbir kazancın kabul edilmemesi, yönetimin büyük bir başarısızlığıdır; güvenliğin hayatla doğrudan ilgili olduğu yerlerdeyse ahlaki bir başarısızlıktır Bugün Boeing'de olan da fiilen bu
Mesele, değeri dinleyicinin anlayacağı şekilde ifade etmek. Bu sonuçta bir satış becerisi ve bence çoğu geliştiricinin ne deneyimi var ne de bunu fark etmesi kolay İyi bir yönetici bunu iyi desteklerse ideal olur ve benimle aynı zihniyete sahip bir staff dev ya da engineering manager ile çalışınca gerçekten büyük fark yaratıyor Ben de böyle insanlarla çalıştığımda hep minnet duyuyorum
Eğer el yıkamanın gerekli olduğunu açıklayıp bunun için yatırım kararı çıkarmak zorundaysan, takımda bir sorun var demektir. Üst düzey bir restoran şefini "sabun alalım mı almayalım mı" diye ikna etmenin gereksiz olması gibi, bunun zaten doğal olduğu bir organizasyona girmek kariyerde bir seviye atlamak demek. Başarılı bir SWE, bu standardın zaten varsayıldığı bir takımda çalışan kişidir
Katılıyorum. Refactor, geliştiricinin doğal sorumluluğudur. Özellik geliştirirken bunu doğal biçimde birlikte yapıp teslim tarihini ona göre güncellersen, sadece teknik kişilerle konuşman yeterli olur ve ikna çok daha kolaylaşır; uzun vadede de kod tabanının kalitesi ciddi biçimde artar. Bunun sonucu bakım kolaylaşır ve yeni özellik geliştirme hızlanır
Biriktirebileceğim en büyük politik sermaye, teknik anlayışım ve yetkinliğimdir. Ama bu güç ancak şirketin genel stratejisi ve bağlamı içinde tavsiye verip gerçekten teslimat yaptığımda işe yarar Doğru tavsiyeyi verip şirket için harekete geçtiğimde insanlar beni dinlemeye ve bana güvenmeye başlıyor. Sonunda da yön belirleme yetkisi oluşuyor Ayrı bir Plan B gibi risk yönetimi seçenekleri hazırlamak ve gerektiğinde bunları önermekle uygulamak en iyi yol
Oldukça sert ama iyi noktalar içeren bazı kariyer kitapları var Bunlardan biri, teknik yetkinliğin aslında kariyerime ve gücüme zarar verebileceği fikri. Zamanımı ve enerjimi gerçekten bir şeyler yapmaya harcarsam, yetkin bir yönetici beni mümkün olduğunca politik etki kazanamayacağım bir rolde tutmak için aktif şekilde uğraşır Buna karşılık yönetici olduğunda, gerçekten bir şey yapmak yerine olabildiğince çok initiative (proje, politika, değişim) başlatman ve sahip olduğun politik gücü ustalıkla yönetmen yeterlidir Bu initiative'lerin gerçekten değer üretip üretmemesi önemli değildir, hatta umursamaya bile gerek yoktur. Ben zaten sahneden çıkmışımdır; burada hâlâ başarı ve değer üretme fikrine takılıp çalışanlar geride kalıyordur Gerekirse yönetici sonradan çıkıp bütün krediyi de alabilir
"Flavor of the month"a uyum sağlamak için pozisyon değiştirmeye odaklı ekipler lazım; benim siyaset teorim bu. Washington DC de böyle çalışıyor. Büyük bir master plan yok, fırsat gelince anında pitch yapacak birlikler sürekli hazır bekliyor
Eğer politik mücadele yapmayı öğrenip güç biriktirmek zorundaysan, yeni bir şirket bulman daha doğru Bunun safça olduğunu düşünebilirsin ama her şirket böyle değil. Benim şirketim öyle değil