Profesyonel olarak yazılım geliştirmeye başladığımda etrafımda gerçekten çok iyi yazılımcılar vardı. En azından o zamanki bilgimle yaptığım bir çok hatada bana yardımcı oldular, hatta öyle ki basit bir XML parser yazarken bile haftalarımı almasına göz yumarak benim hata üzerine hata yapmama izin verdiler. Sonrasında her zaman gittiğim firmalarda rol model alabileceğim yazılımcıların olmasına hep dikkat ettim.

Bir yazılımcı olarak kendinizi geliştirmeniz için size neden yanlış yaptığınızı söyleyecek, sizden daha tecrübeli yazılımcıların olması çok önemli. Özellikle uzmanlaşmak istediğiniz alanda bulabildiğiniz rol modellerle çalışmak sizin ilerlemenize inanılmaz bir katkıda bulunuyor. Ancak kariyerinizde yazılımcı olarak ilerlediğinizde bir noktada, siz firmadaki “o” yazılımcıya dönüşmeye başlıyorsunuz. Durum böyle olduktan sonra da kendinizi ilerletmek, bir üst seviyeye geçmek gerçekten çok güçleşiyor. Özellikle küçük firmalarda çalışıyorsanız bu sorun önünüze daha hızlı çıkıyor. Bu gibi durumlarda daha iyisinin nasıl olduğunu size gösterecek kaynaklara ihtiyacınız oluyor.

Bültenin bu yazısında size bu sorunla ilgili yol gösterecek bir kitabı tanıtmak istiyorum. Bu bölümdeki kitabımızın adı “Staff Engineer: Leadership beyond the management track”. Kitabın yazarı da blog yazılarından ve önceki kitabı olan “An Elegant Puzzle: Systems of Engineering Management”’tan tanıdığımız Will Larson. Bugün inceleyeceğimiz kitabı oluşturan makalelerin bazılarını internetten ücretsiz bulmak mümkün olduğu gibi kitabı alarak daha fazla detaya ulaşmanız da mümkün.

Larson’un bu kitapta ulaşmak istediği kitle yazılımcılar. Önceki kitabında yöneticilere hitap ederken bu sefer kariyerinde ilerlemek isteyen yazılımcılara odaklanmış. Kitap içerisinde hemen iş hayatına uygulayabileceğiniz tavsiyeler ve tecrübeler var. Aynı zamanda kitap içerisinde bu rolde çalışan profesyonellerle yaptığı görüşmeler ve o kişilerin nasıl o rollere ulaştığı ile ilgili güzel hikayeler de bulunuyor.

Kitap başlangıçta Staff Engineer rolünü tanıtarak başlıyor. Ancak tecrübeli olanlar bilecektir, staff engineer denilen rol bir çok farklı firmada farklı isimlerle kullanılıyor. Hatta firmaların ihtiyaçlarına, yaptıkları işe, firmanın dinamiklerine göre de şekillenen bir rol bu. Bu yüzden yazar burada öncelikle 4 farklı arketipten bahsediyor. Bunlar kitapta anıldığı şekliyle aşağıdaki gibi tanıtılıyor.

Teknik Lider:
Mimar
Sorun çözücü
Üst düzey yöneticinin sağ kolu

Tüm kitapta da bu arketipler ve aralarındaki farklılıklara vurgu yapıyor. Bu tanımları oturttuktan sonra da Staff Engineer için belirlenen çıtayı tanımlıyor. Bence kitabın etkili olduğu yerlerden birisi de burası. Bu konuyla ilgili yaşadığım sorunları yazının ilerisinde tartışmak üzere not alıyorum. Ancak burada güzel olan birebir gündelik profesyonel hayatınıza uygulayabileceğiniz güzel örnekleri barındırması. Bu bölümü okuduktan sonra aklınızda Staff Engineer rolüyle ilgili güzel bir tanım kalıyor. Bu bence çok önemli çünkü eğer neyi hedeflediğinizi ve bu hedeflediğiniz rol için gereken minimum çıtayı bilirseniz hem kendi seviyenizi daha objektif bir şekilde değerlendirebilirsiniz, hem de eksikliklerinizi daha iyi görerek hangi alanlarda kendinizi yetiştirmeniz gerektiğini keşfedebilirsiniz.

Gelin bu kısmı biraz daha açalım.

Staff Engineer rolü çoğunlukla karşımıza orta ya da büyük ölçekli firmalarda çıkıyor. Türkiye’de bir çok farklı firmada yazılım mimarı gibi rolleri görürken büyük teknoloji firmalarında (FAANG) ise Staff Engineer ya da Principal Engineer rollerini görüyoruz. Bu konuda Gergely Orosz’un güzel bir paylaşımına denk geldim ki paylaşmadan edemeyeceğim.

Bu alıntıda Gergely, Yazılım Mimarı pozisyonunun yenilikçi firmalarda olmamasının tesadüf değil, tasarım gereği olduğunu söylüyor. Gerekçe olarak da bu rolün ekiplerdeki diğer yazılımcıları yetkilendirmeyi olumsuz etkilediğini, kararlara dahil olmalarına bir engel olduğunu söylüyor ve bu isimlendirme değişikliğinin önemine vurgu yapıyor.

Peki o zaman, nedir bu Staff Engineer?

Bir çok firmada farklı görev ve sorumlulukları olabilir ancak ben çoğunlukla karşılaşılan tanımına göre bir tanım yapmaya çalışacağım ve kitaptaki örneklerden bahsedeceğim. Staff engineer, çoğunlukla, senior engineer rolünden sonraki kariyer adımında yer alıyor. Senior staff engineer ve sonrasında da çoğu zaman principal engineer rolü geliyor. Kimi firmalar senior engineer sonrasında principal engineer rolünü de kullanıyorlar. Ancak genellikle büyük teknoloji firmaları için konuşursak staff engineer, senior engineer rolünden bir sonraki kariyer adımıdır diyebiliriz.

Bunu bu kadar basit bir şekilde özetlemiş olsak da çoğu zaman bir çok kişi bu tarz firmalarda staff engineer rolüne gelmeden önce senior engineer rolünde uzun süre kalabiliyorlar. Çünkü bu geçiş genellikle hem bakış açısı tarafından hem de çoğu zaman kişinin organizasyonda yarattığı etki açısından ciddi farklılıklar gösteriyor. Buna şimdilik İngilizce bir terim olarak “Sphere of Influence (SoI)” ya da Türkçesiyle “Etki Alanı” diyelim. Örneğin bir senior engineer’ın etki alanı kendi takımı iken, staff rolüne geçtiğinde etki alanı grup, organizasyon ya da firma seviyesinde olabiliyor. Bu durum haliyle o kişinin kimlerle “networking” yaptığını da etkiliyor. Küçük firmalarda, staff engineer çoğunlukla CxO seviyesinde bir iletişim ağına sahipken, firmalar büyüdükçe bu Group Engineering/Product Manager seviyesinde olabiliyor. Ancak eğer senior engineer için “networking”’i düşünürsek, o zaman etki alanı genellikle takımındaki yazılımcılar, diğer takımlardaki yazılımcılar, takım lideri, takımın Product Manager’ı ya da Engineering Manager’ı olabiliyor.

Bu farklılıkları düşündüğümüz zaman, Staff Engineer rolünün gündelik iletişimde olduğu kişilerin gerek tecrübesi gerekse de yetkinlikleri açısından bakarsak, teknik yetkinliğinin yanı sıra, iletişim ve liderlik becerilerinin de gelişmiş olması gerekiyor. Yani buradan yakalayabileceğimiz birinci önemli ipucu; Liderlik ve Güçlü İletişim becerisi/tecrübesi.

İletişim becerisi dediğimizde bu tanımın altını da doldurmak gerekli elbette! Benim gördüğüm en efektif staff engineer’ler, bir sorunu ele alırken farklı açılardan bakabiliyor, avantaj ve dezavantalarını ürünün başarısıyla ilişkilendirip bir şekilde sonuçlarıyla anlatabiliyorlar. Yani bunu bu şekilde yaparsak, sonucunda şu kadar kazanç sağlarız ya da ekiplere şöyle bir katkısı oluru güzelce anlatabiliyorlar. Yeterince ayakları yere basmadı değil mi? Gelin bir örnek üzerinden gidelim.

Diyelim ki ekibin ürün yöneticisi ekibe yaptığı çalışmalar sonrası keşfettiği bir fırsatla geldi. (Fırsat ve hedef konusunu gelecek bölümlerde farklı kitaplarla ele alacağım.) Ekip de bu ürün fırsatını değerlendirmesi için gereken çözümü aramaya koyuldu. İşte bu aşamada ekibin “scoping” dediğimiz süreci başlamış oldu. Scoping aşamasında ekip kapsamı, ellerindeki çözüm yöntemlerini inceledi ve 3 tane alternatif oluşturup tartışmaya koyuldular. Diyelim ki çözümlerden biri ekip tarafından destek görüyor ve çoğunlukla ikna olmuş durumdalar. Ancak bunun sonucunda platformun performansı da etkilenecek. Bu durum, ekip seviyesinde basit bir şekilde “bunun performans sorunları olacaktır” diyerek geçilebilir. Eminim ekip içerisindeki herkes bunun ne demek olduğunu çok iyi bir şekilde de anlayacaktır. Ancak bunu ekibin dışındaki paydaşlara anlatmak istediğinizde bunun sonuçlarını daha iyi anlatmanız gerekir. Çünkü muhtemelen ürün ekibinin paydaşları teknik kişiler olmayacaklardır. Dolayısıyla onlara teknik metrik ve yöntemlerden bahsedemezsiniz. Mesela, bu performans sorunu yıllık ciroya etki yaratacak mı? Ya da ekip bu sorunu ne kadar geç çözmeli? Bu durumda ekip bu geliştirmeye başlarken bu sorunu çözerek mi başlamak istiyor? Eğer öyleyse bunun nedeni nedir? Her ne kadar bu örnekte bir staff engineer rolü olmasa da, ekipteki teknik liderin bu sorunu etkileriyle anlatması, ekibin yaratacağı etki için çok önemli.

Gelin şimdi biraz daha geniş kapsamlı bir problem düşünelim. Bir ya da birden fazla ekibin üretkenliğini etkileyen bir problemle karşılaşıldı ve farklı ekiplerdeki yazılımcılar sorunu çözmenin bir yolunun uçtan uca testlerden vazgeçilmesi olduğunu düşünüyorlar. Bu durumda bu probleme teknik olarak liderlik sağlayacak birisinin olması gerekiyor. Bu kişinin aynı zamanda böyle bir yatırım yapılacaksa bunun sebeplerini, paydaşlara anlatarak onları ikna etmesi de gerekiyor. Bu gibi bir durumda bu liderliği bir senior engineer’ın da üstlenmesi mümkünken bu durum ekibin problemi olmaktan çıkmış ve daha büyük bir soruna evrilmiş duruyor. Dolayısıyla konuya daha yukarıdan bakabilecek teknik bir kişiye ihtiyaç olabilir. Mesela bir Staff Engineer! Bu ölçekte bir problemi çözmek için sahip olunması gereken yetkinlikler de senior engineer rolüne göre daha farklı. Öncelikle ekipler arasında uzlaşma yaratabilmeli dolayısıyla iletişim becerileri güçlü olmalıdır, bunun için de ekibi aktif bir şekilde dinleyip onların fikirlerini sınayabilecek teknik yetkinlikte olmalıdır. Sonrasında da firmanın hedeflerini anlayıp, burada farklı alternatifler üretebilmesi ve nihayetinde de bunları bir şekilde farklı seviyelere, onların anlayacağı şekilde anlatabilmelidir.

Staff engineer’den çok mu şey bekliyoruz sizce? Bence evet, bu yüzden de bu rol gerçekten zor doldurulan bir rol.

Çalıştığım bir çok yerde bu rolü doldurmak her zaman sorun olmuştu. Fakat gördüğüm en büyük problem her zaman bu rolün tanımını yaparken kesin kalıplara oturtmaya çalışılmasıydı. Çünkü her firmanın içinde bulunduğu dinamiklere göre bu rolün kapsamı ve etkisi ciddi farklılıklar gösterebiliyor. Örneğin, orta ölçekli bir startup’ta bu roldeki bir kişiden beklenti, ortak yazılım standartlarını uzlaşmacı bir şekilde belirleyip gelecekteki sorunlara hazırlık yapmakken, scale up ya da hypergrowth aşamasındaki bir startup için liderlik ve mühendislik kültürüne odaklanmak olabilir. Dolayısıyla bu rolden beklenti zaman içerisinde değişeceği için rolün tanımından çok iletişim, liderlik ve teknik yetkinliklerini iyi tanımlamak rol için gereken çıtayı belirlemek için daha sağlıklı olacaktır.

Bir senior engineer nasıl staff engineer olabilir?

Son 4 yıldır çalıştığım bütün startup’larda her zaman bu büyük bir sorundu. Ne kadar çabalasak da her zaman bu rolün ne olduğuyla ilgili net bir açıklama yapamamak ekiplerdeki yazılımcıları her zaman bir bunalıma itti. Neden mi? Anlatayım.

Bir senior engineer, firmada 2 yıla yakın zaman geçirdikten sonra kariyerinde bir ilerleme beklemeye başlıyor. Yanlış anlamayın, bence çok yerinde bir beklenti bu. Çünkü bu adımdan önceki yılları düşünürsek, kariyerinin başında terfi almak çok basitken, ilerleyen yıllarda rollerden beklentiler artacağı için bunlar daha zor olmaya başlayacaktır. Örneğin üniversiteden mezun olan ve kariyerinin başındaki bir yazılımcı, bir yerde çalışmaya başladığında muhtemelen 1-2 yıl içinde terfi alıp orta seviye bir yazılımcı olacaktır. Benzer şekilde orta seviye bir yazılımcı da eğer hızlı öğrenip uygulama fırsatını yakalarsa 2-3 yıl içerisinde senior rolüne gelecektir. Ancak bundan sonrası biraz daha engebeli. Çünkü bundan sonra senior engineer’ın önünde genelde iki yol oluyor.

Yöneticilik Yolu
Bireysel Katılımcı (Individual Contributor - IC) yolu.

Genelde senior engineer’den sonraki adım IC yolunda ya principal ya da staff engineer oluyor. Bu durumda da haliyle yazılımcıların hedefi o role geçmek haline geliyor.

Typical dual-track engineering career ladder — Kitapta bahsedilen ve benim de alışkın olduğum yazılımcı kariyer yolu.

Burada iki farklı grubun da hatalarına çok fazla tanık oldum.

Görevleri ya da günlük sorumluluklarını çok iyi yaptıklarında hemen bir sonraki seviyeye geçmeleri gerektiğini düşünen senior engineer’lar.
IC kariyer yolunda maaş aralıklarını dar tutan ve yazılımcılara havuç olarak terfiyi gösteren yönetici ya da firmalar.

Grup 2’nin bir temsilcisi olarak açık yüreklilikle söylemeliyim ki, bu hatayı çok kere yaptım ve sonuçlarını da ağır bir şekilde yetenekli yazılımcıları kaybederek ödedim. Ancak diğer taraftan, Grup 1’in beklentilerini iyi bir şekilde yönetmek de çok önemli tabii ki. Bu yüzden yazılımcılara terfi etmenin tek motivasyon ve daha fazla para kazanma yolu olmadığını çok iyi anlatmak ve farklı şekillerde de onları ödüllendirerek kariyerlerinde ilerlemelerini sağlamak bir yönetici için gerçekten çok önemli.

Peki madem bu role geçiş yapmak çok zor ve zaman alıyor, o zaman nasıl ilerlemeliyim?

Öncelikle kariyerinizde ilerleyip bir staff engineer olmanız kolay değil. Bunu kabullenmeniz lazım. Orta seviye bir yazılımcının belki 10 yıl boyunca aynı seviyede kalması kötü bir durum olsa da, senior engineer’ın 10 yıl boyunca senior olarak kalması aslında sorun değil.

Eğer ileriye gitmek istiyorsanız öncelikle konfor alanınızın dışına çıkmayı göze alıp, toplantı yönetmek, uzun bir doküman yazarak ya da beyaz tahta karşısında diğer yazılımcıları ikna etmek, başka yazılımcıların yazdığı dokümanlara yorumlar yaparak ya da toplantılarda fikirlerini sınamak gibi daha önce deneyimlemediğiniz şeyleri yapmaya da hazır olmanız lazım. Eğer bunlar benim karakterime uygun değil diye düşünüyorsanız, üzgünüm ama bilim tam aksini söylüyor. New Scientist’te yayımlanan Miriam Frankel’in makalesine göre sanılanın aksine içe dönük kişilerin dışa dönük birine bilinçli bir şekilde dönüşmeleri bile mümkün. Makalede yapılan araştırmalara göre bunun için alışkanlıklarınızı gözden geçirip, bunları ufak iterasyonlarla değiştirmenizin mümkün olduğundan bahsediyor.

Benim tecrübeme göre bunu başarmak bakış açınızı ve düşünme şeklinizi değiştirmekten geçiyor. Kariyerimde bir üst seviyeye çıkmayı hedeflediğimde her zaman “Şu anda bir sonraki rolde olsaydım nasıl davranırdım?” diye düşünmeye çalışıyorum ve vereceğim tepkiyi ona uyarlayıp kendimi bir nevi kalibre etmeye çalışıyorum. Ancak tabii ki herkesin farklı yetenekleri, güçlü yanları ve zayıf yanları var. O yüzden sizin maceranız kuvvetle muhtemel size özgü olacak ve size uygun bir zaman alacaktır. Burada odağınızı iyi belirlemeniz gerekli. Bu yüzden kendinize aşağıdaki soruları sorarak başlayabilirsiniz;

Teknik yetkinlikler; bir problemi çözerken bir sistem ya da metodoloji izliyor musunuz? Bir sorun için birden fazla çözüm görebiliyor ve bunlardan birini seçtiğinizde sebeplerini anlatarak başkalarını ikna edebiliyor musunuz?
Etki alanınız (Sphere of Influence); Etki alanınızda hangi rollerde kişiler var? Takımınızdakilerin düşüncelerine etki yaratabiliyor musunuz? Peki diğer takımlardaki kişilere ilham verebiliyor musunuz? Peki ya organizasyon seviyesinde ne kadar sesiniz duyuluyor? Yazılımcılar karar verirken biz odada yoktuk diye yakınırlar ya, eğer etkiniz yoksa o odaya çağrılmazsınız. Peki odaya nasıl girip orada kalacağınızı biliyor musunuz? (kitaptan, sayfa 102)
Networking; Network’ünüz yazılımcılardan mı oluşuyor yoksa yönetici ve ürün yöneticileri mi? Kaç defa yöneticilerinizle fikir alışverişi yapıp kararlara etki sağlayabildiniz? Sizi kimler tanıyor ve fikirlerinizi biliyorlar? Firmanın liderleri sizi tanıyor mu? Odadaki tüm oksijeni emmeden nasıl daha fazla görünür olabilirsiniz? (kitaptan, sayfa 102)
Projeler; En son büyük çaptaki hangi projede görev aldınız? Hangi fırsatları kaçırıyorsunuz? Kaçırdığınız fırsatları sonradan da olsa kaçırdığınızın farkına varabiliyor musunuz?

Bunları kendinize sorduğunuzda kendinize karşı açık ve dürüst olmanız şart. Bu kimileri için zor gelebilir. Bir çoğu için belki de yöneticinizi ya da firma kültürünü suçluyor olabilirsiniz. Benim tavsiyem yapmayın! Eğer başka bir şeyi suçladığınızı farkederseniz, durun. Düşünün. Belki suçlamakta haklı olabilirsiniz, ama biraz zaman ayırıp sizin bir şeyi nasıl farklı yapabileceğinizi düşünmeye çalışın. Unutmayın, gerçek dünyadaki fırsatlar eşit bir şekilde dağıtılmaz.

Bu sorulara dürüst bir şekilde cevap verdiğinize ikna olduktan sonra gideceğiniz en iyi yer yöneticiniz ya da mentorunuz olacaktır. İşte bu noktada kendinize bir sponsor bulmanızın etkisi çok fazla olacaktır. (kitaptan, sayfa 110). Sponsorunuzu bulabildikten sonra onunla dürüst bir şekilde ne başarmak istediğinizi ve eksiklerinizi açıkça paylaşmalısınız. Emin olun eksiklerinizi kabul ettiğinizi göstermeniz ve bunun için sizden tecrübeli birinden yardım istemeniz kadar değerli bir şey yok.

Bundan sonra kendinize bir Kişisel Gelişim Planı hazırlayın. Burada kısa ve uzun vade için hedefler belirleyin. Neleri öğrenmek ve nasıl geliştirmek istediğinizi belirledikten sonra bunlardan hangileri bilgi eksikliği yüzünden, hangisi tecrübe eksikliği yüzünden anlamaya çalışıp planınıza elle tutulur aksiyonlar ekleyin.

Tüm bunları yaptıktan sonra hala daha kendinizi sıkışmış hissedebilirsiniz. Bazen olaylar sizin etrafınızda sizin kontrolünüz dışında gerçekleşebilir. Bu kadar çaba harcadıktan sonra başarmak istediğinizi başaramamış olmak elbette bir burukluk yaratacaktır. Ancak kendinizi suçlamadan önce gerçekçi bir şekilde durumunuzu değerlendirin. Belki de sizin için uygun bir firmada çalışmıyor olabilirsiniz. (kitaptan, sayfa 113). Bu gibi durumlarda moralinizi bozmak yerine belki de farklı bir firmaya geçmek doğru seçim olabilir. Umarım kimse bu son paragrafı okuyup, yukarıda anlatılanları tamamen pas geçerek ertesi gün istifasını vermez!

2100 kelime sonunda bu haftanın yazısının sonuna geldik. Biraz uzun mu oldu dersiniz? Sanırım twitter’dan bu kadar uzun bir flood yapmam mümkün olamazdı! Doğrusu bu formatı yeniden değerlendirmeyi çok istiyorum, ancak bunu bu yazı görücüye çıktan sonra yapacağım. Peki madem buraya kadar okudunuz sizden iki tane ricam var.

Eğer içeriği beğendiyseniz lütfen bunu okumaya ihtiyacı olduğunu düşündüğünüz arkadaşlarınızla paylaşın!

Share

Hatta henüz abone olmadıysanız hemen şimdi abone olun!

Subscribe now

Şurası şöyle olsaydı daha iyi olurdu diye mi düşünüyorsunuz? Geribildirimleriniz benim için altın değerinde! Buradan fikirlerinizi paylaşabilirsiniz!

Haftaya görüşmek üzere!

Ürün Geliştirici Kütüphanesi

Yazılım ekiplerinde yönetici olmadan lider…