Araç Yorgunluğu Gerçek: Engineering Manager'lar Ne Yapabilir
Engineering manager'lar çok fazla araçla boğuşuyor. Araç yorgunluğunun nasıl işlediği, maliyeti ve gerçekten işe yarayan sistem düzeyindeki çözümler.
By Ellis Keane · 2026-03-31
Salı sabahı saat 9:47 ve engineering manager tek bir satır kod yazmadı, tek bir pull request incelemedi ya da takımından herhangi biriyle gerçek engineering çalışması hakkında konuşmadı. Linear'dan aldığı durumla bir Notion belgesi güncelledi, bir kararın alınıp alınmadığını yoksa sadece tartışılıp tartışılmadığını anlamak için bir Slack thread'ine çapraz referans verdi ve dün gördüğü Figma yorumunun v2 mockup'ında mı yoksa v3 mockup'ında mı olduğunu hatırlamaya çalıştı – çünkü bildirim bunu söyleyecek kadar bağlam içermiyordu.
Bir engineering manager iseniz, bunu hiç araç yorgunluğu olarak adlandırmamış olsanız bile bu sabahı muhtemelen tanıyorsunuzdur.
Sorunun Şekli
Engineering manager'lar için araç yorgunluğu aslında çok fazla araç kullanmakla ilgili değildir (genellikle bu şekilde çerçevelenmiş olsa da). Bilginin nerede olduğuna, oraya kimin koyduğuna ve hâlâ güncel olup olmadığına dair zihinsel bir model sürdürmenin bilişsel yüküyle ilgilidir. Yığındaki her araç ayrı bir doğruluk kaynağıdır ve engineering manager'ın işi sessizce bu kaynakları kararlar almaya yetecek kadar tutarlı bir şekilde bir araya getirmeye dönüşmüştür.
Bunun pratikte nasıl göründüğü şöyle: Altı mühendisten oluşan bir ekibi yönettiğinizi ve şirketinizin proje takibi için Linear, kod için GitHub, iletişim için Slack, tasarım için Figma ve dokümantasyon için Notion kullandığını varsayalım. Bu beş araç – dürüst olmak gerekirse, konuştuğumuz çoğu startup için oldukça mütevazı.
title: "Bir Engineering Manager'ın Salı Sabahı" 8:30 AM|ok|Linear'ı açar, aktif sprint'i tarar. Son güncellemesi olmayan üç sorun "devam ediyor" olarak işaretlenmiş. 8:42 AM|amber|Bu sorunlar için PR'ların var olup olmadığını kontrol etmek için GitHub'a geçer. İkisi var. Biri yok. 8:51 AM|ok|Eksik PR için bağlam bulmak amacıyla Slack'e bakar. Mühendisin bir engelleyiciden bahsettiği Cuma'dan bir thread bulur. 9:03 AM|amber|Engelleyici bir Figma yorumuna atıfta bulunuyor. Figma'yı açar. Tasarım dosyasındaki yorum thread'lerini kaydırır. 9:14 AM|missed|Yorumu bulur, ancak Linear sorunu güncellenmeden çözüldü. Mühendis, engelleyicinin temizlendiğini bilmiyor olabilir. 9:22 AM|amber|Kontrol etmek için Slack'ten mühendise DM atar. Yanıt bekler. 9:31 AM|ok|Şimdiye kadar öğrendikleriyle Notion durum belgesini günceller. Üç paragraf, çoğunlukla henüz bilmedikleri hakkında. 9:47 AM|missed|Gerçek bir yönetim işi yapmadığını fark eder. Sadece bilgi arkeolojisi.
Bu süreçte bir yerde, "Engineering Manager" unvanı "Human API Router"ın – birincil işlevi birbirleriyle konuşmayı reddeden sistemler arasında bağlam taşımak olan birinin – kibar bir eşanlamlısına dönüştü.
Bu olağandışı bir sabah değil. Bu standart. Engineering manager'lar için araç yorgunluğu, takımda neler olduğunu anlamanın sessizce tam zamanlı bir veri entegrasyon egzersizine dönüştüğü anlamına gelir – ve kimse bunu böyle planlamadı.
stat: "77 dakika" headline: "Günlük ortalama bağlam birleştirme süresi" source: "Ekibimizin 4 haftalık dahili zaman takibine dayanmaktadır"
Neden İyileşmiyor, Kötüleşiyor
Araç yorgunluğu birikerek artar – bunu kendi ekibimizde yaşandığını gören biri olarak söylüyorum. Eklediğiniz her yeni araç yalnızca kendi yükünü eklemez, mevcut araçlar arasında sürdürmeniz gereken bağlantıları çarpar.
5 araçla 10 olası ikili bağlantınız vardır. 8 araçla 28 bağlantınız olur. 12 araçla 66 bağlantınız olur. Engineering manager'ın bu bağlantıların tamamını aktif olarak kullanması gerekmez, ancak hangilerinin var olduğunu ve hangilerinin bozuk olduğunu bilmesi gerekir – çünkü bozuk bir bağlantı, bilginin kaybolduğu yerdir.
Engineering management'taki bilgi kaybı soyut değildir. Engelleyicisinin çözüldüğünü bilmeyen ve bir sonraki iterasyona başlamadan önce iki gün bekleyen bir tasarımcıdır. Linear durumu "tamamlandı" dediği için bir bağımlılığın bittiğini varsayan, ama gerçek PR'ın hâlâ incelemede olduğu bir sprint taahhüdüdür. Araçlar bu sinyalleri birbirine bağlamadığı için herkesin bireysel olarak zaten bildiği ama paylaşmadığı şeyleri belirlemeye ilk on beş dakikasını harcayan haftalık senkronizasyon toplantısıdır.
Araç yorgunluğu araçların sayısıyla ilgili değildir. Bunlar arasındaki boşlukların sayısıyla ilgilidir – ve bu boşlukları kapatmanın engineering manager'ın gayri resmi ikinci işi hâline gelmesiyle ilgilidir.
İşe Yaramayanlar
Araç yorgunluğuna karşı gerçekten işe yaramayan üç yaygın tepki:
Kendi başına birleştirme. İçgüdü anlaşılabilir: sorun çok fazla araçsa, daha az araç kullanın. Ancak engineering ekipleri araçları hakkında iyi nedenlerle güçlü görüşlere sahiptir. Linear'ı "[hepsi bir arada platform X] içindeki proje yönetimi modülüyle" değiştirmeyi deneyin ve isyanı izleyin. Araçlar sorun değildir, aralarındaki boşluklar sorundur. Bir araç setini başka bir araç setiyle değiştirmek yalnızca boşlukları yer değiştirir.
Dashboard'lar. Biliyorum, biliyorum. "Hepsini yönetecek tek bir dashboard" çekiciliği neredeyse karşı konulamaz ve her kurumsal SaaS şirketinin bunun hakkında bir slayt destesi vardır. Ancak test ettiğimiz dashboard'ların çoğu salt okunur durum anlık görüntüleridir – şeylerin nerede olduğunu gösterirler, ama dünden bu yana neyin değiştiğini, neden değiştiğini veya ne yapmanız gerektiğini göstermezler. Bir dashboard'a bakan engineering manager, rakamların arkasındaki gerçek bağlamı almak için yine de her araca gitmek zorundadır.
Daha fazla toplantı. Bu en çok acıtan çünkü çok yaygın. Araçlar birbirleriyle konuşmadığında, ekipler senkron iletişimle telafi eder (günlük standup'lar, haftalık senkronizasyonlar, anlık kontroller). Toplantı sorunu çözmüyor – bozuk bir bilgi akışını insan bant genişliğiyle örtüyor. Ve insan bant genişliği ekibin en pahalı kaynağıdır.
İnsanların denediği şeyler
- Araç birleştirme – 5 aracı 1 araçla değiştirmek. Mühendisler isyan eder, hepsi bir arada 5 şeyi vasat yapar.
- Dashboard'lar – yine de orijinal araçlardan bağlam gerektiren salt okunur anlık görüntüler.
- Daha fazla toplantı – bozuk async iş akışını telafi etmek için senkron bilgi transferi.
Gerçekten yardımcı olanlar
- Birleştirme değil, bağlantı – araçları koruyun, aralarındaki boşlukları kapatın.
- Sinyal yönlendirme – her şeyi değil, neyin değiştiğini ve neyin dikkat gerektirdiğini ortaya çıkarın.
- Async bağlam teslimi – bilgi, sormadan ihtiyaç duyduğunuz yere ve zamanda ulaşır.
Gerçekten Yardımcı Olanlar
Gerçek bir engineering ekibiyle temasa geçmeyi başaran düzeltmeler ortak bir özelliği paylaşma eğilimindedir: insanlardan entegrasyon işini yapmasını istemezler. Bağlantıları sistem düzeyinde kurarlar ve engineering manager'ın zamanını bilgi toplamak yerine karar vermek için harcamasına izin verirler.
Kasıtlı bildirim yönlendirme. Araç yorgunluğunun büyük bölümü yanlış bilginin yanlış yere gelmesinden kaynaklanır. Durum güncellemelerini tasarım geri bildirimiyle karıştıran Slack kanalları. Aktif olarak çalışmadığınız depolar için GitHub bildirimleri. Düzeltme daha az bildirim değil, daha iyi yönlendirilmiş bildirimdir. Kanal kuralları belirleyin (engineering sinyalleri için #proj-[name]-eng, tasarım için #proj-[name]-design kullanıyoruz) ve agresif biçimde budayın. Hemen kendini amorti eden somut bir otomasyon: mesajda Linear sorun kimliğiyle PR durum değişikliklerini projenin Slack kanalına gönderen bir GitHub webhook'u kurun. Bu tek başına "bu sorun için PR var mı?" kontrolünü sabah ritüelinden kaldırır. Görkemli bir iş değil, ama gürültüyü anlamlı biçimde azaltır.
Haftalık "bilgi arkeolojisi" bütçesi. Şu anda bazı araçlar arası birleştirmenin kaçınılmaz olduğunu kabul edin ve bunu zaman kutusuna alın. Pazartesi sabahı özellikle "Cuma'dan bu yana araçlar genelinde ne oldu" taraması için otuz dakika ayırıyoruz. Planlanmış olması, haftanın her saatine sızmamasını sağlar; zaman kutusu olması ise tavşan deliğine girmek yerine zamanı dolduğunda durmanızı sağlar.
Araçlar arası sinyal yönlendirme. Kategorinin gittiği yer burası – ve evet, Sugarbug'da inşa ettiğimiz şey bu. Engineering manager'ın dünyanın durumunu oluşturmak için manuel olarak Linear'ı, sonra GitHub'ı, sonra Slack'i, sonra Figma'yı kontrol etmesi yerine: tüm bu araçlara API'leri aracılığıyla bağlanan ve ilgili değişiklikleri, kararları ve engelleyicileri size yönlendiren bir katman. Bir dashboard değil (o pasiftir) – neyin dikkatinizi gerektirdiğini ve neden gerektirdiğini size aktif olarak söyleyen, deneyimli bir ekip liderinin sizi briefleyeceğine benzeyen bir şey; eğer o ekip lideri dünden bu yana her Slack thread'ini ve her PR yorumunu okumuş olsaydı.
Dürüst versiyonu: İlk iki düzeltme bugün çalışıyor ve üçüncüsü Sugarbug'ın hedeflediği şey. Henüz bitmedi – sinyal filtrelemenin tam olarak ne kadar agresif olması gerektiğine henüz karar vermedik ve sıralama modeli hâlâ bastırmayı tercih ettiğimiz bazı gürültüler çıkarıyor. Ama çekirdek mimari çalışıyor: her araç için API bağlayıcıları, LLM tabanlı sinyal sınıflandırması ve kişileri, görevleri ve tartışmaları kaynaklar arasında birbirine bağlayan bir bilgi grafiği. "Cuma'dan bu yana ne oldu" taramasını yetmiş yedi dakika yerine saniyeler içinde hallediyor – bu, devam etmemizi sağlayan kısım.
Bir engineering manager'ın işi beş aracı tutarlı bir resme dikmek olmamalıdır. Bu bir makinenin işidir. İnsanın işi, o resimle ne yapılacağına karar vermektir. attribution: Ellis Keane
Sıkça Sorulan Sorular
Sinyal istihbaratını gelen kutunuza iletilmiş şekilde alın.
Q: Engineering manager'lar için araç yorgunluğu nedir? A: Araç yorgunluğu, çok fazla birbirine bağlı olmayan SaaS aracı üzerinden çalışmayı yönetmenin bilişsel ve operasyonel maliyetidir. Engineering manager'lar için bu, Linear, Slack, GitHub, Figma ve Notion arasında bilgi taşımaya, bu bilgiyle gerçek kararlar almaktan daha fazla zaman harcamak anlamına gelir.
Q: Sugarbug araç yorgunluğuna yardımcı olur mu? A: Evet – mevcut araçlarınıza yerel API entegrasyonları aracılığıyla bağlanır, her birinden gelen sinyalleri sınıflandırır ve önemli olanları tek bir yerde sunar. İlk kahvenizden önce beş dashboard'u kontrol etmek yerine, ihtiyaç duyduğunuz bağlamı size iletilmiş şekilde alırsınız. Sinyal filtrelemenin tam olarak nasıl çalışacağı üzerinde hâlâ yineliyoruz (dürüstçe, üstesinden geldiğimiz en zor tasarım sorunlarından biri), ancak çekirdek boru hattı çalışıyor.
Q: Tipik bir engineering ekibi kaç araç kullanır? A: Konuştuğumuz ekiplerin çoğu, ekip büyüklüğüne ve işlevine bağlı olarak 8 ila 14 SaaS aracı kullanıyor. Sorun sayının kendisi değil, bunlar arasındaki boşluklarda ne kadar bağlamın kaybolduğudur. Sekiz araçla çalışan üç kişilik ekipler ve dokuz araçla çalışan elli kişilik ekipler gördük. Sayı, araçların gerçekten bilgi paylaşıp paylaşmadığından daha az önemlidir.
Q: Engineering manager'lar araç yığınlarını birleştirmeli mi? A: Bazen, ancak genellikle yanlış bir çerçevedir. Beş amaca yönelik aracı, beş şeyi vasat yapan tek bir hepsi bir arada araçla değiştirmek temel sorunu çözmez. Gerçek düzeltme, sahip olduğunuz araçları birbirine bağlamak ve bilginin aralarında birinin bağlamı elle kopyalayıp yapıştırması olmadan akmasını sağlamaktır. Gerçek fazlalığı azaltabilirseniz – iki proje takipçisi gibi – yapın. Ancak daha küçük bir sayı için birleştirmeyin.