Привіт, спільното. З вами знов Сергій Немчинський. Коротко про мене: 30 років в ІТ, з яких 15 — тімлідом. Пройшов шлях від джуніор-розробника до власника та CEO навчального центру ІТ-професій FoxmindEd, а ще я ведучий власного YouTube-каналу про ІТ.
У своїх роздумах про те, як ШІ впливає на індустрію розробки, я намагаюся розглянути актуальні тренди та екстраполювати їх на майбутнє. Але сьогодні доведеться звернутися ще й до минулого.
Отже, у технологічні компанії прийшла нова модна оптимізація — штучний інтелект у менеджменті. Компанії спрощують організаційні структури, скорочують середню ланку менеджерів і покладають частину управлінських функцій на ШІ. Це не абстрактний тренд: Енді Яссі в Amazon публічно оголосив курс на скорочення менеджерських рівнів на користь IC, а Gartner прогнозує, що понад 20% технологічних компаній уже впроваджують або планують org flattening.
Паралельно стара роль Team Lead, або Engineering Manager, часто розкладається на дві: окремий People Manager займається людьми, а Staff/Senior/TLM відповідає за технічні рішення. Ба більше, технічні рішення в цій парадигмі цілком нормально передати IC, тобто Individual Contributor. Так називають будь-якого досвідченого розробника без менеджерських функцій — адже в епоху ШІ кожен із нас трохи тімлід. Особливо якщо цей IC ще й озброєний Cursor, Copilot або Claude Code.
Gallup уже підрахував, що середня кількість підлеглих на одного менеджера зросла з 8,2 людини у 2013 році до 12,1 у 2025-му. При цьому залученість самих менеджерів впала до критичних 22% — що чітко сигналізує про вигорання та формалізацію управління. Згідно з прогнозами, дедалі більше компаній використовуватимуть ШІ для скорочення середньої ланки й подальшого збільшення span of control.
Як завжди, усе робиться з найкращими намірами. Менеджер більше не лізе в архітектуру. Сильний розробник не витрачає час на performance review. Кожен займається тим, що вміє найкраще. Ще й економія яка — адже під кожну нову роль можна долучити більше підлеглих.
Мені цей тренд категорично не до вподоби, і ось чому. Розділення leadership-функцій може працювати. А ось спроба просто прибрати Team Lead, розмазати його обов’язки між People Manager та Senior IC і назвати це новою моделлю управління — значно гірша ідея.
Чому я такий впевнений? Тому що добре пам’ятаю спроби відокремити Team Lead і Tech Lead та до чого вони призвели. Це ж було вже.
Треба розуміти: разом із посадою нікуди не зникає відповідальність.
Проблема не в тому, що менеджер перестав кодити
Почнемо з популярної крайності: мовляв, Engineering Manager, який не пише код, автоматично втрачає авторитет. Це надто примітивне пояснення. Справа не в тому, наскільки хороший розробник ваш менеджер — він взагалі може ним не бути.
Проблема починається, коли менеджер настільки віддаляється від технічного контексту, що вже не здатний оцінити наслідки рішень. Тобто він має бути зануреним у щоденні процеси команди й добре їх розуміти.
Не обов’язково самому писати реалізацію, але необхідно розуміти, чому один архітектурний компроміс коштуватиме команді два додаткові дні роботи, а інший через півроку перетвориться на місяць переробок.
Якщо People Manager усувається від технічного контексту, виникає питання: чим саме він займається? У невеликих командах робота з людьми не займає весь робочий час. Тоді є лише два шляхи: або вигадувати безглузду бюрократію й імітацію діяльності, щоб зайняти 40 годин фултайма, або працювати на п’ять різних команд — де він остаточно втрачає розуміння процесів у кожній із них.
Навіть компанії, які свідомо розділяють технічне лідерство та управління людьми, це добре розуміють.
Наприклад, у GitLab ролі Engineering Manager і Staff+ Engineer належать до різних напрямів розвитку. Технічне лідерство там справді може бути відповідальністю IC. Але від Engineering Manager усе одно очікують технічної компетентності, розуміння архітектури продукту та особливостей роботи команди.
Там, де People Manager відповідає лише за людей, а IC — лише за техніку, вони майже не взаємодіють. І ціна такої моделі часто виявляється значно вищою через додаткові витрати на координацію.
Двовладдя, коли ніхто не володіє результатом
Уявіть команду оцього нового типу. People Manager відповідає за performance, розвиток людей, 1-on-1 та конфлікти. Tech Lead відповідає за архітектуру, якість коду і технічні рішення. Краса.
Але ось продакшн падає через рішення, яке команда прийняла три місяці тому, щоб вкластися в строки.
«Я попереджав про ризик. Але бізнес вирішив, що дедлайн важливіший», — каже Tech Lead.
«Нам поставили задачу, ми виконали її вчасно», — знизують плечима розробники.
«Архітектура — не моя зона відповідальності», — каже People Manager.
Формально всі праві. Але система лежить.
Це називають accountability gap — розривом відповідальності. Ситуацією, у якій окремі функції між учасниками розподілені, але ніхто не відповідає за кінцевий результат.
Важливий нюанс: Tech Lead технічно має право вибору архітектури. Але він не має менеджерських важелів впливу — 1-on-1, участі в оцінці, інструментів мотивації. Тому People Manager тисне вимогами «встигнути в спринт», а Tech Lead не може ані захистити рішення, ані реально вплинути на поведінку команди. Повноваження є, а влади — немає.
У класичній моделі Team Lead теж не ніс одноосібної відповідальності за все. Проте в команді була людина, яка одночасно бачила технічний стан системи, розуміла можливості команди, оцінювала ризики та враховувала бізнес-контекст.
Один конфлікт, два керівники, нуль рішень
Розглянемо ще один сценарій: конфлікт між двома розробниками щодо технічного рішення. Один пропонує швидкий варіант, щоб випустити нову функцію вже в поточному спринті. Інший наполягає на складнішому архітектурному рішенні, оскільки швидкий підхід створить надмірну залежність між компонентами в критичному модулі.
Хто має ухвалити остаточне рішення? People Manager? Ні — він здатний лише модерувати розмову, а не оцінювати запропоновані рішення. Tech Lead, навпаки, добре розуміє технічний бік проблеми, але не має управлінських повноважень та організаційного авторитету.
Так з’являється прихований менеджмент. Інженер отримує лідерські обов’язки, але не отримує ні повноцінної ролі, ні відповідної підготовки. Відповідальність уже є, а повноважень ще немає. Швидше за все, і грошей за додаткове навантаження теж. У професійній спільноті це явище описують як New leader syndrome — коли на інженера вішають управлінські обов’язки без підготовки та реальних повноважень.
IC не стає Team Lead від одного рядка в оргструктурі
Ще один популярний міф: сильним розробникам Team Lead більше не потрібен. Мовляв, сучасні Senior-інженери настільки автономні, що здатні самостійно проєктувати системи та домовлятися з бізнесом. А якщо ще й озброїти такого IC інструментами на кшталт Cursor або Claude Code — він взагалі замінить цілу команду. І тут є проблема.
Так, ШІ-інструменти справді роблять IC продуктивнішим. Але вони прискорюють написання коду, а не прийняття рішень. Без тімліда такий ШІ-IC просто втричі швидше накопичує code churn і некоординований техборг. Швидше — не означає краще, якщо немає людини, яка бачить систему цілком.
Бізнес говорить мовою грошей, термінів і прибутку. Інженери говорять мовою архітектури, рефакторингу та технічного боргу. І дуже часто вони просто не розуміють одне одного.
Ось як це виглядає на практиці.
Як каже звичайний IC — і програє бізнесу: «Це спагетті-код і погана архітектура!» Бізнес відповідає: «Нам байдуже, робіть».
Як каже тімлід-перекладач: «Ми можемо вкластися в шість тижнів. Але це рішення збільшить вартість будь-яких подальших змін у цьому модулі й поставить під загрозу наступні релізи. Можемо піти іншим шляхом: скоротити обсяг функціональності, ізолювати новий код і запланувати його рефакторинг у наступному циклі розробки».
Технічна проблема не змінилася. Змінилася мова. Але цю мову ще треба вивчити. Саме тому навіть дуже сильний Individual Contributor не стає лідером автоматично. І саме це часто відрізняє сильного Senior Engineer від людини, готової реально вести команду.
Архітектурна експертиза не замінює лідерство
Отже, чистий People Manager не може бути повноцінним лідером команди розробки — бо не має технічної експертизи. Але чистий інженер теж на це не здатний. Він може чудово розуміти контекст, бачити ризики й ухвалювати складні рішення. У багатьох компаніях такі фахівці визначають технічний розвиток продукту. Але архітектурна експертиза сама по собі не робить людину лідером.
Побачити проблему недостатньо. Потрібно переконати бізнес, домовитися з командою, розставити пріоритети й узяти на себе відповідальність за наслідки. Саме тому технічний авторитет і управлінський авторитет далеко не завжди збігаються. Уміння знайти ризик не означає вміння пояснити, як цей ризик вплине на строки, витрати або прибуток.
Якщо компанія прибирає Team Lead, але очікує, що Senior IC просто підхопить його функції, вона фактично створює нову управлінську роль — тільки без назви, без підготовки й без необхідних повноважень. І часто без відповідної оплати.
Ентропія організаційної структури
Ось що мене найбільше бентежить у цій моді на org flattening та ШІ: простіше не стає. Відповідальність розмивається, кількість точок ухвалення рішень збільшується, а організаційна ентропія лише зростає.
У класичного Team Lead є одна важлива перевага: значна частина контексту зосереджена в одній голові. Після розділення ролей ця картина змінюється. Бізнес спілкується з Product Manager, той передає інформацію People Manager, координується з Tech Lead, а Tech Lead працює з командою. Між цими етапами з’являються додаткові зустрічі, листування, уточнення та погодження. Що більше таких переходів — то вищий ризик втрати контексту.
Компанія, яка піддалася модному тренду, може заощадити на менеджменті, але дуже швидко зіткнутися зі зростанням витрат на координацію. Проблема не зникає. Вона просто переміщується з однієї частини системи в іншу.
ШІ може автоматизувати рутину, але не замінить лідерство
Саме тут час згадати про штучний інтелект. Він уже вміє писати код, готувати звіти, підбивати підсумки зустрічей і допомагати з плануванням. Саме тому ідея скоротити менеджмент здається такою привабливою: значну частину рутинної роботи можна делегувати ШІ.
Але найскладніша частина роботи Team Lead ніколи не полягала в рутинних завданнях. Хтось усе одно повинен вирішити, чи варто жертвувати якістю коду заради швидкого релізу, як знайти компроміс між двома досвідченими розробниками та хто візьме на себе відповідальність за наслідки цього рішення.
Штучний інтелект може надати дані й запропонувати варіанти. Але відповідальність за остаточне рішення все одно залишиться за людиною.
Чи повернеться класичний Team Lead
Я не впевнений хіба що в старій назві. Організаційні структури змінюються, ролі еволюціонують, а компанії постійно експериментують із новими моделями управління. Може, це називатиметься по-новому.
Але команді, як і раніше, потрібна людина, яка бачить повну картину. До якої приходять із технічними питаннями, конфліктами, новими вимогами бізнесу та виробничими інцидентами. Єдина точка відповідальності, яка поєднує всі процеси в команді.
Цю функцію можна розділити між кількома людьми та ШІ-агентами. Але що більше учасників з’являється в цьому ланцюжку — то складнішою стає координація.
Прогнозую, що після першої хвилі захоплення org flattening компанії знову почнуть шукати фахівців, які здатні поєднати технічну експертизу та управління людьми. Тобто тімлідів. Навіть якщо ця роль уже не називатиметься Team Lead, потреба в такій людині нікуди не зникне.
Два крила, без яких лідер не злетить
Наприкінці пропоную невеликий тест. Чи можете ви пояснити цінність рефакторингу мовою бізнесу? Чи приймає команда ваші технічні рішення завдяки вашому авторитету, а не тому, що так сказало керівництво? Чи здатні ви під час кризи захистити команду й одночасно пояснити бізнесу, що саме сталося?
Якщо хоча б на одне із цих запитань ви відповіли «ні» — вам, найімовірніше, потрібно розвивати обидві компетенції. Технічну — щоб розуміти архітектуру й бачити наслідки рішень. Управлінську — щоб працювати з людьми, вирішувати конфлікти й говорити з бізнесом однією мовою.
Саме для цього у FoxmindEd існують курси Team Lead та Architecture — де ми вчимо не просто технологій і не просто менеджменту, а вмінню поєднувати обидва світи. Тому що майбутньому лідеру недостатньо бути просто хорошим розробником. І недостатньо бути просто хорошим менеджером. Найбільшу цінність матимуть люди, які вміють поєднати обидва.