Як на мене, ця враза так само вірна як і фраза «Чим раніше займались Senior Deveoper’и тепер називають модним словечком Architect Developer». А власне, всі кордони умовні і скоріш за все Ви праві. Як я казав у пості, одна справа «посада», інша «ролі». Якщо все те, що перелічено вище, можна навантажити на Team Lead і в компанії це ок, то тоді це він і є. У великих компаніях більше процесів і команд більше, тому EM може займатись кількома командами.
Тут інше питання, що часто плутають в компаніях Team Lead і Tech Lead, і я дуже часто бачу плутанину, коли фактично не можуть це розділити.
Ну, може і так. Все залежить від розмірів команд і укомплектованості компанії, мені здається.
Тобто зазвичай у техліда багато роботи саме по проєкту і керуванню самим процесом написання коду, вибором технологій, проектування фіч, прийняття важливих технічних рішень.
А от займатися людьми (ширше ніж просто хороводити таски, скрам, фічі, робити код ревью і так далі) — часу не дуже багато.
Планування версій, контроль E2E тестування, спілкування з PM та іншими представниками бізнесу про те що і коли вийде, обговорювати пріоритети, вистроювати план робіт на майбутній квартал та інше — тут взагалі не реально. От всім цим, що вже не влазить в техліда і займається Engineering Manager.
Ну і так, цех схоже на «Teхлід на Техлідами», хоча скоріше навіть «тімлід над тімлідами».
Чекаємо перших дописувачів на цей холівар )
Так, у Valve Corporation дещо унікальна організація розробки, у низ немає (точніше є, але дуже мало і точково) виділених Engineering Manager. Але вони використовують модель «Peer Leadership», коли хтось з команди бере на себе менеджерську роль по якомусь проекту. Це цікава модель, але вона як раз вимагає щоб велика кількість членів команди мала б якісь менеджерські навички.
Має право на життя, но не завжди будь де так працюватиме.