- Yetenekli kıdemli mühendisler için faydalı olabilen ancak deneyimsiz mühendisler için zararlı olabilecek "tehlikeli tavsiye (dangerous advice)" kavramını ele alan bir yazı
- Production SQL erişim yetkisi gibi şeyler **"keskin araçlar (sharp tools)"**dır
- İş önceliklerini kendi başına belirlemek, bazen şirket kurallarını kasıtlı olarak çiğnemek ve belirsizlik olsa bile net bir tavır almak, tehlikeli tavsiyenin somut örnekleri arasında
- Kariyer tavsiyelerinin çoğu, sorumluluktan kaçınma ya da izlenim yönetimi amacıyla yazılmış sahtelerdir; oysa gerçekten işi tamamlamak için resmî kuralların dışındaki davranışlar gerekir
- Yöneticilerin, kendilerine dönecek risk nedeniyle bu tür tavsiyeleri doğrudan verememesi şeklinde yapısal bir sınır vardır
- Tehlikeli tavsiye, yüksek risk-yüksek getiri özelliği taşır; organizasyonun resmî kurallarının ötesindeki görünmez (illegible) alanı anlamak bunun merkezindedir
"Keskin araçlar" ve "tehlikeli tavsiye" benzetmesi
- "Sharp tools", ssh, kubectl ve yazma izni olan production SQL konsolu gibi, yetkinliğe bağlı olarak çok yardımcı olabilen ya da büyük zarar verebilen araçlardır
- "Tehlikeli tavsiye" de aynı özelliği taşır; doğru kullanılabilmesi için yetkinlik ve muhakeme gerekir
- Yanlış kişiye tehlikeli tavsiye vermek, yanlış kişiye production SQL erişimi vermekle aynıdır
Tehlikeli tavsiyenin somut örnekleri
- Ne üzerinde çalışacağını kendin belirle
- Bazen şirketin yazılı kurallarını kasıtlı olarak çiğne
- Belirsizlik olduğunda bile net bir tavır al
- Kendini biraz 'grifter' olarak tanımla
- Shipping ile ilgili olmayan tüm faaliyetlerden bilinçli olarak kaçın
Kariyer tavsiyelerinin çoğu neden sahte?
- Güçlü mühendisler, keskin araçları istemelerinin aynı nedeni ile tehlikeli tavsiyeyi arzular
- Kariyer tavsiyelerinin çoğu sorumluluktan kaçınma (liability avoidance) ya da insanları etkileme (impress people) amacıyla yazılır
- Gerçekten işi çıkarma niyetinde olan biri için, bu tür tehlikeli davranışlar açıkça işe yaradığı için eninde sonunda uygulanır
- Herkesin resmî olarak işlerin böyle yürümediğini bilmesine rağmen bunu kimsenin söylememesi, derin bir yabancılaşma hissi yaratır
- Junior dönemde, gayriresmî olarak dürüst konuşan az sayıdaki meslektaş çok yardımcı olmuştur
Yöneticilerin tehlikeli tavsiye verememesinin yapısal nedeni
- Bir yönetici şirket politikasını görmezden gelmeni tavsiye edip mühendis bunu kötü uygularsa (ör. Slack'te yöneticinin izin verdiğini açıkça paylaşırsa), daha büyük zarar yöneticiye döner
- Teknoloji şirketi liderliği, mühendisleri "useful idiots" olarak görme eğilimindedir ve yöneticilerden profesyonel davranış bekler
- Birçok yönetici aslında bu tür tavsiyeleri vermek ister ve mühendis kendi başına böyle davrandığında bunu yüksek takdirle karşılar
- İşe daha stratejik ve iş tanımına daha az bağlı yaklaşırsa çok daha etkili olabilecek güçlü bir mühendisi yönetmek, yönetici açısından çok sinir bozucu olabilir
Tehlikeli tavsiyenin özü: yüksek risk-yüksek getiri
- Tehlikeli tavsiyeyi izlemek için cesaret gerekir
- Yüksek risk-yüksek getiri niteliği nedeniyle güçlü mühendislere orantısız biçimde fayda sağlar, zayıf mühendislere ise zarar verir
- Rahat hissetmiyorsan bunu asla izlememelisin; ancak zaten bu şekilde çalışıyor ve bunun uzun vadeli bir hata olup olmadığını düşünüyorsan, muhtemelen durum böyle değildir
Hacker News tepkileri ve organizasyonların görünmez unsurları
- Hacker News'te çok olumlu tepkilerle çok olumsuz tepkiler bir arada görüldü
- Olumsuz yorumların temel hatası, organizasyonu yazılı kurallar bütünü olarak görmek ve organizasyon içindeki ana işleyiş biçiminin resmî ve yapısal işbirliği olduğunu varsaymaktır
- Bu, James C. Scott'ın Seeing Like a State kitabında anlattığı okunabilirliğe (legibility) aşırı öncelik verme hatasıdır
- Her toplulukta görünmez ama taşıyıcı nitelikte (load-bearing illegible) unsurlar bulunur
- Kendi işinde bu görünmez kısımları dikkatle düşünmek, bu yazının ve blogun genelindeki temel argümandır
Henüz yorum yok.