Mühendislik Ekibini 10'dan 50'ye Teknik Borç Biriktirmeden Ölçeklendirme

10 mühendisle haftada bir özellik çıkaran bir ekip, 30 mühendise ulaştığında iki haftada bir özellik çıkarır hale gelir — ve genelde kimse bunun hangi sprint'te başladığını gösteremez. Kod tabanı bir gecede kötüleşmedi. Bozulan organizasyon yapısıydı: 10 kişide işe yarayan aynı düz hiyerarşi, aynı tek Slack kanalı, "herkes herkesin pull request'ini review eder" alışkanlığı, 30 kişide teslimatı sessizce boğan şeye dönüştü.

Bu, büyüme aşamasındaki mühendislik organizasyonlarına danışmanlık verirken en sık gördüğümüz başarısızlık örüntüsü: yönetim, ölçeklenmesi gereken değişkenin çalışan sayısı olduğunu düşünüyor ve yapının "kendiliğinden oturacağını" varsayıyor. Oturmuyor. Koordinasyon maliyeti çalışan sayısından daha hızlı büyüyor, teknik borç en hızlı hiper-büyüme döneminde birikiyor çünkü onu ödemeye kimse karar vermiyor, ve organizasyon kendi team topology'sini genelde bir kaza sonucu keşfediyor — çoğunlukla üç ekibi ve altı saati bulan bir incident'ten sonra, çünkü çöken servisin sahibinin kim olduğunu kimse bilmiyordu.

Bunu yanlış yapmanın maliyeti belirli bir biçimde ağır: tek bir felaket değil, her sprint'e binen katlanarak artan bir vergi. 40 mühendisli bir organizasyon 10 kişilik bir yapıyla çalışıyorsa sadece dört kat yavaş olmaz — DORA'nın State of DevOps raporlarındaki deployment frequency (dağıtım sıklığı) ve lead time (teslim süresi) kıstaslarına göre, dağınık büyüyen şirketler genelde "elite" veya "high performer" seviyesinden "low performer" seviyesine düşer; mühendisler kötüleştiği için değil, koordinasyon yükü artık teslimata gitmesi gereken zamanı yediği için. Bu yazı yapının tam olarak nerede kırıldığını — 10, 20, 35 ve 50 mühendiste — ve her eşiğe gelmeden önce ne inşa etmeniz gerektiğini gösteriyor.

Öne Çıkan Noktalar

• İletişim yükü çalışan sayısıyla doğrusal büyümez. Fred Brooks'un The Mythical Man-Month kitabıyla yaygınlaşan ikili iletişim kanalı formülü n(n-1)/2, olası kanal sayısının 10 kişide 45'ten 50 kişide 1.225'e çıktığını gösterir — bu kesin bir üretkenlik modeli değil, kullanışlı bir sezgisel kontrol aracıdır.
• 10, 20, 35 ve 50 mühendis olmak üzere dört somut kırılma noktası vardır; her biri belirli bir mekanizmayı (günlük stand-up, backlog tutarlılığı, onboarding süresi, span of control) kırar. Bunları kutlanacak kilometre taşları değil, planlama tetikleyicileri olarak ele alın.
• Team Topologies (Skelton & Pais) çerçevesi, büyüyen bir organizasyonda kimin neyi sahiplendiğine dair gerçek kararlarla doğrudan eşleşen dört ekip tipi sunar: stream-aligned, platform, enabling ve complicated-subsystem.
• Teknik borç bütçesi, ancak sprint kapasitesinin sabit ve korunan bir yüzdesi olarak tanımlanır ve özellik baskısına karşı hayır diyebilecek bir sahibi varsa işe yarar — her planlama döngüsünde yeniden tartışılan bir niyet değil.
• 50 mühendise ölçeklenmek varsayılan doğru hedef değildir. Bazı şirketler yapısal olarak 15-20 mühendiste kalıp yetenek satın almakta, çalışan sayısını büyütmekten daha iyi durumdadır — aşağıdaki karşı-senaryo bir dipnot değil, gerçek bir karar noktasıdır.
• Architecture Decision Record (ADR) ve code review SLA'ları bu aşamada mevcut en hafif iki yönetişim aracıdır; ikisi de bürokrasi olarak değil alışkanlık olarak ele alınmazsa başarısız olur.

Yapısal Değişim Olmadan Çalışan Sayısı Artışı Neden Kırılır

Mekanizma koordinasyon yüküdür ve kabaca hesaplanabilir bir şekli vardır. İkili iletişim formülü — n kişi için n(n-1)/2 olası iletişim kanalı — genellikle Fred Brooks'un The Mythical Man-Month kitabına dayandırılır; burada Brooks Yasası'nın temelini oluşturur: geciken bir projeye insan eklemek, projeyi daha da geciktirir, çünkü onboarding ve koordinasyon maliyeti eklenen kapasiteyi aşar. Bu formülü gerçek bir üretkenlik kaybı ölçümü değil, bir sezgisel araç olarak ele alın — gerçek ekipler tüm ikili kanalları sürdürmez, iyi bir yapı bunların çoğunu bilinçli olarak bastırır. Ama eğrinin şekli gerçektir:

Bu, çalışan sayısında 5 kat artışa karşılık, olası koordinasyon yollarında 27 kat artış anlamına gelir. Ayrı bir bağlamda, antropolog Robin Dunbar'ın primatlarda neokorteks büyüklüğü ile istikrarlı sosyal grup büyüklüğü arasındaki korelasyonuna dayanan araştırması, bir kişinin sürdürebileceği yaklaşık 150 istikrarlı ilişki rakamını popülerleştirdi — "Dunbar sayısı." Bu rakam, popüler anlatımlarda genelde daha küçük katmanlı grup büyüklükleriyle (sıklıkla 5, 15 ve 50 olarak anılır) birlikte kullanılır. Burada onu organizasyon tasarımında kullanılması gerektiği gibi referans alıyoruz: insan koordinasyon kapasitesinin sonlu ve kabaca sınırlı olduğuna dair yönlendirici bir sinyal olarak, işe alım yapılacak kesin bir eşik olarak değil. Buradaki eyleme geçirilebilir nokta tam rakam değil — belirli bir büyüklükten sonra, ne kadar yetenekli olursa olsun hiç kimsenin sistemin tamamını (teknik ya da organizasyonel) kafasında tutamayacağıdır. Bu tutma işini artık yapı üstlenmelidir.

Kırılma Noktaları: 10, 20, 35 ve 50 Mühendiste Somut Olarak Ne Kırılır

Bu eşikler, koordinasyon mekanizmalarının (stand-up formatı, tek backlog görünürlüğü, span of control, bağlam kazanma süresi) yapısal olarak doyuma ulaştığı noktalara dayanan makul tahminlerdir — evrensel bir kural değildir. Alışılmadık derecede güçlü dokümantasyon disiplinine sahip bir ekip bir eşiği erteleyebilir; yüksek düzenlemeye tabi veri akışları olan bir ekip (örneğin finans sektörü) eşiğe daha erken ulaşabilir. Tabloyu geri sayım değil, planlama tetikleyicisi olarak kullanın.

Büyüyen Bir Mühendislik Organizasyonu İçin Team Topologies

Matthew Skelton ve Manuel Pais'in Team Topologies kitabı dört temel ekip tipi ve üç etkileşim modu tanımlar. 10'dan 50'ye giden bir organizasyona uygulandığında, bunlar gerçek işe alım ve yeniden yapılanma kararlarıyla eşleşir:

Stream-aligned ekipler

Tek ve sürekli bir iş değeri akışına — bir ürün alanına, kullanıcı yolculuğuna veya müşteri segmentine — hizalanmış ekiplerdir. 10 mühendiste varsayılan olarak bir tane vardır. 20'de bilinçli olarak ikiye bölünmüş olmalısınız; her biri günlük teslimat için minimum çapraz ekip bağımlılığıyla net bir dilime sahip. 50'de çalışan sayınızın çoğu stream-aligned ekiplerde olmalı — bu sizin teslimat motorunuz, geri kalan her şey bu motorun bilişsel yükünü azaltmak için var.

Platform ekipleri

Stream-aligned ekiplerin bir talep bileti kuyruğu değil, self-servis bir ürün olarak tükettiği iç servisleri (CI/CD, deployment araçları, ortak auth, gözlemlenebilirlik) inşa eden ekiptir. Çok erken kurmak henüz kimsenin talep etmediği altyapıya çalışan sayısı harcamak demektir; çok geç kurmak ise iki-üç stream-aligned ekibin aynı şeyin uyumsuz versiyonlarını çoktan inşa etmiş olması demektir. Team Topologies'in kendi rehberliğine göre tetikleyici, ekipler arasında yinelenen altyapı emeğine dair kanıttır — pratikte bu, 3 veya daha fazla stream-aligned ekibi olan organizasyonlarda genelde 30-35 mühendis civarında ortaya çıkar.

Enabling ekipler

Stream-aligned ekiplere yeteneklerini artırmak için geçici olarak katılan, sonra kalıcı bir bağımlılık haline gelmek yerine bilinçli olarak geri çekilen küçük bir uzman ekibidir (güvenlik, performans, developer experience). Tam bir platform-güvenlik ekibini gerekçelendiremeden önce bir security champion veya DX uzmanının ait olduğu yer burasıdır — genelde 20-35 mühendis aralığında.

Complicated-subsystem ekipler

Sistemin nadir uzmanlık bilgisi gerektiren bir parçasını — bir fiyatlandırma motoru, bir şifreleme modülü, bir video encoding pipeline'ı — istikrarlı bir arayüzün arkasında sahiplenen ekiptir; böylece organizasyonun geri kalanının üzerine inşa etmek için o uzmanlığa ihtiyacı olmaz. 50 mühendisin altındaki çoğu organizasyonun buna ihtiyacı yoktur; gerçekten nadir teknik karmaşıklığınız varsa (örneğin regüle bir risk skorlama motoru), daha erken kurmayı gerekçelendirebilir.

Pratikte en sık başarısız olan etkileşim örüntüsü: her ekibin her ekiple, her konuda, sürekli işbirliği yapması. Bu, n(n-1)/2 probleminin organizasyonel karşılığıdır. Team Topologies'in çözümü, çoğu etkileşimi bilinçli olarak iyi tanımlanmış modlara sınırlamaktır — sürekli işbirliği yerine X-as-a-Service (platform ekibinin stream-aligned ekiplere temiz bir arayüz üzerinden hizmet vermesi) gibi — tam olarak çalışan sayısı büyürken ikili kanal sayısını yönetilebilir tutmak için.

Organizasyonu Kurmak: İşe Alım Sırası ve Onboarding Sağlığı

Hangi rol, hangi çalışan sayısında

Bu bir sıralama sorusudur — işe alımın kendisinin derinlemesine sürecine (kaynak bulma, mülakat süreçleri, yapılandırılmış onboarding, elde tutma mekanikleri) dair kapsamlı içerik için Yüksek Performanslı Mühendislik Ekipleri Kurmak yazısına bakın. Burada soru daha dar: her yapısal rol hangi çalışan sayısında gerekli hale geliyor.

Sağlık göstergesi olarak onboarding'den ilk pull request'e geçen süre

Bir mühendisin işe başlama tarihi ile ilk anlamlı, merge edilmiş pull request'i arasındaki gün sayısını takip edin. 10 mühendisin altında bu genelde bir haftanın altındadır çünkü bağlam insanların kafasında yaşar ve sorular anında cevaplanır. 35'ten sonra, bu rakam sessizce iki-üç haftayı aşmaya başlıyorsa, bu, dokümantasyonunuzun ve kod tabanı modülerliğinizin çalışan sayısına ayak uyduramadığına dair, teslimat metriklerinde görünmeden önce ortaya çıkan öncü bir göstergedir. Bu izlenmesi gereken bir sinyaldir, kurulması gereken bir program değil; onboarding sürecinin kendisi — yapılandırılmış ramp planları, buddy sistemi, 30/60/90 gün hedefleri — Yüksek Performanslı Mühendislik Ekipleri Kurmak yazısında derinlemesine ele alınıyor.

Code Review Kültürü: Geri Dönüş SLA'ları ve Derinlik Beklentileri

10 mühendiste review senkron ve hızlı gerçekleşir çünkü reviewer'lar zaten tam bağlama sahiptir. Bu 20'de bozulur. Açık hedefler koyun — aşağıdakini kendi bağlamınıza uyarlanacak bir çalışma taban çizgisi olarak ele alın, evrensel bir standart değil: ilk yanıt (onay, yorum veya "şu tarihe kadar review edeceğim") 4 iş saati içinde; yaklaşık 400 satırdan az değişiklik içeren pull request'ler için tam review 1 iş günü içinde tamamlanır. Daha büyük PR'lar olduğu gibi review edilmek yerine bölünmek üzere işaretlenmelidir — bu boyuttan sonra review kalitesi, reviewer ne kadar özenli olursa olsun, keskin biçimde düşer.

Derinlik beklentileri hız kadar önemlidir. Yalnızca geri dönüş hızına göre optimize edilmiş bir review kültürü kaşe gibi onaylar üretir; yalnızca titizliğe göre optimize edilmiş bir kültür ise günler süren tıkanıklıklar üretir. 20-50 mühendis aralığında işe yarayan denge şudur: her PR, etkilenen sistem hakkında bağlama sahip en az bir reviewer alır; reviewer'ların, önemsiz olmayan mantığı onaylamadan önce değişikliği yerelde veya CI'da çalıştırması beklenir; merge'i engelleyen review yorumları sadece bir itiraz değil, somut bir öneri içermelidir.

# CONTRIBUTING.md içinde belirtilen hafif bir PR review SLA örneği
- İlk yanıt: 4 iş saati içinde
- Tam review: 1 iş günü içinde (400 satırdan az değişiklik içeren PR'lar)
- 400 satırdan fazla PR'lar: review başlamadan önce bölünmesi istenir
- Paylaşılan/platform koduna dokunan değişiklikler için iki onay gerekir
- Tek bir stream-aligned ekibin sahip olduğu servisle sınırlı değişiklikler için bir onay yeterlidir

Architecture Decision Record: Bürokrasiye Dönüşmeyen Hafif Dokümantasyon

10 mühendiste sözlü/örtük bilgi (tribal knowledge) geçerli bir dokümantasyon stratejisidir. 35'te sertçe bozulur; iki yıl önce neden event bus mimarinizi seçtiğinizi hatırlayan kişi başka bir ekibe geçmiş ya da şirketten ayrılmıştır. ADR'ler bunu bürokrasiye dönüşmeden çözer — kısa tutar ve yalnızca geri alınması pahalı kararlar için zorunlu kılarsanız.

İşe yarayan bir ADR tek sayfadır: başlık, durum (proposed/accepted/superseded), bağlam (2-3 cümle), karar ve sonuçlar (açıkça vazgeçtiğiniz şeyler dahil). Bunları eskiyen bir wiki'de değil, repo'nun kendisinde numaralandırılmış markdown dosyaları olarak saklayın (/docs/adr/0001-event-bus-secimi.md). Bir kararın altı ay içinde geri alınması pahalı olacaksa yazın — birincil veri deposu seçimi, servis sınırlarının tanımı, auth mimarisi, temel altyapı için build-vs-buy kararı gibi. Bir kütüphane sürüm yükseltmesi veya isimlendirme kuralı gibi geri alınabilir kararlar için yazmayın; ADR'lerin gereksiz angarya haline gelip tamamen yazılmaz olmasının sebebi tam olarak budur.

Teknik Borç Bütçesi: Özellik Baskısına Karşı Sabit Bir Yüzdeyi Korumak

Birçok mühendislik organizasyonu, her sprint kapasitesinin kabaca %10-%20'lik bir çalışma aralığını teknik borç ödemesi, refactoring ve altyapı sağlamlaştırması için ayırır — bunu adı belirtilmiş bir çalışmaya dayanan bir kıstas değil, bağlamınıza göre uyarlanacak makul bir planlama aralığı olarak ele alın. Rakamın kendisi, uygulama mekanizmasından çok daha az önemlidir. Yalnızca beyan edilmiş bir niyet olarak var olan bir teknik borç payı, bir deadline'ın kaydığı ilk anda yağmalanır — ve deadline'lar her zaman kayar, çünkü lansmanlar görünürken borç ödemesi görünmezdir.

Bütçeyi gerçekten koruyan şey: sprint planlamasında "buffer"a gömülmek yerine kendi kapasite satırıyla ayrı bir kategori olarak izlenmesi; adı belirli bir sahibin (genelde EM veya rotasyonlu bir tech lead) engineering director veya fractional CTO'ya eskale etmeden özellikler için yeniden tahsis etmeyi reddetme yetkisine sahip olması; ve özellik teslimatıyla aynı ritimde raporlanması, böylece harcanmayan kısmın sessiz değil görünür olması. Bu, tam olarak fractional CTO yönetişiminin kapsamına giren türde bir karardır — aşağıda ele alınıyor.

Ayrık Bir Platform Ekibi Ne Zaman Kurulmalı

"Er ya da geç" değil — eşik gözlemlenebilir. Üç veya daha fazla stream-aligned ekibiniz olduğunda ve bunlardan en az ikisinin birbirinden habersiz çakışan altyapı inşa ettiğini gösterebildiğinizde (aynı sorunu çözen ayrı deploy script'leri, yinelenen auth middleware'i, paralel logging kurulumları) ayrık bir platform ekibi kurun. Pratikte, çoğu büyüme aşamasındaki organizasyon için bu koşul kombinasyonu genelde 30-35 mühendis civarında ortaya çıkar — stream-aligned ekipleriniz alışılmadık derecede altyapı-ağırlıklıysa daha erken, ilk günden itibaren paylaşılan bir başlangıç şablonu konusunda disiplinliyseniz daha geç.

Bu eşiğe kadar, "bir platform ekibi" işe almayı çalışan sayısı artırma bahanesi olarak kullanma dürtüsüne direnin — ekipler arasında görevlendirilen tek, güçlü bir platform odaklı mühendis (enabling ekip rolüne daha yakın işlev görerek) organizasyonun henüz ihtiyacı olmayan bir koordinasyon katmanı eklemeden ihtiyacı karşılar.

Fractional CTO Yönetişimi: Bu Aşamada Kapsam ve Sınırlar

Bu aşamada bir fractional CTO angajmanı genelde şunları kapsar: mimari inceleme ritmi (ekipler arası teknik kararların ve ADR'lerin onaylandığı düzenli bir oturum), teknik borç bütçesini özellik baskısına karşı yağmalanmaktan korumak, ekipler arasında tedarikçi ve araç standardizasyonu ve stream-aligned ekipler paylaşılan bir arayüz konusunda anlaşamadığında hakemlik yapmak.

Kapsamadığı ve kapsaması da beklenmemesi gereken şeyler: günlük insan yönetimi, performans değerlendirmeleri veya işe alım sürecinin yürütülmesi — bunlar EM'lerin sorumluluğundadır ve Yüksek Performanslı Mühendislik Ekipleri Kurmak yazısında ele alınmıştır; ayrıca organizasyon fractional ritmi gerçekten aştığında tam zamanlı bir teknik işe alımın yerini tutmaz — bu genelde haftalık değil günlük mimari karar alma ihtiyacı doğduğunda gerçekleşir ve çoğunlukla 50 mühendis eşiğinin aşılmasıyla çakışır.

Karşı Senaryo: Mühendislik Ekibini Ölçeklendirme 50'de Ne Zaman Yanlış Hedeftir

Her şirketin mühendislik çalışan sayısını 50'ye çıkarması gerekmez. Bu bir çekince değil — gerçek bir karar noktasıdır ve ters yönde hata yapmak (ihtiyaç duyulmayan çalışan sayısını büyütmek) yapısız büyümek kadar maliyetlidir.

50'ye ölçeklenmek şu durumlarda büyük olasılıkla yanlış hedeftir: ürününüzün özellik yüzeyi gerçekten istikrarlı ve yavaş değişiyorsa (uyumluluk araçları, iç back-office sistemleri, düşük release sıklığına sahip olgun B2B ürünleri) aktif genişlemek yerine; temel farklılaşmanız teslimat hızından çok alan uzmanlığı veya hizmet kalitesindeyse; ya da işe alacağınız şeyin önemli bir kısmı — altyapı operasyonları, özel güvenlik testleri, taşma kapasitesi — şirket içi bir işe alımdan daha düşük koordinasyon maliyetiyle yönetilen bir hizmet veya dış kaynak olarak mevcutsa. Bu durumlarda, yukarıdaki iletişim yükü matematiği aleyhinize işler: ürününüzün gerçekten ihtiyaç duyduğu noktadan sonra eklediğiniz her mühendis, karşılık gelen teslim edilebilir değer artışı olmadan koordinasyon maliyetini (n(n-1)/2 eğrisi) artırır. Dalgalı veya çekirdek dışı işler için yönetilen hizmetler veya uzman bir tedarikçiyle desteklenen 15-20 mühendislik yalın bir ekip, sık sık 40 kişilik bir ekibi mühendis başına hız açısından geride bırakır; tam olarak her ek stream-aligned ekiple gelen koordinasyon vergisini hiç ödemediği için. Durumunuz buysa, üzerinde durulması gereken karşılaştırma 30 ile 50 mühendis arasında değil — build ile buy arasındadır; bu karar çerçevesi için Yönetilen BT Hizmetleri vs Şirket İçi Mühendislik yazısına bakın.

İzlenmesi gereken dürüst sinyal şu: önümüzdeki 18 aylık yol haritanız 2-3'ten fazla eşzamanlı stream-aligned ekip gerektirmiyorsa, muhtemelen 50 mühendise değil, mevcut büyüklüğünüzde daha iyi bir yapıya ihtiyacınız var.

Anti-Patternler ve Yaygın Hatalar

• Bozuk bir sürece çalışan sayısı eklemek. Bu, Brooks Yasası'nın pratikte işleyişidir: bir koordinasyon sorununa mühendis fırlatmak, teslimatı hızlandırmadan önce koordinasyon sorununu daha da kötüleştirir, çünkü her yeni işe alım, onboard olana kadar hıza geçici net bir olumsuz katkı sağlar.
• 20 mühendisten sonra düz kalmak. 20'den fazla kişiyi kapsayan tek bir EM (ya da daha kötüsü, EM yok ve kurucu hâlâ herkesi yönetiyor) yalın değildir, yalın kılığına girmiş bir darboğazdır.
• Başka bir şirketin organizasyon şemasını kopyalamak. Team Topologies, 200 kişilik bir şirketin nasıl organize olduğunu anlatan bir blog yazısından olduğu gibi alınmak için değil, sizin bağımlılık yapınıza ve ürün yüzeyinize uygulanmak için var.
• Her şey için ya da hiçbir şey için ADR yazmak. Her iki başarısızlık modu da yaygındır: mühendislerin etrafından dolandığı bürokratik ADR süreçleri ve sıfır ADR, yani bir sonraki ayrılışla kapıdan çıkmayı bekleyen fazladan adımlı örtük bilgi.
• Teknik borç bütçesinin ilk kesilen şey olmasına izin vermek. Onu korumaya yetkili, adı belirli bir sahibi yoksa bu bir bütçe değildir — bir öneridir, ve öneriler her seferinde deadline'lara kaybeder.
• Çözmesi gereken tekrar sorunu ortaya çıkmadan bir platform ekibi işe almak. Açık bir tüketicisi olmayan (paylaşılan altyapı ihtiyacı kanıtlanmış stream-aligned ekipler) bir işe alım, görev arayan bir ekibe dönüşür.
• Fractional CTO yönetişimini EM düzeyinde insan yönetiminin yerine geçen bir şey olarak ele almak. İkisi farklı sorunları çözer; ikisini karıştırmak her ikisini de yetersiz kaynaklı bırakır.

Sıkça Sorulan Sorular

Bir startup ilk engineering manager'ı ne zaman işe almalı? Genelde 8 ile 12 mühendis arasında — bir kişinin artık hem tam zamanlı production kod yazamayacağı hem de insanları yönetemeyeceği, ikisinden birinin mutlaka bozulacağı nokta. Daha erken bir tech lead rolü mantıklı bir köprüdür ama bu aralıktan sonra yerini tutmaz.

Ayrık bir platform ekibi kurmadan önce kaç mühendise ihtiyaç var? Sabit bir rakam yok — tetikleyici, iki veya daha fazla stream-aligned ekip arasında yinelenen altyapı emeğine dair kanıttır. Bu durum en sık, üç veya daha fazla stream-aligned ekibi olan organizasyonlarda 30-35 mühendis civarında ortaya çıkar.

Team Topologies nedir ve büyüyen bir mühendislik organizasyonuna nasıl uygulanır? Skelton ve Pais'in Team Topologies çerçevesi dört ekip tipi (stream-aligned, platform, enabling, complicated-subsystem) ve aralarındaki etkileşim modlarını tanımlar; amaç, çalışan sayısı büyüdükçe koordinasyon yükünü yönetilebilir tutmaktır.

Her sprint'in ne kadarı teknik borca ayrılmalı? Yaygın kullanılan bir çalışma aralığı, özellik deadline baskısına karşı savunma yetkisine sahip adı belirli bir sahip tarafından korunan sprint kapasitesinin %10-%20'sidir. Bunu bağlamınıza göre kalibre edilecek bir planlama sezgisi olarak ele alın, sabit bir kural değil.

Architecture Decision Record (ADR) nedir ve gerçekten gerekli mi? Veri deposu seçimi, servis sınırları, auth mimarisi gibi geri alınması sonradan pahalı olan kararların bağlamını, kararını ve sonuçlarını içeren tek sayfalık bir kayıttır. Örtük bilginin "bunu neden bu şekilde inşa ettik" sorusuna güvenilir biçimde cevap veremediği noktada gerekli hale gelir; bu genelde 20-30 mühendisten sonra olur.

30-50 mühendise ulaştığımızda tam zamanlı bir CTO'ya ihtiyacımız var mı? Otomatik olarak değil. Fractional CTO yönetişimi, mimari inceleme ritmini, teknik borç bütçesi savunmasını ve tedarikçi standardizasyonunu 30-50 aralığında büyük ölçüde kapsayabilir. Tam zamanlıya geçme tetikleyicisi, haftalık değil günlük mimari karar alma ihtiyacıdır; bu genelde 50 mühendis eşiğinin aşılmasıyla veya sürekli gözetim gerektiren ağır regüle bir sektöre girişle çakışır.

İlgili İçerikler

• Monolitten Mikroservislere Geçiş Rehberi — sadece organizasyon şemanızın değil, mimarinizin de ekip sınırlarına göre bölünmesi gerektiğinde.
• Yönetilen BT Hizmetleri vs Şirket İçi Mühendislik — yukarıdaki karşı senaryoda referans verilen build-vs-buy karar çerçevesi.
• Yüksek Performanslı Mühendislik Ekipleri Kurmak — bu yazının bilinçli olarak kısa tuttuğu işe alım süreçleri, onboarding, performans yönetimi ve elde tutma konularının derinlemesine ele alındığı yazı.

D-Elite Solutions ile Konuşun

D-Elite Solutions'ın Kıdemli Mühendislik ve Güvenlik Ekibi, Kanada ve Körfez bölgesindeki büyüme aşamasındaki teknoloji organizasyonlarına, tam olarak bu 10'dan 50 mühendise geçiş sürecinde organizasyon tasarımı, ekip topolojisi ve yönetişim yapısı konusunda danışmanlık yaptı. Ücretsiz danışmanlık görüşmesi ayırtın; mevcut organizasyon şemanızı, teslimat metriklerinizi ve işe alım planınızı birlikte inceleyelim, hangi kırılma noktasına en yakın olduğunuzu ve ona ulaşmadan önce ne inşa etmeniz gerektiğini belirleyelim — hiçbir yükümlülük ve satış baskısı olmadan.