Mühendis İşe Alımını Hızlandırın (Daha İyi Belge Değil)
Mühendisleri daha hızlı işe alıştırmanın gerçek darboğazını çözerek: Slack, GitHub ve Linear'a dağılmış, hiçbir wiki'nin yakalayamadığı bağlamı düzeltin.
By Ellis Keane · 2026-03-31
Nasıl Çalıştığını Bilmeyen Bir Ekibe Katıldığımda
Mühendisleri daha hızlı işe alıştırmanın yolunu arıyorsanız kendi işe alım deneyimimden bahsedeyim – zira bu muhtemelen elinizdeki en güçlü argüman olacak.
2019'da San Francisco'daki bir startup'a üçüncü mühendis olarak katıldım. Dahiyane ve inanılmaz derecede dağınık olan CTO, ilk gün bana bir dizüstü bilgisayar uzattı ve özünde şunu söyledi: "Kod tabanı GitHub'da. Geri kalanı için Slack kullanıyoruz. Bol şans."
İşe alım programı buydu.
İlk üç haftamı geriye dönüp bakınca mühendislikle hiçbir ilgisi olmayan bir şey yapmakla geçirdim: arkeoloji. Kimlik doğrulama sisteminin neden böyle yapıldığını anlamak için altı aylık Slack thread'lerini kazdım. Kimsenin hiçbir yerde belgelemediği (tabii ki belgelememiştiler) veritabanı şema kararlarına ilişkin konuşmaları bulmak için kapalı GitHub PR'larını gözden geçirdim. #general'da sorular sordum; aldığım yanıt "ah evet, o konu – Ocak ayında fikir değiştirmiştik, tasarımcımızla olan thread'e bak" oldu.
Hangi thread? Hangi tasarımcıyla? Hangi kanalda?
Kötü bir yönetici değildi. Kurumsal bilginin yalnızca insanların zihninde ve birbirinden kopuk dört farklı araçta yaşadığı bir dünyada faaliyet gösteriyordu – dürüst olmak gerekirse bu durum çoğu mühendislik ekibini tanımlar. Sorduğum her soru, birinin elindekini bırakmasını, "işe alım moduna" geçmek için bağlam değiştirmesini, ilgili thread veya belgeyi bulmasını ve aylarca önce verdikleri bir kararın arkasındaki gerekçeyi yeniden kurgulamaya çalışmasını gerektiriyordu. Zihinsel çarkların döndüğünü neredeyse duyabiliyordunuz.
Arkeoloji yaparak mühendislik yapmak yerine üç hafta harcayan bir mühendisin maliyeti, artı sorularımı yanıtlayan herkesten biriken kesinti maliyeti – bilanço da hiçbir zaman görünmese bile bu gerçek bir paradır.
Bu deneyim de münhasır değildi. Tasarım ve mühendislik ajansımız Vulcan'ı yönetmekle on yıl geçirdim ve şaşırtıcı biçimde büyük bir kısmını benden bile daha dağınık organizasyonlara adım atarak (gerçi bu çıta pek yüksek değil) gördüm. Her müşteride aynı şablon: bilgi vardı, yalnızca insanların zihninde ve kimsenin birbirine bağlamayı düşünmediği araçlarda yaşıyordu.
Mühendisleri Daha Hızlı İşe Alıştırma: Belge Sorununu Değil, Arama Sorununu Çözün
Çoğu işe alım kılavuzu, mühendis işe alımını bir içerik sorunu olarak ele alır. Daha iyi belgeler yazın! Notion wiki oluşturun! Renk kodlu kilometre taşları içeren bir işe alım listesi hazırlayın!
Listeler fena değil. "1. Gün – 30. Gün" şablonunuzu çöpe atmanızı söylemeyeceğim. Ancak asıl darboğaz "yeterli belgemiz yok" değil. Gerçek sorun, yararlı bağlamın – dağınık, nüanslı, gerçek şeylerin – Slack thread'lerinde, GitHub PR yorumlarında, Linear issue açıklamalarında ve bir tasarımcının yeni çalışan gelmeden altı hafta önce bıraktığı Figma notlarında yaşamasıdır. Yazılımın ne yaptığını açıklayan wiki'ler oluşturmak için topluca yirmi yıl harcadık; neden sorusunu keşfedilebilir kılmak içinse neredeyse hiç zaman ayırmadık.
Hiçbir wiki "neden" sorusunu yakalamaz. Wiki'ler birinin yazmaya değer bulduğunu yakalar – bu ise yeni bir mühendisin gerçekten bilmesi gereken şeyden tamamen farklıdır.
Asıl işe alım darboğazı belgeler değil – yararlı bağlamın kimsenin aramayı düşünmediği araçlarda yaşıyor olmasıdır. attribution: Chris Calo
O günden bu yana mühendisleri işe alıştırdığımda – önce bir tasarım ajansında, sonra Sugarbug'ı kurarken – aynı şablonu tekrar ettiğini gözlemledim. Yeni çalışanların sorduğu sorular kabaca dört kategoriye ayrılıyor ve bunlardan yalnızca biri geleneksel işe alım belgeleri tarafından karşılanıyor:
Belgelerin kapsadığı
- Mimari genel bakış – sistem diyagramları, servis sınırları, dağıtım topolojisi
- Yerel kurulum – klonlama, derleme, çalıştırma ve test etme
- Kodlama standartları – linting kuralları, PR kuralları, adlandırma kalıpları
Belgelerin kaçırdığı
- Karar geçmişi – neden bu mimari, Slack'te tartışılan üç alternatif değil?
- Ekip içi bilgi – fatura modülünün gerçek sahibi kim? O CSS kararını kim verdi?
- Bağlam zincirleri – bir tasarım tartışmasına bağlı PR'a bağlı, ürün spesifikasyonuna bağlı Linear issue
- Aktif durum – şu anda ne üzerinde çalışılıyor ve neden?
"Belgelerin kapsadığı" sütunu çoğu ekibin optimize ettiği şeydir. Deneyimlerime göre "belgelerin kaçırdığı" sütunu, yeni mühendislerin uyum sürecinin büyük bölümünü harcadıkları yerdir – gerçek cevapların yaşadığı yer burasıdır ve kimse yeni çalışanları oraya yönlendirmeyi düşünmez.
Bu bilgi kaybolmuş değil, çünkü kimse onu yazmamış. Yazılmış – bir Slack mesajında, bir GitHub inceleme yorumunda, bir Linear issue güncellemesinde. Sorun keşfedilebilirlik, belgeleme değil.
Kimsenin Bütçelemediği Kesinti Vergisi
Yeni bir mühendis "bunu neden böyle yaptık?" diye sorduğunda ve kıdemli bir mühendis elindekini bırakıp yanıt verdiğinde iki şey olur. Yeni çalışan bir cevap alır (iyi), kıdemli mühendis ise önemli bir üretken odak dilimi kaybeder – sorunun aldığı 2 dakikayı değil, ilgili thread'i bulmak, gerekçeyi hatırlamak ve önceden ne yapıyorsa ona yeniden odaklanmak için gereken yaklaşık 15 dakikayı.
stat: "Günde birkaç kez" headline: "Uyum sürecindeki tek bir mühendisten kaynaklanan kesintiler" source: "Sugarbug'daki kendi işe alım düzenlerimize dayalı"
Aynı çeyrekte iki mühendis işe alıyorsanız (büyüyen bir startup'sınız, muhtemelen alıyorsunuzdur), mevcut ekibiniz haftalarca gerçekten makul olmayan sayıda kesinti yaşar. Hız kazandırmak için işe aldığınız kişiler geçici olarak hızı düşürüyor. Kimse bunun için bütçe ayırmaz çünkü kimse ölçmez – yalnızca "ekip bu çeyrek daha yavaş hissettiriyor" gibi belirsiz bir his olarak ortaya çıkar; kimse bunu işe alımla ilişkilendirmez.
Ve en can sıkıcı kısım: bu soruların yanıtları zaten bir yerlerde mevcut. Slack'te, GitHub'da, Linear'da. Bilgi, karar verildiği anda yakalandı. Yalnızca kimsenin yeni çalışana aramayı söylemediği bir araçta, var olduğundan habersiz oldukları bir kanalda, bağlamın dışında anlam ifade etmeyen bir thread başlığının altında oturuyor.
Bağlı Bağlam: Pratikte Ne Anlama Gelir
Mühendis işe alımında bağlı bağlam, yeni bir çalışanın ekibinizin kullandığı tüm araçlarda – Slack, GitHub, Linear, Notion – tek bir arayüzden arama yapabilmesi anlamına gelir. Yalnızca anahtar kelime araması değil (Slack'in arama özelliği, açıkçası, en iyi ihtimalle yeterli, en kötü ihtimalle aktif olarak düşmanca), ilişkileri anlayan bağlamsal bir arama.
"Fatura modülü yeniden düzenlemesiyle ilgili her şeyi göster" şunu döndürür: Linear epic, GitHub'daki altı PR, ekibin yaklaşımı tartıştığı Slack thread'i ve Notion mimari belgesi – hepsi bağlantılı, hepsi kronolojik sırada, hiçbir arkeoloji gerektirmeden.
Kavram bu: ekibinizin tüm araçlardaki çalışmaları arasındaki ilişkileri haritalayan, kimin neye, nerede ve neden karar verdiğinin canlı bir dizinini oluşturan bir bilgi grafiği.
Ortağım Ben ile ben bunu inşa ettik çünkü alternatifi yaşayarak yıllar geçirmiştik. Vulcan'da birden fazla organizasyonda aynı anda tasarım ve mühendislik ekipleri yönetiyorduk ve istisnasız, gerçek uzmanlıklarımız tek bir şeye indirgendi: bilginin yüce insan yönlendiricileri. Tasarım ve inşaat yapması gereken iki kişi, günlerini "o şey nerede?" sorusunu yanıtlamakla geçiriyordu (ruhunu eritici bir farkındalık, inanın). Bunun durması gerekiyordu.
Bağlı bağlam daha fazla belge yazmakla ilgili değil – araçlarınızda zaten mevcut olan bağlamı keşfedilebilir, aranabilir ve bağlantılı hale getirmekle ilgilidir. Yeni mühendislerin hangi Slack kanalında arama yapacaklarını veya hangi GitHub deposuna bakacaklarını bilmeleri gerekmemelidir.
Sugarbug ile inşa ettiğimiz şey bu. Bilgi grafiği Linear issue'ları GitHub PR'larına, Slack konuşmalarına ve Notion belgelerine bağlar; her şeyi aranabilir kılar. Yeni bir çalışan katıldığında, ekibin karar geçmişi ilk günden itibaren erişilebilir olur. (İşe alıma özel iş akışlarını hâlâ iyileştiriyoruz, açıkçası – ancak temel grafik, temeli oluşturuyor.)
3 Haftalık Mühendis İşe Alım Çerçevesi
İşte o dizüstü bilgisayar uzatılıp "bol şans" denildiğinde sahip olmak istediğim çerçeve. Mühendisleri daha hızlı işe alıştırmayı bulmaya çalışıyorsanız, bu işe yarıyor çünkü hayal edilen darboğazı (belge hacmi) değil gerçek darboğazı (keşfedilebilirlik) ele alıyor.
1. Hafta: Yönlendirme
Yeni çalışanı bir "bağlam arkadaşı" ile eşleştirin – bir mentor değil, bilginin nerede yaşadığını bilen biri (mutlaka en kıdemli kişi olmak zorunda değil – bazen en son soruları en çok soran ve şeylerin nerede olduğuna dair en taze haritaya sahip kişidir). Bağlam arkadaşının işi her soruyu yanıtlamak değil. İşi "o karar Şubat ayı civarında #backend kanalında verildi, thread'i bulmana yardımcı olayım" demektir.
Sugarbug gibi bağlı bir bağlam aracı kullanıyorsanız bağlam arkadaşının işi önemli ölçüde kolaylaşır: "fatura modülü yeniden düzenlemesi için arama yap, tüm karar zincirini göreceksin."
2. Hafta: Yön Bulma
Yeni çalışan artık ilk PR'larını yapıyor olmalı; ancak daha da önemlisi, ekibin nasıl iletişim kurduğuna dair zihinsel modelini oluşturuyor olmalı. Slack'te hangi tartışmalar yapılıyor? Linear yorumlarında? GitHub PR incelemelerinde? İletişim topolojisini anlamak, kod tabanını anlamak kadar önemlidir – ilk ayda belki daha da önemli. (Bir haftada kod tabanını kavramış ama üç hafta geçince hâlâ kararların nerede bulunacağını bilmeyen mühendisler gördüm.)
3. Hafta: Katkı
Üçüncü haftaya gelindiğinde, bağlam sorunu çözülmüşse yeni bir mühendis anlamlı katkılar yapıyor olmalı – kod tabanını ezberlediği için değil, birine sormak zorunda kalmadan ihtiyacı olanı nasıl bulacağını bildiği için.
- [x] 1. Gün: Yerel ortam çalışıyor, tüm araçlara erişim sağlandı
- [x] 2-3. Gün: Bağlam arkadaşı atandı, iletişim topolojisi anlatıldı
- [x] 1. Hafta: Bağlam arkadaşı desteğiyle 2-3 "iyi başlangıç issue'u" tamamlandı
- [ ] 2. Hafta: Bağımsız PR'lar yapılıyor, sormadan önce bağlam aranıyor
- [ ] 3. Hafta: Tasarım tartışmalarına katkı sağlanıyor, başkalarının PR'ları inceleniyor
- [ ] 2. Ay: Bağımsız olarak verimli çalışılıyor, bağlam arkadaşıyla haftalık check-in'ler
Bu Neden Bileşik Etki Yapar (ve Wiki'ler Neden Yapmaz)
Mühendis işe alım sorununu bağlı bağlamla çözmek ile kimsenin bakımını yapmadığı 47 sayfalık Notion wiki'siyle çözmek arasındaki fark (o wiki'yi biliyorsunuz – sekiz ay önce o zamandan beri ayrılmış biri tarafından güncellendi) şu: bağlı bağlam bileşik etki yapar. Ekibinizin Slack'teki her konuşması, her PR incelemesi, her Linear issue güncellemesi – hepsi indekslenir, bağlanır ve aranabilir hale getirilir. Bilgi grafiği zamanla kimse ekstra çalışma yapmadan zenginleşir.
İkinci yeni çalışanınız, birinci yeni çalışanın işe alım sorularının ortaya çıkardığı her şeyden yararlanır. Beşinci yeni çalışanın daha zengin bir grafiği vardır. Onuncuya gelindiğinde, yalnızca CTO'nuzun zihninde yaşayan kurumsal bilgi dağıtılmış, aranabilir ve bağlantılı hale gelmiştir.
Ve bu yaklaşımda beni gerçekten heyecanlandıran kısım bu! Yalnızca verimlilik kazancı değil – bağlı bağlamı deneyen ekiplerle erken görüşmelerimizden anlaşılan o ki uyum süresi sıkıştırması gerçek. Ve beklemediğim kısım şu: Ortağım Ben ile ben konuşkan insanlarız, daha iyi fikirlerimizin yarısı ikimizden biri onları yazmadan günlük gürültüye karışıp gidiyor (çok profesyonel, biliyorum). Grafik, tamamen unuttuğumuz kendi konuşmalarımızdan kısayolları ve gerçekten yararlı içgörüleri yüzeye çıkarmaya devam ediyor. Onu inşa eden iki kişiden bağlamı kurtarabiliyorsa, on beş kişilik bir ekibe katılan yeni bir çalışan için ne yapabileceğini düşünün.
Gerçekten mühendisleri daha hızlı işe alıştırmaya çalışan ekipler için daha derin değer, insanlar ayrıldığında kurumsal bilgiyi kaybetmeyi bırakmaktır. Kararlarının bağlam zinciri geride kalır, sonraki herkes için aranabilir. Bu bir verimlilik kazancı değil. Bu bir kurumsal bellektir.
Sinyal istihbaratını gelen kutunuza alın.
Sıkça Sorulan Sorular
Q: Yeni bir mühendisi işe alıştırmak ne kadar sürmeli? A: Kendi deneyimimizden ve diğer mühendislik ekipleriyle yaptığımız görüşmelerden yola çıkarak, yeni bir mühendisin tam verimli hale gelmesi genellikle 2-3 ay sürer. Darboğaz nadiren teknik beceridir – asıl sorun kararların nerede olduğunu, kimin neye sahip olduğunu ve ekibinizin araçlar arasında gerçekte nasıl iletişim kurduğunu öğrenmektir. Bağlı bağlam araçları kullanan ekipler bu süreyi önemli ölçüde kısalttıklarını bildiriyor; ancak tam iyileşme ekip büyüklüğüne ve araç karmaşıklığına bağlı.
Q: Sugarbug mühendis işe alımına yardımcı olur mu? A: Evet. Sugarbug, Linear, GitHub, Slack ve Notion hesaplarınız genelinde canlı bir bilgi grafiği oluşturur. Böylece yeni mühendisler geçmiş kararları, özelliklerin neden belirli şekilde geliştirildiğini ve kime ne sormaları gerektiğini – kimseyi rahatsız etmeden – her araçta arayabilir.
Q: Mühendis işe alımında bağlı bağlam nedir? A: Bağlı bağlam, araçlar arasındaki bilgileri birbirine bağlamak anlamına gelir; böylece yeni bir çalışan bir kararı Linear issue'dan GitHub PR'a, oradan da ekibin yaklaşımı tartıştığı Slack thread'ine kadar izleyebilir. Bu zincir aranabilir olduğunda, yeni çalışan meslektaşlarını rahatsız etmek yerine cevapları kendi kendine bulabildiğinden uyum süresi kısalır.
Q: Geleneksel işe alım wiki'leri mühendisler için neden işe yaramaz? A: Wiki'ler birinin yazmaya değer bulduğunu yakalar – mimari genel bakışlar, kurulum kılavuzları, kodlama standartları. Asıl uyum darboğazı, Slack thread'lerinde, PR yorumlarında ve Linear issue'larda yaşayan dağınık, bağlamsal içeriktir. Bu neden böyle inşa edildi? O kararı kim verdi? Bu bağlam araçlarınızda zaten yakalanmış – sorun onu bulmak, yazmak değil.
Q: Sugarbug işe alım sürecinde GitHub ve Linear ile entegrasyon sağlıyor mu? A: Evet. Sugarbug, API aracılığıyla GitHub, Linear, Slack, Notion, Figma ve Google Calendar'a bağlanır; konuşmaları, issue'ları, PR'ları ve belgeleri yeni mühendislerin ilk günden itibaren sorgulayabileceği aranabilir bir bilgi grafiğine indeksler.