Startup’lar canlılığını nasıl kaybeder
(blog.johnqian.com)- İyi yönetilen seed aşamasındaki startup’larda mühendisler kullanıcı problemlerini bulur, uygular ve yayına kadar süreci bizzat yürütür; ancak şirket büyüdükçe bu döngü yavaş ve parçalı bir işe dönüşür
- 10 kişiden küçük ekiplerde kullanıcıyla temas, fikir seçimi, ekip arkadaşı geri bildirimi, küçük bir kod tabanı ve hafif deployment sayesinde uygulama hızı yüksektir
- 100+ kişilik organizasyonlarda kullanıcı teması PM’lere ayrılır; güvenlik incelemeleri, CI, PR review ve altyapı prosedürleri biriktikçe çalışma hızı ciddi biçimde düşer
- Bu değişimin arkasında çıkar ortaklığının azalması, çalışan sayısı arttıkça ortaya çıkan O(N^2) iletişim yükü ve kullanıcı sayısı ile regülasyon arttıkça düşen risk iştahı vardır
- Eğlencenin kaybolmasını tamamen engellemek zor olsa da, büyük şirket süreçlerini aceleyle kopyalamamak, küçük bağımsız ekipler ve teşvikler tasarlamak ve işe alım hızını yavaşlatmak bunu geciktirebilir
Küçük startup’larda iş neden bağımlılık yapıcı gibi gelir?
- İyi yönetilen seed aşamasındaki startup’larda mühendisin temel işi, kullanıcı problemlerini anlamak, fikir üretmek, ekip arkadaşlarıyla tartışmak, uygulamak ve ardından yayına alıp geriye dönük değerlendirme yaparak bunu tekrarlamaktır
- 10 kişiden küçük ekiplerde bu döngünün her adımı keyifli olabilir
- İlgini çeken kullanıcılara doğrudan ulaşıp bir bira eşliğinde sohbet edebilirsin
- Şirket için değerli ve kişisel olarak ilginç bir fikir bulursan yaptığın işi bırakıp hemen üzerinde çalışabilirsin
- Ekip arkadaşların aynı şirket başarısında doğrudan pay sahibi olduğu için iyi fikirleri teşvik etmeye, kötü fikirlerin sorunlarını anlatmaya motive olur
- Ekip arkadaşın o fikrin kullanıcısı olabilir, seninle birlikte çalışmak isteyebilir ve kod tabanının büyük bir bölümünü bildiği için faydalı içgörüler sunma ihtimali yüksektir
Hızlı uygulama ve yüksek beklenti
- Küçük ekiplerde uygulama hızı yüksektir
- İstediğin araçları seçebilirsin ve güvenlik incelemesi yoktur
- Kod tabanı küçük olduğu için genel yapıyı zihninde tutabilir, büyük refactor’ları bile nispeten rahat deneyebilirsin
- Hızlı hot reload sayesinde deneme-yanılma tipi debugging’i hızlıca tekrar edebilirsin
- Değişiklikleri merge etmek de hafif ilerler
- CI’da yavaş testler yoktur ve güvenli değişiklikler için engelleyici PR review gerekmeyebilir
- Bazı durumlarda doğrudan
master’a push edebilir ya da riskli değişikliklerde ekip arkadaşının omzuna dokunup review isteyebilirsin - Kullanıcı sayısı azsa hızlı backend veya veritabanı değişiklikleri için downtime göze alınabilir
- Küçük startup’larda her şey mümkündür beklentisi güçlüdür
- Yeni bir özellik hisse değerini artırabilir ve sonrasında başka insanlar o özelliğin üstüne inşa etmeye devam edebilir
- Kullanıcının “Bu fikri sen mi ortaya attın, hayatımı kurtardı” demesini bekleyebilirsin
- Tüm ekip aynı çıkarları paylaştığı için birbirinin başarısını destekleyen bir atmosfer oluşur
Şirket büyüyünce aynı döngü nasıl değişir?
- 100+ kişilik organizasyonlarda kullanıcıyla doğrudan temas azalır
- Kullanıcılarla konuşmak PM’in rolü olur ve mühendis, kullanıcı içgörülerinin özetiyle önceliklendirilmiş görev listesini almakla yetinebilir
- Kötü senaryoda, kullanıcı anlayışı hatalı olan ya da yöneticinin benmerkezci vizyonuna dayanan karmaşık bir görev listesi alırsın; ayrıca bu işlerin neden önemli olduğunu açıklayacak kimse de olmayabilir
- Kişinin istediği işi hemen seçmesi zorlaşır
- Herkes kendi istediği işi yaparsa O(N^2) iletişim karmaşası ortaya çıkar
- Yönetici, organizasyondaki diğer işleri de hesaba katarak kişinin planını tasarlar
- Kendi fikrini ancak verilmiş işi bitirdikten sonra ya da boş zamanında gizlice ilerletebilirsin
- Ekip arkadaşlarınla fikir konuşabilsen de ilgi ve boş zaman azalır
- Ekip arkadaşının senin bireysel başarından elde edeceği fayda küçüktür ve hatta terfi yarışında rakibin olabilir
- Herkesin uzun bir iş listesi vardır; bu yüzden elindeki işi bırakıp seninle çalışacak özgürlüğe sahip olmayabilir
- İlgili kod hakkındaki hafızası ya da bağlam bilgisi de yetersiz olabilir
Büyük organizasyonlarda uygulama neden yavaşlar?
- 100+ kişilik organizasyonlarda araç seçimi çoğunlukla önceden belirlenmiştir
- Daha iyi yeni araçlar olsa bile tutarlılığı bozmanın maliyeti nedeniyle buna değmeyeceği düşünülebilir
- Yeni bir araç kullanmak için yöneticine sorman ve güvenlik inceleme ekibine e-posta atman gerekir
- Büyük kod tabanları çoğunlukla legacy nedenlerle büyür
- Dokunmaya çekinilen çok sayıda kod vardır ve artık kimsenin tam olarak anlamadığı bölümler bulunur
- Kapsamlı testler, tüm sistemi bozmadığının tek güvence kaynağına dönüşür
- Deneme-yanılma tipi debugging gerekir ama compile süreleri uzadığı için tekrar döngüsü yavaşlar
- Küçük bir PR’ı merge etmek bile 2 hafta sürebilir
- CI’ın geçmesini beklemek için 20 dakika harcarsın; testler flaky ise yeniden çalıştırman gerekir
- Review beklerken merge conflict’ler birikir
- Reviewer, yeterli bağlama ya da motivasyona sahip olmadığı için önemli öneriler yerine önemsiz noktalara takılabilir
- İstenen değişiklikleri yapıp yeniden push ettikten sonra yine 20 dakika bekleme süreci, her PR için üç kez tekrarlanabilir
- Altyapı değişiklikleri, 10 milyon kullanıcı için downtime ya da veri kaybını önlemek amacıyla 14 adımlı bir prosedüre dönüşebilir
- 3 ay sessizce çalışıp yayına çıksan bile ödül ve takdir sınırlı kalabilir
- Cuma toplantısında CEO’ya gösterilebilecek bir demo fırsatı elde edersin ama gerçekten dikkat kesilen ekip arkadaşlarının sayısı az olabilir
- Yöneticin bunun 5 ay sonraki performans değerlendirme döngüsünde işe yarayacağını söyleyebilir
- İyi senaryoda %20 maaş artışı ve unvan değişikliği alırsın; kötü senaryoda ise 4 ay sonra gelen organizasyonel yeniden yapılanmayla yeni bir yönetici gelir ve proje öncelik sırasından düşer ya da iptal edilir
Eğlencenin ölümünü nasıl geciktirebiliriz?
- Bu değişim, tamamen engellemekten çok geciktirme problemidir
- Temel nedenler çıkar ortaklığının azalması, O(N^2) iletişim ve düşen risk iştahıdır
- Çıkar ortaklığındaki azalma ve iletişim sorunları, çalışan sayısı arttıkça kaçınılması zor hale gelir
- Risk iştahındaki düşüş, kullanıcı sayısının artmasının sonucudur ve kısmen devlet regülasyonlarıyla da ilgilidir
- Startup’lar, büyük şirket süreçlerini kopyalayarak kurumsallaşmayı gereksiz yere erkene çekebilir
- Büyük şirket geçmişi olan yöneticiler işe alındığında, kullandıkları playbook da beraberinde gelebilir
- Birçok startup, büyük şirketler kullanıyor diye Jira kullanır; ancak burada savunulan görüş bunun gibi yaklaşımlardan kaçınmak gerektiğidir
- Y Combinator’ın, büyük şirketlerin startup gibi çalışmaya çalışması gerektiği yönündeki anlayışı yaygınlaştırdığı söylenebilir
- Büyük şirket playbook’ları büyük şirketler içindir; startup büyümeye başladığında, ölçek sorunlarını ele almak için daha iyi çözümler mevcut olabilir
- Ölçek acıları yaşarken birinci prensiplerden çözüm üretmek ya da aynı ölçekte daha hızlı hareket eden startup’lardan ilham almak daha iyidir
- Şirketi birden fazla bağımsız startup gibi yapılandırmak, mümkün olan ölçüde denenmeye değerdir
- Rippling, bunu belli ölçüde başarmış bir örnek olarak anılır
- Ancak ürün bileşenleri çoğu zaman fazla sıkı bağlıdır ve bileşenlerin çoğu tek başına gelir üretemediği için bunun genelde sınırları vardır
- Teşvik tasarımı, çıkar ortaklığındaki azalmayı anlamlı biçimde geciktirebilir
- Ancak büyük hisse payı ve onun değerini değiştirebilme gücü kadar kuvvetli teşvikler nadirdir
- En iyi yöntemlerden biri daha az işe alım yapmaktır
- Pek çok şirket, yönetici teşviklerindeki uyumsuzluk, yatırımcıların diğer hızlı büyüyen startup’lara benzemeleri yönündeki baskısı ve bir çalışanın gerçek maliyetini anlayamama nedeniyle çok hızlı işe alım yapar
- Araçlar, özellikle yapay zeka, geliştikçe küçük ekiplerin destekleyebileceği kullanıcı sayısı artar
- Geleceğin kurucuları bu ölçek acıları hakkında daha az kaygı duyabilir ve iş herkes için daha eğlenceli hale gelebilir
1 yorum
Hacker News yorumları
10 yıl önce Netflix henüz küçükken çalışma biçimi gerçekten iyiydi. Olgun insanları işe alıp süreçleri ortadan kaldırabiliyorlardı; gerçekten de her şeyi süreçsizleştirmeye çalışıyorlardı.
Sonuçta işler kendiliğinden yürüyordu ve o dönemde Netflix’te “büyük bir olay çıkmadan doğal şekilde olması” sık sık beklenen bir şeydi. Active-active region birkaç ay içinde yapılmıştı, kullanımı kolay dağıtım aracı Asgard da ortaya çıkmıştı; kendi CDN’ini kurup ISP’lerle ortaklık yapma planı da yaklaşık 12 kişiyle 6 ayda hayata geçmişti.
Bir mühendisin bakış açısından haftada yalnızca bir ekip toplantısı vardı; yöneticiler ve direktörler ekip bağlamını hizalayan çok sayıda toplantıyı üstlenirdi, böylece mühendisler istedikleri gibi üretken çalışabilirdi. O zamanlar bunu doğal sanıyordum ama sonradan bunun çok yüksek bir standart olduğunu gördüm.
Elinden tutulup yönlendirilmeden işi bitirebilen geliştiricilere ihtiyaç var; ama yöneticilerin de elinden tutup kontrol etmek yerine koordinasyon kurmayı bilmesi gerekiyor.
Ama iki veya daha fazla kişiden öznel girdi alıp yinelemeli olarak iyileştirilmesi gereken bir ürün söz konusuysa iletişim ve dağıtık iş birliği önemli ve gerekli. Bu mutlaka acı verici olmalı demek değil; fakat yukarıdaki Netflix modeli her yerde uygulanabilir değil ve körü körüne kopyalanmamalı.
Çalıştığım yerlerde ürün iyi tanımlı değildi; ihmal edildiği için değil, yeni ve biçimi belirsiz olduğu için kimse ne olması gerektiğini bilmiyordu. Buna karşılık Netflix’te “videoyu mümkün olduğunca verimli şekilde ekrana ulaştırmak” gibi net bir hedef var; bu da işi saf teknik problem çözmeye yaklaştırıyor.
Elbette reklam ya da back-office gibi ürün geliştirmeleri sürüyordur; ama ürünün temel misyonu epey sağlam olduğu için insanları aynı yöne hizalamaya daha az zaman harcamak yeterli mi, merak ediyorum.
Böyle yazılar gördüğümde her seferinde göz devirmeden edemiyorum. Yazanın ya oldukça junior biri olduğunu ya da çalışanların neden kendi şirketi için çalıştığına dair tuhaf biçimde bozulmuş beklentileri olan bir kurucu tipi olduğunu hissediyorum.
Bu büyük ölçüde SF teknoloji sektörünün tuhaf kültüründen çıkıyor; ama onun dışında insanlar kendi mesleklerini böyle düşünmüyor. Birlikte çalıştığım en iyi geliştiriciler işe “sarhoş” değildi; ne yaptığını bilen profesyonellerdi, bu bilgi karşılığında iyi ücret alıyorlardı ve iş dışında da arkadaşları ve kişisel ilgi alanları olan dolu dolu hayatlar yaşıyorlardı.
Bu anlatı, genç ve kolay etkilenebilir mühendislerin, maaşlarının haklı çıkarabileceğinden daha fazlasını işlerine ve hayatlarından vermesini sağlamaya dönük propagandaya yakın. Genç bir mühendisseniz bunu yapmamalısınız. Heyecanınızı ve saflığınızı kullanıp özel hayatınızı tamamen mahveden çok sayıda patron var; ama normal bir işveren-çalışan ilişkisi bekleyen yerler de çok.
Ürün çıkana kadar ücretleri ertelemeyi önerdiğinde, yıllar boyunca kurduğu güven taktikleri sonunda paraya çevrilmiş oldu; berbat maaşın kasıtlı olduğunu da yavaş yavaş fark ettim. O iş için makul bir ücret ödeyebilirdi; ama düzgün bir karşılık istediğimde karşıma yalnızca direnç, kırıntı gibi vaatler ve duvar örme çıktı.
Daha sonra biriken alacaklarımı istediğimde “verecek para yok” dedi; ama ben öfkelenip ayrıldıktan sonra ikinci projemi baştan yaptırmak için başka birini işe aldı. En hızlı geliştirici ben değildim ve yeni işe aldığı kişi de sanırım epey iyiydi; ama hem bana hem de diğer geliştiriciye göre işimi yeterince yapıyordum.
“Üç iş arkadaşım işten çıkarıldı, şimdi dört kişinin işini yapıyorum; fazla çalıştığımı söylesem de patron dinlemiyor” gibi durumlar. Profesyonel biri ya işten çıkarmalardan önce çoktan ayrılmış olurdu ya da böyle bir durum ortaya çıkınca normal çalışma haftası içinde neyi yapıp neyi yapmayacağı konusunda sınır koyup pazarlık ederdi.
Şirket düşünmeden işten çıkarabiliyor; buna karşın kendi hayatından çok şirketi dert etmeye beyni yıkanmış çok fazla insan var, akıl alır gibi değil.
Sonra bir startupa geçtim ve pişman değilim. Daha çok çalışıyorum ama çok daha keyif alıyorum; sonsuza kadar yapamam belki, fakat maddi karşılığı da daha iyi oldu, bu yüzden eskisi gibi istikrarlı ama sıkıcı bir işte 65 yaşıma kadar çalışmam gerekmeyecek gibi.
Bu, hayatlarının dolu olmadığı ya da sömürüldükleri anlamına da gelmez. Hatta bunun böyle olmadığını söyleyenler, işten elde edilebilecek şeyleri daha az elde ediyor gibi görünüyor. Haftada 40 saati öyle geçirmek biraz yazık.
Temelde Kool-Aid içmiş ve neyi bilmediğini bile bilmeyen bir durumda.
“Kıvılcım”ın bir adım ötesine geçip tam yıkıma yol açan etkenler de var
Şimdiye kadar mühendislik ekiplerini ve ürünleri geriletmede ya da çökertmede büyük rol oynadığını düşündüğüm, eksik bir liste şöyle: aşırı teknik liderler, teknik olmayan liderler, sorunlu mühendisler ve mikroyönetim
Startup büyürken süperstar mühendisler VP Engineering, mimar, CTO gibi liderlik rollerine geçer; ancak lider tipinde değillerse ekip kolayca vizyonsuz bir hayvanat bahçesine dönüşebilir. Tersine, mühendislik deneyimi neredeyse hiç olmayan teknik olmayan liderler de benzer ölçüde risklidir
Yüzeysel mülakatlarla sorunlu mühendisler içeri girer ve işten çıkarma da gevşek olursa, ekibin yalnızca %5–10’u bu tipte olsa bile ilerlemeyi engeller, sorumluluktan kaçar, sadece itibar biriktirir ve berbat çıktıları dayatarak morali ciddi biçimde zedeler. İyi bir mühendislik ekibini ve kültürünü korumak, bir kalemi ucunun üzerinde dik tutmak kadar zor görünüyor
Acemi kurucular çoğu zaman olumsuz geri bildirim vermekte, IC olarak kalması gereken aşırı teknik yöneticileri görevden indirmekte ya da uyumsuz çalışanları göndermekte fazla tereddüt eder
Yerel bir startup, C-level bir yöneticinin UI tasarımcısı arkadaşını ürün VP’si yaptı; işi hiç kaldıramıyordu ama “büyümesi için fırsat veriyoruz” denerek 2 yıl tutuldu. VP’nin altındaki herkes onun yetersiz olduğunu biliyor ve etrafından dolaşmanın yollarını konuşuyordu
Sonunda ürün inisiyatifleri daha başlayamadı bile ve şirket tamamen hizmet tabanlı işlere pivot etmek zorunda kaldı. Şirketteki insanların çoktan gözden çıkardığı niteliksiz bir lideri tutmaya devam eden bir startup’ta kalmamak en iyisi
Aynı şirket, küçülme sırasında ürün VP’sini ve onun neredeyse hiç çalışmayan imparatorluğunu tasfiye etmek için mükemmel bir fırsata sahipti; ancak C-level bağlantıları nedeniyle bundan kaçındı ve bunun yerine mühendisleri işten çıkardı. Önce yüksek ücret alan mühendisleri azaltmaya başlayınca kilit mühendislerini kaybetti; doğru insanları tanıyorsan yetersizliğin de tolere edildiği sinyalini verdi ve sonraki birkaç ay içinde daha fazla kilit kişi ayrıldı
İşe alım hatasını herkes yapar; ama bu hataya nasıl karşılık verdiğiniz şirketin kaderini belirler
“IC’lere kaldırabilecekleri azami özerklik verilmelidir” gibi deneyime dayalı kurallar söyleyebilirsiniz; ama her kuralın istisnası vardır. Sıkıştırılmış bilgelik bağlamını kaybedip yanlış yorumlanmaya ya da deneyimi az biri tarafından kargo kültü gibi taklit edilmeye çok açıktır
Kişisel karakterler ve organizasyon yapısındaki ince farklardan doğan küçük dinamiklerin, herkes iyi niyetle elinden gelenin en iyisini yaparken bile devasa işlev bozukluklarına ve üretkenlik kaybına yol açtığını gördüm. Yukarıdan emir vererek ve merkezi planlamayla iyi mühendislik olmaz
Ürünü ve işi uçtan uca anlayan yeterince insanın, sahadaki mühendisler dahil, bulunması gerekir ki küçük kararlar büyük resme uygun alınsın ve doğru endişeler liderliğe taşınabilsin. Ürün, tasarım, hukuk, finans, destek, güvenlik ve operasyonların kısa ve uzun vadeli maliyetleri birlikte tartılmalıdır
Bu, uzmanların fikir beyan edebildiği ve uygun denge noktalarının bulunabildiği yüksek güven ve güvenlik ortamı varsa mümkündür; ego ve kişilik çatışmaları bunu kolayca engellediği için liderlikte olgunluk gerekir. Kalemi ucunun üzerinde dik tutma benzetmesi epey yerinde
Kişi uygulamayı inceleyip bağlamı olmayan kararların hepsine teknik borç demeye başlıyor. Bunu birkaç kez gördüm; yeni VP Engineering’e, asıl sorunların, kararların ve takvimin içinde hiç bulunmamışken bunlara kötü karar demesinin bilgisizce göründüğünü söylediğim oldu
Neyse ki daha sonra beni ayrıca çağırıp teşekkür etti ve daha fazla arka plan sordu. Hikâyenin tamamını dinledikten sonra doğru seçimler yaptığımıza katıldı. Ama tersine giden durumlar da gördüm; o zaman gerçekten zor oluyor
Tüm ekipleri bir elektronik tabloya koyup tek tip metriklerle yönetimi otomatikleştirmeye çalışıyordu; doğrudan kendisine raporlayan kişileri yönetmeye ve geliştirmeye odaklanmıyordu
Tersine, daha az teknik bir liderin geldiğini ve etrafındaki mühendislerin biraz erkek üstünlükçülüğü katarak göz devirdiğini gördüm; ama gerçekte kötü işe alımları gönderdi, yıldız oyuncuları işe aldı ve herkesin önceliklerini hizalayıp üretken hale getirdi. Liderlik, teknik mükemmellikten tamamen farklı bir iştir ve zam ya da bonusla ödüllendirilmesi gereken yetenekler, fazlasıyla sık biçimde terfiyle ödüllendiriliyor
Liderlik deneyimi olup aynı zamanda uygulama becerisi bulunan; yeterli zaman verildiğinde yeni teknoloji stack’ini veya finansal hamlelerin ayrıntılarını anlayabilen kişiler, uzun vadeli liderlik katkılarıyla sahadaki süperstarlardan saygı görebilir
Katılmıyorum. Küçük bir şirket kurmayı denedim ve FAANG ile büyük bankalar dâhil dev şirketlerde de çalıştım; ama böyle sürükleyici bir ortam her yerde yaratılabilir.
Esas mesele, dinamik bir liderin insanların neden orada olduğunu tam olarak bilen bir ekip kurması, herkese iyi yaptığı işi vermesi ve iyi yapamadığı işlerde de o işi iyi yapanların destek olmasını sağlamasıdır. Sonra ekibin görevinin şirketin misyonu ve dünyadaki amacı açısından nasıl bir değer taşıdığını netleştirmek, üretimin ve etkinin önündeki engelleri inatla kaldırmak gerekir.
N² iletişim gibi iddialar indirgemeci ve isabetsiz. Hiçbir ekip organizasyondaki tüm ekiplere bağımlı değildir; genelde alan küçüktür ve komşu ekiplerin sayısı da sınırlıdır. Çekirdek ekipler istisnadır; ama iyi işleyen bir çekirdek ekip, N² ek yük değil, ekiplerin başvurduğu bir odak noktası gibi çalışarak N yapısına dönüşür.
N büyük olabilir; bu yüzden etkili önceliklendirme, otomasyon, self-servis, kendi kendini belgeleyen tutarlı platformlar ve öğretmeyi gerçekten seven ekip üyeleri önemlidir. Böyle ekipler kurmak yönetim açısından inanılmaz zor olduğu için yoruldum; ama zaten yönetim inanılmaz zor bir iş olmalı. Bir sonraki işimde geç aşama bir startup’ta distinguished engineer olarak köklere bir süreliğine geri döneceğim.
Yine de böyle sürükleyici bir ortamın her yerde yaratılabileceği ve insanların neden orada olduğunu bilen bir ekip kuran dinamik bir liderin önemli olduğu doğru. Gene de bunun ölçek ve kötü teşviklerle ilgili olduğunu düşünüyorum. FAANG’de bile bazı bölümlerin startup gibi, bazılarının ise insanın ruhunu emen bir sıkıcılık olduğu söyleniyor.
Verdiğiniz karşı örnek, N² karmaşıklığının var olmadığına değil, o karmaşıklığın doğru yönetildiğine dair bir örnek.
Tüm ekiplerin diğer tüm ekiplere bağımlı olmadığını söylüyorsanız, aslında yazıyla hemfikir oluyorsunuz. O hâlde hangi kısmın yanlış olduğunu anlamıyorum.
Büyük organizasyonlarda elde edildiği söylenen ölçek verimliliği bana gerçekte verimlilik değilmiş gibi geliyor. İşe alım, İK, kalite güvencesi, kullanıcı araştırması gibi uzman personel bulundurma türünden verimlilikten söz ediyorum.
Daha “verimli” bir organizasyon yapısı kurmak yerine, en küçük hâliyle etkili çalışmış ekip modelini tekrar tekrar kopyalayarak organizasyonu büyütmek daha iyi olabilir. Ama bu “mini şirketlerin” birbirleriyle verimli biçimde nasıl iletişim kuracağı ayrı bir mesele.
Şirketin değeri büyüyüp risk iştahı düşük hissedarlar ve yöneticiler devreye girince, risk yönetimi ve riskten kaçınmaya çok para harcamak gerekiyor. Önceki şirketimde bir rakip, kullanıcı ihtiyaçlarını çözmek için açıkça yasaları çiğniyordu; ama küçük oldukları ve gelirleri de olmadığı için sanırım paçayı kurtardılar.
Ayrıca kişisel deneyimime göre çoğu çalışan, kurucular kadar enerji yatırmıyor; bu da tamamen anlaşılır. Kurucu/çalışan oranı küçüldükçe, tek başınıza yapabileceğiniz işi istikrarlı ve zamanında bitirmek için üç kişi işe alır hâle geliyorsunuz.
İlk işe alınanlar kuruculara yakındır ve şirket başarılı olursa kazanacakları şey daha büyüktür; bu yüzden kuruculara daha çok benzerler. Ama 213. çalışan haftada 40 saatlik emeğini satar ve fiilen elde ettiği neredeyse tek şey sabit maaştır. Bağımsız startup’lardan oluşan büyük şirket fikri romantik olarak güzel; ama pratikte çalıştığını hiç görmedim ve hayal etmekte de zorlanıyorum.
Ölçeklenmenin en iyi yolunun, ekipte istediğiniz özellikleri güçlendiren süreçler oluşturmak ve ekiplerin birbirinden farklı bireylerden oluştuğunu anlayan yöneticiler işe almak olduğunu düşünüyorum. Yöneticiler, kendi insanlarını teslimatı optimize edecek ve ayrılmaları azaltacak şekilde özgürce yönetebilmelidir.
Ekipler arasında iletişim ve çıktı kalitesi standartları çok yüksek olmalı; organizasyon kültürü, işe alınan her bireye saygı ve herkesin etkili çalışabileceği ekibe yerleştirilmesine yönelik inatçı bir odak üzerine kurulmalı.
Emeğin meyveleri giderek daha yükseğe asılıyor. Startup’ın ilk dönemlerinde problem alanı zengindir, bir bireyin yaratabileceği etki anormal derecede büyüktür ve o başarıyı paylaşacak kişi sayısı en azdır.
Şirket büyüdükçe bu üç unsurun tamamı baskı altına girer. Problem alanı seyrekleşir, büyük etki için takdir giderek hiyerarşinin üst kademelerine gider, etkiyi paylaşan kişi sayısı artar ve takdir kısa ve bulanık hâle gelir.
Ama sonunda tek bir dev organizasyona dönüştü. Valve’in yatay organizasyon yapısı da benzer. Yeterince büyüyünce her şey sonunda bir yığına dönüşüyor.
Büyümeyi yönetme sanatının önemli bir kısmı, insanları zincire vurmak yerine özgürleştirmenin yollarını bulmaktır.
“Çoğu startup, büyük şirket süreçlerini kopyalayarak gereksiz yere kurumsallaşma hızını artırır. Genelde büyük şirketlerden yöneticiler getirirler ve onlar da kendi playbook’larını getirir” cümlesi acı verecek kadar doğru.
Bu döngüyü birkaç kez yaşadım. En sevdiğim ve son başarılı olan startup, 4. yılında, 2007’de dev bir küresel şirket tarafından satın alındı; ben de 2 yıl daha kaldım.
Ürün piyasaya çıktıktan sonra müşteri desteği ve satış desteği ihtiyacı yüzünden kesinlikle yavaşladık. Harika VP Engineering CTO oldu; orta kademe yönetici olarak bir aptalı VP diye işe alınca da iyi günler bitti. Yeni VP, iyi mühendisler yerine “takım oyuncuları” işe aldı, yetkinlikten çok sadakati ödüllendirdi ve gülünç şeyler yaşandı.
Eğlenceli startup benzeri zamanım yılda tam bir haftaya, Noel ile yılbaşı arasına indi. O hafta kimse ortalıkta olmadığı için önemli olduğunu düşündüğüm işleri çok daha özgürce yapabiliyor, parlak yeni bir özelliğin alfa sürümünü çıkarıp organizasyonun peşimden gelmesini sağlayabiliyordum.
Aday havuzunda şaşırtıcı derecede çok köpekbalığı gibi insan var. Çıkıp geliyorlar, yeni olduğunuzu seziyorlar, duymak istediğiniz her şeyi söylüyorlar ve tüm sorunları çözeceklerini anlatıyorlar. Önceki her şirketlerinde tam da sizin ihtiyaç duyduğunuz işi yaptıklarını iddia ediyor, yağcılık yapıyor ve sizin gibi biriyle çalışma fırsatını beklediklerini söylüyorlar.
Bunu, şimdiye kadar mülakata aldığınız en kaypak IC adayının beş kat daha güçlü ve fark etmesi daha zor bir versiyonu gibi düşünebilirsiniz. İnanılmaz bir karizmaları var ama zor işleri yapmaya pek niyetleri yok; şirkete sızdıktan sonra söküp almak istiyorlar.
Kendi ücretlerini, arkadaşlarını işe alacak kadroları, arkadaşlarının ücretlerini, dışarıdaki arkadaşları için kârlı sözleşmeleri koparırlar; hatta komisyon bile olabilir. Çok fazla hareketlilik yarattıkları için aslında pek bir şey yapmadıklarının anlaşılması yıllar sürebilir. Bu süreçte yetenekli çalışanlar saçmalıklardan bıkıp ayrılabilir ya da beceriksizliğe işaret ettikleri için kenara itilip gidebilir.
Safi Bahcall’ın Loonshots kitabı bu olguyu oldukça iyi açıklıyor. Yaklaşık 150 kişi civarında teşviklerde bir “faz geçişi” yaşanıyor ve bu birçok organizasyon için ölümcül olabiliyor.
İşin püf noktası, startup’ın bu çalışan sayısını nasıl aştığında yatıyor. Açıkçası birçok yazılım şirketinin 150’den fazla çalışana ihtiyacı olmayabilir.
Dunbar sayısı, istikrarlı sosyal ilişkiler sürdürebilecek kişi sayısına dair bilişsel bir sınır olarak önerilen bir kavramdır. Buradaki ilişki, her bir kişinin kim olduğunu ve birbirleriyle nasıl bağlantılı olduklarını bilmeyi ifade eder.
https://en.wikipedia.org/wiki/Dunbar%27s_number
Dünya bu sınırı binlerce yıl önce çoktan aşarak ölçeklendi; şirketler de bunun ötesine ölçeklenebilir.
Daha az işe alın tavsiyesinin değeri ne kadar vurgulansa az. Başka bir deyişle, yalnızca sorunu çözmenin başka yolu yoksa işe alın; o zaman bile dikkatli olun.
Bu ilke yüzünden takvimin epey uzamasını göze almak gerekir. Aşırı işe alımın orta-uzun vadeli maliyeti, lansman gecikmesinin maliyetinden çok daha kötüdür. Ne yazık ki startup’ların finansman ortamı ve büyüme beklentileri çoğu zaman tam tersini teşvik eder.
Yine de Silikon Vadisi startup’larındaki işe alım durumunun bu kadar kötüleştiğini epey hafife almışım. Birçok kişi, FAANG tükenmişliğinden toparlanırken ya da mülakatlara hazırlanırken CV’sine yazacak bir pozisyon olarak startup’ları kullanıyor.
Böyle bir yapıda, şirketi kurabilecek az sayıdaki kişiyi kaçırma riski yüzünden işe alım yöneticilerinin aşırı iyimser tarafa kayması kolay. Sonuçta iyi uymayan insanları agresif biçimde göndermek gerekiyor.
Bu yazıda hoşuma giden kısımlar da vardı, katılmadığım kısımlar da.
En çok katıldığım bölüm “çok hızlı işe alım yapmayın”dı. İşe alım çok yavaş olduğu için başarısız olan ya da acı çeken startup veya şirket pek aklıma gelmiyor; ama çok hızlı işe alım yüzünden çıkan sorunlar, kendi deneyimlerim de dahil, aklıma fazlasıyla geliyor.
Öte yandan “Jira kullanmayın” kısmı göz devirmeme neden oldu. Güneşin doğudan doğması gibi, mühendislerin Jira’yı gömmesi de sevdikleri bir hobi. Startup’ın türüne bağlı olarak Jira bu iş için çok iyi bir araç olabilir.
Şirketin desteklemesi gereken çok sayıda iş akışı varsa, takip iyi yapılmadığında ve issue sahipliği net olmadığında kaçan işler artar ve ciddi zaman kaybı yaşanabilir. Elbette gereksiz durumları milyon tane yaratıp Jira’yı aşırı karmaşık hâle getirerek de zaman kaybetmek kolaydır; ama günümüzde Jira’nın küçük ekiplerin hızla verimli kullanmasına daha uygun hâle geldiğini düşünüyorum.
Jira’nın başlamak için en iyi araç olduğu anlamına gelmiyor; önceki startup’ımız Trello ile başladı ve iyi gitti. Ancak operasyona geçtiğinizde ve yeni özellik geliştirmeyle birlikte çok sayıda operasyonel issue’yu yönetip önceliklendirmeniz gerektiğinde, herkesi aynı hizaya getirmek ve bilgiyi paylaşmak için Jira gibi bir araca ihtiyaç duyma olasılığınız yüksektir.