@ahmetcantryk
Ece, tech lead olduktan altı hafta sonra kendini junior bir arkadaşının takıldığı pull request'i ona anlatmak yerine bizzat bitirirken buldu. Bu tek alışkanlık, tech lead'liğin ilk 90 gününün neden bu kadar zor olduğunu özetliyor: artık kendi commit'lerin değil, ekibinin çıktısı değerli ve bu geçişin el kitabını kimse sana vermiyor.
Kimse Seni Hazırlamıyor: Kimlik Değişimi
Ece dört yıl boyunca odadaki herkesten daha hızlı ve daha titiz çalışarak başkalarının hatalarını çözen kişi olmuştu. Terfi almasını sağlayan da tam olarak buydu. Aynı beceri, kontrol altına alınmadığında yeni bir tech lead'i sessizce baltalayan beceri hâline geliyor. Başkasının pull request'ini bitirmek için harcadığı her saat, aslında sadece kendisinin yapabileceği işlere ayrılmayan bir saatti: başka bir ekiple takılan API sözleşmesini çözmek, acele verilen bir teslim tarihine itiraz etmek ya da junior bir mühendisin işi izlemek yerine gerçekten debug etmeyi öğrenmesini sağlamak gibi.
Güçlü IC'leri (bireysel katkı sağlayanları) en çok şaşırtan da bu. Eskiden kodunla değerlendirilirken artık etrafındaki ekibin iyi kod üretip üretmediğiyle, zamanında teslimat yapıp yapmadığıyla ve büyüyüp büyümediğiyle değerlendiriliyorsun. Kendi klavye başında geçirdiğin süre, şirketin seni ölçme biçiminde neredeyse anlamsızlaşıyor. İlk 90 günün en zor becerisi bir plan hazırlamak ya da iyi bir birebir görüşme yapmak değil; bir takım arkadaşı takıldığı anda klavyeye uzanma isteğine direnmek. Çünkü her uzandığında, ileride ihtiyaç duyacağın güveni harcıyor ve karşındaki kişinin kendi başına gelişme fırsatını elinden alıyorsun.
Gerçekten İşe Yarayan Bir 30-60-90 Günlük Plan
30-60-90 günlük plan, yeni mühendislik liderleri için standart bir işe alışma aracı ve bunun iyi bir nedeni var: seni çeyrek için iki üç büyük hedef belirlemeye, sonra her hedefi somut ve SMART alt hedeflere bölmeye zorluyor. "Paydaşlarla tanış" değil, "ilk 30 günde ürün paydaşlarıyla beş birebir görüşme planla" gibi. Belirsiz niyetler yoğun bir ilk çeyreği atlatamaz; somut ve tarihli taahhütler atlatır.
İlk 30 Gün: Dinle ve Haritayı Çıkar
İlk ay, nöbet düzenini yeniden kurmanın ya da sprint sürecini baştan yazmanın zamanı değil; farklı yapardım dediğin üç şeyi çoktan görmüş olsan bile. Bu dönem, neden seçildiğini, ekibin gerçek kısıtlarının ne olduğunu ve henüz sahip olmadığın bağlamı kimin elinde tuttuğunu anlama zamanı. Her ekip üyesiyle ve ulaşabiliyorsan ekibin önceki liderleriyle birebir görüşmeler yap. Herhangi bir şey önermeden önce mevcut strateji dokümanlarını, OKR'leri ve post-mortem'leri oku. İlk kez ekip yöneten bir mühendisin LeadDev'de anlattığı deneyim de aynı noktaya işaret ediyor: en çok canını yakan hatalar, bu dinleme aşamasını atladığında yaptıklarıydı. Ece ilk üç haftasını neredeyse tamamen dinleyerek geçirdi ve bu ona rahatsız edici derecede yavaş geldi; ta ki ekibin daha önce iki kez tartıştığı bir önbellekleme kararını yeniden gündeme getirmekten onu kurtarana kadar.
30-60. Günler: Gözlemlerini Dile Getirmeye Başla
Dinlemeden liderliğe geçiş genellikle bu aşamada gerçek anlamda oturuyor. Artık fikir sahibi olacak kadar bağlam biriktirdin ve ekip de senden fikir bekleyecek kadar seni tanıdı. Küçük başla: bir süreç değişikliği öner, fark ettiğin bir riski dile getir, ekibin günlük çalışma biçimini etkileyen tek bir karar ver. Bu aşama, yüksek riskli bir şeye öncülük etmeden önce yargını gerçek geri bildirimle sınadığın dönem ve etkili kod incelemesi yapmanın da salt bir kalite kapısı olmaktan çıkıp bir liderlik aracına dönüştüğü yer burası; yorumların artık sadece neyin bozuk olduğunu değil, ekibin neye değer vermesi gerektiğini de işaret etmeye başlıyor.
60-90. Günler: Gerçek Değişikliklere Öncülük Et
Üçüncü aya gelindiğinde bir kararı uçtan uca sahiplenebilmelisin: sorunu tanımlamak, anlaşmazlıklar arasından onu ileriye taşımak, yayına almak ve sonucundan sorumlu olmak. Bu aynı zamanda yapmak istediğin bir değişiklik için RFC yazmak için doğal bir zaman; çünkü yazılı bir öneri, kararla birlikte yaşayacak kişilerin önünde onu savunmanı zorunlu kılıyor ve bu tam olarak bir tech lead'in erken pratik yapması gereken sorumluluk türü.
Aşama | Odak | Somut Hedefler | Kiminle Görüşüyorsun |
|---|---|---|---|
İlk 30 gün | Dinle ve haritayı çıkar | 5+ birebir görüşme, tüm OKR ve strateji dokümanlarını oku, süreçte değişiklik yok | Ekip üyeleri, önceki lider, yöneticin |
30-60. gün | Gözlemlerini dile getir, küçük öneriler sun | Bir süreç değişikliği yayına al, bir riski açıkça dile getir, bir retro yönet | Diğer tech lead'ler, ürün ortağı, skip-level yönetici |
60-90. gün | Gerçek değişikliklere öncülük et | Bir kararı uçtan uca sahiplen, bir RFC yayınla, gelecek çeyreğin hedeflerini belirle | Fonksiyonlar arası ortaklar, yöneticin, tüm ekip |
Tam anlamıyla 30-60-90 günlük bir plana harfiyen uyulması nadirdir; bazı maddeler gecikir, bazıları erken tamamlanır ve bu gayet normaldir. Değer, takvime birebir uymakta değil; hedeflerini baştan adlandırmanın ve planı kendi yöneticinle beklentileri hizalamak için kullanmanın zorlayıcı gücündedir.
İlk 90 Günde Kurulan Geniş Bir Ağ
İlk 90 gününde kurduğun ilişkiler orantısız derecede değerli, çünkü temel sorular sormaya bu kadar rahat lisansa bir daha asla sahip olmayacaksın. Skip-level yöneticinle zaman ayır; sadece görünür olmak için değil, senin ekibinden gerçekte ne beklediğini anlamak için. Kendi grubunun dışındaki tech lead'lerle tanış; iki yıl sonra bir bağımlılık tıkandığında seni çözüme kavuşturacak kişiler onlar olacak. Ekibinin yol haritasına dokunan fonksiyonlar arası ortaklarla, yani ürün, tasarım ve veri ekipleriyle tanış; çünkü staff engineer'ların kurduğu türden şirket geneline yayılan bir ağ, unvanın "lider" değil de "staff" olsa bile aynı şekilde büyür. Ece'nin o çeyrekten kalan en değerli ilişkisi, sadece ilk birebir görüşmelerine fazla kişi davet ettiği için tanıştığı, iki ekip ötedeki bir veri analistiyle kurduğu bağlantı oldu.
Odadaki En İyi Kodcu Olma İhtiyacından Vazgeçmek
İkinci ayın bir noktasında, Ece'nin ekibinden biri, onun kendisinin yazacağından daha iyi bir çözümle çetrefilli bir eşzamanlılık hatasını yayına aldı. İlk tepkisi hafifçe savunmacıydı. İkinci ve daha yararlı tepkisi ise bunun tam olarak amaçlanan şey olduğunu fark etmekti: ekibi zor bir problemde ondan daha iyi mühendislik yapabiliyorsa, işini doğru yapıyor demekti. Odadaki en güçlü bireysel katkı sağlayan olma ihtiyacından vazgeçmek bir statü kaybı değil; rolün asıl teslim ettiği şey budur. Burada tükenmişliğe de dikkat etmek gerekir: hem liderlik yapıp hem de en iyi kodcu kalmaya çalışmak, aslında iki tam zamanlı işi birden yapıp ikisini de iyi yapamamanın hızlı bir yolu ve pek çok yeni lider bunu üçüncü ayda zor yoldan öğreniyor.
Bu geçiş mentorluk şeklini de değiştiriyor. Birini junior'dan senior'a taşımak artık senin üzerinden geçiyor ve bu, on saniyede yazabileceğin bir cevabı bile, karşındaki kişi kendi başına bulana kadar geri tutman anlamına geliyor. Ayrıca tahminlerinin şekli de değişiyor: bir projeye öncülük etmek, yalnızca kendi sezgine değil başkalarının girdilerine dayanan daha iyi mühendislik tahminleri yapmayı gerektiriyor.
Uyarlayabileceğin Bir 30-60-90 Şablonu
Kendi ekibinin Temmuz 2026 itibarıyla gerçeğine göre uyarlayarak doldur:
- İlk 30 gün hedefi: Ekibin en büyük mevcut riskini, önceki lider dâhil N kişiyle konuşarak anla.
- 30-60. gün hedefi: Bir süreç ya da araçta bir değişiklik öner ve kod incelemesinde belirlediğin önceliği yansıtan geri bildirimler ver.
- 60-90. gün hedefi: Belirli bir kararı ya da projeyi uçtan uca sahiplen; buna RFC yazmak ve sonucu yöneticine raporlamak da dâhil.
- Ağ hedefi: Skip-level yöneticinle, en az üç eş seviye lider ile ve ekibinin bağımlı olduğu her fonksiyonlar arası ortakla haftalık olarak görüş.
Sıkça Sorulan Sorular
İlk 90 günde bir tech lead ne kadar kod yazmaya devam etmeli?
Teknik güvenilirliğini korumaya yetecek kadar, bir darboğaza dönüşmeyecek kadar az. Deneyimli liderlerin çoğu, ilk ayı geçtikten sonra kodu bol bol okumayı ama üretim koduna nadiren yazmayı öneriyor; çünkü klavyede geçen her saat, ekibinin senden gerçekten ihtiyaç duyduğu engel kaldırma, koçluk ve ilişki kurma işlerine ayrılmayan bir saat.
30-60-90 hedeflerimi takvime uygun tutturamazsam ne olur?
Bu normaldir. 30-60-90 planı, sabit teslim tarihleri olan bir sözleşme değil, yön ve beklenti belirlemeni sağlayan zorlayıcı bir araçtır. Birkaç haftada bir yöneticinle planı gözden geçir, neyin geciktiğini ve nedenini not et, kaçırılan bir tarihi başarısızlık saymak yerine planı güncelle.
Hâlâ koda fazla müdahil olup olmadığımı nasıl anlarım?
Yararlı bir işaret: takım arkadaşların takıldıkları sorunları kendi başlarına çözmek yerine sana yönlendirmeye başlıyorsa ya da başkasının branch'indeki düzeltmeleri sen merge ediyorsan, IC moduna geri kaymışsın demektir. Ne kadar koda dokunduğunu değil, engel kaldırma ile işi bizzat yapma arasındaki oranı takip et.
İlk 90 günde geniş bir ağ kurmak gerçekten buna ayrılan zamana değer mi?
Evet ve etkisi yıllar boyunca katlanarak büyüyor. İlk çeyreğinde tanıştığın eş seviye liderler, skip-level yöneticin ve fonksiyonlar arası ortaklar; seni engellerden kurtaran, mayınlı alanlar konusunda uyaran ve sen orada olmadığında seni savunan kişiler hâline geliyor; hem de ilk 90 gün çoktan unutulduktan çok sonra bile.
