Büyük teknoloji şirketlerinde 'işi bitirdim (Done)' demenin gerçek anlamı

• Büyük teknolojide gerçekten işi bitirmek, sonsuza kadar iyileştirilebilecek bir sistem içinde şirketin tatmin olduğu noktaya kadar işi tamamlayıp oradan ayrılmak anlamına gelir
• Yetenekli ama inisiyatif eksikliği olan mühendisler, durmadan küçük iyileştirmeleri tekrar ederek gerçek çıktıları kaçırabilir
• Karar vericilere göze çarpan, net çıktılar sunmanız gerekir; ancak o zaman “iş yapılmış” olarak kabul edilirsiniz
• Yaptığınız işin üst düzey yöneticiler tarafından okunup değerlendirilebilecek bir biçimde olup olmadığını her zaman kontrol etmelisiniz
• Her işi tamamen toparlamak mümkün değildir; belli bir noktadan sonra "zafer ilan edip ayrılabilme" becerisi temel bir yetkinlik haline gelir

---

'İş' doğası gereği tamamlanamaz

• Matematik problemi ya da ödevlerden farklı olarak, gerçek dünyadaki işler sonsuz biçimde iyileştirilebilen açık sistemlerdir
• Hizmet geliştirmek, ağaç dikmeye benzer; sonrasında da sürekli bakım gerektiren bir süreçtir

Tuzağa düşen yetenekli mühendis

• Kendi başına her şeyi üstlenip yalnızca küçük ve sürekli iyileştirmeleri tekrar eden mühendis, kendini sonuç üretiyor gibi hissedebilir
• Ancak üst düzey yöneticinin bakış açısından bu, "şirket için görünür değer üretimi yok" şeklinde değerlendirilebilir
• Sonuç olarak sonuç almayan ama sürekli meşgul biri gibi yanlış anlaşılabilir

‘Bitirmek’in pratikteki anlamı

• Şirketin (karar vericilerin) tatmin olduğu noktaya ulaşmasını sağlamak ve sonra bir sonrakine geçmek
• Sürekli refactor yapmak ya da küçük iyileştirmeleri tekrarlamak yerine, net bir çıktı listesi oluşturmak gerekir
• “Bitti” diyebilmek ve bir sonraki işe geçecek kararlılığı göstermek önemlidir

İşin ‘okunabilirliğini’ sağlamak

• Yöneticinin zaten bildiği ya da talep ettiği projeler ve büyük olaylara verilen yanıtlar yüksek okunabilirliğe sahiptir
• Temelde teknik işlerin çoğu, yönetici açısından değerlendirmesi zor teknik gürültüden ibarettir
• Bu yüzden çıktıları görünür hale getirmek ya da parasal etkisini vurgulamak gibi yollarla, okunabilir olacak şekilde ayarlamak gerekir

‘Bitirmek’ sosyal bir kavramdır

• Felsefi olarak 'bitirdim' kavramı da toplumsal bir inşa olsa da, gerçek dünyada çok somut bir güce sahiptir
• Bunu görmezden gelirseniz takdir görmeyebilir, nihayetinde işten bile çıkarılabilirsiniz

Özet

• Çalışıyor olmak, işi bitirdiğiniz anlamına gelmez
• Çoğu iş gerçekten bitmez; sürüp gidebilir
• Bahçıvan değil, çıktı odaklı bir taktisyen olmak gerekir
• "Bitti" ölçütü şirketin/yöneticinin tatminidir
• "Zafer ilan et → ayrıl → sonraki işe geç" temel stratejidir

[aer0700]

Zafer ilan edebileceğiniz türden işleri seçmek de önemli bir beceri gibi görünüyor.

[elbanic]

Kapsamı sınırlamaya scoping denir. Kazanabileceğiniz şekilde iyi scoping yapmak bir beceridir.

[bakyeono]

Hanshin vs Soha

[doolayer]

Ayrıntılar değil, sayısallaştırılmış ve görünür çıktılar

[GN⁺]

Hacker News görüşü

• Bu yazının tezine tamamen karşı değilim ama büyük teknoloji şirketleri, çeşitli startup’lar ve unicorn’larda çalışma deneyimime göre bunun pek de pratik bir tavsiye gibi gelmediğini düşünüyorum. Son 10 yılda geliştiricilerin işi aşırı uzmanlaştı ve karar vericilerle müşterilerin ihtiyaçlarından koptu. Bu durum, Product Manager’ın mühendislerle şirketin geri kalanı arasına girmesiyle ortaya çıkıyor. Ben her zaman değerli sonuçlar üretmek istiyorum ama bunu gerçekten yapabilmek için sürekli strese katlanmak gerekiyor. Katkım, mutlaka karar vericilerle konuşan kişinin egosundan geçerek şekilleniyor. Son 5 yılda gerçekten başarı hissi duyduğum tek dönem, 9 ay boyunca geçici Product Manager rolünü üstlendiğim zamandı. O süre boyunca ekibimiz, daha önce başka ekiplerin defalarca başarısız olduğu üç projeyi başarıyla tamamladı. Bunun sırrı, işi kendi yöntemimle yapmaya çalışmak değil, paydaşlarla gerçekten konuşup ihtiyaçları anlamaktı. Bu yüzden ben de bundan sonra sadece benden isteneni teslim edeceğim, bug’lar için suçlanacağım ve özellikler için takdir görmeyeceğim. En azından maaş fena değil. Hâlâ gerçekten katkı sunabileceğim bir yer arıyorum

  • Buradaki “maaş fena değil” kısmı özellikle aklımda kaldı. Büyük teknolojide çalışırken “yerinde sayma” durumunun da o kadar kötü olmadığına dair kişisel bir görüşüm var. Mesela Google ya da MS gibi yerlerde 300 bin dolar maaş alıp 10 yıl boyunca aynı sıkıcı projede çalışsan bile, o geçmiş her yerde değer görüyor. Eskiden benim gibi hırslı biri için bu sinir bozucu olabilirdi ama böyle bir yapın varsa zaten daha küçük bir şirkete geçmeye çalışırsın. Yaş aldıkça ilgi alanların şirketten çok aileye ve arkadaşlara kayıyor. Biri bana terfi olmayacağını söylese “Ee, ne olmuş?” derim. Ailem için yeterince para kazanıyorum ve iş-yaşam dengemi koruyorum. Açıkçası şirketteki en iyi şey maaş ve onun sayesinde hayatın geri kalanının iyileşmesi
  • Product Manager rolünün pratikte, teoride anlatıldığı kadar ideal olmadığını; ortada kalıp iki tarafı da iyi temsil edemediğini deneyimledim. Bunun sonucunda ürün yönetimi becerilerimi kendim geliştirdim ve bu beceri boşa kürek çekmemek için gerçekten çok faydalı oldu. O yüzden iyi bir mühendisin product management’i de temel bir yetkinlik olarak edinmesi gerekip gerekmediğini düşünüyorum
  • Düşünülmesi gereken bir başka nokta da bu gidişin şu anki haliyle burnout’a çıkıyor olması
  • İletişimin her organizasyonda en güçlü beceri seti olduğunu fark ettim. Sadece 9 aylık geçici bir görev, bunun gerçek değerini anlamak için yeterli değil. Yazı, tıpkı diğer mühendisler gibi çok sinirlenmiş haldeyken organizasyondaki diğer insanlardan daha zeki olduğunu düşünen biri tarafından yazılmış gibi duruyor. Çoğu zaman durum böyle olmuyor ve bu zihniyet işbirliğine zarar veriyor
  • İyi çalışan her web uygulamasının arkasında her zaman bir bahçıvan gibi emek veren biri vardır
  • Neden Product Manager olarak devam etmediğini merak ediyorum
  • Şirkete göre gerçekten çok değişiyor. Mühendislerin etkisinin daha yüksek olduğu pek çok yer var. Özellikle büyük teknoloji içinde bile müşteriden kopuk olmayan örnekler mevcut
  • Yani Product Manager’ları işten çıkarmamız mı gerekiyor?
  • Product Manager rolünde, yani mühendislerle şirket arasında arabuluculuk yaparken benim katkımın da kendi egomdan süzüldüğü doğruydu ama anlattığından bunun oldukça tatmin edici olduğu sonucu çıkıyor… Oldukça tatmin edici bir işmiş gibi duruyor

• Başarıyı sadece güç sahiplerini memnun etmekle ölçmeye temelden itiraz ediyorum. Evet, saçma sapan statü yapılarının içindeyiz ama Jira’da bir bileti “tamamlandı” durumuna almak ya da derleyici uyarılarını kaldırmak her şey değil. Kimse “40 yıl boyunca her seferinde sadece patronumu memnun ettim ve hiç pişman değilim” demez

  • 40 yılın 30’unda çalışmış biri olarak, patronumu ve onun patronlarını memnun etmenin de kesinlikle bir değeri olduğunu söyleyebilirim. Alaycı bakış açısı hayatın tamamı olmasa da, bu alaycı perspektifin farkında olmak gerçeğe biraz daha yaklaşmak demek
  • Aslında “patronu ve onun patronunu memnun etmek” istihdamın tanımı gibi geliyor. Biri sana ne yapacağını söyler, sen de yapar ve karşılığında para alırsın

• Genel olarak katılıyorum ama bir şey ekleyeyim: Yöneticinin ne istediğini anlamak için şirketin iş modelini kavramak gerekir. Şirketin nasıl para kazandığını ve neyi değerli gördüğünü bizzat anlamalısın. Şirketin değerleriyle uyumlu bir yerde çalıştığında hem ödül daha yüksek olur hem de tatmin artar. Müşterilerle, satışla, pazarlamayla ve mümkünse yöneticilerle doğrudan konuşmak önemli. Sadece iç sistemler üzerinde çalışsan bile, o sistemin nerede değer yarattığını ya da neyi koruduğunu bilmek kritik. Eğer bulunduğun departman net bir değer yaratmıyorsa, değerli bir ekibe geçmeyi düşünmelisin. Şirketin ihtiyaçlarıyla uyumsuz işlerde çalışmak her zaman büyük bir hata oldu

  • Kendini bir marangoz gibi görmenin sorun olmadığını düşünüyorum. Geliştirme, verilen spesifikasyona göre yapılır ama spesifikasyon saçmaysa ya da imkânsızsa bunu doğrudan söylemek gerekir. İş tarafı kendi işini net açıklayamıyorsa, aslında kendileri de ne istediklerini bilmiyordur. Ayrıca geliştiricinin iş tarafını da iyi bilmesi gerçekten gerekiyorsa, bunun karşılığında mutlaka ödeme olmalı. Sonuçta o sürede teknik olarak daha iyi gelişebilirsin; bunun bir fırsat maliyeti var
  • “Yöneticinin gerçekten işi anlayıp buna özen göstereceği” varsayımı çoğu zaman geçerli olmuyor

• Yazar “karar vericilerin görebildiği sonuçlar üretmek gerekir” demişti; ben bu kişinin “iş” zihniyetine katılıyorum. Pek çok geliştirici, yaptığı işin iş açısından ne tür bir fayda sağladığını anlatmakta zorlanıyor. Refactoring de buna dahil. Kod iyileştirmesi kısa vadede tamamen anlamsız görünebilir ama duruma göre organizasyona muazzam fayda sağlayabilir. Sonuçta asıl mesele, yaptığın işi kuruluşun geliri ya da tasarrufuyla ilişkilendirebilmek ve bunu nasıl anlatacağını düşünmek

  • Geliştiriciler iş dilini öğrenmeli ve sorunları, iş tarafındaki insanların anlayıp önem vereceği şekilde çerçevelemeli. Çoğu iş kararına baktığında sonunda mesele maliyet ve fayda oluyor. Hatta birçok iş insanı yazılımın kendisini bile sadece maliyet olarak görüyor. Yani geliştiricilerin “yazılım gelir yaratmanın tam merkezinde değil mi?” diye düşündüğü şeyin aksine, iş tarafı yazılımın kendisiyle ilgilenmiyor. Ürünü bedavaya satabilseler tüm maliyet sıfır, dolayısıyla marj sonsuz olurdu; iş insanının gerçek düşüncesi bu. Satış da akıldan çok hava, ilişkiler, hatta bazen rüşvetle sonuç alınan bir alan. Kulağa irrasyonel gelse de bunu anlamak şart

• “Bu zihniyet, birçok mühendisin kod kalitesi, test ve dokümantasyona önem vermemesinin sebebi mi?” diye düşünüyorum. Eğer tek önem verdiğin şey üst düzey birinin anlık memnuniyetiyse, kim uzun vadede bakımı yapılabilir kod yazmak için uğraşır? Gereğinden fazla kaliteye ihtiyaç olmayabilir ama asgari düzeyde yatırım bile milyarlar kazandırabilir

  • Giderek daha fazla insan ustalığa ve kaliteye önem vermiyor. “Ben maaşım kadar çalışırım” söylemini her yerde duyuyorsun. Eskiden, ücret ne olursa olsun işini özenle yapma duygusu daha güçlüydü; sanki bu epey kayboldu
  • Herkesin kendi rolü olmasının bir sebebi var. Film setlerinde olduğu gibi mühendislerin de amaçları farklı olabilir. Eğer mühendislerin tutkularını yaşamasını engellersen, geriye sadece para için çalışan insanlar kalır. Bu da ciddi bir risk
  • Kimsenin bilerek kötü kod yazdığını sanmıyorum. Kayıtsızlık ya da burnout, ekstra çabanın tekrar tekrar ödüllendirilmediği ortamlarda ortaya çıkıyor; o zaman da kimse fazladan emek vermiyor. Ayrıca birçok geliştirici zaten temelde yeterince iyi değil. Aktüerlik kadar aşırı rekabetçi bir meslek olmadığı için her tür geçmişten insan girebiliyor ve baştan çok yetkin olmak da kolay değil
  • Birçok Product Manager sadece hız istiyor. Biz test ve dokümantasyon istiyoruz ama CFO’lar bu tür ek işleri “özellik değil, o halde gerek yok” diye gereksiz görüyor
  • Mühendislerin şirkette uzun süre kalacağı varsayılmadığı için gelecekteki sorumluluğu da üstlenmiyorlar. Sürekli iş değiştirince, önceki işyerinde yazdığın kodun sorunlarını kendin yaşamıyorsun; böylece başarısızlığın bedelini görmeden aynı döngüyü tekrar ediyorsun. Ben yaklaşık 20 yıldır aynı şirketteyim ve hep aynı hataların tekrarlandığını gördüm. Asıl sorunu bırakıp sadece dış yüzeyi değiştiren değişimlerden de bıktım. Gerçek sorunu çözmüyorsan, değişimin bir anlamı yok. Benim amacım gerçek sorunu çözmek

• Bu gerçekliği ve sorunları defalarca yaşadım, anlıyorum ama yine de itiraz ediyorum. Bir sürü proje başlatılıyor, sonra “çözüldü, done!” deniyor ve ekip dağıtılıyor. Ama üründe hâlâ sorunlar kalıyor, yeni özellikler gerekiyor ve şirket değişmeye devam ediyor. Sonunda kötü yönetim yüzünden sadece teknik borç birikiyor. Yeni bir yönetici geliyor, eski projeyi yeniden yaptırıyor ve aynı hatalar tekrar ediliyor. Bu yaklaşım verimsiz. Klima benzetmesiyle anlatırsak, sıcaklığı sürekli kapatıp sonra yeniden düşürmektense sabit tutmak daha verimli. Nitekim yaptığım yönetim aracı üst yönetimin ilgisini çekmiyordu ama içeride 500’den fazla kullanıcı tarafından gerçekten ihtiyaç duyuluyordu. Büyük bir bakım yükü olmadan güveni sürdürmek önemliydi. İhmal edilirse dağılır ve araca duyulan güven kaybolur. Oysa birkaç dakikalık emekle bile tutarlılığı korumak mümkündü

  • Klima benzetmesi aslında termodinamik olarak yanlış. Kapatıp sonra yeniden soğutmak daha verimli

• Birçok açıdan karışık duygular içindeyim. Görünürlük ve terfi açısından bu yazıda söylenenler doğru ama özünde bu, yöneticiyi memnun etmeye odaklı, yönetici merkezli bir tavsiye. Peki ya net bir yön verilmez ve öncelikler sürekli değişirse? O zaman anlamlı sonuç üretmek zorlaşır ve yönetici-çalışan ilişkisi tamamen “evet efendim” düzenine döner. Bu da pek iyi bir sonuç değil

  • Cevap basit. Aptal bir patronun altında çalıştığını düşünüyorsan, bırak git. Acısı geçici olur ama sonunda daha iyiye çıkarsın. İşini bir aptala anlatmaya uğraşarak zaman kaybetmekten çok daha iyidir
  • Tersine, gerçekten iyi bir yöneticiyle çalışıyorsan, sadece “yöneticiyi memnun etmek” bile hem kariyerinin hem de ortaya çıkan işin hızla büyümesini sağlayabilir

• "unagentic engineer", yani inisiyatif göstermeyen mühendis demek. Bir mühendis böyle çalışırsa verimsizliğe ve ciddi sorunlara yol açabilir: aşırı bulut maliyetleri, güvenlik olayları, müşteri şikâyetleri gibi. Hiç bitmeyen işlere örnek olarak güvenlik yamaları, hata düzeltmeleri, maliyet optimizasyonu ve müşteri geri bildirimlerine yanıt vermek sayılabilir. Şirket bunun değerini anlamıyorsa çözüm iş değiştirmektir

  • Yazının özü zaten bu. Bazı organizasyonlar gerçeklik odaklıdır, bazılarıysa statü odaklı. Gerçeklik odaklı organizasyonlar uzun vadede daha rasyoneldir; statü odaklı olanlarda ise tek amaç patronu memnun etmektir. Ürün kalitesinden ya da müşteri ilişkilerinden çok hiyerarşi önemlidir. Böyle organizasyonların mutlaka çökmesi gerekmez ama bazen bir anda dağılabilirler
  • “Unagentic”, agency’si yani özne/inisiyatif kapasitesi olmayan çalışan demek. İnsan kendi başına hareket etmeyi beklerken, pratikte geliştiricinin kendi varlığının görünmez hale gelmesi gibi bir tuzağa dönüşebiliyor
  • Her zaman böyle olmak zorunda değil ama yöneticiler umursamazsa varsayılan kültür bu oluyor. Ben mesela arayüz tasarımındaki küçük detaylara özen göstermeyi seviyorum. Ama bu tür dikkat ancak organizasyon tarafından değer olarak görülürse karşılık buluyor. Birçok yerde kimsenin umurunda olmuyor
  • “unagentic engineer”, kendi kendine karar alıp işi sürükleme özelliği zayıf olan, akışa kapılıp giden kişi demek
  • Yani özerk olmayan, karar alanı dar bir mühendisten söz ediliyor
  • “high agency” olmayan; yani zeki ve yetkin görünse bile sürekli talimat bekleyen ve kendiliğinden öne çıkmayan kişi anlamına geliyor

• "alignment" gibi buzzword’lerden nefret ediyorum. Yine de özünde önemli bir kavram olduğu doğru. İdeal durumda benim, yöneticimin ve onun üzerindeki liderliğin en önemli işin ne olduğu konusunda uzlaşmış olması gerekir. Eğer bu yoksa, benim bulunduğum organizasyon açısından ortada bir sorun var demektir. Bunun doğru ya da adil olup olmaması ayrı mesele ama sonuçta buna göre yaşamak zorundayız. Nihayetinde tepeden geleni yapmak, bize para ödenmesinin sebebi. Yalnızca çok az kişi yukarıya etki etme ayrıcalığına sahip. Buna da so-called "managing up" deniyor

• Orijinal yazı faydalı ama bence daha önemli bazı noktaları atlıyor:

  • Doğru takımda çalışmak, doğru işi yapmaktan daha önemlidir
  • İyi bir PM ve yönetici, iyi işten daha önemlidir
  • İyi bir raporlama yapısı, sonucun değerinden daha önemlidir
  • Liderliğin hedefleriyle uyumlu işler, gerçek iş operasyonlarını desteklemekten çok daha fazla ödüllendirilir
  • Her şeyi bizzat yapmaya her zaman hazır olmalısın ve büyük şirket siyasetinde işbirliğini caydıran dinamikler her zaman vardır

[heal9179]

Buradaki görüşler aslında tam da can alıcı noktaya değiniyor.

[roxie]

Aynen öyle, haha