VP of Engineering Olmanın Yolu
(honeycomb.io)- Honeycomb’un ilk VP of Engineering’i, Şubat 2020’de Director of Engineering pozisyonundan terfi etti; bu yol, planlanmış bir yönetici kariyerinden çok, şirket büyürken ortaya çıkan boşlukları üstlenme sürecine yakındı
- Honeycomb’un ilk dönemlerinde kurucu ortak Charity Majors neredeyse herkesi yönetiyordu; yönetim felsefeleri benzer olsa da geçmişleri ve tarzları farklı olan iki kişi, R&D yönetim sorumluluğunu paylaşmaya başladı
- Terfi, tek bir büyük geçiş değil, küçük kapsam genişlemelerinin birikimiydi; startup’ta yeni süreçler ve sorumluluklar oluşturmak bu yolun özünü oluşturdu
- Role uygun şekilde hazırlanmak için şirketin tamamını gören bir düşünme biçimi, generalist eğilim, farklı soyutlama seviyeleri arasında gidip gelebilme, sorumluluk duygusu, sistem düşüncesi, ekip üyelerinin gelişimini destekleme ve geniş ilişkiler gerekiyordu
- İyi bir VP of Engineering’in nasıl göründüğü, standart bir şablondan çok şirketin o anki sorunlarına, mevcut liderlik ve IC yapısına, teknik zorluklara ve büyüme aşamasına göre değişir
Planlanmış bir yönetici kariyeri olmayan başlangıç noktası
- Honeycomb’un ilk VP of Engineering’i, Şubat 2020’de Director of Engineering pozisyonundan terfi etti
- Honeycomb’a ilk katılma hedefi mühendis olarak çalışmaktı; gerekirse tekrar yönetim rolüne dönebileceğine dair bir anlayış vardı
- Katıldığı dönemde yaklaşık 12. çalışandı ve erken aşama bir startup’ta şirket başarılı oldukça farklı aşamalarda çeşitli işler üstlenileceğini biliyordu
- Belirli bir göreve sıkı sıkıya tutunmanın hem bireye hem şirkete yardımcı olmaktan çok engel olabileceğini düşünüyordu
- Honeycomb’u seçme nedeni ekibin zeki ve nazik görünmesi, öğrenecek çok şey var gibi durması ve önceki işinde istediği ama bulamadığı ürüne benzemesiydi
- Belirli bir role hızlı büyümek için Series B sonrası bir startup’a katılmak daha verimli olabilir; ancak Honeycomb’a Series A aşamasında katıldı
Yönetim sorumluluğunun nasıl el değiştirdiği
- İlk dönemde kurucu ortak ve o zamanki CEO Charity Majors, yöneticilerden bireysel mühendislere kadar neredeyse herkesi yönetiyordu
- İki kişi yönetim felsefesinde genel olarak iyi uyuşuyordu, ancak geçmişleri ve güçlü yönleri farklıydı
- Charity Majors’ın altyapı, operasyon, veritabanı ve backend mühendisliği deneyimi derindi
- Terfi eden kişi ise tasarım, frontend ve ürün mühendisliğinden geliyordu; ürün yönetimi ve UX tasarımıyla iş birliği yapmaktan hoşlanıyordu
- Metrikler ve izleme teknolojileri konusunda ikisinin de deneyimi vardı, ancak yaklaşımları farklıydı
- Charity Majors bunlardan pek hoşlanmayan taraftaydı
- Terfi eden kişi ise güçlü bir ilgi duyuyordu
- Çalışma tarzı farkları da büyüktü
- Terfi eden kişi kurallara ve süreçlere önem verir; günlük işlerde ve hobilerde de planlama ve risk yönetimini çokça kullanır
- Charity Majors sezgisel ve doğaçlama bir tarza sahiptir; özellikle kriz anlarında parlar, kontrol listelerinden hoşlanmaz ve kuralların ya da süreçlerin işe yaramadığı zamanı hızla fark eder
- Honeycomb büyüdükçe R&D yönetim işi arttı ve her biri, kendi geçmişinin daha iyi uyduğu alanlar etrafında sorumlulukları giderek daha fazla paylaşmaya başladı
Terfi, küçük kapsam genişlemelerinin birikimiydi
- VP’ye giden yolda net tek bir kilometre taşından çok çok sayıda küçük adım vardı
- Aradaki unvan değişiklikleri, geriye dönüp bakıldığında ilerlemeyi gösteren işaretler olarak faydalıydı; ancak genellikle yeni bir toplantının eklenmesi dışında iş kapsamının büyük ölçüde değiştiğinin işareti değildi
- Büyüyen bir startup’ta süreç ve sorumluluk boşlukları sürekli ortaya çıkar; küçük sızıntılar gibi görünen sorunlar zamanla çok fazla zaman ve dikkat tüketen problemlere dönüşebilir
- Yeni bir sorunu üstlenip seviye atlama fırsatı her zaman vardır; ancak şirketin bunu yeni bir unvan ve rol olarak tanıyıp tanımaması ayrı bir konudur
- Honeycomb’un iki kurucu ortağı, yalnızca bu kişiyi değil diğer ekip üyelerini de içeriden terfi ve etki alanlarının tanınması konusunda aktif şekilde destekledi
- Gelecekte başka bir startup ararsa, yüksek performanslı çalışanları içeriden terfiyle büyütmüş örnekleri olan ve rol kapsamının ötesinde halihazırda etki yaratan kişileri hızla tanıyıp ödüllendiren bir yönetici ekibi ya da kurucu ekip arayacağını söylüyor
IC yönetiminden yönetici yönetimine geçiş
- Tüm yolculuktaki en ilginç geçiş, yalnızca IC’leri yönettiği durumdan yöneticileri de yönetmeye başladığı andı
- Bu geçişi isteyen biri için bunu yeni bir şirkette denemektense, ekipleri, teknolojiyi ve iş problemlerini zaten bildiği bir şirkette denemesinin daha iyi olduğunu düşünüyor
- Mevcut hat yönetimi becerilerinin büyük bölümü aktarılabildi; ancak ek yönetim katmanı üzerinden tüm organizasyonu etkili biçimde “görmeyi” öğrenmek zaman aldı
- Özellikle organizasyon içinde sürtüşme olan noktaları ya da daha fazla desteğe ihtiyaç duyulan yerleri belirlemek zordu
- Mühendislik organizasyonundaki insanları ve sorunları doğrudan deneyimlemiş olması sayesinde, yöneticilerle birlikte ekip durumlarını değerlendirme pratikleri ve becerileri oluşana kadar dayanabildi
Dışarıdan VP adayı arayışı ve içeriden terfi
- Şirketin akışının bir miktar sarsıldığı bir dönemde, dışarıdan VP of Engineering işe alma seçeneği de değerlendirildi
- Charity Majors bunu açıkça paylaştı ve uygun kişiyi bulma ve seçme sürecine de onu dahil etti
- Birkaç güçlü mühendislik lideriyle görüşüldü; ancak bazıları o dönemde Honeycomb’a uygun değildi, bazıları da Honeycomb’u bir sonraki adım olarak seçmedi
- Daha sonra şirkette yeni sorunlar ortaya çıktı ve daha önce çözülmesi imkansız gibi görünen sorunlar daha yönetilebilir hale geldi
- O noktada hemen terfi etmedi, ancak dışarıdan işe alım arayışı durdu
- Belirli bir seviyenin üzerindeki liderlik terfileri bireye göre değil, şirketin neye ihtiyaç duyduğuna göre yapılmalıdır; Honeycomb’a uygun VP of Engineering’in nasıl görüneceğini birlikte hayal etme süreci yardımcı oldu
Role uygun kişi olmasına yardımcı olan özellikler
- Bütüncül düşünme önemli bir özellik olarak işledi
- Yalnızca ekibe değil, Honeycomb şirketinin tamamının daha başarılı olacağı yöne doğal olarak odaklandı
- Departman, ekip ya da birey yerine şirketin tamamının çıkarı için hareket etmenin ödüllendirildiği bir ortamda iyi çalışır
- Generalist eğilim de yardımcı oldu
- Bir yazılım şirketindeki neredeyse tüm iş problemlerine ve alanlara ilgi duyar
- Startup’ta tüm parçaların nasıl birbirine geçtiğini görebilmeyi sever
- Gerektiğinde dikkat çekmeyen, gösterişsiz işleri üstlenmekten rahatsız olmaz
- Farklı soyutlama seviyelerinde çalışabildi
- Alt katmanları tamamen anlamadan da üst katman kavramlarını hızla kavrayabilir
- Gerektiğinde ayrıntıların içine girmekten de hoşlanır
- Güçlü sorumluluk duygusu startup’ta yardımcı olur, ancak sınırlar da gerekir
- Önemli işlerin fonksiyonlar arası boşluklara düştüğü startup’larda faydalıdır
- Ancak işlerin birikmesini ya da ekibin büyümesini engellemesini önlemek için işi tamamlamak veya başkasına devretmek yönünde sürekli çaba gerekir
- Hem insanlara hem teknik sistemlere ilgi duyan sistem düşüncesi de önemli listeye dahildi
- Ekip üyelerinin büyümesinden içtenlikle keyif alma tutumu da önemliydi
- Bir sonraki aşamaya hazır olan kişiyi, yetkinliğinin sınırında çözmesi gereken önemli bir problemle eşleştirmeyi enerji kaynağı olarak görür
- Şirketin farklı yerlerindeki iyi ilişkiler de gerekliydi
- Şirket içindeki ve dışındaki insanların, dış adaylardan beklenti duymasından çok bu kişinin rolü üstlenmesine dair daha fazla heyecan duyması gerekiyordu
Yardımcı olan iş deneyimleri
- Farklı aşama ve ölçeklerde startup deneyimi, özellikle B2B SaaS startup deneyimi yardımcı oldu
- B2C ve B2B startup’lar görece farklı problem kategorileriyle uğraşır ve her biri kendi problem çözme tekniklerini geliştirmiştir
- İki alanı birden görmek de iyidir; ancak B2B veya B2C’den birinde uzmanlık oluşturmak da değerlidir
- Pazara giriş biçimi, organizasyon yapısı, mühendislik sorunları ve ölçeklenme zorlukları B2B ve B2C’de farklı olabilir
- Tüm stack genelinde çalışmış olmak da yardımcı oldu
- En derin mühendislik deneyimi frontend teknolojilerindeydi
- Pair programming yapan ve DevOps zihniyetini uygulayan çeşitli organizasyonlarda erken deneyim kazandı
- Backend, altyapı, platform ve operasyon mühendislerinden öğrenerek onların nasıl düşündüğünü ve hangi sorunları önemli gördüğünü anladı
- Tüm mühendislik alanlarında uzman olmak gerekmez; ancak farklı ekiplere empati ve yüksek seviyede alan anlayışı büyük fayda sağlar
- Geliştirici araçları ve monitoring alanındaki deneyim de role uygundu
- Üst üste üç geliştirici araçları şirketinde çalıştı
- Honeycomb ürününü gerçekten seviyordu; observability, monitoring ve geliştirici araçları alanındaki çeşitli ürünlere de ilgi duyuyordu
- Alan bilgisi ve araçlara duyulan tutku, iş arkadaşlarına yardımcı olur ve moral bozucu durumlarda enerji kaynağı olabilir
Şans ve ekip bileşiminin yarattığı uyum
- Role uygun kişi olmasında şans da büyük rol oynadı
- Charity Majors ile birbirini tamamlayan beceri ve deneyimlere sahip olmak tek başına yeterli değildi; erken dönemdeki kıdemli IC’lerin temel mühendislik zorluklarını iyi ele alıyor olması da önemliydi
- Frontend geçmişine sahip bir VP of Engineering görece nadirdir; çünkü startup’ların en acil teknik sorunları genellikle ölçeklenme, güvenilirlik ve backend mimarisi etrafında olur
- Sürekli kesintiler, ölçeklenme sorunları, sorgu ve depolama motorunda büyük mimari problemler devam ediyor olsaydı, daha derin backend ve operasyon deneyimine sahip birinin seçilme ihtimali yüksekti
- Ben Hartshorne, Ian Wilkes, diğer olağanüstü IC’ler ve kurucu ekibin sağlam tasarım kararları sayesinde teknik açıdan bir alan vardı; o dönemde liderliğin en öncelikli odağı ürün stratejisini yürütmek ve kullanıcı deneyimini iyileştirmekti
- Yönetici ekipte go-to-market fonksiyonlarında deneyimli, dışarıdan getirilmiş yöneticiler zaten vardı
- Şirket içinde büyümüş liderler olarak görülebilecek Christine ve Charity’nin de önceki şirketlerinde kurucu ya da liderlik deneyimi vardı; Charity ise Honeycomb’u kurmadan önce de güçlü bir yönetici olarak biliniyordu
- Yönetici ekip yeni yöneticilere ya da içeriden terfi edenlere daha fazla eğilimli olsaydı, bir yöneticiyi daha yetiştirecek alan olmayabilirdi
VP of Engineering şirket bağlamına göre değişir
- En önemli öğrenim, iyi bir VP of Engineering’in nasıl göründüğünün bağlama bağlı olduğudur
- Önceden iyi bir VP of Engineering’i oluşturan standart özellikleri listeleyebileceğini düşünüyordu; ancak şirketten şirkete temel şablonun neredeyse aynı olduğu fikri pek doğru değildi
- Çoğu yazılım şirketinde yapılması gereken temel işler benzerdir; ancak bunlara liderlik edecek yöneticinin biçimi, organizasyonun mevcut sorunlarına ve halihazırda var olan yöneticiler, manager’lar ve IC’lerin bileşimine göre büyük ölçüde değişir
- Role girdikten sonra da gereksinimler sabit kalmaz
- Büyüyen bir şirkette, diğer startup rolleri gibi VP of Engineering rolünün de şekli zamanla değişebilir
1 yorum
Hacker News görüşleri
Şu bölüm ilginçti: “Charity daha sezgisel ve doğaçlama bir tarza sahip, kriz anlarında en çok parlıyor ve kontrol listelerinden nefret ediyor” ifadesi neredeyse gelişigüzel yapılmış bir kabul gibi görünüyor
Başka bir deyişle, kurucu, astlarının liderlik pozisyonları için gerekli gördüğü niteliklere ya da özelliklere sahip değil demek
Bir şirket kurduğunuzda otomatik olarak CEO, CTO vb. oluyorsunuz; bugün büyük şirketlere dönüşmüş şirketlerin kurucuları için de aynı durum geçerli
Kurucunun unvanını meşrulaştıracak belirli bir niteliğe ihtiyacı yok; kendisi lider olduktan sonra arkadaşlarını ilk çalışanlar olarak seçiyor
İşe alımın resmileşmesi çok daha sonra oluyor ve hiyerarşinin ne kadar liyakatçi olduğuna inanmak istersek isteyelim, o hiyerarşinin başlangıcı açıkça kaotikti
Hiyerarşik ve itaatkâr düşünce bana hep tuhaf gelmiştir; önceki yöneticilerimin benden “daha iyi” olduğunu da hiç düşünmedim
Şirket merdivenlerini tırmanmak özünde siyasete daha yakın ve “senior engineer nedir” gibi bitmek bilmeyen yazılar da hiyerarşiyi meşrulaştırmaya çalışan kurumsallaşmış düşünceden çıkmış gibi görünüyor
Ama zamanla şirketi batırmayıp başarılı kılarak o pozisyonu meşrulaştırmanız gerekir
Bu, çoğu zaman herhangi bir değerlendirmeden çok daha dürüst ve sert bir liyakat ölçme yöntemi olabilir
Google gibi büyük şirketler, beceriksiz ve tembel tek bir VP yüzünden iflas etmeyeceği için değerlendirme sistemlerine ihtiyaç duyar
https://gwern.net/backstop ile karşılaştırmaya değer
Ben tamamen icra tipiyim, ama ideal bir kurucu ortak için gereken özelliklerin benimkinin tersi olduğunu erkenden öğrendim; burada görülen de bu fark
Tarif edilen kişi tipik bir alışılmadık lider: doğaçlamacı, oradan oraya koşturan ve dağınık olabilen, ama aynı zamanda harika bir yenilikçi ve insanları harekete geçiren bir motivatör
Başarılı bir startup’ta hem vizyoner/alışılmadık kişiler hem de icra odaklı kişiler gerekir
Rocket Fuel’i öneririm: https://www.amazon.com/Rocket-Fuel-Essential-Combination-Bus...
Bana farklı iki tarzın var olduğuna dair dürüst ve dostane bir kabul gibi geliyor; bu farkı kabul etmek sağlıklı bir şey, hiyerarşiye örtük bir başvuru değil
Aksine, “ast”, “üst” gibi ifadeler kullanması ve şirket kurmayı hiyerarşi kurmakla eşitlemesi bakımından, hiyerarşiden şüphe ettiğini söylemesine rağmen yorumun tamamı hiyerarşiyi güçlendiriyor
Bilgi sektöründe yöneticiler lider değil, destek personelidir
En iyi yazılım yöneticileri ve üst düzey yöneticiler, gerçek liderlerin ve uzmanların, yani işi yapan bireysel katkı sağlayıcıların kolayca çalışmasına yardım etmeleri gerektiğini bilir
Yönetimin destek işlevlerinden biri de bu beklentiyi kendi davranışlarıyla tesis etmektir
Bir startup büyük bir şirkete satıldığında, startup ekibindeki kimsenin o şirketin İK kriterlerine göre işe alınmış olmayacağı ortaya çıkınca oldukça ilginç hâle geliyor
Sonra bir anda o startup’ın ekip üyeleri, İK’nın onayladığı iyi okullu büyük şirket çalışanlarından önce terfi edebiliyor
Pek çok insan Amerikan tarzı kurumsal komuta zinciri tarafından beyni yıkanmış durumda ve birinin belli bir unvanı varsa gerçekten o unvana uygun niteliklere sahip olduğunu varsayanların sayısı çok fazla
Unvan enflasyonu her yerde; benim hissiyatıma göre unvanlar çoğu zaman yetkinliğin tanınması değil, maaş artışı ve kıdemi tanıma aracı olarak kullanılıyor
Bunu yalnızca ABD’ye özgü bir şey olarak söylemek istememiştim
Benim deneyimime göre içeriden terfi örneklerini arama ölçütü çok nadir görülüyor
Çoğu startup’ta hiyerarşide yeni bir kademeye ihtiyaç duyulduğunda ya da mevcut biri ayrılıp pozisyon açıldığında varsayılan seçenek dışarıdan işe alım oluyor
Herkes gereken işi iyi yapıyorsa kurcalamamak daha iyidir gibi bir mantık var sanırım, ama açıkçası bu motivasyonu çok kırıyor
Bir iş arkadaşımın terfi edip beni geride bırakmasından çok daha moral bozucu; çünkü terfi ve gelişim kültürü varsa bir dahaki sefere adil bir fırsat olabileceğine inanabilirsiniz
Ama sürekli dışarıdan biri alınıyorsa, bu şirketteki kariyerim işe girdiğim pozisyonda kalmış demektir
Mantık, unvanından daha yüksek performans gösterebilen zeki insanları mümkün olduğunca ucuza elde tutmaya daha yakın görünüyor
İş değiştirmenin çalışan açısından gerçek bir maliyeti var ve ekonomi zorlaştıkça bu maliyet büyüyor
Yine de ayrılanlar da var, sessizce elini işten çekenler de var, sadece dayananlar da var
Benim deneyimime göre onlar çoğu zaman uyum sağlamayı reddedip ya ayrılıyor ya da işten çıkarılıyorlardı
10 kişilik bir ekibi yönetebilmek, 100 kişilik bir organizasyonu, hele 1000 kişilik bir organizasyonu yönetebileceğiniz anlamına gelmez
Bu örnekte mutlaka böyle olduğunu söylemiyorum, ama bazı durumlarda Peter İlkesi’nden kaçınmak için meşru bir neden olur
Çünkü o kusurlara katlanmış ya da onları hiç görmemiş kişiler terfi eder
Bu kusurları fark edecek deneyime sahip az sayıdaki dışarıdan işe alınan kişiden biriyseniz oldukça zor zamanlar geçirmeniz muhtemel
En üst liderliğin büyük bölümü içeriden terfiyle geldi; bazen bireysel katkı sağlayıcıdan VP’ye kadar yükselenler de oldu ve bunun etkisi görülüyor
Birden fazla organizasyonda bu ölçeği deneyimlemiş birinin gelmesi organizasyona kesinlikle fayda sağlayacak gibi görünüyor
Gerçekte ne yaptığı ve şu an VP rolünde ne yaptığı anlaşılması zordu
Güzel söz çok, ama gününün çoğunu şu anda neye harcadığı net değil
“Tasarım, frontend, ürün mühendisliği kökenli” demek de fazla bilgi vermiyor
Ben de eskizden Figma yerleşimlerine, SvelteKit frontend ve ara katmana, FastAPI API kurulumuna kadar yapan tam da böyle biriyim; neyi iyi yaparak VP olduğunu, sahadan uzaklaşıp şimdi ne yaptığını ve en çok neyi özlediğini bilmiyorum
Yazı inanılmaz uzun ama ne söylediğini pek anlamıyorum
Günümüzde FAANG’den daha küçük şirketlerde beklenen rolü ve bir mühendisin yönetim hattında yükselme yolunu görmek için “The Manager's Path”e bakmaya değer
Üst düzey liderliğe gidildikçe işin çok daha stratejik hale geldiğini ve doğrudan icranın nadir olduğunu düşünürdüm; ama yazıda, kendisini iyi bir VP yaptığını söylediği çok sayıda taktik deneyim ve nitelik sıralanıyor
Teknoloji çevresinde yoksul biri olarak, şirketlerin insanlara bir şeyler yazmaları için baskı yaptığı çok örnek gördüm ve hep böyleydi
Kampüs işe alımları sırasında arama sonuçlarında güncel yazılar çıksın diye şirkettekilere bu tür yazılardan bir iki tane yazdırılır
Aynı anda hem makul ölçüde yağcılık hem de potansiyel adayları pohpohlama amacına hizmet eder
https://www.honeycomb.io/blog/becoming-vp-of-engineering-pt2
Bu yazı temelde hayatta kalan yanılgısı ve bunun rasyonelleştirilmesine bir örnek
Eksik olan şey, VP koltuğuna giden iç geçiş ile dışarıdan işe alım arasındaki istatistiksel bakış açısı
İster startup ister büyük şirket olsun, içeriden VP’ye geçmenin son derece zor olduğunu düşünüyorum
Startup’ın başarılı olması gerekir; büyük şirkette ise yıllarca dayanıp iyi siyasi ilişkiler kurmak gerekir
En kolay yol, en alttan başladığını düşünmemek; hayatın erken döneminde yüksek bir rolü hedefleyip bunu sürdürmektir
Mevcut şirkette tepeye çıkamıyorsan, kendin kurarsın
En alttan başlarsan orada kalırsın; çünkü o beceri en üst liderlik rollerinde değerli değildir
Denemişler ama sonunda öyle olmamış; bir değer yargısı da yoktu
İyi bir aday bulamayınca sonunda yazar terfi etmiş gibi görünüyor
Benim önceki startup’ımda da VP arayıp sonunda içeriden terfi yaptılar; istatistiksel olarak bakıldığında bu tür şeyler kesinlikle ara sıra oluyor
Yazarın “en alttan başlarsan orada kalırsın” şeklindeki son cümleye katılacağını sanmıyorum
Şirket altyapısının ölçeklenme sırasında bile stabil kalmasının, “en alttaki insanların” işi iyi yapmasından kaynaklandığını ve bu sayede kendisinin stratejiyi daha fazla düşünebildiğini söylüyor
Bu, yukarı-aşağı meselesinden çok hangi tür problemleri iyi çözdüğünle ilgili görünüyor
Planlama, yönetim ve stratejiyi seviyorsan, üstte, ortada ya da altta hangi rolde olursan ol bu yetkinliği kullanabileceğin pozisyonları hedeflemek iyi olur
Örneğin öne çıkmak istiyorsan JavaScript pozisyonunda rahatına bakmamalı, kendini rekabetçi bir alana itmelisin; gerçekten iyi bir programcı olmak için de OCaml ile lanetli kod yazmalısın
Girişim sermayesi yatırımı almış bir startup’ın CTO’su olarak baktığımda, yüksek pozisyonlardaki insanlar genelde zekidir; kurnazlığı da aynı kategoriye koyuyorum
Ama aynı derecede zeki olup yüksek pozisyonda olmayan çok kişi var; çünkü fırsatları olmadı
Kendi işini kurarsan fırsatların daha iyi olur; kimse başka bir şirkette VP pozisyonu almak için şirket kurmaz ama bu iyi bir alternatif yol olur
Ya da doğru insanları tanımayı sağlayan networking gerekir; bu da genellikle önceki girişimcilik yoluyla birlikte gider
Google gibi tanınmış bir şirkette çalışıp sonra daha küçük bir yere geçerek büyük balık olmak da bir yöntem
Ya da patronunun ve onun patronunun gözüne girip, doğrudan yöneticin istifa ettiğinde sıradaki atama adayı olmalısın
Öğrendiğim bir şey şu: Bir şirketin yöneticileri yetenek dışında nedenlerle terfi ettirdiğini ve işe aldığını görüyorsan, yeni iş aramaya başlamanın zamanı gelmiştir
Mülakat sırasında bilmiyordum ama önceki şirkette VP ve üzeri pozisyonlar, niteliklerden bağımsız olarak CEO ile bağlantılı kişiler tarafından neredeyse tamamen kapılmıştı
Yetkinlikle terfi eden ya da satın alma sürecinde doğal olarak yükselen birkaç kişi de vardı; ama zamanla C-level yöneticilerin arkadaşlarına, hatta aile üyelerine yer açmak için düzenli olarak değiştirildiler ya da rütbeleri düşürüldü
Birlikte çalışması iyi olan bir C-level yönetici VP’ye düşürüldü; CEO’nun eski bir arkadaşı o C-level koltuğu aldı
Rütbesi düşürülen yönetici sektörün en iyi şirketlerinde yıllarca deneyim kazanmış ve bu görev için ailesiyle birlikte ülkenin bir ucundan diğerine taşınmıştı; ama yerine gelen kişinin o sektörde hiçbir deneyimi yoktu
O VP’den, CEO’nun eski arkadaşı işi öğrenip devralabilsin diye şirkette kalması istendi ve hisse opsiyonlarını korumasına “izin verildi”
Bazı şirketlerde nepotizm ve sadakatin nasıl işlediği konusunda gözüm açıldı
Bu alıntı özellikle gözüme çarptı
Frontend kökenli Engineering VP’lerin nispeten nadir olmasının nedeni, startup’ların en acil teknik sorunlarının genellikle ölçeklenebilirlik, güvenilirlik ve backend mimarisinde olmasıymuş
Geçmişte liderlerin tamamının backend/altyapı tarafında olduğu, frontend’in düşük değerlendirildiği şirketlerde çalıştım; o backend geliştiricilerin kod kalitesinin epey korkunç olduğu durumlar gördüm
Liderlik temsiliyeti ile mühendislik yeteneği arasında ters korelasyon olup olmadığını merak ediyorum
Ben frontend mühendisi olarak başlayıp teknik lider olmuş biriyim; geliştiricilerin odağını kişisel eğilimlerine ve önem verdikleri değerlere göre seçtiğini düşünüyorum
Frontend’i seçenlerle backend geliştiriciler genellikle farklı eğilimlere sahip oluyor
Korkunç kod nedir
Biçimlendirmesi tutarsız ya da güzel değil mi, değişken adları açıklayıcı değil mi, kod iyi görünecek şekilde bölünmemiş ya da yapılandırılmamış mı
Frontend geliştiricilerin kodu yüzeysel değerlerle yargılama eğiliminde olduğunu hissediyorum
Özellikle mühendislik odaklı organizasyonlarda insanlar sorun çözerek takdir görür
Birçok ekip, temel bir frontend sorumlusu olmadan da yeterince işleyebilir; ama güçlü bir altyapı ya da backend mühendisi, hatta birkaç tanesi yoksa çoğu zaman sarsılır
Gerçek bu
Frontend geliştirme sık sık kadınsı şekilde kodlanıyor ve daha az önemli görülüyor
Örn: https://thoughtbot.com/blog/tailwind-and-the-femininity-of-c...
Teknoloji sektöründe liderliği erkeksi kodlanmış özelliklerle ilişkilendirme eğilimi de var
Bu yüzden liderlik ile frontend geçmişinin bir şekilde uyuşmuyor gibi görülmesi hiç şaşırtıcı değil
Aynı cinsiyet dinamikleri kod için de geçerli
Benim için iyi kodun bir parçası, başkaları için iyi ve iş birliği için iyi olan koddur
Ama maço, alfa nerd techbro gibi davranmak istiyorsanız tek başınıza kovboy kodlama yapıp dehanızı sergileyebilirsiniz
O durumda hedef, ekiple yakın çalışıp birlikte üretmek değil; yönetimin gözüne çarpan inanılmaz bir bireysel katkı sağlayıcı olmaktır
Engineering VP şirketler arasında standartlaştırılıp karşılaştırılabilecek bir rol değil
Şu anki şirkette direktörlerin çoğu zaman 500 kişiye kadar organizasyonlardan sorumlu olduğu görülüyor; VP’ler ise genellikle 1000’den fazla, bazen 3000–5000 kişiden sorumlu oluyor
50 kişilik bir organizasyondaki startup VP’si ile 1000+ kişilik bir organizasyondaki FAANG VP’sini aynı görmek mantıklı değil
Birinin diğerinden daha iyi olduğu anlamına gelmiyor; gereken beceriler açıkça farklı
Gerçekten de küçük şirketlerde VP unvanı almış kişilerin bu farkı anlamayıp FAANG’e başvurduktan sonra kendilerine manager ya da senior manager rolü teklif edilince şoke olduklarını gördüm
Tamamen anlamsızdı
Deneyimime göre o VP, büyük organizasyon ölçütlerine göre stajyer seviyesinde deneyime sahipti ama şirkete erken katılmıştı
Direktör daha da kötüydü; kendisine rapor veren iki kişi ise yetenekliydi
Honeycomb çalışanlarının blog yazısı yazmak yerine ürünü gözle görülür şekilde iyileştirmeye biraz zaman ayırmasını isterdim
Şirketimde Honeycomb’u deneme talihsizliğini yaşadım; birkaçdan fazla servisle etkileşen sistemlerde düpedüz kullanılamazdı
Bu şirkete neden bu kadar abartılı beklenti yüklendiğini anlamıyorum
Bu yazıyı, Honeycomb’daki VP’nin büyük teknoloji şirketlerindeki senior manager’a benzer olduğunu akılda tutarak okuyorum
Büyük şirket ölçütlerine göre bu direktör seviyesine denk gelir
Benim deneyimime göre bireysel katkı sağlayıcılar ürün yapar, manager’lar insan yetiştirir, direktörler süreç kurar, VP’ler politika oluşturur
Onların üzerindeki herkes bütçe talebi onaylama katmanıdır
Politika ile stratejinin aynı şey olmadığını düşünüyorsak tabii
Yok eğer kimsenin strateji oluşturmadığına dair ince bir şakaysa, güzel şaka