Чому шлях у тімліди простіший, ніж у техліди (і як ним іти)

💡 Усі статті, обговорення, новини про HR — в одному місці. Приєднуйтесь до HR спільноти!

У житті будь-якого сеньйорного розробника колись настає момент рефлексії. Зазвичай це виглядає так: увечері після робочого дня він (або вона) закриває ноутбук і раптом усвідомлює, що вже десятий рік качає хард скіли, тобто здобуває та вдосконалює технічні навички. Виникає болюче питання: ще довго тягти? Скільки ще це триватиме, і що далі робити з цим прекрасним багажем?

Якщо ми не розглядаємо кардинальної зміни професії, то в IT для таких кризових душ є два стандартні шляхи.

Перший — глибше в техніку, в бік позицій технічного лідера або архітектора.

Другий — у менеджмент, тобто в людей. І це виглядає досить ризиковано, бо там, жах-жах, треба розмовляти, а не тільки код писати.

Кодити не можна менеджерити

Шлях в техліди розробникам зрозумілий з очевидної причини: «Я і так всю дорогу техскіли качав, треба просто глибше розібратися». Додати ще одну мову програмування, нові технології, бібліотеки, та хоч ШІ — аби не дивитися в бік менеджменту.

Перехід у менеджмент багато кого лякає, бо треба засвоїти певні софт скіли. А це з культури проджект-менеджерів, яку розробники не люблять.

Коли людина не може вирішити, вона обирає не те, що легше, а те, що зрозуміліше. У нашому випадку — технічний розвиток. Ми не засуджуємо, але давайте подивимося на речі тверезо.

Скільки техлідів треба, щоб вкрутити лампочку

Більшість навіть не замислюється, що шлях в техліди призводить до суттєво більших проблем із пошуком роботи.

Давайте порахуємо. На 100 розробників у компанії потрібен, дай Боже, один архітектор, а може навіть один на 200. Може, ще пара-трійка техлідів — якщо в компанії взагалі передбачена така позиція (у багатьох її просто немає). Принсипали та стафф-інженери — це взагалі не позиції, а фантастичні істоти: знайти їх може лише чарівник.

Тобто з 40-50 сеньйорних розробників один влаштується на таку позицію. А решта?

Тепер підрахуємо тімлідів. Середня команда розробників — це 4 особи. Отже, на 100 розробників потрібно 20 тімлідів. Відповідно, потрапити на позицію тімліда в рази простіше, ніж на позицію техліда.

Добре, математика виглядає переконливо. Але як стати тімлідом, якщо ти в житті не займався менеджментом?

Проблема з навчанням і як навчають не тому

Розробник, який вирішив стати тімлідом, робить перші кроки дуже невпевнено. У звичайних програмістів менеджерських навичок небагато — звідки б? Починається пошук курсів. І тут у нас проблема.

Я колись шукав аналогічну інформацію. Усі курси для тімлідів, які є на ринку, написані проджект-менеджерами. Це дуже неправильно. Це як курс для медсестер, написаний лікарем. Начебто чомусь навчили, але це ж інша професія!

Позиція тімліда вимагає набагато глибшого занурення в технічні знання та проблеми. Проджект-менеджер про багато технічних аспектів розробки не повинен знати. Тімлід, своєю чергою, не повинен глибоко вдаватися в управління обсягом робіт та ризиками, вимоги замовника, фінансові ризики — це все за межами його компетенції.

Методи, які використовує проджект-менеджер, не підходять для управління невеликою командою розробників. У результаті випускники курсів знають дуже багато, але не те що треба. І не розуміють, як це застосувати на практиці.

Як стати тімлідом (і не облажатися)

Проблема з навчанням і як навчають не тому

Мені до душі практичний підхід до освоєння нових скілів. Отримати базові навички керівництва командою просто. Сеньйор-розробник може взяти шефство над джунами. Зібрати невелику команду і стати в ній лідером. Не в сенсі пафосних промов на тлі логотипу компанії, а в реальному, повсякденному: допомогти, пояснити, іноді пожаліти, іноді посварити. Такий управлінський sandbox.

У процесі потрібно буде вдосконалювати критично важливі софт скіли.

1. Паблік спікінг (публічні виступи)

Тімлід — це той, хто постійно щось пояснює: «Йдемо туди», «У нас проблема», «Робимо ось це». Навіть інтроверту все одно доведеться розмовляти, а не тільки писати технічні доки пасивно-агресивним тоном.

2. Управління конфліктами

Більшість розробників не замислюється про те, що конфлікти в IT — це не баг, а фіча. Причини класичні: у бізнесу свої інтереси, у розробників — свої, і збігаються вони приблизно так само часто, як смаки у фанатів Vim та VS Code. Програмісти — люди захоплені, у кожного своє бачення «як правильно». У підсумку в команді два козаки й три гетьмани, а тімліду треба знайти компроміс і змусити їх працювати, причому ефективно.

3. Активне слухання

Джунів треба буде слухати. Не просто чекати своєї черги говорити, а справді слухати. Іноді джун скаже дурницю, але в ній буде зерно істини — і задача тімліда це зерно не викинути разом із лушпинням.

Чим насправді займається тімлід

Перейдемо до практичних аспектів роботи тімліда. Це мікс із психотерапії, організації та технічного контролю.

Найм та онбординг

Проведення технічних співбесід. Тімлід на технічній співбесіді вирішує, кого впустити в команду, а кого — ні. Саме він оцінює не лише технічний рівень кандидата, а й те, наскільки той впишеться в команду.

Онбординг. Навіть якщо прийшов досвідчений розробник, його потрібно ввести в курс справи: процеси, кодстайл, архітектура, CI/CD, розгалуження, код-рев’ю. Проджект-менеджер цього не вміє і ніколи не буде робити. Це не його обов’язки. Це повинен робити тімлід, але на курсах цей нюанс зазвичай ігнорують.

Процеси в команді

Загальне управління процесами. Тімлід відповідає за те, щоб процес йшов, задачі не губилися, люди розуміли пріоритети, а всі дедлайни дотримувалися (ну або майже всі). Треба налагодити планування, оцінки, мітинги. Хай це буде хоч кастомний Agile із гівна та палиць, головне, щоб працювало. Коли нова людина приходить в команду, вона підлаштовується під те, як там прийнято. Для цього потрібно осмислити та створити оце «прийнято».

Декомпозиція та розподіл задач. Тімлід декомпозує великі таски на завдання і розподіляє їх. Можливо, самі співробітники вибирають таски за пріоритетами. Але задача правильно розподілити роботу, щоб ніхто не був ображений, — це для тімліда.

Налаштування код-рев’ю. Тімлід повинен стежити, щоб рев’ю не було формальністю, але й не викликало PTSD у розробників. Як, хто, коли проводить код-рев’ю, як зробити, щоб не створювалося пляшкового горлечка — має знати тімлід. Ще один блок, який проджект-менеджери не знають і ніколи в нього не лізли — це далеко за межами їхніх компетенцій.

Зворотний зв’язок та комунікація

Конструктивний фідбек. Хороший тімлід учиться його давати, як позитивний, так і негативний. Не просто «ти зробив погано», а «ти зробив не так, і ось чому, і ось як зробити краще». А також саме тімлід повинен доносити до колег, що треба, приміром, зменшити токсичність у спілкуванні. Це і зворотний зв’язок, і управління конфліктами.

І так, похвала — теж обов’язкова. Ніхто не вигорає так швидко, як людина, яку ніколи не хвалять. Конструктивно хвалити теж треба вчитися.

Регулярні мітинги. Розробники їх недолюблюють, а менеджери знають, що без них не обійтися. Створити та підтримувати найбільш ефективний графік мітингів — задача тімліда.

One-on-one зустрічі. Регулярні особисті зустрічі — це не менеджерська вигадка, а реальний інструмент. На них вирішуються особисті питання, мотивація, непорозуміння. Їх теж треба вміти проводити так, щоб це було не балаканиною, а коректним, екологічним обговоренням професійних питань.

Комунікація з менеджментом

Обов’язок тімліда — робота з проджект-менеджером та, можливо, з представником замовника або бізнес-аналітиком (залежно від структури компанії). Його задача — тримати баланс між двома світами, які щиро вважають один одного дивними. А іноді цих світів більше, якщо компанія велика.

Потрібно максимально захищати свою команду, прикривати від менеджменту, і навпаки, менеджмент від команди. Ми знаємо, як програмісти люблять спілкуватися з високим керівництвом, а тим більш із замовниками.

Так що тімліду треба бути перекладачем від команди до проджект-менеджера і навпаки. Тімлід доносить до бізнесу, що «технічний борг — це не нитво», і пояснює команді, чому бізнесу «треба вчора». А те, що каже бізнес, треба пояснювати команді технічною мовою: «Хлопці, нам треба зробити ось це, і ось чому».

Технічні рішення

Хороший тімлід не перестає бути інженером. Він бере участь в обговоренні архітектурних рішень, слухає команду, особливо досвідчених розробників. Іноді він приймає рішення одноосібно, іноді — колективно, але завжди відповідає за результат.

Загальне керівництво

Є такий анекдот: «З прорабом тут працює десять чоловік. А без прораба ніхто не працює». Так влаштовані люди: якщо немає людини, яка за все відповідає, нічого не рухається. Військові погодяться: краще поганий командир, ніж відсутність командира. Хтось повинен цим займатися.

Чому навчання тімлідів майже не існує

Більшість компаній живуть у логіці: «Нехай кожен росте, як трава після дощу». Розробникам дають курси з Kubernetes, але не дають жодного з управління людьми.

У підсумку виходять чудові інженери, які вміють підіймати інфраструктуру, але губляться, коли двоє колег сперечаються через табуляцію.

Системного підходу до розвитку тімлідів немає. Хоча саме від них залежить, як працює команда і чи буде вона вигоряти.

Я сам був тімлідом близько 15 років, посади мої називалися по-різному, але обов’язки були тімлідські. Зараз як директор компанії теж керую програмістами, але вже на іншому рівні. Я був з усіх боків барикад: і програмістом, і керівником проєкту, і директором, який їх наймає. От і вирішив трохи привідкрити завісу на це болюче питання.

І моя вам рекомендація — головне, не самоусувайтеся і не бійтеся брати на себе відповідальність.

Сподобалась стаття автора? Підписуйтесь на його акаунт вгорі сторінки, щоб отримувати сповіщення про нові публікації на пошту.