2 puan yazan GN⁺ 2024-04-12 | 1 yorum | WhatsApp'ta paylaş
  • Startup liderliği rolü, koddan çok belirsiz sorumluluklarla uğraşmayı gerektirir; panik ataklar, anksiyete ve tükenmişlik hem iş performansını hem de hayatın tamamını sarsabilir
  • Kıdem arttıkça net ticket’ların yerini değişen talepler, çakışan teslim tarihleri ve 24/7 incident müdahalesi gibi ucu belirsiz baskılar alır
  • “make it happen” tarzı kültür; gerçekçi olmayan deadline’ları kabul etme, mikroyönetim, gece PR yeniden yazımı, öğün atlama ve üst üste toplantılarla tükenmişliği büyütür
  • Her deadline aynı riskte değildir; regülasyon, sözleşme ve kendi kendine konan deadline’ları ayırmak, pazarlık edilebilir baskıyla gerçek riski birbirinden ayırmayı sağlar
  • Toparlanma, büyük kararlarla değil; erken uyarı işaretlerini fark etme, hafta sonunu koruma, delege etme, bildirimleri kapatma ve terapi gibi küçük ama tekrarlanabilir davranışlarla başlar

Startup liderliği rolüyle başlayan anksiyete ve tükenmişlik

  • 2017’de Head of IT rolünü devralırken 5 kişilik bir geliştirme ekibi, partnerlere verilmiş çok sayıda söz ve “her şeyi teslim et, hiçbir şeyi bozma ve kimseyi yakma” baskısını birlikte üstlenmiş oldum
  • O dönemde ruh sağlığı gerekçesiyle izin alabileceğimi hissedemiyordum; şirket el kitabında mental health day olsa bile mühendislerin hâlâ tereddüt ettiği durumlar var
  • Anksiyete bastırdığında Reddit’te r/Anxiety içinde benzer belirtileri aradım; uzun vadeli bir çözüm değildi ama ofisten fırlayıp çıkmadan dayanabilmeme yardımcı oldu
  • Sonunda doktora gidip resmî tanı aldım ve yavaş yavaş temel durumuma geri döndüm; bugün bile acil durum kontrol listesini elimin altında tutuyorum

Kontrol edilebilir geliştirme işlerinden belirsiz liderlik işlerine

  • İlk dönem geliştirme işlerinde net ticket’lar, kabul kriterleri, testler ve merge gibi görece kontrol edilebilir bir akış vardı
  • Kıdem yükseldikçe iş tanımı bulanıklaşıyor, deadline’lar çakışıyor, paydaşlar sprint’in ortasında fikir değiştiriyor ve olasılıksal kararlar gündelik hayatın parçası hâline geliyor
  • Altyapı ve SRE işleri, 24/7 pager yüküyle yaşandığı için ürün deadline’larından daha güçlü bir sürekli gerginlik yaratıyor
  • CEO’nun en büyük müşteriye söz verdiği özelliği en öncelikli iş yapmamızı istediği, ardından bir gün sonra onunla çelişen başka bir özelliğin de en öncelikli olduğunu söylediği bir durum oldu
    • İki özelliğin aynı anda en yüksek öncelikte olamayacağını söylesem de gelen cevap “make it happen” oldu

“make it happen” kültürünün yarattığı birikimli hasar

  • Tükenmişlik, tek bir büyük olaydan çok binlerce küçük öz-zararın birikmiş sonucu gibiydi
  • Zihinsel yükü artıran davranışlar tekrar tekrar ortaya çıktı
    • Satış ekibinin itibarını korumak için bütün gerçekçi olmayan deadline’ları kabul etmek
    • Ekibi koruma bahanesiyle doğrudan koda girip mikroyönetim yapmak
    • Gece 2’de banka hesabını yenileyip maaşların ödenip ödenemeyeceğini kontrol etmek
    • O anda çıkan arızayı söndürürken aynı zamanda gelecekteki mimariyi planlamaya çalışmak
    • Junior’ları koçluk ederken geceleri gizlice PR’ları yeniden yazmak
    • Aralıksız toplantılar, soğumuş kahve ve atlanan öğle yemekleri
  • Hafta sonu sabahlarının ilk 10 saniyesi iyi geçip hemen ardından anksiyetenin üstüne çökmesi hissi tekrar tekrar yaşanıyordu

Her deadline aynı riskte değildir

  • Eskiden her release’i sanki Mars Rover inişiymiş gibi ele alıyordum ama dönüp baktığımda şirketin varlığını gerçekten etkileyen deadline sayısı çok azdı; geri kalanı daha çok gurur ve beklenti yönetimi başarısızlığıydı
  • Şirketin nakit akışı iyileşip müşteri yapısı istikrar kazandıkça work-life balance daha az gerçek dışı görünmeye başladı
  • Bir cuma gecesi deploy patladı ve 6 saat boyunca toparlamak zorunda kaldım; müşterinin sözleşmeyi feshedeceğini düşündüm ama pazartesi öğrendim ki müşteri yelken gezisindeymiş ve staging link’ini bile açmamış
  • Deadline’lar üçe ayrılabilir
    • Regülasyon deadline’ları: Pazarlık edilemez
    • Sözleşme deadline’ları: Erken konuşulursa çoğu zaman pazarlık edilebilir
    • Kendi kendine konan deadline’lar: Genellikle gururdan kaynaklanır
  • Bazı şirketler 4 günlük çalışma haftası ve mesai sonrası Slack yasağını benimsiyor; tükenmişliği onur madalyası gibi gören şirketlerde kalmak zorunda değilsiniz

İşe yarayan kişisel başa çıkma yöntemleri

  • Bu bir tıbbi tavsiye değil ama işlevselliğimi korumama yardımcı olan bazı davranışlar oldu
  • Erken uyarı işaretlerini arıyorum
    • Benim için bunlar doom-scroll kaynaklı uykusuzluk ve normalde sevdiğim code review’a karşı aniden gelişen nefret oldu
    • Bu işaretler belirdiğinde tempoyu düşürüyorum
  • “Hayır”ı net söylüyorum
    • Hafta sonu korunmalı; pager bildirimi değilse pazartesiye kadar bekleyebilir
  • Gerçekten delege ediyorum
    • Elimde tuttuğum her PR, bir mentorluk fırsatını kaçırmak ve anksiyeteyi biriktirmek anlamına geliyor
  • Kafeini azaltıyorum
    • half-caf’e geçip ardından decaf’e döndüm; kalbim rahatladı
  • Günde 12.000 adım yürüyorum
    • Özel ekipmana gerek yok; ayakkabı ve rota yeterli
  • Telefon bildirimlerini kapatıyorum
    • Prod gerçekten yanıyorsa birinin beni arayacağını varsayıyorum

İnsanı önceleyen liderlik

  • Duygusal zekâ üzerine okumaya başlayınca insanları merge conflict çözen makineler gibi görmemeye başladım
  • Önce dinleyip sonra düzeltmek, bazen bir sprint retrospektifinden daha faydalı olabiliyor
  • Diş tedavisini utanmadan uzmana bırakırken ruh sağlığını tek başına refactor etmen gerektiğini düşünmek doğru değil
  • Bir uzmana ayırdığım zaman, en yüksek ROI sağlayan zamanlardan biri oldu
  • İyileşme tekrar eden bir süreç; hâlâ geç saate kadar çalıştığım ya da öğle yemeğini unuttuğum oluyor ama artık bunu fark edip düzeltiyor ve devam ediyorum

Koddan daha önemli varlık

  • Kod yeniden yazılabilir ama insanlara aynı şekilde davranılamaz
  • Depresyon, Kubernetes uptime’a aldırmaz; liderlik insanları tüketirse cluster çalışsa bile o cluster’ı ayakta tutan insanlar dayanamaz
  • Bütün müşteri ticket’larını bizzat çözme dürtüm olsa da artık önce “Bu benim kontrol alanımda mı?” diye soruyor, değilse devrediyorum
  • Sonuç olarak biraz daha sakin bir mühendis oldum ve Apple Watch verilerine göre geceleri 45 dakika daha fazla uyumaya başladım
  • Zor bir dönemden geçiyorsanız bozuk değilsiniz ve yalnız değilsiniz; yardım istemek, küçük denemeler yapmak ve ruh sağlığı izni kullanmak daha iyidir
  • Değerinizi tükenmişlik saatleriyle ölçen şirketler o zamanı vermeye değmez; en büyük varlık, yazılmış kod değil o kodu yazan insandır

1 yorum

 
GN⁺ 2024-04-12
Hacker News yorumları
  • Neredeyse 30 yıldır yazılım mühendisliği yaptıktan sonra vardığım sonuç şu: çoğu son teslim tarihi tamamen keyfî
    1 hafta, hatta 6 ay gecikmek şirketi batırmaz; gerçekten batırıyorsa da, mühendislik organizasyonu kendi teslim tarihi tahminlerini tekrar tekrar boşa çıkaracak kadar bozulmuş olmadığı sürece bu mühendisliğin suçu değildir
    Regülasyon, müşterinin kavram kanıtı, teslimat gibi gerçek son tarihler vardır; ama normal bir mühendislik/iş organizasyonunda bu tür son tarihler çok önceden bilinir ve asıl mesele, yeterince pay bırakılmış bir takvim içinde uygulanabilir olup olmadığıdır
    Bir ürün belli aralıklarla yayımlanmıyor diye müşterilerin ayrıldığını neredeyse hiç görmedim; aksine, kendi talep ettikleri bir sorunu düzeltmiyorsa yükseltmeleri memnuniyetle karşılamayan çok müşteri var
    Bitmek bilmeyen haftada 80 saat çalışma çoğu zaman ters etki yaratır ve sürekli bozulan, çöpe atmak isteyeceğiniz düşük kaliteli ürünler ortaya çıkarır

    • Benim deneyimime göre işin kendisi de çoğunlukla keyfî
      Son 30 yıla bakınca, tamamen atlanmış olsaydı uzun vadede hiçbir fark yaratmayacak işlerin oranı yüzde kaç olurdu? Benim durumumda rahatça %50’yi geçer; kötü bir günümdeyse %90’a yakın derdim
    • Sektöre göre değişir
      Video oyunları hâlâ Target, Best Buy gibi perakende mağazalarında da satılıyor ve mağazaların raf alanını aylar öncesinden koordine etmesi gerekiyor. 15 Kasım’a kadar paketlenmiş oyunu lojistik rampasına bırakacağınıza söz verip bunu kaçırırsanız, sizin için ayrılan raf olduğu gibi boş kalır
      Tüketici elektroniği de benzer; reklamlar, özellikle TV reklamları da eskiden çok daha önceden rezerve edilmek zorundaydı. 6 ay önceden reklam slotu satın almazsanız hepsi satılır; reklam yayımlandığında ürün satın alınabilir değilse büyük para yakarsınız
      Sıradan bir IT projesinin son teslim tarihi epey saçma olabilir, ama perakende ürünlerde son teslim tarihlerinin neden ortaya çıktığını anlayabiliyorum
      Çözüm, ürün %100 tamamlanmadan raf alanı pazarlığına başlamamak olurdu; ama şirketler genelde bunu yapamaz. Maaşları sipariş ödemeleriyle ödemeleri gerekir; ürün tamamlandıktan sonra reklam ve raf ayarlayıp 6 ay beklerlerse o süre boyunca çalışanların ne yapacağı belirsizleşir, sonraki ürüne geçip sonra yeniden önceki ürünün desteğine dönmenin maliyeti de büyür
    • VirtualBox, Docker gibi çeşitli yazılımları kullanan biri olarak güncellemelerden ve sözde yükseltmelerden gerçekten nefret ediyorum
      Çok daha seyrek güncellenen kararlı sürümleri tercih ederim
    • Şirketleri son teslim tarihinden çok, son teslim tarihinin tutturulamayacağına dair yeterli ön bildirimin olmaması daha çok zorlar
      Hiçbir uyarı yokken mühendisliğin yaklaşan son teslim tarihini tutturamayacağını aniden duyurması ya da “neredeyse bitti, sadece bir sprint daha”ın sürekli tekrarlanması daha sinir bozucudur
      Bu yüzden “artık tahmin yapmıyoruz”, “bitince bitmiştir” gibi anlık tepkiler hiç yardımcı olmaz
    • Birçok yönetici ve lider, her işin bir son teslim tarihine ihtiyacı olduğunu varsayar
      Kendi programlarını da zaman blokları ve keyfî son tarihlerle yönetip üretken hissettikleri için bu içgörüyü tüm şirkete genişletirler. Zaman sınırlı bir tehdit yoksa işlerin zamanında bitmeyeceği varsayımı bunun altında yatar
      Bir işin belirli bir tarihte biteceği hissi insana çekici gelir; iyi yağlanmış bir makinenin öngörülebilir bir takvimle çalıştığına dair sıcak bir duygu da verir
      Ama birinin kaygısını ve takvim takıntısını yönetmek için çok sayıda insana zorunlu programlar dayatmak acımasızdır. Gerçeklik karmaşıktır; onu düzgün kutulara koyma arzusu ise sanrısal ve verimsizdir
  • Yazılım mühendisliğinin doktorluk, avukatlık, satış, mühendislik, profesyonel sporculuk, öğretmenlik gibi diğer beyaz yakalı mesleklerden ruh sağlığı için daha kötü olduğuna pek ikna olmuş değilim.
    Bu mesleklerin hepsinin kendine özgü stres kaynakları var ve zor geldiği için ayrılan çok kişi olduğuna dair yazılar da fazlasıyla var. Sınır koymazsanız boş zamanınızı yer; teslim tarihleri yüzünden stres yaşamak da ortak bir durum.
    “Zihinsel olarak zorlandığım için bir gün izin alacağım” diyerek ekibe hastalık izni alamama kısmını okumak rahatsız ediciydi.
    20 yıllık kariyerimde böyle bir tavırla hiç karşılaşmadım; insanlar ruh sağlığı nedeniyle sık sık hastalık izni alıyor. Bunu söyleyemeyeceğinizi hissetmiş olmanız üzücü, ama bu kuraldan çok istisnaya daha yakın.
    Son 20 yılda ruh sağlığına karşı açıkça tavır alan bir şirket oldu mu?

    • Askerî ortamda ise bu tür durumlar aktif biçimde engellenmeye çalışılır.
      Ruh sağlığı sorunları olan çok sayıda 18–20 yaşında genç var; onlara çok kolay izin vermek çoğu zaman yardımcı olmuyor. Uzmanlar, evde içki içip oyun oynamaya bırakmaktansa çalışmaya devam etmelerini ister.
      Bazı gençler iş stresi arttığında tam tersine daha iyi tepki verdi. Eğitim kampındaki gibi sıkı çalışıp yorulunca eve gidip uyuyorlar; ama yorgun değilken eve gönderilirlerse bu içki ve gece geç saatlere kadar oyunla sonuçlanıyor, ertesi gün de zombi gibi işe geliyorlar.
      Bu herkes için geçerli bir yöntem değil, ancak kendimiz için mutlaka en iyi terapist olmadığımızı kabul etmeliyiz. İzin süresi arttığında olumsuz davranışları büyüyen çok kişi var.
      Daha iyi cevap “Bir gün dinlenmeliyim”den çok “Yarın 08:00’de danışmanlık randevum var”a daha yakın.
    • Tıptan gelen biri olarak bakınca yazılım mühendisleri gerçekten iyi bir konumda. Sahip olduklarının kıymetini bilmeliler.
      Kötü yönetim, gerçekçi olmayan takvimler ve ilgi çekmeyen projelerle ilgili kişisel deneyimleri kabul ediyorum; ama bunlar her yerde var.
      Buna her gün hastaların ve ailelerinin hayatlarının en kötü gününü yaşadığı bir ortamda bulunmayı, yüksek baskı altında kararlar almayı ve vardiya boyunca oturmaya ya da tuvalete gitmeye bile neredeyse fırsat bulamamayı ekleyince durum değişiyor.
      Üstelik iyi olmadığınız tek bir gün, uzun ve yorucu bir soruşturmaya ya da mahkeme sürecine dönüşebilir.
      Duyarsız gelebilir ama yazılım mühendisliği birçok sağlık mesleği kadar karmaşık ya da stresli değil. Hem zihinsel hem de fiziksel olarak daha az yıpratıcı.
    • Yazılım mühendisliğinin avukatlıktan ruh sağlığı için daha az zararlı olduğunu düşünmüyorum.
      Neredeyse 10 yıl boyunca avukatlarla çalışıp mühendislik dışı profesyonel hizmetler verdim; ayrıca yazılım mühendisliği ve startup alanında da onlarca yıllık deneyimim var.
      Yazılım mühendisliğindeki baskı, hukuk ortamında yaşadığımdan tamamen farklı ve çok daha kötüydü.
      Genel olarak avukatlar yöneticiden çok avukattır. Junior associate’ten en üst düzey ortağa kadar bir hiyerarşi vardır ama hem üsttekiler hem alttakiler avukattır. Bir avukatın bir yöneticinin altında çalıştığı yapıdan farklıdır.
      Hukuk ortamında da baskı ve uzun çalışma saatleri var; eşler avukatların sürekli ofiste olmasından ya da evdeyken bile aklının başka yerde olmasından şikâyet eder. Ama orada anksiyete atakları ya da ruh sağlığı sorunları yaşamadım; yazılım ve startup ortamlarında yaşadım.
      Hukuk tarafında herkes süreci bilir ve o süreci uygular; üstleri de o süreci daha önce yapmış kişilerdir.
      Yazılımda ise çoğu zaman bu süreç bilinmez ve bizzat öğütülmemiş birini memnun etmeye çalışırken sürekli öğütülmek kolaydır. Eskiden çalıştığım başarılı halka açık şirketin kıdemli yazılım mühendisi ilanlarının tam da bu nedenle sürekli açık olması bundandı.
    • Pek çok kişi, yöneticisine yalnızca sağlık/tıbbi nedenlerle izinli olduğunu söylemesinin yeterli olduğunu; grip mi, bel sorunu mu, ruh sağlığı mı olduğu hakkında ek bilgi vermek zorunda olmadığını bilmiyor.
      Okullarda istihdamla ilgili temel hukuk öğretilse çok kişiye faydası olur gibi.
    • Yazılım mühendisliğinin daha zor olduğunu kimin söylediği neden önemli?
      İster dışkıya basmış olun ister dizinize kadar batmış olun, sonuçta dışkının içindesiniz. Kimin daha çok battığı konusunda yarışmak yerine birbirimizi temizlemeye çalışmak daha iyi değil mi?
      Karşılaştırmayı bırakmalıyız. Şu an triyaj gerektiren bir durum da yok; ortalama olarak daha iyi durumda olan birine de sempati ya da empati gösterebiliriz. Hepimiz insanız ve birlikte olduğumuzda kazançlı çıkarız.
  • Eskiden genç, üniversiteyi bırakmış CEO’lara karşı bir ölçüde hayranlık duyardım; ama birkaçının altında çalıştıktan sonra tepesinde 20’li yaşlarında biri olan startup’larda çalışmamaya karar verdim.
    Gerçekten yönetimden ya da liderlikten anlamıyorlar. Başarısızlık korkusuyla motive oluyorlar ve henüz bir şey başarmadıkları için insanlara çöp gibi davranıyorlar. Uzak durmak en iyisi.

    • Stanford’a gidip 21 yaşındaki birine sen İsa Mesih’sin diyerek milyonlarca dolar vermeyi vadetme olgusu, şirket yağmacıları kadar Amerikan iş kültürünün bir çıbanı.
      Üniversite Amerikan futbolu/basketbolu oyuncu toplamanın tuhaf bir versiyonu.
    • 25 yaşındaki birinin harika bir startup CEO’su olamaması için bir neden görmüyorum.
      Zor olan asıl nokta şu: 25 yaşındaki biri genel olarak zeki, nadir görülen bir öz farkındalık ve alçakgönüllülüğe sahip olsa ve büyük bir soruna girişse bile; ne zaman ekibi ya da danışmanları dinlemesi gerektiğini, kimi dinlemesi gerektiğini ve ne zaman kendi yargısıyla ters yönde gitmesi gerektiğini bilmesi zordur.
      Tüm iyi niteliklere sahip olup iyi bir ekip ve danışmanlarla karşılaşırsa bir ölçüde mümkün olabilir.
      Ne var ki pek çok alanın kötü uygulamalar ve tavsiyelerle, açıkça aldatma ve manipülasyonla dolu olması da yardımcı olmuyor. Eskiden PG yazılarını okuduğum dönemde, aynı zamanda teknoloji insanı ve girişimci olan birinin akıllı ve iyi niyetli tavsiyelerle başarılı olmanızı isteyeceğini bekleyebilirdiniz; artık bu kesinlikle standart değil.
      Şimdi nereye baksanız kötü tavsiye alma olasılığı çok daha yüksek; bireylerin ve kurumların sizi manipüle etmeye çalışması da daha yaygın. Kendiniz süzgeçten geçirseniz bile, etki etmesine izin verdiğiniz akıllı ve düzgün insanlar üzerinden ikinci elden gelen etkiler de size ulaşır.
    • Başkalarına çöp gibi davranan birine, 20 yaşında da olsa 60 yaşında da olsa hayranlık duymaya gerek yok.
      49 yaşındaki bir kurucu/CEO ile yaşadığım deneyimden yeni çıktım; bundan sonra çöp kokan tüm sinyalleri arayacağım gibi görünüyor.
    • Genç orta kademe yöneticiler arasında da gerçekten sinir bozucu olanlar vardı. Çok da genç sayılmayan, 20’lerinin sonu ile 30’larının başındaki kaygılı işkolikler herkesin hayatını berbat ediyor.
      Terfi etmek için deli gibi çalıştılar ve şimdi ekibi kendileri gibi insanlarla doldurabileceklerini sanıyorlar.
      Ama öyle değil. O “kendileri gibi insanlar” ya sağlıklarını bozmayacak kadar akıllı oldukları için ya da bunu istemedikleri için terfi etmedi.
      Daha iyi iş çıkardınız, daha çok para ve yetki elde ettiniz; tebrikler. Ama artık herkes çarşafını kaldırıp kırıntı döktüğünüz o yatağa yatmak zorunda.
    • Teoride doğru, ama pratikte de öyle mi? Amazon ve Oracle, Facebook ve Stripe’tan çalışmak için daha iyi yerler mi?
  • Bir noktadan sonra yalnızca bir kuyruk oluşturup, sıradaki en yüksek öncelikli işe başlamak gerekir
    Devam eden iş çok fazlaysa işler sarpa sarar

    • Bu yüzden Kanban en sevdiğim proje yönetimi metodolojilerinden biri
      “Yeni en öncelikli özellik bu demek. Kısa bir keşif yaptım; bu işin 20 yapışkan notla ifade edilebileceği görünüyor. Ekibimizin geçmiş işleme hızı 2 haftada 10 yapışkan not. Dolayısıyla mevcut devam eden işleri tamamen indirirsek muhtemelen 4 hafta sonra biter. Lütfen mevcut yapışkan notların her birine bakıp gerçekten durdurulabilir olup olmadığını doğrulayın”
      Paydaş yine karar verebilir, ama ekibinden ne istediğini gerçekçi biçimde anlamasını sağlar
    • Birkaç yıl önce bir şirkette mühendislik direktörü olarak çalışıyor, ürünün büyük yeni bir sürümüne hazırlanıyordum
      Birkaç hafta sonra CEO’ya yeni sürümün kapsamını ve zorluklarını epey iyi anladığımızı düşündüğümü söyledim; CEO ise “Hayır, anlamıyorsunuz” dedi
      Nedenini sorunca hafta sonu aklına gelen “olmazsa olmaz” yeni bir özellik olduğunu söyledi; bu özellik açıkça teknik olarak çok zordu. Ardından her şeyin 48 saat içinde yapılabileceğini kesin bir dille söyledi
      O işte o kadar uzun süre dayanmış olmam şaşırtıcı
    • Yönetici olarak yukarıdan öncelikler değişse bile, yapmakta olduğumuz iş neredeyse bitmişse onu bitirirdim
      Sonradan asıl işe geri dönüldüğünde onun zaten tamamlanmış olmasına hep şaşırırlardı
    • Eski iş yerim tam olarak böyleydi; böyle bir pozisyonda gerekenden uzun kalan kişi başka bir rol aramalı
      Sonu tükenmişliğe ya da ilgisizliğe çıkan bir yol
      O dönemde X-Files’ı çok izlediğim için buna “haftanın canavarı” diyordum; hâlâ bu ifadeyi seviyorum
    • İş tarafıyla muhatap olan bir geliştiricinin sahip olabileceği en güçlü becerilerden biri hayır diyebilme yeteneğidir
  • Çok kısa bir süre için bile olsa yapılan işten kopabilme becerisi gerçekten önemlidir
    Yürüyüşe çıkabilir, kahve demleyebilir ya da sadece gözlerinizi kapatıp nefes alabilirsiniz
    Stres çoğu zaman yapay olarak yaratılır; performansı bozar ve düşünme becerisini de düşürür
    Şirketin sözleşme ya da gelir kazanabileceği gerekçesiyle işlerin “acil” hâle geldiği, bu “crunch”ı başarırsak herkesin süperstar olacağı durumları defalarca yaşadım
    2 ay boyunca sabahlamalar ve 3–4 saat uykuyla projeyi erken teslim ettiğinizde, yönetim ve karar vericiler bu “hediye” gibi crunch’ları sürekli vermeye başlayıp duyarsızlaşır
    Şirkete yardım etmek ve fazlasını yapmak çoğumuzun yaptığı ve yine yapabileceği şeylerdir; ama her şey acilse ve her işin hemen şimdi yapılması gerekiyorsa daha büyük bir sorun var demektir
    Para, zaman ve emek için genellikle sınırlar ve bütçeler vardır. Bu sınırlar ve toleranslar kötüye kullanılırsa insanlar sürekli “kurt geliyor” diye bağıran kişiye saygı duymamaya başlar ve işe de daha az enerji harcar

    • Benim kariyerimde bunların hiçbiri karşılık olarak geri dönmedi
      “Bunu teslim edersek devasa bir büyük sözleşme kesinleşecek” türü dramatik acil işlerle her crunch yaptığımızda sonuçta sözleşme başarısızlığı oldu
      Bir satışçının, uzun vadeli tek bir kumar uğruna tüm Ar-Ge organizasyonunu aylarca döndürüp insanları yakmasına rağmen kovulduğunu pek görmüyorum
      Elbette o satışçı da bu süre boyunca haftalarca fazla mesai yapmıyor
      Artık kendi hatamı telafi etmek için fazladan çalıştığım durumlar dışında fazla mesaiyi neredeyse reddediyorum. Başka bir aptalın gerçekçi olmayan teslim tarihini yakalamak için bir daha fazla çalışmayacağım
    • Öğrenmesi en zor ders bu
      Şirket, ürün ya da müşteri için “doğrusunu” yapma fırsatı bazen verilmez. Sonunda bugün en önemli şeyin ne olduğunu sorup onu yapmaya, iş bitince de tamamen işten çıkmaya karar veriyorsunuz
      Anlamı ve kişisel tatmini özel hayatta bulmak gerekir. Spor yapabilir, gönüllü çalışabilir, hobi edinebilir ya da aileye odaklanabilirsiniz
      İş-yaşam dengesi elde etmenin en iyi yolu ikisini ayırmaktır. Evden çalışmayı sevmememin nedenlerinden biri de bu. İşe gidip gelirken araba kullanmak benim için harika bir ayrıştırma ve basınç düşürme aracı
  • “Zihinsel olarak zorlandığım için bir gün izin alacağım” diyerek hastalık izni alınamayacağı doğru değil
    Bir ruh sağlığı gününe ihtiyacınız olduğunu söyleyebilirsiniz; yetişkinler bunu anlar

    • Çalıştığım şirketlerin çoğunda “Bugün kendimi iyi hissetmiyorum, bir gün izin alacağım” demek yeterliydi
      Kimse ayrıntı sormazdı
    • “Yetişkinler bunu anlar” ifadesi epey balon içi bir deneyim
      İşlerin büyük çoğunluğunda durum böyle değil
    • Senin çalıştığın yerde öyle olabilir ama ben sadece işe gelmeyeceğimi söylerim
      Liderime ya da yöneticime böyle söylesem neden gelmediğimi sorgular
    • Aynı nedenle wellness day de kullanabilirsiniz
  • Yazılım geliştirme pratiğinin kendisinde ruhsal hastalığa yol açan ya da açabilecek bir şey olduğuna inanmaya başladım
    On yıllar boyunca bazı meslektaşlarımın çok ciddi sorunlar yaşadığını gördüm ve sektörümüzde bunun gerçekten oldukça ciddi bir sorun olduğunu düşünüyorum

    • Yazılım mühendisliği nöroçeşitliliğe sahip insanları çekiyor gibi görünüyor
      Ben ADHD’li bir yazılım mühendisiyim ve alışılmadık derecede çok ADHD’li yazılım mühendisi tanıyorum
      Bu düzeyde yürütücü işlev bozukluğu ve “yetişmeye çalışma” sorun hâline geliyor
    • İyi hissetmek için kazanma deneyimlerine ya da sonu olan projelere ihtiyaç var
      Ama birçok proje, şirketin ya da kişinin enerjisi tükenene ya da başka bir şirkete geçip aynı şeyi tekrarlayana kadar yıllar boyunca sonu gelmeden sürer
      Web geliştirmede lansman tarihi bitiş çizgisine en yakın şeydir ama gerçek bitiş çizgisi değildir. Temel metrik hedeflerine ulaşmak da bir ölçüde buna girer; ancak bir masa ya da seramik eseri tamamlamak, ürün hasat edip satmak ya da akşam yemeği olarak sunmak kadar psikolojik olarak tatmin edici değildir
    • Bu sektör temelde bilinçli düşünceyi sermayeye dönüştürme işini mümkün olduğunca verimli yapmaya çalışır
      Bu yüzden zihne kötü gelmesi mantıklı
    • Stresin büyük kısmı, iş arkadaşlarının kaprisleri, öngörü eksikliği ve kötü planlama nedeniyle o “şey”in tanımı hızla değişebildiği hâlde onu çalışır hâle getirme sorumluluğundan gelir
    • Sonuçta yaptığımız işin çoğu yazmaktır
      Diğer yazarların ne kadar iyi uyum sağlayıp yaşadığına bakmak yeterli. Özellikle de kira yüzünden değersiz olduğunu bildikleri yazıları saatlerce yazmak zorunda kalanlara
  • 2017’de etrafındaki tüm belirsizliği kontrol etmeye çalıştığını anlatması, berbat bir şirketteki kâbus gibi bir iş yerinde dayanmaya çalışırken kendini suçlaması gibi geliyor

  • Böyle biri liderlik pozisyonunda olmamalıydı
    Bu tip birinin altında çalıştım; kendisi iyi bir mühendisti ama berbat bir liderdi
    Ekibe güvenmez, her zaman işi kendi halleder, tartışma olmaz, arka kapıdan konuşur ve yönetimin istediğine hep boyun eğerdi. Her şey “önemli” ya da “kritik”ti; mikro yönetimin en kötüsüydü
    Aynı zamanda ben de o pozisyona konulsaydım, daha hafif de olsa benzer şekilde başarısız olmuş olabilirdim. Yönetim çoğu zaman bizi “X’e iyi görünmek” dışında pek de iyi bir gerekçe olmadan imkânsız pozisyonlara iter
    Bunu adı sanı bilinmeyen orta düzey bir yöneticiye puan toplamak için yapıyorlarsa daha da kötüsü
    Bu yüzden teknoloji sektöründe sendikaların olmasının iyi olacağını düşünüyorum. Gerçekçi beklentiler belirlenebilir ve yönetime kolektif bir bakış açısıyla yaklaşılabilir
    Ne yazık ki günümüzde şirketler sadece hızlı exit ve IPO ile girişim sermayesini geri döndürmeyi hedefliyor. Akbabalar arasındaki genel kanaat, sendikaların hızlı exit ihtimalini düşürdüğü yönünde gibi görünüyor

    • Bu bir organizasyon başarısızlığı
      Çünkü organizasyon birini lider olarak eğitmeden terfi ettirmiş
      Teknik olmayan geçmişe sahip bir yöneticiden durup dururken kod yazmaya başlamasını beklemiyorsak, neden bir yazılımcıdan durup dururken yönetmeye başlamasını bekliyoruz?
    • “Ekibe güvenmeyip her zaman işi kendi yapmak”, öğrenmesi benim için en zor derslerden biriydi
      Lider adaylarına koçluk yaparken de sık sık bir engel olarak karşıma çıkıyor
      Liderlik rolüne geçtiğinizde, insanların işleri benim yapacağım şekilde yapmasalar da bunun sorun olmadığını kabul etmeyi öğrenmeniz gerekiyor
      Astınızın sonucu neredeyse yeterliyse ya da yeterince iyiyse bunu kabul etmelisiniz. Ve o “yeterli”nin tolerans aralığı, öğrenmeden önce sandığınızdan çok daha geniş olacaktır
    • Benim de böyle bir patronum olmuştu
      Şirket özellikle işlevsiz de olabilir ama bana verilen proje ve işler konusunda çok deneyimli değildim ve bunu da saklamıyordum
      Ama kendim çözmeye zaman ayırınca patronum işi doğrudan kendi yapıyor ve hiç geri bildirim vermiyordu
    • “Asla lider olmamalıydı” demek aşırı basitleştirme olur
      Gerçekte önceliklendirme, delegasyon ve duygusal zekâ konusunda somut eğitime ihtiyaç duymuş olabilir
      Bu tür eğitimler nadiren veriliyor. Bunun yerine yüksek performans gösteren insanlar derin suya atılıp dayanıp dayanamayacaklarına bakılıyor
    • “Her zaman işi kendi yapmak”, liderlik rolünün sezgilere en ters düşen taraflarından biri
      İnsanlar genelde bireysel katkı sağlayan rolde birçok işi bizzat başardıkları için terfi eder. Ama lider olduktan sonra ne kadar az işi doğrudan yaparsa, bu hem kendisi hem şirket hem de ekip üyeleri için o kadar iyidir
      Bu yüzden eskisine göre daha boşta hissediyor olmanın işi kötü yaptığınızın işareti olmadığını öğrenmek gerekir
  • “Zihinsel olarak zorlandığım için bir gün izin kullanacağım” diyerek ekibe hastalık izni alamayacağınızı söylemek mümkün
    Ben birkaç yıl önce bunu yapmaya başladım ve genel olarak olumlu bir deneyim oldu. Önce ben kendi zorluklarımı açıkça gösterdiğim için ekipteki diğer insanlar da kendi zorluklarını anlattı