T-Shaped Mühendisler: Frontend ve Backend'de Ölçekleme Farkı

T-shaped engineer kavramı sıkça işitilir, ama pratikte ne demek gelir sorusunun cevabı takımın hedefine bağlı değişir. Hızlı özellik teslimi mi lazım? Genişlik kazanmak (yatay çubuk) daha faydalı. Platform kararlılığı mı? Derinlik (dikey çubuk) önemli hale geliyor.

Frontend ve backend için ihtiyaç gerçekten farklı. Bir frontend mühendisi CSS, JavaScript, state management, erişilebilirlik gibi alanlarda güçlü olmalı; aynı zamanda API tasarımı, veritabanı mantığı hakkında fikir sahibi olması değer katabilir. Ama bu, onu backend mimarı yapmaz. Tersine, backend mühendisinin CI/CD, ağ, güvenlik konularında derinliği kritik; frontend ekosistemi hakkında temel bilgi de faydalı.

Gerçek sorun checklist kültürü. İşe alımda, yöneticiler T-shaped olması gereken bir mühendise "bu 10 skill'i bil" listesi verirler. Mühendis onları bir kez tıklar, sonra unutur. Sonra senior frontend mühendisinden CI pipeline'ı yönetmesi istenir, ya da backend lider CSS değişkeni düzeltmek için çağrılır.

Önemli metrik story point değil, MTTR (ortalama onarım süresi) ve velocity dengesi. Genişlik arttıkça context switch artar, bu da çekirdek alanda kalite düşürür. Takım ölçeklenirken, her rolün derinliğini korumak kadar, gerekli alanlarda çapraz bilgi paylaşımı sağlamak da kritik. Bir mühendis tüm yığını bilmek zorunda değil; ama iş akışı içinde işbirliği yaparken diğer tarafı anlayabilmesi gerekir.