Technical Lead Nedir ve Ne İş Yapar?

Yaklaşık 10 farklı organizasyonda en kıdemli mühendis olarak görev yaptığım önceki rolümde, organizasyomdaki Technical Lead (TL) rolü için beklentileri belirlemem istendi. Kesinlikle başka birinin bunu zaten belgelemiş olduğunu düşünüyordum. Daha iyi bir Tech Lead nasıl olunur konusunda sunumlar gibi bu konuya yakın materyaller vardı, ancak TL'lerden tam olarak ne beklediğimize dair özel bir şey bulamadım. İş kademesi konuya bir miktar değiniyordu ve genellikle teknik liderler olan Staff Engineers ile beklentiler arasında oldukça fazla örtüşme vardı, ancak bu gerçekten rolün tam bir açıklaması değildi. İş tanımları konuyla ilgili gerçekten hiçbir ayrıntıya girmiyordu.

Danışmanlığını yaptığım diğer firmalar için bazı Technical Lead'ler işe almam gerektiğinden, referans olarak tekrar bir açıklama yazmayı düşündüm. Ancak yaklaşık 20 yıldır aynı şirkette olduğum için, Tech Lead'lerin sizin organizasyonunuzda ne yaptığını duymakla ilgileniyorum.

Tech Lead'ler

Technical Lead, yazılım mühendislerinin işte öğrenmeleri beklenen bir roldür. Kesinlikle ben öyle yaptım. Mühendisler sorulmaları gerekmeden TL sorumluluklarının çoğunu veya tamamını gayri resmi olarak üstlenebilirler. Organizasyonlar projelerinin kimlerinin TL'leri olduğuna dair net tanımlamaları olmayabilir. "Staff Engineer" veya "Engineering Manager" gibi iş unvanı olan bir şey değildir. Organizasyonlar kaç TL'lerinin olduğunu bilemeyebilir veya kaç taneye ihtiyaç duyduklarına dair net bir fikri olmayabilir, çalışan sayılarına kısmen dayanan yöneticiler, direktörler ve VP'lerin aksine.

Peki Tech Lead nedir ve ne yaparlar? Tabii ki bu günlerde en sevdiğiniz AI chatbot'una sorabilirsiniz, ki ben de yaptım:

_Teknik lead (genellikle tech lead denir) bir ekibin veya projenin teknik yönünü yönlendirmekten sorumludur. Rolleri yazılım mühendisliği uzmanlığını liderlik ve koordinasyon ile harmanlar._

"Yönlendirme" bazı durumlarda "yürütme" olmalıdır. Ve bahsettiğim proje türü bir yazılım geliştirme çabasıdır. Eğer bir online hizmet sağlayan bir şirketse, organizasyonun büyüklüğüne bağlı olarak ilişkili üretim hizmetini çalıştırmaktan da sorumlu olabilirler. Bu, kesintiler gibi sorunlar durumunda nöbetçi olmayı da içerebilir.

1. Teknik Sahiplik

• Teknik yönü belirler ve önemli tasarım kararlarını verir.
• Kod kalitesi, ölçeklenebilirlik, performans ve güvenliği sağlar.
• Kodu gözden geçirir ve en iyi uygulamaları ile kodlama standartlarını uygular.

Bu, insanların "Technical Lead" ile ilişkilendirdiği ana sorumluluk alanlarından biridir.

TL'nin projenin teknik sahibi olması ve teknik yönü belirlemesi gerektiği konusunda hemfikirim. Çözümün veya ürünün çekirdek mimarisini ve diğer önemli tasarım kararlarını tasarlar, onaylar ve/veya geliştirir.

TL'ler ekip içindeki tüm iyi fikirleri bulmazlar, ancak Engineering Manager ve/veya Product Manager, bir ürün özelliği veya başka bir iyileştirme (örneğin, ölçeklenebilirliği artırmak için mimari bir değişiklik) gibi bir fikri ne zaman, nasıl ve ne şekilde takip etme konusunda TL'nin teknik yargısına güvenebilir.

Bu nedenle, temel alan için konu uzmanları olmaları (veya olmaları) gerekir.

2. Ekip Rehberliği ve Mentorluk

• Teknik sorular için başvurulacak kişi olarak hareket eder.
• Junior mühendislere mentorluk yapar ve büyümelerine yardımcı olur.
• Ekip üyelerini karmaşık teknik sorunları çözmede destekler.

"Başvurulacak kişi" Google'ın Staff Engineer için teknik kademe açıklamasından doğrudan çıkmış olabilir. (Genel olarak, atıfta bulunacağım seviyeler Google seviyeleri olacaktır.) TL bir sistemin önemli tasarım kararlarını verdiyse, işleyişi hakkında derin bir anlayışa sahip olmalı ve genellikle yeni karmaşık özellikleri uygulamaya ve/veya istenmeyen davranışları gidermeye yardımcı olmak için çağrılır. Ancak bu rolü de dolduran ekipte başka konu uzmanları olabilir.

Mentorluk'un TL'ye özel olması gerektiğini düşünmüyorum. Ekibin daha kıdemli ve/veya daha deneyimli üyeleri veya hatta kodun belirli bölümlerini veya yönlerini daha iyi bilen bireyler, çeşitli durumlarda diğer ekip üyelerine tavsiyelerde bulunmak veya rehberlik etmek gerekebilir.

3. Proje Yürütme

• İşi yönetilebilir görevlere böler.
• Zaman çizelgelerini tahmin etmeye yardımcı olur ve zamanında teslimatı sağlar.
• Teknik işi iş hedefleriyle uyumlu hale getirir.

Bu muhtemelen insanların "Technical Lead" terimiyle ilişkilendirdiği diğer ana alandır.

Engineering Manager ile ortaklaşa, TL geliştirme ve operasyonel lider olmalıdır. Birlikte ekip geliştirme metodolojisine (örneğin, sprintler) karar verebilir ve görevleri önceliklendirip atayabilirler.

Engineering Manager ayrıca TL'nin kapsamı dışındaki engelleri kaldırmaya ve sorunları ele almaya yardımcı olmalıdır; bunlar arasında ekip performans sorunları, ekipler arası çatışmalar, belirli türdeki yetersiz kaynaklar vb. yer alır. Aksi takdirde, Staff+ TL'nin, minimal süpervizyon ile yazılım projesini/ürününü baştan sona yürütmek ve başarılı bir şekilde teslim etmek için yeterli genişlik ve derinlik deneyimine sahip olmasını beklerim. Bu, tipik olarak yeni yüksek öncelikli projeleri yönlendirmek için seçilen yazılım mühendisi seviyesi ve türüdür.

Daha büyük bir organizasyonda, ekipler arasında teslimatları ve bağımlılıkları izlemek ve koordine etmek için bir proje yöneticisinin yardımına sahip olabilirler, ancak genellikle yoktur.

4. Ekipler Arası İletişim

• Ürün yöneticileri ve diğer paydaşlarla koordine eder.
• Mühendisler, ürün yöneticileri, tasarımcılar ve diğer ekipler arasında köprü görevi görür.
• Teknik kavramları teknik olmayan paydaşlara iletir.

Daha büyük organizasyonlarda, TL'ler proje yöneticileri, ürün yöneticileri, ürün tasarımcıları, dokümantasyon ekipleri, çözüm mimarları, SRE'ler, test mühendisleri ve diğerleri dahil olmak üzere ilgili çapraz fonksiyonel rollerle arayüz oluşturabilir. Daha küçük organizasyonlarda, TL'ler bu tür rolleri üstlenebilir veya bunlara yardımcı olabilir. TL'lerin bu diğer rollere yardımcı olmak için gereken teknik uzmanlığa ve proje önceliklerinin ve durumunun farkındalığına sahiptir. Eğer TL boşlukları doldurmaz ise, Engineering Manager ve/veya Product Manager doldurabilir. Bu boşluk doldurma, TL'nin (her alanda usta olmasa da) çok yönlü biri olmasını gerektirebilir.

5. Uygulamalı Kodlama

• Kod yazar, özellikle kritik bileşenler için.
• Diğer mühendislerden daha az zaman kodlamaya ayırabilir ancak teknik olarak hala aktiftir.

TL ne kadar kıdemli olursa (staff engineer, senior staff, principal, distinguished), kapsamları o kadar büyük olur, tekrar şirket boyutuna göre ölçeklendirilir, iki pizza ekiplerinden onlarca veya yüzlerce mühendise kadar — daha büyük kapsamlara sahip TL'ler aşağıda daha detaylı olarak tartışılmaktadır. Bir TL'nin yaptığı kodlama miktarı ölçeğe (ters orantılı olarak) ve kişisel tercihe bağlıdır. Genellikle bir TL'nin yaptığı en yüksek etkili aktivite değildir, ancak bazı TL'ler projelerinin teknik detaylarıyla temas halinde kalmak, ekiplerinin saygısını korumak veya sadece hoşlarına gittiği için yaparlar.

Şahsen bu noktada kodlama yapma ihtiyacı hissetmiyorum, ancak çalışan bir şey inşa etmenin ürettiği neredeyse anlık tatmin ve çok fazla tartışma olmadan keyif alıyorum. Onlarca yıl önce kodlamayı öğrendim ve kariyerimin başlarında TON kod yazdım. Şimdi genellikle projelerin erken aşamalarında, çözüme yaklaşım ve/veya sistemin şekli henüz başkaları için net olmadığında ve ekip küçük olduğunda en çok kodlama yaparım. Örneğin, geçen yıl çok fazla kodlama yaptım, çünkü bu ürünümüz için vizyon ve ilkeleri iletmenin en iyi yoluydu ve küçük bir ekibimiz vardı. Projelerin sonraki aşamalarında, gerektiğinde kodlama yaparım, ancak genellikle zamanımın üst düzey aktivitelerde harcanmasının en iyi olduğunu görürüm. Benim için, tasarım incelemeleri, kod incelemeleri, kod okuma, sorun giderme vb. teknik detayların üstünde kalmak için yeterli yollardır.

6. Kalite ve Süreç Gözetimi

• Kod incelemeleri, test, CI/CD gibi süreçleri tanıtır ve sürdürür.
• DevOps uygulamalarını ve faydalı olduğu yerlerde otomasyonu teşvik eder.

Bu temelde gerçek ürün kodu yazmanın dışında yazılım geliştirmenin temel taşlarıdır.

Organizasyonel standartlar, konvansiyonlar ve araçlara dayalı olarak kod sağlığı, teknik borç yönetimi, kod incelemeleri, tasarım dokümantasyonu, release prosedürleri, test, üretim operasyonları, nöbetçi rotasyonları, postmortemler, güvenlik, gizlilik, uyumluluk vb. konularında en iyi uygulamaları karar veren, belgeleyen ve uygulayan TL olabilir. Büyük, olgun bir organizasyonda bunların çoğu zaten yerinde olabilir. Daha küçük, daha az olgun bir organizasyonda olmayacak ve zamanla geliştirilmesi gerekecektir.

Bu alanlar küçük, aşırı yüklenmiş ekiplerde de eksik olabilir. Yeni hedefler ve girişimler başarılabilmeden önce bu tür proje temellerinin güçlendirilmesi gerektiğini fark etmek TL'ye bağlı olabilir. İyi bir Engineering Manager, ekibin bu alanlarda ilerleme kaydetmek için kapasiteye sahip olmasını sağlamada ortak olabilir.

Kısacası, teknik lider mühendislik ekibinin doğru şeyleri doğru şekilde inşa etmesini — ve birlikte etkili bir şekilde çalışmasını sağlar.

Bu açıklama fena değildi. En azından benim için bir itici güç olarak iyiydi. :-)

TL'lerin yaptığı BİRÇOK şeyden bahsettim. Açıkçası, bütün bu şeylere aynı anda eşit miktarda zaman ayıramazlar. Gerektiğinde, zaman izin verdikçe, ekiplerinde ve organizasyonlarında ne tür boşlukları olduğuna, organizasyonlarının ne kadar olgun olduğuna, kapsamlarının ne kadar büyük olduğuna vb. bağlı olarak yapılırlar. İyi bir Staff+ TL bunları yapabilmeli ve gerekli olduklarını fark edebilmelidir.

Uber Tech Lead'ler

Google'ın bazı bölümleri "Uber Tech Lead" (UTL) terimini kullanır. Terim en azından bu noktada sadece Google'a özgü değil. Genellikle "TL'lerin TL'si"ne atıfta bulunur, genellikle Google'da L7/Senior Staff veya L8/Principal Engineer olacak olan Staff seviyesinin üzerindeki yazılım mühendisleri durumunda. UTL'lerin genellikle yönetim sorumlulukları yoktur (yani, "Tech Lead Manager" değil).

Diğer zamanlarda, UTL tüm projeler veya ekipler yerine birden fazla projeyi veya ekibi kapsayan yönlerden sorumlu birine atıfta bulunabilir, örneğin Gizlilik veya müşteri odaklı API standartları gibi. Bu bazen "Horizontal TL" olarak adlandırılır. Bazı organizasyonlar "Architect" rolünü/unvanını kullanabilir, ancak diğerleri olumsuz çağrışımlar nedeniyle bundan kaçınır.

Her iki durumda da, UTL'ler sadece danışmanlık/tavsiye verme, geri bildirim sağlama ve/veya bağlayıcı iş yapmak yerine sorumluluk alanlarındaki çabaları yürütmelidir. Daha küçük bir çabanın TL'sine benzer şekilde, teknik sahip ve yürütme lideri olurlar ve başarılı teslimatından sorumludurlar.

UTL rolü genellikle taktiksel olmaktan çok strategiktir. UTL'ler TL'ler, Product Manager'lar (PM'ler) ve Engineering Manager'lar ile birlikte teknik vizyon, strateji ve yol haritasının ortak sahipliğini yapar ve ortak liderliğini üstlenir, ve TL'ler, PM'ler ve UX ile birlikte deneyimin ortak sahipliğini yapar. Teknik ve ürün hedeflerinin alt projelerinin organizasyonlarının daha geniş hedeflerini desteklemesini sağlamaya yardımcı olurlar. Zaman zaman, geliştirici odaklı ürünlerin stratejisi ve/veya yol haritaları üzerinde TL'lerden daha çok Product Manager'larla çalıştım.

UTL'ler daha küçük ekiplerin TL'lerinden daha yüksek seviyede çalışırlar, örneğin bileşenler arası mimari ve teknoloji kararları vererek. Ayrıca sorumluluklarındaki bileşenlerin tasarımlarının daha büyük bağlama tutarlı bir şekilde uymasını sağlamaları gerekir. Ayrıca TL'ler arasındaki anlaşmazlıklar için teknik yürütme noktası olarak hareket edebilir ve önemli teknik kararlar için son onaylayıcı olarak hareket edebilirler.

Bununla birlikte, UTL'nin kapsamı ne kadar büyük olursa, UTL'nin her PR'yi veya tasarım belgesini onaylama kritik yolunda olmak yerine, ilkeler, standartlar, spesifikasyonlar, süreçler, en iyi uygulamalar, yön vb. yoluyla doğru sonuç için zemin hazırlamaya o kadar çok odaklanması gerekir. Mümkün olduğu yerlerde, UTL'ler onları yavaşlatan darboğazlar haline gelmek yerine çabaları hızlandırmak için çerçeveler sağlamalıdır. Bu aynı zamanda Kubernetes SIG Architecture'da kurmaya çalıştığım yaklaşımdı.

TL'lerde olduğu gibi, bu çok fazla sorumluluk ve UTL'ler hepsine aynı anda eşit dikkat veremezler. Dikkatiniz dağıldığında herhangi bir şeyde ilerleme kaydetmek zordur. Genellikle bir seferde odaklanmak için bir veya birkaç önemli alan seçmeye, bunları çözmek için TL'ler, Engineering Manager'lar ve/veya Product Manager'lar ile çalışmaya, onları devretmeye ve sonra bir sonraki en yüksek öncelikli veya en acil yangına geçmeye çalışırdım.