- Şimdi bir mühendislik yöneticisi olsam da, yazılım mühendisi olarak çalıştığım dönemde birkaç gün boyunca karmaşık bir özellik üzerinde çalışıp bir PR açmıştım
- Geri bildirim sert ve soğuktu: “Aşırı mühendislik. Karmaşık. Refactor et” diyen kısa bir cümleden ibaretti
- Tek bir övgü sözü olmadan yalnızca eleştiri almak öfkelendirmişti ama o yöneticiyle yaşadığım olay bunun sadece başlangıcıydı
Duyguları gözetmeyen liderlik tarzı
- Bu yönetici, daha önce tanıdığım liderlerden farklıydı
- Elimden tutmuyor, yumuşak sözler de söylemiyordu
- Şu özelliklere sahipti
- Yarım pişmiş fikirleri anında reddederdi
- Karmaşıklık uğruna karmaşıklıktan hoşlanmazdı
- Yalnızca temiz, bakımı yapılabilir ve verimli kodu önemserdi
- Retrospektiflerde de lafı dolandırmadan sorunları doğrudan işaret ederdi
- İlk başta onun acımasız biri olduğunu düşündüm ama bunun arkasında başka bir felsefe vardı
Özgüvenimi sarsan geri bildirimin dönüm noktası
- Sprint review sırasında kendime güvendiğim bir özelliği gösterdim ama yönetici sözümü kesip şunu sordu
> “Bu kırılgan. Yük altında ne olur? Rollback planın ne?”
- Düzgün cevap veremeyince yönetici şöyle dedi:
> “Şu anda bir kodlayıcı gibi düşünüyorsun. Bir mühendis gibi düşünmelisin”
- Başta sinirlendim ama sonunda kendi kod tarzımın dayanıklılıktan çok zekice görünmeye odaklandığını fark ettim
Asıl ders: o yönetici bana kişisel olarak saldırmıyordu
- Düşünme biçimimde büyük bir değişim oldu
- “Akıllı” kod yerine okunması kolay kod yazmaya başladım
- Başarısızlık senaryolarını hesaba katan tasarıma odaklandım
- Kendim için değil, benden sonra gelecek geliştiriciler için kod yazdım
- Sonrasında o yöneticinin code review'larından zorlanmadan geçmeye başladım
- Değişen yönetici değildi; büyüyen bendim
Bunun kendi liderlik tarzıma etkisi
- Mühendislik yöneticisi olduktan sonra bu deneyimi sık sık hatırladım
- İnsanların sevmediği bir lider olmak istemedim ama sadece yumuşak bir lider de olmak istemedim
- Tarzımı şu şekilde şekillendirdim
- Bağlamı açıklanmış, doğrudan geri bildirim vermek
- Sistem düzeyinde düşünmeyi vurgulamak
- Yüksek standartları korurken insani geri bildirim sunmak
- Mühendisler zorlanmak ister ama küçümsenmiş hissetmek istemez
Ne zaman sert bir yöneticiye ihtiyaç duyulur
- Liderlik; ego, teslim tarihleri ve baskının iç içe geçtiği karmaşık bir alandır
- Sert bir yönetici bu karmaşayı şunlarla ortadan kaldırır
- Özellik değil, ölçeklenebilirlik düşünmeye zorlar
- Zekice kod yerine sürdürülebilir kod yazdırır
- Başarısızlıkları ve istisna durumlarını önceden hesaba katmayı sağlar
- Duygulardan çok kodun hayatta kalma ihtimalini önemser
Sert bir yöneticinin altında hayatta kalıp büyümenin yolu
- Eğer bunaltıcı bir liderin altındaysan, şöyle yaklaşabilirsin
- Bunu kişisel bir saldırı olarak alma: geri bildirim kodadır
- Geri bildirimden sonra “neden?” diye sor: çoğu sert lider merakı takdir eder
- Hata noktalarını önce kendin düşün: yönetici gibi düşünmeye başlamalısın
- Eğer lider sensen, şunları uygulamalısın
- Yüksek standartlar koy ama neden önemli olduklarını açıkla
- Muğlak geri bildirim yerine somut konuş
- Başarıdan çok gelişimi kutla: geliştirici yöneticiden önce sorunu fark ettiyse bunu öv
Reddedilen Pull Request'in verdiği en büyük hediye
- İlk başta gururum incinmişti ama şimdi dönüp baktığımda, reddedilen o PR hayatımdaki en iyi fırsatlardan biriydi
- Kodlamayı kişisel bir proje olarak değil, sistem inşası olarak görmemi sağlayan dönüm noktası oldu
- Sert bir yönetici kendini iyi hissettirmez ama bir geliştirici olarak büyümeni sağlar
- Gerçek büyüme, PR onaylandığında değil, reddedildiğinde başlar
22 yorum
Duyguları gözetmeyen, lafını esirgemeyen bir yöneticiyle ekip içinde sıcak bir ilişki kuran nazik bir yönetici arasında, geri bildirim yoluyla ekip üyelerinin gelişimini hangisi daha iyi destekleyebilir? Önceki yazıyı okurken aklıma şu soru geldi.
Bence bu bir olasılık oyunu. Son derece düşük ihtimalleri aşıp gelişen insanlar her yerde vardır. Yöneticilerin, bu tür insanları bir kenara bırakıp genel başarı olasılığını yükseltmeye çalışması gerektiğini düşünüyorum. Kendi yöntemince bu olasılığı artıran bir tutum sergilediğine inanarak hareket eden yöneticilerin saygıyı hak ettiğini düşünüyorum. Yeter ki, sadece öyle yapılabildiği için bugüne kadar sürdürdükleri yöntemi aynen devam ettirmekle yetinmesinler.
Bu tür geri bildirimler; kişiliğe, kültürel çevreye ve bireysel farklılıklara bağlı olarak duyulduğunda insanı kötü hissettirebilir ya da öfkelendirebilir diye düşünüyorum. Ancak temelde, "bu kişi beni bilerek rahatsız etmiyor" diye düşünerek yaklaşmanın hem zihinsel açıdan hem de gelişim perspektifinden daha iyi olduğu anlaşılıyor. Böyle bir durumla karşılaşıldığında bu yazıyı hatırlayıp, "acaba bu yönetici de öyle mi?" diye düşünmek mümkün olabilir. Güzel bir yazı.
Birçok kişi
kind and directten söz ediyor ama aslında nazik olmaktan çok doğrudan olmak daha zor.Lidere, tüm bağlamı vermese bile takipçilerin uyması gereken bağlamı aktaramıyorsa hiçbir değeri yoktur
Kendi yetkinliğinin yüksek olmasını başkalarına mal eden üstün bir takipçinin yazdığı bir yazı gibi görünüyor
Lider bağlamı aktarmıyorsa o lidere pek de ihtiyaç yoktur
Acilen değiştirilmesi gerekir
Kulağa hoş gelen sözler, her zaman iyi sözler değildir. Ben de hayatımda en çok fayda sağlayan kod incelemesinin, sadece iki kelimeden oluşan "Nasty Code" olduğunu düşünüyorum.
Her geliştirici aynı geliştirici değildir.
"Sistemsel düşünce" denen şeyin ne olduğunu düşündüm; ama yazının bağlamında bunun, bir uygulamanın çalışma perspektifinden düşünmek gibi geldiğini söyleyebilirim. Yine de bunun gerçekten çok önemli bir bakış açısı olduğunu düşünüyorum.
İşleri idare ederek ilerlerken kod tabanının darmadağın olduğuna şahit oldum, o yüzden buna fazlasıyla katılıyorum. Yönetici yetkinliğinin önemi gerçekten çok büyük.
Katılıyorum.
Yazının ima ettiği şey, o yöneticinin çok başarılı olmasından ziyade, asıl iyi olanın yazarın kendisi olduğu gibi görünüyor. (Yazar, nasıl bir geri bildirim alırsa alsın gelişen bir tip değil mi acaba?)
(Bağlamdan yoksun) olumsuz geri bildirim alındığında davranışın beklentinin tersine değişme olasılığının yüksek olduğuna dair bir araştırma gördüğümü hatırlıyorum.
Yapılan işe yönelik geri bildirimin kişisel bir suçlama olmadığını anlamak gerekir.
Yönetici daha iyi biri olsaydı daha iyi olabilirdi ama şirket okul değil.. biz profesyoneliz.. bu yüzden geri bildirime dair öğrenmeyi kendimiz yapmalıyız.
Bilmiyorsak bilmediğimizi söyleyebilecek cesarete de ihtiyaç var.
Bana oldukça farklı bir bakış açısından bakıyor gibisiniz. Sanırım kariyerimin henüz başında olmamdan dolayı, belirsiz geri bildirimlerin ve neyi kastettiği muğlak olan geri bildirimlerin çoğunlukla ters etki yarattığını çok gördüm...
Yazım hatası var.
"Bunun bir eleştiri olmadığını fark etmelisiniz." -> "Bunun bir eleştiri olmadığını fark etmeniz gerekir" diye yazmanız gerekir.
Bunun kişisel bir eleştiri olmadığını biliyor olsanız da, görür görmez benim düzeltmeme sinirlendiğinizi düşündüm. Kimileri buna aynı kapıya çıkar diyebilir ama insanların, anlamı aynı olsa bile söyleniş biçimini farklı algıladığını düşünüyorum.
ps. Ben de yazım yanlışınızı fark etmemiştim; ancak bir örnek bulmak istediğim için yazım denetleyicisine koyduktan sonra yanlış yazdığınızı fark ettim.
Yazım hatasını düzeltince "teşekkürler, fark etmemişim" denip geçilebilecek bir mesele gibi geliyor; öfkelenecek bir konu değil gibi. Kişinin kendi hissettiği gibi başkalarının da hissedeceğini düşünmesi, bence tehlikeli bir genelleme. Ayrıca
받아 드리는 게değil,받아들이는 게olmalı.Stres yaratan işleri de çözebilmenin profesyonellik olduğunu düşünüyorum.
İnsanları strese sokmayı haklı çıkarmaya çalıştığımı söylemiyorum. İşini profesyonelce yaparken öfkeleneceğin durumlar da olacaktır; ama bunları akıllıca çözmenin profesyonellik olduğunu düşünüyorum.
Ben yazım kuralları uzmanı değilim. Komü de bir şirket değil.
Yoruma gerçekten katılıyorum. Bunu alan kişinin becerisi ve zihniyetinin çok iyi olduğunu düşünüyorum. Bence o yönetici, felsefesini net biçimde ortaya koymuştu ama kendi felsefesini takıma yaymak için iyi bir yaklaşım kullanmayı bilmiyordu.
Ne kadar kaba saba atılsa da tam yerinde yakalamak herhalde böyle bir şey... haha
Gerçekten çok iyi bir yazı. Bunu PR göndermeden önce de sonra da sürekli gözden geçirmek gerekecek gibi.
Bunun kişisel bir saldırıya dönüşmemesi için, sanırım önceden iyi bir bağ kurmuş olmak gerekiyor. (Özellikle de Kore toplumunun bağlamında.)
Ben kişisel olarak özne kullanımına dikkat ederim. Sorun "bu kodun" over-engineering olmasıdır; "karşı tarafın" hatalı olması değil.
Uzmanın kafasında tam olarak neler oluyor? yazısını hatırlattı. “Aşırı mühendislik. Karmaşık. Refactor edin”, “Bu kırılgan. Yük altında ne oluyor? Geri alma planı ne?” gibi bir inceleme aldığınızda, neden böyle düşündüğünü, hangi sorunları öngördüğünü ve nasıl bir iyileştirme yönü düşündüğünü sormak da iyi olabilir. (Yazarın bunu yapmadığını söylemekten çok, böyle bir durumda nasıl daha fazla fayda elde edilebilirdi diye düşündüm.)
Gerçekten çok iyi bir yazı..