Mühendisten yöneticiye: Sevdiğim ve sevmediğim şeyler
(thoughtspile.github.io)- 7 yıl frontend geliştiricisi olarak çalıştıktan sonra takım lideri ve tam zamanlı engineering manager olduktan sonra, ürün ve ekip üzerindeki etkisi arttı ama işin doğası büyük ölçüde değişti
- Yönetici, test yazımı, süreç iyileştirme, ekip atmosferini ayarlama gibi IC iken değiştirmesi zor olan sorunlara resmî ve gayriresmî yetkiyle müdahale edebilir
- Uzun vadeli kariyerde, genel mühendis unvanlarına kıyasla daha yüksek ücret, staff+ IC rollerine göre daha geniş fırsatlar ve başka teknik alanlara, proje yönetimine, ürün yönetimine ya da girişimciliğe geçişi kolaylaştıran aktarılabilir beceriler kazanılır
- Buna karşılık performans değerlendirmeleri, mantıksız teslim tarihleri, organizasyon politikaları gibi kurumsal prosedürleri uygulamak gerekir ve çatışma, psikolojik kaygı, sürekli hazır olma baskısını doğrudan üstlenmek gerekir
- Yönetim işleri, sonuçlarını bir ay içinde göstermekte zorlanır; ekip bölme ya da işe alım gibi doğru değişiklikler bile kısa vadede durumu kötüleştirebilir, bu yüzden uzun geri bildirim döngülerine dayanmak gerekir
Mühendisten yöneticiye geçiş süreci
- Yaklaşık 2 yıl önce takım lideri rolüne geçti, ekip büyüdükten sonra da tam zamanlı engineering manager oldu
- Ondan önce 7 yıl frontend geliştiricisi olarak çalıştı; başlangıçta kıdemli bireysel katkıcı (IC) kariyer yolunu seçmişken sonradan yöneticiliğe geçti
- Geçiş süreci engebeliydi ama eğlenceliydi; mevcut işinde hem sevdiği hem de sevmediği şeyler var
Yönetici rolünde sevdiğim şeyler
-
Ürünü ve ekibi değiştirme yetkisi
- Yönetici olunca, ürünün ve ekibin genel durumunu iyileştirecek yetki gelir
- IC iken sabah çok erken stand-up toplantıları, düşük kod kalitesi, anlaşılması zor yeni özellikler gibi sorunları değiştirmek zor olabilir
- EM, resmî ve gayriresmî yetki sayesinde ekibin ve kendisinin daha iyi çalışma biçimlerine yönelmesini sağlayabilir
- Aynı “test yazmalıyız” cümlesi IC söylediğinde ve EM söylediğinde aynı ağırlığa sahip değildir; EM söylediğinde bu gerçekten test yazımına dönüşebilir
-
Daha geniş kariyer fırsatları
- Engineering manager, tipik mühendis kariyer yoluna kıyasla daha geniş fırsatlar sunar
- EM genelde junior, mid, senior gibi temel ekip düzeyi mühendis unvanlarından daha yüksek ücret alır
- staff, principal gibi daha yüksek IC seviyeleri de EM’in üstünde ücret bandına sahip olabilir
- Ancak staff+ IC işleri, daha zor teknik problemleri olan büyük teknoloji şirketlerinde yoğunlaşırken, neredeyse her şirketin yazılım ekibinde liderlik pozisyonları vardır
- Yönetim kariyer merdiveni, IC’ye kıyasla daha yukarı uzanır
- CTO olma ihtimali düşük olsa bile, hiç yönetim deneyimi olmayan saf bir IC’nin sahip olmadığı seçenekler açılır
- EM talebi, staff+ mühendislere olan talepten daha istikrarlıdır ve kariyerin ilerleyen dönemlerinde daha fazla fırsat sunar
-
Başka alanlara geçmeyi kolaylaştıran beceriler
- Yönetim becerileri, belirli bir IC mühendislik rolüne göre daha geniş kullanım alanına sahiptir
- React deneyimi olan bir frontend mühendisi başka bir frontend framework’üne geçebilir ya da unvanda bir miktar gerilemeyi kabul ederek backend veya mobil role kayabilir
- Engineering manager deneyimi varsa, mobil geliştirici ekibi, altyapı ekibi ya da ML mühendisliği ekibi gibi farklı odaklara sahip takımları yönetmek daha kolay olabilir
- Yeni ekibin büyük teknik zorluklarını anlamak zaman alır ama birçok şirket bu geçişi kabul edebilir
- EM olarak devam etmek istemezse proje yönetimi veya ürün yönetimi rollerine geçmek için de iyi bir konumdadır
- Teknoloji piyasasının geneli durgunlaşsa bile, birçok yönetim becerisi başka sektörlerde de işe yarayabilir
- İnsanlarla ve iş kararlarıyla ilgilenme deneyimi, girişimcilik öncesi bir hazırlık olarak da değerlidir
-
Bilginin daha yavaş eskimesi
- En yeni frontend framework’lerini ve araçlarını takip etmenin yorgunluğunu hissediyorsanız, yönetim rolü bu yükü azaltabilir
- “Yeni” agile, kanban, scrum metodolojileri aslında 20-30 yıllık kavramlardır; demo, daily, 1:1 gibi temel toplantı türleri de uzun süredir evrilmektedir
- Yönetimin özünde ekip çalışması ve insan etkileşimi vardır; bunlar da insanlığın ilk dönemlerinden beri büyük ölçüde değişmedi
- Teknolojik değişimleri izlemeye devam etmek gerekir ama acilen derine inme ihtiyacı görece daha azdır
-
Alışıldık teknik problemlerin dışında yeni zorluklar
- Belirli bir teknik alanda 4-5 yıl çalışınca, pratikteki sorunların çoğunu yeterince çözebilir hâle gelirsiniz
- Deneyimli bir mühendisin daha büyük zorluk arama biçimlerinin sınırları vardır
- Yeni bir frontend framework’ü gibi stack’i biraz değiştirmek, ilgiyi uzun süre canlı tutmakta zorlanabilir
- Frontend’den backend’e geçmek gibi daha büyük bir değişim birkaç yıl eğlenceli olabilir ama tesadüfen gerçekleşir ya da ücreti etkileyebilir
- Her şeyi yeni bir kütüphaneyle baştan yazmak veya geleceğe hazırlanmak için 9000 RPS kaldırmaya çalışmak gibi yapay problemler üretmek eğlenceli olsa da ekip ve iş için çoğu zaman zararlıdır
- Deneyimli bir mühendis için yönetime geçiş, ücreti düşürmeden en fazla yeni öğrenme alanı sunan seçenek olabilir
Yönetici rolünde sevmediğim şeyler
-
Kurumsal prosedürleri uygulamak zorunda olmak
- Mühendisken bireysel performans değerlendirmelerinden, anlamsız deadline’lardan, şirketin dayattığı süreç ve teknoloji stack’i kısıtlarından oluşan kurumsal saçmalıklardan hoşlanmıyordum
- Yönetici olunca, bunlara inanıp inanmamanızdan bağımsız olarak bunları uygulayan kişi siz olursunuz
- Performans kalibrasyonu olan organizasyonlarda takım lideri her 6 ayda bir yeterince sıkı çalışmamış 1 kişiyi işaret etmek zorunda kalabilir
- Feda edilecek bir ekip üyesi çıkarmazsanız, sonraki aşamada birisi rastgele seçilebilir; bu yüzden süreci ortadan kaldırmak zordur
- Bazı prosedürler müzakere edilebilir ya da etrafından dolaşılabilir; örneğin “beklentinin altında performans” etiketini round-robin usulü dağıtmak gibi
- Ekip açısından yönetici bazen bir kurumsal canavar gibi görünebilir
- İşten çıkarma, kapatma ya da yeniden yapılanma gibi daha zor durumları henüz yaşamadı
-
İnsanlar arasındaki gerilimi yönetmek zorunda olmak
- Engineering manager olma motivasyonunun başlangıcı bir şeyi iyi inşa edebilme yeteneğiydi; teknik kararları desteklemeyi, kariyer tavsiyesi vermeyi, süreçleri ayarlamayı, otomasyon kurmayı bekliyordu
- Gerçekte işin büyük bir kısmı insanların sosyal gerilimlerini ve psikolojik kaygılarını debug etmek
- Örnek durum:
- Junior bir mühendis, özellik önizlemesini deploy etmek için birkaç testi yorum satırına aldı
- QA sorumlusu, ekibin QA rolüne ve değerine saygı duymadığını hissedip çok öfkelendi
- Yönetici güveni yeniden inşa etmek zorunda kaldı
- Başka bir örnek:
- Proje yöneticisi başarısız bir şaka yaptı ve tasarımcı kırılıp ağladı
- Yönetici, PM’in özür dilemesini sağlamak zorunda kaldı
- Psikolog olmadığı ve insanlarla özel olarak çok iyi olmadığı için bu kısım zor; alışana kadar dayanma sürecine daha çok benziyor
-
Offline olmanın zor olduğu bir iş yapısı
- Mühendis hayatı görece rahat olabilir
- Acil bir iş yoksa yarım gün dışarıda dolaşıp projenin geleceğini düşünebilir, bazı toplantıları da aniden kaçırıp büyük sorun yaşamayabilirsiniz
- EM birkaç saat yerinde olmazsa mesajlaşma uygulamasında sorunlar birikir
- Stajyer
npm installyapmayı unutup işine devam edemez - Kıdemli yönetici, potansiyel bir özelliği konuşmak ister
- Release raydan çıkar
- Stajyer
- Kendisinin yürüttüğü veya organize ettiği toplantıları önceden hazırlık yapmadan atlamak zordur
- Ekip olgunlaştıkça ve süreçler iyileştikçe bu durum düzelebilir ama genel olarak yöneticiler ofis saatlerini daha yoğun hisseder
- İş-yaşam dengesi doğrudan kendi işi ne kadar iyi yaptığınıza bağlı hâle gelir
-
Geri bildirim döngüsünün uzun ve doğrusal olmaması
- Mühendislik işlerinin çoğunda sonuçlar nispeten hızlı görülür
- Yeni bir özellik birkaç hafta ila birkaç ay içinde sonuç verir, bir bug’ı düzeltince ertesi gün kullanıcı tepkisini görebilirsiniz
- Refactoring yaptıysanız, karmaşıklığın azaldığını birkaç saat içinde fark edebilirsiniz
- Yöneticinin davranışları ise bir ay içinde görünür sonuç üretmeye çok nadiren başlar
- Ekip fazla büyümüşse bölmek için birçok adımdan geçmek gerekir
- Yeni ekip için uygun mühendis dağılımını belirlemek
- İlgili kişilerle değişime dair duyguları konuşmak
- Yeni düzenli toplantılar oluşturmak
- Süreç ve iletişimi kurmak
- Jira ile ilgili işleri halletmek
- Gerekirse alt ürünün codebase’ini ayırmak
- Bunları bir haftada bitirebileceğinizi düşünüyorsanız, yanılıyorsunuz
- Doğru değişiklikler bile iyiye gitmeden önce durumu kötüleştirebilir
- Ekipte kişi eksiği varsa işe alım kararı kısa vadede daha çok görüşme yükü doğurur; yeni gelen ekip üyesi de hemen hız kazanamayacağı için onboarding zamanı gerekir
- Yönetim değişiklikleri, hızlı problem çözmekten çok büyük ölçekli bir refactoring gibidir; anında iyileşme görünmediği için sinir bozucu olabilir
Geçişi düşünen mühendislere
- IC mühendisten yöneticiliğe geçmek, hem aydınlık hem karanlık tarafları olan bir roller coaster deneyimi gibidir
- Avantajları; ürün ve ekip üzerinde daha geniş etki, uzun vadeli kariyer yolunda daha fazla fırsat ve esneklik, teknik alanda sıkılınca yeni bir meydan okuma sunmasıdır
- Dezavantajları ise kurumsal politikaları uygulamak, sosyal gerilimleri ve psikolojik kaygıları yönetmek, offline olmanın zor olduğu bir iş düzeni ve çok gecikmeli tatmin ile uzun geri bildirim döngüleridir
- Zorluklardan ve sorumluluktan keyif alıyor ve fırsatınız varsa denemeye değer
- Yöneticilik herkese uygun değil ama teknik kapsamınızı genişleten ve mühendislik işine yeni bir açıdan bakmanızı sağlayan bir deneyim olabilir
- Tam size göre değilse, yeniden kod yazmaya dönmek için hâlâ bolca zaman vardır
1 yorum
Hacker News görüşleri
FAANG'da iki kez olmak üzere dört kez yöneticilik yaptım ama asıl yazıyla aynı fikirde olmadığım çok nokta var
Yönetici kademesi aslında daha yüksek değil ve çoğu mühendislik yöneticisi L6/staff engineer seviyesine denk bir yerde toplanıyor. Senior manager ve üzeri terfiler duruma çok bağlı ve nadirken, mühendislik hattındaki meslektaşlar hazır olduklarında yıldızların hizalanmasını beklemeden terfi ediyor
Tamamen mühendislik yöneticisi olarak kalıp işten çıkarılanlar hâlâ iş arıyor ve çoğu pes etmenin eşiğinde, ama IC'ye geri dönmesi mümkün olanlar genelde iş bulmakta büyük sorun yaşamıyor. Şirketlerin yönetim kültürü çok farklı olduğu için doğrudan taşınabilir değil; bu sektörde en taşınabilir becerinin Linux iç yapısı olduğunu düşünüyorum
5 yıllık deneyimle çoğu sorunun çözülebileceği fikri de tuhaf geliyor. 18 yıldır bu işi yapıyorum, hâlâ bilmediğim ve geliştirmem gereken çok şey var; 40 yıllık deneyime sahip harika mühendisler bile öğrenmeye devam ediyor
Yöneticiliğin en iyi yanı, geleceği düşünmeye çok zaman ayırmak ve C-level ile konuşulan “o odaya” girme ihtimalinin artması. Aynı zamanda kararların nasıl alındığını fazla net görmeye başladığın için en kötü yanı da bu
Asıl yazının sevmediği kısımlara katılıyorum ama zamanla düzeliyor. Yine de yeni bir yöneticiysen, muhtemelen henüz en nefret edeceğin noktayı yaşamamışsındır: birçok şirkette üst yönetimin lise klikleri gibi davranması ve VP, C-level, bazen de direktör düzeyindeki davranış sorunlarının, sıradan bir çalışan yapsa işten çıkarılacağı hâlde tolere edilmesi
Çoğu yazılım mühendisi senior seviyesinde takılıyor; özellikle Google'da bu daha da belirgin, dolayısıyla L6'da toplanmak başlı başına göreli bir ayrıcalık. L6 terfisi aşırı nadir değil ama çoğunluğun aldığı bir şey de değil; L7 ve üzeri ise zor. Etrafındaki çoğu kişinin doğal biçimde oralara çıktığını düşünüyorsan, ya terfi edemediği için ayrılanları hesaba katmıyorsundur ya da senden daha düşük seviyedeki insanlarla yakınlaşma fırsatın az olmuştur
Mühendislik yöneticiliği yolunun eskiden düşünüldüğü kadar çok kapı açmadığına katılıyorum ama terfi fırsatlarının IC'ye göre daha dar göründüğünü düşünmüyorum
0'dan 1'e bir şey çıkarmanın mühendislik yönetimiyle neredeyse ilgisi yok. En önemli şeyler hızlı kod yazabilmek ve potansiyel müşterilerle rahat konuşabilmek; ikisi de mühendislik yöneticisi rolüyle doğrudan bağlantılı değil. Üstelik yönetecek insanları işe alacak noktaya geleceğinin de garantisi yok
Yönetim pozisyonları yapısal olarak mühendislik rollerinden çok daha az ve lead engineer ile birinci kademe yönetici arasındaki sınır iki yönde de epey bulanık, dolayısıyla gerçek rekabet havuzu da o kadar küçülmüş olmuyor
Taşınabilir denmesi, büyük teknoloji balonunun dışında da işe yarayan beceriler anlamına geliyor. Para iyi olduğu için dışarı çıkmak istemeyebilirsin ama bilgisayarları bipletmek dışında da yapabileceğin şeyler olduğunu bilmekte fayda var
Mesela “daha fazla test yapmalıyız” sözünün, bunu bir IC yerine mühendislik yöneticisi söylediğinde daha ciddiye alındığı düşüncesi böyleydi
Aslında ben de staff seviyesine yeni terfi etmiş bir IC iken yeterince güvenilir görülmediğimi hissediyordum; bu yüzden unvanın arkasına saklanmanın yardımcı olacağını düşünüp yönetime geçmeye çalışmıştım. Gerçekte buna gerek yokmuş ve şimdi başka bir şirkette IC olarak fikirlerim ve geri bildirimlerim hem organizasyon düzeyinde hem de meslektaşlarım tarafından ciddiye alınıyor
Her yarıyılda zorunlu sıralama yapıp düşük performans gösteren birini seçmeyi gerektiren sistem bozuk bir yöntem. Birçok yerde performans yönetiminin böyle üzücü bir gerçekliği var ama bir yönetici olmanın zorunlu ve evrensel gerçeği bu değil. Gerçek performans sorunlarıyla ilgili zor konuşmalar istatistiksel olarak kaçınılmaz olabilir, ama “bu yarıyılda ekipte herkes senden daha iyi performans gösterdi” ya da “birini seçmek zorundaydık, bu kez sana denk geldi” demek zorunda olmadığın şirketler de var
Ben sorun çözmeyi ve büyük resmi seviyorum; çözüm bulmayı ve engelleri aşmayı seviyorum. Bana en uygun rol “mimar”dı, ama bu unvan sanki ortadan kalkıyor gibi görünüyor. Yine de bu işin gerekli olduğu gerçeği değişmiyor
Takım lideri/menajer, Scrum Master ve ürün yöneticisi rolleri de yaptım ama iyi bir menajer için gereken beceriler bir mühendisin becerilerinden çok farklı. Özünde gereken şey aşırı düşük nevrotiklik, yani uzun süreli stres altında bile iyi karar verebilmek ve sakin, mantıklı bir dış görünüşü koruyabilmek
Alt kademe yöneticilerin %90’ında bu özellik yok ve stres altındayken takımı da şirketi de bozuyorlar. Menajer olmak istiyorsanız, uzun süren strese nasıl tepki verdiğinizi dürüstçe değerlendirmelisiniz. Çevrenizdekilere öfkelenip öfkelenmediğiniz, içinize kapanıp donup kalarak karar veremediğiniz ya da başkalarını suçlayıp kendi itibarınızı korumaya çalıştığınız gibi sıkıcı görünen unsurlar, etkili menajerlerle geri kalanlar arasındaki gerçek farkı oluşturuyor
Genellikle bunun içinde herkesin kaçındığı sorunları gündeme getirmek, insanların benim kararlarımdan topluca şikâyet etmesine izin vermek ve karşı taraf ilgisini kesip sizi itmeye çalışsa bile işin içinde kalmayı sürdürmek gibi eğlencesiz işler var
Bana göre yöneticilik, sahip olduğum tüm kaşıkları istemekle kalmayıp daha fazlasını da istemek gibi hissettirdi. Ama bunun yöneticiliğin özünden çok, benim ona uygunluğumla ilgili olduğunu düşünüyorum. İnternet testlerine göre nevrotiklik düzeyim orta seviyede, ama “yeterince iyi”de durmakta zorlanıyorum ve yöneticiliğin genişleyen sorumluluk alanının duygusal açıdan bir ölçeklenebilirlik sorunu yarattığını hissediyorum
Crunch ve tükenmişliği çözmenin anahtarı, çalışanların tüm geçiminin — sağlık, kira, devlet üniversitesi öğrenim kredisi geri ödemeleri gibi şeylerin — tek bir işi sürdürmeye bağlı olmamasını sağlayan bir düzenleyici ortam yaratmak olabilir
IC iseniz yeni teknolojiler veya alanlar öğrenerek kariyerinizi büyütebilirsiniz, ama menajerler için kariyer gelişimi giderek olgunluk, bakış açısı ve duygusal dayanıklılık gibi kişisel gelişimlere bağlanıyor. Kıdem arttıkça mindfulness meditasyonu gibi şeylere ilginin artmasının nedeni de bu olabilir
HN bundan hoşlanmayacaktır ama ben de bekâr olmama rağmen, ebeveynlerin daha iyi menajer olup olmadığını merak ediyorum. Belki de büyük resimde önemli olmayan şeyler yüzünden perspektiflerini kaybedip strese girme olasılıkları daha düşüktür. Garip şekilde, yöneticiliği duygusal olarak bir adım geri çekildiğimde en iyi yaptığımı düşünüyorum
Görünüşe göre ben mizaç olarak epey hassasım ve kişisel olarak yöneticilik için yapısal olarak uygun olmayabileceğimden endişe ediyorum. “İnsanları yönetmiyorsun, motive ediyorsun” gibi zaman zaman ikiyüzlü gelen yönü de zorlayıcı. Ben sadece organizasyondan organizasyona dolaşıp sorunları çözmek, süreçleri sadeleştirmek ve iş sistemlerini yeniden kurmak istiyorum
12 yıldır yazılım mühendisiyim ama menajer olma isteğim hiç yok. Ben sadece bir şeyler üretmek istiyorum, yönetmek değil
Menajerlerle yakın çalışıp ne yaptıklarını görüyorum ama bana hiç çekici gelmiyor. Kıdemli mühendis olarak benim sözüm de sık sık etkili oluyor ama menajerlerin taşıdığı devasa sorumluluk bende olmadığı için memnunum. Hayatıma daha fazla stres eklemek istemiyorum
Muhtemelen önümüzdeki 30 yıllık kariyerimde de bugünkü gibi bir rolde olurum
Birkaç yıl önce ben de benzer durumdaydım. Yöneticim beni seviyordu ve iyi bağlantıları vardı; benimle her türlü bilgiyi paylaşıyor, beni karar toplantılarına oturtuyor, yön konusundaki görüşümü soruyor ve gerekirse kendi yerine ya da başka menajerler karşısında konuşsam beni arkadan destekleyeceğini söylüyordu
Şimdi ise tamamen yeni bir yönetim yapısı geldi ve çok tepeden inmeci, egosu yüksek ve geri bildirimi kabul etmeye isteksiz. Sesini çıkaran alt kademe yöneticiler ve mühendisler sürekli kenara itildi; benim sahip olduğum özerklik ve söz hakkı da neredeyse yok oldu
Mühendislik kararı olduğunu düşündüğüm pek çok şey bile elimden alındı. Geliştirdiğim hizmette X’e ihtiyaç vardı, bu yüzden otomatik bir çözüm geliştirdim ve gayet iyi çalışıyordu; ama birkaç ay sonra X için başka planlar olduğu söylenerek hata yaptığım bildirildi ve tamamen otomatik çözümü silip başka bir ekibin manuel kurumsal süreciyle değiştirmem istendi. Bu iş sık sık aksadığı için hizmetimin güvenilirliği düştü
Böyle insanlarla savaşmak zorunda olan menajer ben olmadığım için mutluyum. Öyle olsaydım muhtemelen şimdiye kadar işimi kaybetmiş ve onların arkadaşlarından biriyle değiştirilmiş olurdum. Yine de kıdemli bir mühendisin etkisi, aynı şirket ve takım içinde bile uzun vadede çok değişebilir
Yönetim sorumluluğu olmayan ya da çok az olan daha üst teknik roller de var. Staff/Principal mühendis, mimar gibi roller bulunuyor ve bu biraz da şirketin size ne kadar değer verdiğine bağlı
Gördüğüm en iyi örneklerden biri, doktora derecesi ve onlarca yıllık deneyimi olan bir mühendisin araştırma/mimari gurusu olarak çalışmasıydı; ekibi ya da doğrudan bağlı çalışanı yoktu, bol bol Matlab kullanıyordu ve yüzlerce kişilik bir şirkette “VP of technology” unvanını taşıyordu
Zor olan şey öğrenmenin kendisi ya da insanlar değil, bunun etrafındaki koşullar. Yöneticilik perspektifi edinmek, neyi neden yaptığınızı ve işlerin neden verimsiz ve bozuk göründüğünü anlamakta çok faydalı. Ayrıca çözüm yolları ve düzgün aktarılmayan bağlam hakkında da içgörü kazandırıyor
Şu anda kıdemli bir geliştiriciyim ve bir startup'ta takım lideri pozisyonu için mülakat sürecindeyim. Teknik olarak güçlü olduğumu düşünüyorum ama günlük hayatta beni en çok zorlayan şeyler takım çalışmasıyla ilgili problemler
Güven eksikliği, birbiriyle konuşmak istemeyen ekip arkadaşları, yetersiz işleri yapıp geçmelerine göz yumulmuş diğer kıdemliler, net bir takım amacı ve ürün vizyonunun olmaması, ortak mühendislik pratikleri konusunda uzlaşma eksikliği gibi şeyler. İnsan yöneticisi olunca, iyi ya da kötü, bu sorunlar benim etki edebileceğim ve sorumluluk alacağım alanın içine giriyor
Ama gerçekten takım lideri olunca, etki alanımın sandığımdan çok daha küçük olduğunu gördüm. Patronum da dahil olmak üzere her şeyi bizzat yönetmek isteyen çok insan var ve benden sadece onay damgası basmam bekleniyor
Hatta ekipteki insanların söylemeye korktuğu şeyleri benim dile getirmem gerektiği için daha da zor oluyor. Mesela “bir hikâyenin hazır sayılması için API'nin tanımlanmış olması gerekir” demek gibi. Ne test edileceği bile bilinmiyorken QA paralel şekilde otomasyon testlerini nasıl hazırlayabilir?
Scrum Master, ürün sahibi, yönetici ve mimarlar o gün işlerine gelen şeyi apaçık bir gerçekmiş gibi söylüyor, ertesi gün de testler neden gecikti diye şikâyet ediyor
Sonunda iş, mevcut durumun sorumlusunun kim olduğu siyasetine dönüyor ve o yönüyle stratejiyi seçenler de genelde bağlantıları güçlü ve suçu başkasına atmakta başarılı kişiler oluyor
Eskiden, o zamanki patronum başka bir departmandan birine iş yaptırmak için telefonla başarılı bir ricada bulunduktan sonra odasında duruyordum
Patronum masasından bana bakıp hafifçe gülümsedi ve şaşkın bir tonda, “Unvanımın ‘Specialist’ten ‘Manager’a dönüşmesi beni daha güzel yapmadı ama işleri oldurmak konusunda kesinlikle yardımcı oluyor” dedi. Unvanın gücünün gerçekten çalıştığı an buydu
Yönetici, gerçek bir yaptırım tehdidi olmadan kolayca görmezden gelinebilir ve böyle kartları dikkatli kullanmak gerekir
Birkaç yıl önce küçük bir startup'ın CTO'su olarak mühendislik yöneticiliğine başladım ve hayatım çok değişti. Asıl yazıda sevilen ve nefret edilen her şeye karşı aynı duyguları hissediyorum
Ek tavsiyem gerçekten meditasyon yapmanız olur. İnsanlara zarar verebilecek önemli ve etkili kararlar almadan önce, beyniniz kapanacak kadar uzun süre sessizce oturmanız gerekir
Başta bu biraz ebeveyn-çocuk dâhi ilişkisine benziyor. İnsanları kabul etmeli ve onların yöntemlerini anlamalısınız. Ne kadar çok kontrol koyarsanız, gerçekte o kadar az kontrolünüz olur. İnsanlar gereksiz bürokrasiyi aşmaya ve ona direnmeye çalışır; dürüst olmak gerekirse ben de aynısını yapardım
İkinci tavsiyem, her zaman yarın ayrılacakmış gibi davranmanız. Böylece ekip ve iş arkadaşlarınız hazırlıklı olur, sizin yaşam tarzınız da iyileşir
Gerçekten çok hızlı gelişiyorlar ve organizasyonun ben olmadan da işlediğini görmek tuhaf biçimde rahatlatıcı oluyor. Aynı zamanda ben yokken daha hızlı geliştiklerini görmek, acaba yanlış bir şey mi yapıyorum diye düşündürüyor
Bazı günler işte öğrendiğim becerilerle ailemi yönettiğimi hissediyorum
Benim geçmişim bunun tersi. Sıradan bir yazılım mühendisiyim ama insanlarla çalışma becerim oldukça iyi
Neyin zaman aldığını ve sistemin hangi kısımlarının daha önemli olduğunu anlayacak kadar deneyimim var. Gerçekten dikkatle dinleyen ve çok güven ile yetki veren birkaç kıdemli mühendis var
Tasarım kararlarını ben değil onlar veriyor, ben de görüş ekliyorum. Başarısız olursa sorumluluk alıp ders çıkarıyorum, başarılı olursa takıma pay çıkarıyorum. Mütevazı biçimde söylemek gerekirse, yöneticilik rolü her şeyden önce insanlarla ilgili bir iş
Kodlayıcı/IC rolünden yönetim hattına geçmek istememin tek bir nedeni var: iş değiştirirken her seferinde gereken whiteboard mülakatları
Neredeyse acı verici olacak kadar baştan hazırlanmak gerekiyor ve bu sürecin olmadığı roller var ama çok nadir. Sırf o hazırlığı düşününce “ah, lütfen yine mi?” deyip aynı işte kaldığım çok oluyor
Kötü bir mühendislik yöneticisi, kötü bir IC'den çok daha büyük zarar verebilir. Bunun yeterince sık konuşulmadığını düşünüyorum
Uzun kariyerim boyunca 1 harika yönetici, birkaç idare eder yönetici ve çok sayıda berbat yöneticiyle çalıştım. Berbat yöneticiler işi çok daha zor, bazen de tamamen perişan edici hâle getiriyor
Kötü bir mühendislik yöneticisi ile junior bir IC kombinasyonu özellikle çok kötü olabilir. Yaş aldıkça, kötü bir yöneticiyle de çalışıp durumu daha iyi bir yöne çekebileceğinizi ya da umut olmadığını hissederseniz ayrılabileceğinizi öğreniyorsunuz
Bu aralar benim de yönetim sorumluluklarım arttığı için bilmek istiyorum
Bir zamanlar doktora dereceli IC'lerden oluşan bir ekibe liderlik ettim. Onlara iş bulmam, hayalperestleri engellemem ve mutlu kalmalarını sağlamam gerekiyordu
Şaka değil, bazen tek seferde altışar saat bire bir konuşup kariyer danışmanı ve teselli edici rolü üstleniyordum. Bunun işimin bir parçası olacağını hiç düşünmemiştim
Ekip üyelerinden biri ayrı iki adet 1 milyar dolarlık sözleşmenin alınmasına yardımcı olduysa, demek ki harcadığım zaman karşılığını verdi