Async-First Mühendislik Ekibi Nasıl Yönetilir
Async-first mühendislik ekipleri için iletişim normlarından gerçekten işe yarayan karar alma ritüellerine kadar pratik bir el kitabı.
By Ellis Keane · 2026-04-06
Telgraf günlük brifingleri öldürdüğünde
1844'te Samuel Morse Washington ile Baltimore arasında ilk telgraf mesajını gönderdi ve on yıl içinde, günlük kurye brifinglerine dayanan işletmeler farklı çalışmaya başladı. "Telgraf-first" olmak istedikleri için değil (kimse bunu söylemedi), kısıtlamalar değiştiği için. Bilgi bir attan daha hızlı hareket edebiliyordu, dolayısıyla atlara inşa edilmiş ritüeller sessiz sedasız gereksiz hale geldi.
Async-first bir mühendislik ekibini yönetmekle bu paralel rahatsız edici derecede doğrudan. Slack, Linear, GitHub, Notion ve bir webhook hızında bilgiyi hareket ettiren yaklaşık yedi araç daha var; yine de ekiplerin çoğu, günlerini bağlamı paylaşmak için aynı odada olmanız gerektiği dönemler için tasarlanmış senkron ritüeller etrafında düzenlemeye devam ediyor – ikinci monitörde zaten aynı panoyu açık tutan bir yöneticiye Jira biletlerini okuyan herkesin bulunduğu günlük standup, başka herkes telefona bakarken üç kişi sırayla ekran paylaşımı yaptığı için 45 dakika süren "hızlı senkronizasyon."
Bizim gibi küçük bir mühendislik ekibi için – üç saat diliminde dört kişi – kısıtlamanın değiştiğini fark etmek kolaydı. Ritüelleri yeniden inşa etmek daha uzun sürdü.
Async-first bir mühendislik ekibi gerçekte nasıl görünür
Async-first mühendislik, ekibinizin varsayılan iletişim modunun asenkron olduğu anlamına gelir. Kararlar yazıya dökülür. Durum sormaya gerek kalmadan görünürdür. Bağlam, insanların kendi programlarında bulabileceği yerlerde belgelenir. Toplantılar hâlâ gerçekleşir, ancak bunlar varsayılan olarak katılmak zorunda olmadığınız bir istisnadır.
Bu, kimsenin gerçek zamanlı konuşmadığı anlamına gelmez; bu saçmalık olur ve açıkçası biraz da yalnızlık yaratır – tasarım incelemeleri, çatışma çözümü, beyin fırtınası oturumları ve beden dilini okumanız ve beyaz tahtalara çizim yapmanız gereken nüanslı mimari tartışmalar senkron kalmaya devam eder, bu da iyidir. Ayrım, bir şeyi iletmeniz gerektiğinde hangi moda ilk ulaştığınızdır ve bir mühendislik ekibindeki çoğu şey için cevap, bir arama planlamak yerine yazmak olmalıdır; çünkü Brooklyn'de öğleden sonra 14:00'te iyi yazılmış bir Linear yorumu, ertesi sabah Berlin'de 09:00'da hâlâ mükemmel okunabilirdir.
Async-first, async-only anlamına gelmez. Varsayılanınızın asenkron olduğu ve durumun gerçekten gerektirdiği durumlarda senkron iletişimi bilinçli olarak seçtiğiniz anlamına gelir.
Dört temel direk (deneyene kadar bariz görünen)
Geçen yıl boyunca Sugarbug'ı ABD Doğu Kıyısı ve Avrupa'ya yayılmış dört kişilik bir ekip olarak inşa ettik ve async-first mühendislik ekibimizin gerçekten işe yaramasını sağlayan şeyler araçlar veya politikalar değildi – alışkanlıklardı. İşte yerleşen dört tanesi.
1. Kararları gerçekleştikleri yere yazın
Bunu tutarlı biçimde neredeyse kimse yapmıyor. Bir Slack iş parçacığında karar alınıyor. Biri "tamam, B seçeneğiyle gidelim" diyor. Ve sonra... orada yaşıyor. Üç hafta içinde pratikte bulunamayacak bir iş parçacığında.
Düzeltme bir karar günlüğü değil (en azından öncelikli olarak değil). Düzeltme bir normdur: son kararı veren kişi, işin yaşadığı araçta ne kararlaştırıldığını ve nedenini tek cümleyle özetler. API yanıt biçimini değiştirmeye karar verdiyseniz, bu özet Slack iş parçacığında veya kimsenin yeniden izlemeyeceği toplantı kaydı dökümünde değil, Linear sorunu veya GitHub PR açıklamasında yer alır.
Bunu pahalıya öğrendik: Bir PR, inceleyicinin o sayfa için sunucu tarafı oluşturma kullanmaya zaten karar verdiğimizi bilmediği için üç gün incelemede kaldı – karar önceki haftanın Slack iş parçacığına gömülmüştü ve kimse bunu soruna yazmamıştı. İnceleyici, zaten çözülmüş olan istemci tarafı hidrasyon ödünleşimleri hakkında altı yorum bıraktı, yazar sinirlendu ve bağlam en başından işe eklenseydi on saniye sürecek bir konuşmaya haftanın büyük bölümünü harcadık.
Bundan sonra ayrı bir karar belgesi tutmaya çalışmayı bıraktık (kimsenin güncellemediği bir şey haline gelmeden önce yaklaşık iki hafta işe yaramıştı) ve kararları doğrudan soruna yazmaya başladık. On saniyelik çaba ve işe bağlı olduğu için hayatta kalıyor; kimsenin kontrol etmediği bir meta-belgede yüzmüyor.
2. Durumu raporlanan değil, görünür kılın
Ekibimiz için durum güncelleme toplantısı en pahalı senkron ritüeldi – her kişi dün ne yaptığını ve bugün ne yapacağını anlatırken diğerleri yarım kulakla dinleyip sıralarını bekliyordu. Async-first bir ekipte durum, birinin size söylemesi gereken bir şey değil, görebileceğiniz bir şey olmalıdır.
Bu, proje yönetim aracınızın gerçekliği gerçekten yansıtması gerektiği anlamına gelir. Bir Linear sorunu "Devam Ediyor" durumundaysa, bunun nedeni birinin gerçekten şu anda üzerinde çalışması olmalıdır; Pazartesi günü oraya taşıyıp o günden beri dokunmamış olmaları değil. GitHub PR'larının açıklayıcı başlıkları ve bağlantılı sorunları olmalıdır. Figma dosyalarının, nelerin devam ettiğini nelerin onaylandığını anlatan net isimlendirmeleri olmalıdır.
Durumu görünür kılan şeyler
- PR'ları sorunlara bağlamak – Herkes hangi kodun hangi görevle eşleştiğini görebilir
- Net dal isimlendirmesi –
feat/user-onboarding-flow, fix-stuff'tan daha fazla bilgi verir
- Güncellenmiş sorun durumları – Biletleri standuplar sırasında değil, iş gerçekten ilerlediğinde taşıyın
- Yazılı haftalık özetler – Bir kişi özet yazar, herkes asenkron okur
Durumu görünmez tutan şeyler
- Yalnızca sözlü güncellemeler – Toplantı bittiği anda bilgi kayboluyor
- Kayıt sistemi olarak durum toplantıları – Standupda söylenmemişse olmamıştır
- Eski panolar – Pazartesiden beri dokunulmamış bir Kanban panosu
- DM'lerde kilitlenen bağlam – İki kişi biliyor, diğerleri tahmin ediyor
3. Yanıt sürelerini değil, yanıt pencerelerini tanımlayın
Asenkron iletişimle ilgili daha ince kaygılardan biri ucu açık beklemedir. Bir mesaj gönderirsiniz ve yirmi dakika içinde mi yoksa yarın öğleden sonra mı yanıt alacağınızı bilmiyorsunuzdur. Belirsizlik gerçek gecikmeden daha kötüdür.
Çözüm, daha hızlı yanıt talep etmek değil (bu sadece senkron kültürü ekstra adımlarla yeniden yaratır). Çözüm, farklı iletişim türleri için yanıt pencereleri konusunda açık beklentiler belirlemektir. Ekibimiz için kabaca şöyle görünüyor:
- Genel kanallardaki Slack mesajları: 4 çalışma saati içinde
- PR incelemeleri: Bir iş günü içinde
- Linear sorun yorumları: Bir iş günü içinde
- Acil işaretli DM'ler: Çalışma saatlerinde 1 saat içinde
- Diğer her şey: 2 iş günü içinde
Belirli pencereler, var olmalarından ve herkesin üzerinde anlaşmış olmasından daha az önemlidir. Kadans açık olduğunda, "bunu gördüler mi?" kaygısı azalır ve insanlar otuz dakikalık sessizliğin ardından takip pingi göndermeyi bırakır.
4. Gerçekten ihtiyaç duyan şeyler için senkron zamanı koruyun
Beklemediğimiz bir şey: tuttuğumuz toplantılar gözle görülür biçimde daha iyi hale geldi. Bir toplantı varsayılan yerine istisna olduğunda, insanlar hazırlanmış ve katılımcı bir şekilde geliyor; çünkü birlikte bir şeyi çözmeleri için tek pencerenin bu olduğunu biliyorlar.
Üç tür senkron toplantıyı koruduk:
- Haftalık ekip senkronizasyonu (maksimum 30 dakika) – Durum güncellemeleri değil, engelleyiciler, çapraz kesme endişeleri ve "bu mimari kararın bizi ileride zor durumda bırakacağını düşünen var mı?" konuşmaları
- Tasarım incelemeleri – Bazı şeyler gerçekten senkron görsel geri bildirime ihtiyaç duyar
- Çift programlama oturumları – İki kişi takıldığında, birlikte konuşmak hâlâ asenkron gidip gelmeden daha hızlıdır
Eskiden toplantı olan diğer her şey yazılı bir öneri, Loom videosu veya ilgili sorun üzerindeki yorum iş parçacığı haline geldi. Takvimimiz Tetris oyununa benzemekten gerçekten bir insanın etrafında çalışabileceği bir şeye döndü – ki sonuçta takvim almanın tüm amacı bu.
stat: "3 toplantı/hafta" headline: "12'den düştü" source: "Async-first'e geçtikten sonra ekibimizin gerçek takvimi"
Kimsenin sizi uyarmadığı kısım
Async-first'in zor kısmı iletişim normları veya araç kurulumu değil. Duygusal uyumdur. Günlük standup'ı bıraktığımızda, mühendislerimizden biri önce biriyle iletişim kurmadan sabah 10'da derin çalışmaya başlamanın "tuhaf biçimde suçluluk" hissettirdiğini söyledi. Bir diğeri, GitHub her saat commit geldiğini gösterse de öğleden önce Slack'teki sessizliğin kimse çalışmıyor gibi hissettirdiğini söyledi.
Bu, sorunun insan doğası kısmıdır ve sistem düzeyinde bir düzeltmesi yoktur. Bize yardımcı olan şey, bu konuda açık sözlü olmaktı. Asenkronun bazen yalnız hissettirebileceği gerçeğinden söz ettik ve çözdüğünüz sorun hakkında bir insanla konuşmak istediğiniz için aramak tamamen uygundu. Norm "asla arama" değil, "ihtiyaç duymayan şeyler için arama gerektirme"dir.
Ekipteki bazı kişiler daha fazla senkron etkileşimi tercih ediyor ve buna uyum sağlamak async-first felsefesinin başarısızlığı değil – iletişim tercihlerinin kişisel olduğunu ve herhangi bir tek moda katı bağlılığın kendi başına bir tür işlev bozukluğu olduğunu kabul etmektir.
Zor kısım, async iş akışlarını kurmak değil. Mesajlar arasındaki sessizliğe alışmak ve göremediğiniz halde takım arkadaşlarınızın çalıştığına güvenmektir. attribution: Ellis Keane
Yerleştirmek: ilk 30 gün
Mevcut bir ekibi async-first mühendislik ekibi modeline geçiriyorsanız, ilk ay ya kök salacağı ya da sessizce "hızlı bir arama yapalım"a geri döneceği yerdir. Kabaca bir zaman çizelgesi olarak bize işe yarayan şeyler:
1. Hafta: İletişim normlarını yazıya dökün. Gerçek anlamda – "işte nasıl iletişim kurduğumuz, işte beklenen yanıt pencereleri, işte toplantıyı gerektiren şey" diyen tek sayfalık bir belge. Paylaşın, senkron olarak tartışın (evet, ironi var) ve onay alın.
2. Hafta: Üç yinelenen toplantıyı iptal edin veya dönüştürün. En açık şekilde gizlenmiş durum güncellemesi olanları seçin ve yazılı bir formatla değiştirin. Her şeyi birden iptal etmeyin – insanların uçurumla değil, kademeli bir rampayla geçişe ihtiyacı var.
3. Hafta: Araç hijyeninizi denetleyin. Linear sorunları gerçekten güncel mi? PR açıklamaları işe yarıyor mu? Kararlar işin gerçekleştiği yerlere yazılıyor mu? Değilse, bu hafta bu normları oluşturmanın haftasıdır. Bir karar sözlü gerçekleştiğinde ama yazıya dökülmediğinde nazikçe hatırlatan birini "async şampiyonu" olarak atayın.
4. Hafta: Retrospektif (doğal olarak, asenkron). Basit bir form gönderin: "Neler işe yarıyor? Neler yaramıyor? Neyi özlüyorsunuz?" Cevaplar sizi şaşırtacak – bazıları sessizliği sevecek, diğerleri zorlanacak. Normlara teori değil, gerçek geri bildirime göre uyum sağlayın.
- [x] İletişim normları belgesi yazın
- [x] Her kanal için yanıt pencerelerini tanımlayın
- [ ] 3 durum toplantısını iptal edin veya dönüştürün
- [ ] Araç hijyenini denetleyin (sorunlar, PR'lar, karar belgeleri)
- [ ] Geçiş için async şampiyonu atayın
- [ ] 30 gün sonra async retrospektif düzenleyin
- [ ] Ekip geri bildirimlerine göre normları ayarlayın
Async-first'in yanlış tercih olduğu durumlar
Async-first birçok yaygın durumda uygun değildir. Ekibiniz aynı ofiste oturan üç kişiyse, senkron iletişim muhtemelen iyidir ve async normlarını resmileştirmenin yükü, sahip olmadığınız bir sorunu çözmek olur. Benzer şekilde, ekibiniz gerçek bir krizde ise – üretim çöktü, kritik bir lansman yaklaşıyor veya ürün yönünü değiştiriyorsunuz – bu senkron bölgesidir ve aksini iddia etmek pratik olmaktan ziyade dogmatik olur.
Async-first, saat dilimleri arasında dağılmış ekipler, yaklaşık beş kişiden fazla ekipler (senkron koordinasyonun kombinatoryal patlamasının acı vermeye başladığı yer) ve sevk ettikleri şeyi toplantıda anlatmak yerine kod sevk etmeyi tercih eden ekipler için en iyi çalışır. Bu sizseniz, async normlara yapılan yatırım toplantı-sanayi kompleksine kaybolan kurtarılmış mühendislik saatleri sayesinde ağırlıklı olarak ilk ay kendini amorti eder.
Telgraf, yüz yüze konuşmayı ortadan kaldırmadı – sadece günlük kurye yolculuğunu gereksiz kıldı. Async-first'in bir mühendislik ekibi için yaptığı şey budur: yalnızca araçlar henüz yetişmediği için var olan ritüelleri emekliye alır ve gerçekten önemli olan konuşmaları korur.
Sıkça Sorulan Sorular
Q: Async-first bir mühendislik ekibinde kod incelemelerini nasıl yönetirsiniz? A: Açık bir inceleme SLA'sı belirleyin (bizimki bir iş günüdür) ve PR açıklamalarının ağır yükü taşımasını sağlayın – yalnızca neyin değiştiğini değil, neden değiştiğini açıklayın, ilgili sorunu bağlayın ve inceleyicinin odaklanması gereken şeyleri işaretleyin. En büyük async-inceleme başarısızlık noktası, inceleyicinin yalnızca birinin zihninde var olan bağlamı gerektirdiği için üç gün bekleyen bir PR'dır. Yazıya dökün ya da ileride ödeyin.
Q: Sugarbug, async-first iş akışlarında yardımcı olur mu? A: Bağlamın araçlar arasında parçalanması sorunuyla yardımcı olur – Slack'te bir karar, Linear'da bir görev, Figma'da bir tasarım yorumu. Sugarbug bu sinyalleri birbirine bağlar, böylece kimsenin bir toplantıda anlatmasına gerek kalmadan durum görünür olur. Bu sorunu çözmenin tek yolu bu değil (her şeyi manuel olarak çapraz bağlama konusunda çok disiplinli de olabilirsiniz), ancak biz onu manuel versiyondan yorulduğumuz için inşa ettik.
Q: Ekiplerin async-first'e geçerken yaptıkları en büyük hata nedir? A: Bunu bir alışkanlık değişikliği yerine bir politika değişikliği olarak görmek. Güzel bir "iletişim normları" belgesi yazabilirsiniz, ancak insanlar Linear sorunlarını gerçekten güncellemez veya PR'lara kararlar yazmaz ise, bilgi akışını değiştirmeden toplantıları kaldırmış olursunuz. Normların kas belleği haline gelmesi gerekir; bu da yaklaşık bir ay nazik, tutarlı hatırlatma gerektirir.
Q: Async-first bir ekipte acil üretim sorunlarını nasıl yönetirsiniz? A: Bunları asenkron olarak yönetmezsiniz – "async-first, async-only değil" demenin tüm amacı bu. Net bir yükseltme yolu tanımlayın: gerçek acil durumlar için özel bir Slack kanalı veya PagerDuty; diğer her şeyin normal yanıt pencerelerini izlediği anlayışıyla. Temel ayrım, "acil" (üretim çöktü) ile "şimdi bir yanıt istiyorum" (bu genellikle aciliyet değil sabırsızlıktır) arasındadır.
Q: Sugarbug standup toplantılarının tamamen yerini alabilir mi? A: Bilgi toplama kısmının – "herkes dün ne yaptı?" ritüelinin – yerini alabilir; çünkü bu bağlam zaten GitHub, Linear ve Slack üzerinden akıyor. Yerini alamayacağı şey ise insan bağlantısı kısmıdır; bu nedenle hâlâ aynı (sanal) odada olmaktan fayda gören konuşmalar için kısa bir haftalık senkronizasyonu koruyoruz.
Sinyal istihbaratını doğrudan gelen kutunuza alın.