Oryantasyonun İlk 90 Günü - Performans Algısı Nasıl Şekillenir
İlk 90 Gün Performans Değil, Hikaye
Yeni şirkette ilk üç ay sana ne kadar iyi yazılımcı olduğunu kanıtlama dönemi gibi görünüyor. Aslında değil. İlk 90 gün performans ölçen bir dönem değil, hakkında hikaye kuran bir dönem. Yöneticin, takım arkadaşların, hatta üst yönetim seninle ilgili bir hikaye yazıyor; "hızlı adapte oldu", "soru sormaktan çekinmiyor", "ilk PR'da kalite yüksekti" gibi cümleler. Bu hikaye altı ay sonraki performans değerlendirmesinde, bir yıl sonraki maaş zammında, hatta ilk terfide referans noktası oluyor.
Sorun şu: çoğu yazılımcı bu üç ayı "öğrenme dönemi" olarak geçiriyor; sessizce kodu okuyor, mevcut sistemi anlamaya çalışıyor, kötü bir izlenim bırakmamak için risk almaktan kaçınıyor. Bu strateji güvenli ama stratejik değil. Çünkü ilk 90 gün boyunca herkes seninle ilgili kararını veriyor, sen ise henüz "hazır olmadığın" için bu süreçte pasif kalıyorsun.
Bu yazıda ilk 90 günü stratejik geçirmek için neye dikkat etmek gerektiğine, hangi tuzaklara düşmemek lazım olduğuna ve ilk performans değerlendirmesine ne tür kanıtlarla girmen gerektiğine bakıyoruz.
Demo Etkisi Nedir, Nasıl Çalışır?
Yeni başlayanın hatırlanma şekli ilk üç-dört çıktısıyla şekilleniyor. İK literatüründe buna çapa atma deniyor: insanların seninle ilgili ilk veriyle bir referans noktası oluşturup sonraki tüm değerlendirmeleri o noktaya göre yapması. Yazılım takımlarında bunun en somut hali "demo etkisi" olarak görünüyor.
Demo etkisi kabaca şöyle çalışıyor: ilk üç ayda görünür bir çıktı (bir PR, bir demo, bir küçük proje) takıma sunduğunda, o çıktının kalitesi senin "varsayılan kalite seviyen" olarak işaretleniyor. Sonraki altı ayda yaptığın işler bu seviyenin altına düşerse "ilk performansını koruyamadı" gibi bir algı oluşuyor; üstüne çıkarsa "ilk başta sessizdi ama açıldıkça çıkardı" diye okunuyor.
Bu etki adil değil ama gerçek. Pratik anlamı şu: ilk 90 günde tek bir görünür çıktı üretmek, üç ay boyunca sessizce çok iyi kod yazmaktan daha etkili. Görünür çıktı ille büyük olmak zorunda değil; takımın bir acı noktasını çözen küçük bir tooling, dokümante edilmemiş bir akışı dokümante etmek, ya da oryantasyon sürecini kolaylaştıran bir kontrol listesi bile olabilir.
İlk PR Hangi Sinyali Veriyor?
İlk PR'ın sandığından çok daha fazla şey söylüyor. Sadece "kod yazabiliyor mu" sorusunu cevaplamıyor; soru sorma alışkanlığı, dokümantasyon okuma disiplini, kod tarzı, takım konvansiyonlarına saygı, kod incelemesi sürecinde nasıl davrandığın gibi yarım düzine sinyal aynı anda toplanıyor.
İlk PR için tipik tavsiye "küçük bir bug fix bul, hızlıca aç". Bu doğru ama eksik. İdeal ilk PR şu üç özelliği taşıyor:
- Sınırlı kapsam, 50-200 satır arası. Daha büyük PR ilk haftada inceleyenleri yoruyor; daha küçükse "trivial change" olarak okunabilir.
- Mevcut kod tarzına uyum. Lint kuralları, naming, dosya organizasyonu - hiçbiri zorlanmasın. PR'da senin tarzın değil, takımın tarzı görünmeli.
- Açıklama yazılı. Commit mesajı + PR açıklaması: ne değişti, neden değişti, nasıl test edildi. Takımın aynı yapıyı kullanmasa bile sen yaz; "yeni başlayan ama disiplinli" sinyali güçlü.
İlk PR'ın bir bug fix değil, dokümantasyon güncellemesi olabilir. Oryantasyon sırasında karıştığın bir adımı dokümana ekleyen bir PR, hem teknik bir katkı hem de takım kültürüne uyum sinyali. Eski yazıda CV ve LinkedIn rehberinde bahsedilen ATS taraması mantığı burada da geçerli: ilk PR'ın bir tarayıcının önünden geçiyor, yöneticin saniyeler içinde değerlendiriyor.
Yöneticinle İlk Üç Konuşma
İlk 90 günün muhtemelen en çok ihmal edilen kısmı yöneticiyle kurulan ilişki. Çoğu yeni başlayan yöneticisini sadece haftalık 1:1'lerde görüyor ve o görüşmelerde gündem çoğunlukla "haftalık güncelleme" oluyor. Bu yetersiz.
İlk 90 gün boyunca yöneticinle üç farklı konuşma yapman gerekiyor:
Birinci konuşma - beklenti netleştirme: İlk iki haftada. Şu soruyu sor: "İlk 90 günün sonunda nasıl bir görüntü senin için başarı sayılır?" Cevap muğlaksa ("hızlıca adapte ol", "kodu öğren") tekrar zorla: "Somut bir örnek verir misin? Hangi konuda hangi seviye?" Bu cevap senin sonraki üç ayın yol haritası oluyor.
İkinci konuşma - ilk geri bildirim. 30-45. günde. "Bana açık geri bildirim verir misin? Hangi konularda iyi gidiyorum, hangilerinde gelişmem gerekiyor?" Bu sorunun zamanlaması önemli; çok erken sorarsan yöneticinin sana dair somut gözlemi olmaz, çok geç sorarsan ilk algı zaten kemikleşmiş olur.
Üçüncü konuşma - 90. gün değerlendirmesi. 80-90. günde. "İlk 90 günde belirlediğimiz hedeflere göre nasıl gidiyorum? Önümüzdeki 90 gün için yeni hedefler belirleyelim mi?" Bu konuşma, ilk performans değerlendirmesine bir ön provadan ibaret. Burada öğrendiklerin, altı ay sonraki resmi değerlendirmede aynı yöneticiyle aynı dili konuşmana yardım ediyor.
Performans değerlendirmesi rehberinde detaylı paylaştığımız 1:1 disiplini bu üç konuşmanın temel altyapısı.
Soru Sorma Stratejisi - Ne Sorulur, Nasıl Sorulur?
Yeni başlayan iki tür hata yapıyor: ya hiç soru sormuyor (gözden kaybolma riski) ya da her şeyi soruyor (zaman kaybettirme riski). Doğru orta yol soru sormanın maliyet-fayda dengesini anlamaktan geçiyor.
Birkaç pratik kural var:
İlk olarak sorudan önce 15 dakikalık öz-araştırma yap. Dokümantasyona, repository'nin kendisine, eski Slack/Teams mesajlarına bak. Hala bulamadıysan sor. Bu önaraştırma görünür bir disiplin sinyali; "Şuraya baktım, bulamadım" diyerek soru sormak "hiç bilmiyorum" demekten çok farklı duyuluyor.
İkinci olarak sorularını toplu sor. Bir kerede beş soru sormak, beş ayrı zamanda bir soru sormaktan daha az kesinti yaratıyor. Notlarını gün boyu biriktir, akşam ya da haftalık 1:1'de toplu sor.
Üçüncü olarak doğru kişiye sor. Bir mimari kararı yöneticine sormak yerine senior yazılımcıya, bir İK sorununu yöneticinle konuşmak yerine doğrudan İK'ya yönlendirmek hem cevap kalitesini hem hız algını artırıyor.
Dördüncü olarak sorduğun her şeyi yaz. Soru-cevap notu tutmak hem aynı soruyu iki kez sormamanı sağlıyor hem de 60. günde yöneticinle yapacağın değerlendirme konuşmasında "şunları öğrendim" listesi olarak işine yarıyor.
Sosyal Bağlantı - Sadece Yazılımcılar Değil
İlk 90 günün teknik tarafına çoğu yazılımcı dikkat ediyor; sosyal tarafına çok azı. Aslında sosyal yatırım uzun vadede daha yüksek getirili.
Üç farklı katman var:
Yakın takım. Doğrudan birlikte çalıştığın 4-8 kişi. Bu insanlarla en az ayda bir kahve içmek, masada yemek yemek, yan masada kod yazarken sohbet etmek - hepsi performans algının yapı taşı. Bu insanlar yöneticiye seninle ilgili ne söylerse söylesin, sözel olmayan kanal en güçlü değerlendirme kaynağı.
Diğer takımlar. Backend takımındaysan frontend, DevOps, ürün, tasarım - hepsiyle tanışmak. Bu çoğu zaman doğal kanaldan olmuyor; istek üzerine olur. "Ürün takımında çalışan biriyle 30 dakika konuşabilir miyim, akışı anlamak için" demek yeterli. Bu konuşmalar hem teknik bağlamı genişletiyor hem de ilerideki cross-team projelerde "bu ismi tanıyorum" demene yardım ediyor.
Yönetim ve İK. İlk 90 günde üst yönetimle direkt temas çoğunlukla sınırlı; ama olabilecek bir şirket etkinliği, all-hands toplantısı, takım dışı sunumlarda görünür olmak. İK ile en az bir kez tanışmak (sözleşmen, yan haklar, eğitim bütçesi konularında) ileride faydalı.
Şirket içi yatay geçiş yapmak istediğinde şirket içi rotasyon yazısında belirtildiği gibi referans şebekesi en kritik faktör. İlk 90 günde kurduğun bağlantılar üç yıl sonra rotasyon talebinde işine yarıyor.
İlk Maaş Hakkında Ne Zaman Konuşmalısın?
Yeni başlayan çoğu yazılımcı ilk yıl maaş konusu açmaktan çekiniyor. Bu kısmen mantıklı; ilk yıl katkın hala ölçülüyor. Ama tamamen pasif kalmak da yanlış strateji.
İlk 90 günde maaş konusu açmıyorsun ama altyapıyı kuruyorsun. Bunun anlamı şu:
İlk olarak şirketin maaş artış takvimini öğren. Yıllık mı, altı aylık mı? Performans değerlendirmesi ne zaman? Yeni başlayanlar bu döngüye dahil mi yoksa ilk yıl atlanıyor mu? Bu bilgi İK'dan ya da daha önceden başlamış takım arkadaşlarından geliyor.
İkinci olarak şirketin terfi takvimini öğren. Junior'dan Mid'e, Mid'den Senior'a geçiş ne zaman değerlendiriliyor, hangi kıstaslarla? Bu bilgi takımının senior'larından geliyor.
Üçüncü olarak başarı kaydı tutmaya hemen başla. İlk PR, çözdüğün ilk bug, dokümante ettiğin ilk akış - hepsi ilk performans değerlendirmesinde sana lazım. Geriye dönük yazılması zor; günlük tutarsan altıncı ayda elinde 50+ kalemlik bir liste oluyor.
İlk maaş konuşmasının doğal zamanlaması ilk performans değerlendirmesi (genelde 6-12 ay sonra). O zamana kadar yıllık zam müzakeresi rehberinde paylaşılan stratejilere hazırlanıyorsun.
En Sık Yapılan Üç Hata
İlk 90 gün tuzakları çok belli kalıplarda tekrar ediyor:
Birinci hata - sessiz kalmak: "Daha tam öğrenmedim, görüşlerimi söylemeyeyim" düşüncesiyle her toplantıda susmak. Bu strateji ilk üç ay güvenli görünüyor ama dördüncü ay itibarıyla "bu kişi pasif" algısı yerleşiyor. Bunu kırmak zor. Çözüm: ilk haftadan itibaren soru sormak (görüş değil), 30. günden itibaren küçük öneriler getirmek, 60. günden itibaren görüş belirtmek.
İkinci hata - yanlış savaşı seçmek: Yeni başlayan bazen mevcut sistemde gördüğü kötü kararları hemen sorgulamaya başlıyor. "Bu mimari neden böyle?", "Bu kod neden bu kadar dağınık?" gibi sorular ilk haftalarda "yeni geldi, hemen eleştirmeye başladı" olarak okunuyor. Bu sorular 60-90. günde, tarihsel bağlamı öğrendikten sonra sorulduğunda çok daha güçlü oluyor.
Üçüncü hata - aşırı çalışma: İlk üç ay boyunca akşam mesai yapmak, hafta sonu çalışmak, izin kullanmamak ilk anda iyi izlenim gibi görünüyor; uzun vadede tükenmişlik fitilini ateşliyor. Yazılımcı tükenmişliği yazısında bahsedilen döngü genelde ilk 90 günün aşırı çalışma alışkanlığıyla başlıyor. Sürdürülebilir tempo ilk günden kurulmalı.
90. Gün Sonrası
İlk 90 gün bitince üç şey değişiyor: takım sana "yeni başlayan" muamelesi yapmayı bırakıyor, yöneticin sana ait somut bir görüş oluşturmuş oluyor, sen de şirketin gerçek dinamiklerini görebiliyorsun.
Bu dönüm noktası kullanılması gereken bir an. 90. günde kendin için bir öz-değerlendirme yap: ne öğrendim, ne çıktı verdim, kimleri tanıdım, sırada ne var? Bu öz-değerlendirme bir sonraki 90 günün haritası oluyor.
İlk 90 günü iyi geçirmek bir maraton koşusunun ilk üç kilometresi gibi. Tempo erken belirleniyor, hata yapılırsa toparlamak ileride zorlaşıyor; doğru kurulduysa kalan parkur çok daha rahat geçiyor.
Veriye dayalı maaş analizi için Dashboard'a göz atabilirsin - ilk 90 günün sonundaki performans konuşmasında kanıt olarak kullanmak için sektör ortalamasını bilmek işine yarayacak.