# Orta seviyeden senior'a geçerken beklenen "daha geniş etki"yi nasıl gösteririm?

> "Daha geniş etki" daha büyük feature demek değil; etkinizin yazdığınız kodun ötesine, ekibe ve sistemlere ulaşmasıdır. Sahipsiz, bulanık bir problemi uçtan uca üstlenin.

- Soruldu: 2026-07-24
- Yanıtlandı: 2026-07-28
- Soran: Deniz
- Etiketler: kariyer, gelişim
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/orta-seviyeden-seniora-gecerken-beklenen-daha-genis-etki-yi-nasil-gosteririm/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Özellikleri güvenilir biçimde teslim ediyorum, sprint'lerde tıkanmıyorum ve kod kalitem iyi. Ama lead'im terfi için sürekli "daha fazla scope" ve "daha geniş etki" göstermem gerektiğini söylüyor.

Açıkçası bunun pratikte ne demek olduğunu tam çözemiyorum. Daha çok mu iş almalıyım, daha büyük feature'lar mı yazmalıyım, yoksa bambaşka bir şey mi bekleniyor? Somut olarak hangi davranışları değiştirmem gerekiyor?


Kısa cevap: "Daha geniş etki" daha çok kod ya da daha büyük feature değildir; etkinizin, tek başınıza yazdığınız kodun sınırlarını aşıp etrafınızdaki insanları ve sistemleri daha iyi hale getirmesidir. Scope, satır sayısı değil etki yarıçapıdır.

1. **Ticket değil, sonuç sahiplenin.** Orta seviye net tanımlı task'leri iyi kapatır. Senior, bulanık ve tanımsız bir problemi alır: kendisi tanımlar, parçalara böler, insanlar arasında koordine eder ve belirsizliği yönetir. "Bana ne yapacağımı söyle"den "şu problemi ben alıyorum"a geçiş budur.

2. **Çarpan olun.** Senior'ın kodu ekip tarafından kopyalanır. Öğreten code review'lar, izlenen desenler, junior'ları açan dokümanlar — kendi throughput'unuzu değil ekibin throughput'unu artırırsınız. Bir kişinin yaptığı iş kadar, sizin sayenizde beş kişinin daha hızlı yaptığı iş de sizindir.

3. **Kararı tradeoff'larla getirin.** Lead'e "ne yapayım?" diye gitmek yerine "iki seçenek var, artıları/eksileri şunlar, ben B'yi öneriyorum çünkü…" diye gidin. Kısa design doc'lar, ADR'lar yazın. Senior'lık, doğru cevabı bilmekten çok doğru soruyu sorup kararı yazılı savunabilmektir.

4. **Operasyonel sahiplik alın.** Bir alanın on-call hikâyesini, toil'ini ve incident'lerini sahiplenin. Etkiyi teknik değil iş diliyle anlatın: "p99 latency'yi %40 düşürdüm" değil, "checkout'taki gecikmeyi düşürüp sepet terk oranını azalttım". Güvenilirlik, en görünür scope alanlarından biridir.

5. **Etkinizi görünür kılın.** Sessizce iyi iş yapmak tek başına terfi getirmez; yaptıklarınızı bir "brag doc"ta biriktirin ve metriklerle bağlayın. En pratik adım ise şu: lead'inizden "senin gözünde 'scope' gösteren somut bir örnek nedir?" diye net bir örnek isteyin, sonra onu bir projeye çevirin.

Burada kod değil davranış konuşuyor, o yüzden örneği de davranışla vereyim: bir sonraki bulanık işte lead'e gidip "ben bunu sahipleneyim mi?" diye sorun ve evet aldığınızda haftalık kısa bir güncellemeyle ilerleyişi görünür tutun. Bu iki cümle çoğu insanın hiç yapmadığı şeydir.

**Sonuç:** Ben olsam terfiyi soyut bir hedef olarak kovalamaz, somut bir hamleye çevirirdim: ekipte kimsenin sahiplenmediği, herkesin şikâyet ettiği bulanık bir problemi seçip bir çeyrek boyunca uçtan uca üstlenirdim — tanımını, çözümünü ve ekibe yayılmasını. Terfi dosyanız tam olarak budur. Scope bir gün size verilmez; siz doldurmaya başlayınca fark edilir.