Yeni iş yerlerinde 3 kere onboard edildim. Bazı yerlerde 2 haftada productive oldum, bazılarında 2-3 ay debug mode’daydım. Şimdi iki küçük ekibi yönetiyorum, aradaki farkı yaratan ne olduğunu biliyorum.
Onboarding doğru yapıldığında yeni developer’ın ikinci haftasında gerçek bir PR açıyor. Yanlış yapıldığında ikinci ayında bile standup’ta “hala environment kuruyorum” diyor.
Bu yazıda 6 maddelik süreç.
1. Environment 1. günde hazır olsun
En çok zaman kaybedilen yer local dev environment. Docker compose’da typo, gerekli env variable’ı yok, dokümanda referans verilen internal tool’a erişim yok, falan falan.
Yeni developer’ın ilk günü environment kurmak olmamalı. Ben şunu yapıyorum:
- Docker compose veya devcontainer.json ile “clone ve run”
- Gerekli access’ler (GitHub, Slack, DB, monitoring) offer kabul anında otomatik verilsin. IT ticket 5 günde gelmesin.
- README’de “başlamak için” 10 adım, her biri test edilmiş
- Bir senior setup’a ortak geçiyor: yeni developer ekrana paylaşıyor, senior yanında takip ediyor
Oluşan sorunlar README’ye ekleniyor.
İlk gün sonunda: yeni developer local’de test suite geçirmiş, dev server açılmış, basit bir “hello world” endpoint’i görmüş. Kazanç hissi.
2. Codebase tour: ilk gün rehberli gezinti
Yeni developer’a “codebase’i incele” demek onu bataklığa atmak. Organize edilmiş tour gerekli.
1-saatlik walkthrough:
– Repository yapısı: hangi klasör ne için
– Ana entry point: nerede request geliyor, hangi route’tan geçip nereye gidiyor
– Data layer: nasıl DB’ye gidiyor, hangi ORM/query builder
– Test patterns: unit vs integration, nerede fake data
– CI/CD pipeline: PR → tests → deploy nasıl
– Production architecture: servisler, iletişim, monitoring
Bu session recording’i tutulsun (Zoom kaydet + Notion/Google Drive’a koy). Sonraki yeni developer aynı tour’u async izleyebiliyor.
3. Starter ticket: küçük ama gerçek iş
Onboarding sırasında yeni developer’a verilecek ilk iş özenle seçilmeli.
İyi starter ticket kriterleri:
– 1-3 günde bitiyor (küçük)
– Gerçek business value var (onboarding task değil)
– Production’a deploy ediliyor (kazanım hissi)
– Codebase’in çok yerine dokunuyor (frontend + backend + test)
– Senior’a soru sorabileceği konular içeriyor
Kötü starter ticket:
– “Dokümantasyon yaz” (engaging değil)
– Süper komplex feature (overwhelming)
– Obscure module (isolated, öğrenme yok)
– Trivia bug (öğrenme yok)
“Profile sayfasına telefon numarası field’ı ekle” gibi basit ama end-to-end touch yapan feature ideal.
4. Buddy system
Yeni developer’a senior bir “buddy” ataması. Manager’dan farklı. Günlük 15-30 dakikalık quick-sync yapıyorlar:
- Dün ne yaptı, bugün ne yapacak
- Blockerlar
- Codebase’te anlamadığı yerler
- Process / culture soruları
Buddy senior engineer olmalı, manager değil (hiyerarşi buddy’de olmadığı için daha açık konuşulabiliyor). “Salak soru yok” policy.
2-3 hafta sonra buddy check-in’leri seyreliyor, yeni developer bağımsız çalışmaya başlıyor.
5. Dokümantasyon: runbook yaklaşımı
Çoğu ekibin dokümantasyonu ya eksik ya stale. Yeni developer’a fayda vermiyor.
Kritik dokümantasyon:
Architecture overview. Bir sayfa, diyagram + paragraph. Ana servisleri ve aralarındaki iletişimi gösteriyor.
Setup guide. Environment kurulumu, commande komutlu. README.md içinde veya SETUP.md.
Common tasks runbook. “Database’e migration nasıl koşuluyor”, “yeni feature flag nasıl eklenir”, “production log nasıl çekilir” gibi 15-20 yaygın görev, step-by-step.
Decisions log. Niçin bu framework, niçin bu DB, niçin bu pattern. ADR (Architecture Decision Records) formatı iyi.
Glossary. Ekip-spesifik terimler. “Tenant” ne demek bizim için, “run” vs “job” farkı nedir, vs. Alınan notlar küçük olabilir, geniş faydalı.
Yeni developer bu docs’lara bakıp kendi başına cevap bulabilecek %60’lık soru havuzu olmalı. Kalan %40 buddy ile konuşuluyor.
6. Feedback loop: 2 hafta, 1 ay, 3 ay check-in
Manager’ın yeni developer ile yapılandırılmış check-in’leri olmalı.
2 hafta check-in:
– Onboarding nasıl gidiyor? Nerede takıldın?
– Team dynamic’i nasıl hissediyorsun?
– Beklenti net mi?
– Eksik olan kaynak / erişim var mı?
1 ay check-in:
– Şimdiye kadar ne öğrendin?
– İlk feature’ın deneyimi nasıldı?
– Roadmap net mi?
– Buddy system işliyor mu?
3 ay check-in:
– Ne kadar productive hissediyorsun (1-10)?
– Takım içinde ne değişsin isterdin?
– Gelişim planına odak nerede?
– Long-term expectation’lar hizalı mı?
Bu check-in’ler manager’ın “yeni adam iyi mi?” intuition’undan ziyade yapılandırılmış bilgi sağlıyor. Eksik yerler proactive fark ediliyor.
Yaygın hatalar
1. “Kendin öğrenirsin” approach. Senior engineer kendi deneyimini projeksiyondan, junior da onu öğrenir bekliyor. Hayır. Dokümantasyon + walkthrough + buddy olmadan öğrenme 3x daha uzun.
2. Overwhelming ilk hafta. Tüm sistem mimarisini, tüm tool chain’i, tüm process’i tek hafta anlatmak. Bilgi yutuluyor, kullanışlı değil. Just-in-time öğrenme daha iyi.
3. Solo’yu bırakmak. Yeni developer’ın sorduğu sorulara “cevap Google’da” demek. Google’da ekip-spesifik cevap yok. Buddy time reserve edilmeli.
4. İlk PR’a kritik feedback spam’i. PR review’da 50 yorum gelen ilk PR yeni developer’ı kırıyor. Ben en kritik 5 feedback’i veriyorum, kalanı iyileşme seans’larında.
5. Onboarding document maintenance’sizliği. Doküman yaptık, güncel tutmuyoruz, 6 ay sonra stale. Her yeni kişi aynı onboarding doc’u okurken düzeltme yapsın.
2 haftada ne olmalı
Success metrics:
- Environment tamamen çalışıyor
- En az 1 PR merge edilmiş (küçük ama gerçek)
- En az 2 sprint ceremony’sine katılmış
- Team members’la 1-on-1 tanışmış
- Codebase’in ana akışını çizebiliyor
- Standup’ta anlamlı update verebiliyor
- Buddy ile rahatça konuşuyor
Bu check’leri hafta sonunda gözden geçirirsem yeni developer “tracking” veya “needs support” kategorisinde oluyor. Proaktif müdahale imkanı.
Son ders
Yeni developer’ın ilk 2 haftası şirkete yatırım. Manager ve senior engineer zamanlarının %20’sini buraya ayırmalı. Bu yatırım 2 hafta sonra productive bir çalışan, 6 ay sonra takımın critical üyesi olarak geri dönüyor.
Yapılmadığında ise: 3 ayın sonunda hala debug mode, 6 ay sonra frustration-based quit.
Onboarding lüks değil, bir gereklilik. Hiring’i kazanmak sadece offer’ı değil, ilk 90 günü yönetmektir.