Перший тиждень на новій ролі, і ти ловиш себе на тому, що замість написання коду сидиш на четвертій за день зустрічі, а власні задачі так і лежать невиконані. Вчора ти був найсильнішим розробником у команді, а сьогодні твоя робота це вже не код, а люди, які його пишуть. І це два абсолютно різні набори навичок.
Головна пастка переходу в тому, що тебе підвищили за технічну майстерність, а оцінювати тепер будуть за те, чого тебе ніхто не вчив: комунікацію, делегування, рішення. Розберемо, що реально змінюється і як пройти цей перехід без вигорання.
Чому найсильніший розробник не завжди стає добрим тімлідом
Тут криється найпоширеніша помилка, і вона коштує командам дорого. Компанії підвищують людину за те, що вона круто пише код, а на новій позиції цей навик стає другорядним. Бути тімлідом це не «старший розробник із ширшими правами», це окрема професія зі своїм набором задач.
Різниця відчувається одразу. Раніше твій результат вимірювався твоїм кодом. Тепер він вимірюється результатом п’ятьох чи семи людей, більшість з яких пишуть гірше за тебе, і з цим доведеться змиритися. Спокуса зробити все самому величезна, і саме вона вбиває нових тімлідів. Ти береш задачу за задачею на себе, вигораєш за три місяці, а команда так і не навчилася працювати без тебе.
Ще один момент, який ламає багатьох. Технічний авторитет не дорівнює лідерському. Люди слухають тебе не тому, що ти найкраще знаєш фреймворк, а тому, що довіряють твоїм рішенням і відчувають, що ти на їхньому боці. Це будується не кодом. Щоб зрозуміти, наскільки далеко роль тімліда відійшла від суто інженерних задач, корисно згадати, що взагалі роблять на роботі Junior, Middle і Senior і де в цій драбині губиться момент, коли технічна експертиза перестає бути головним.
Які навички доведеться качати з нуля
Більшість того, що зробило тебе сильним розробником, на новій ролі майже не допомагає. Але нові навички цілком опановуються, якщо не робити вигляд, що вони прикладаються самі. Ось що доведеться свідомо розвивати:
- Делегування. Найважче для колишнього розробника. Треба навчитися віддавати задачу, яку сам зробив би за годину, людині, яка витратить день і зробить гірше. Інакше команда не росте, а ти тонеш.
- Зворотний зв’язок. Давати фідбек так, щоб він мотивував, а не ображав. Це окреме мистецтво, і природної здатності тут немає майже ні в кого.
- Комунікація з бізнесом. Тепер ти міст між командою й замовником чи менеджером. Треба говорити з ними однією мовою й захищати команду від нереальних дедлайнів.
- Прийняття рішень в умовах невизначеності. Раніше була одна правильна відповідь у документації. Тепер часто немає жодної, а рішення все одно треба ухвалити й нести за нього відповідальність.
- Управління власним часом. Твій день тепер рветься на шматки зустрічами й питаннями. Без жорсткої дисципліни особиста продуктивність падає в нуль.
Жоден із цих пунктів не вмикається сам собою після підвищення. Їх треба качати так само свідомо, як колись ти качав алгоритми. Детальний розбір того, як прокачати саме ці soft skills, є в матеріалі про те, як стати ефективним Team Lead у IT-команді, і його варто прочитати ще до того, як ти отримаєш роль.
Що робити в перші місяці на новій ролі
Перехід не відбувається за день, і перші місяці визначають, чи станеш ти тімлідом, якого поважають, чи тим, від кого команда тихо тікає. Кілька конкретних кроків, які працюють на старті.
Спершу слухай, а не наказуй
Перші тижні витрать на те, щоб зрозуміти, як команда працює насправді, де в неї болить і які процеси зламані. Не кидайся все переробляти з першого дня, навіть якщо бачиш очевидні проблеми. Довіру спочатку треба заробити.
Свідомо відпускай код
Постав собі правило: складну технічну задачу, яку ти вмієш, віддавай тому, хто хоче навчитися, і будь поруч як підтримка, а не як виконавець. Так ти одночасно ростиш команду й звільняєш собі час на керівництво.
Побудуй психологічну безпеку
Люди мають могти сказати тобі про ризик, помилку чи незгоду без страху. Команда, де бояться приносити погані новини, завжди програє тій, де про проблему кажуть одразу. Це не про м’якість, це про швидкість, з якою ви ловите проблеми.
Не соромся визнавати, що чогось не знаєш
Новий тімлід, який робить вигляд, що має всі відповіді, втрачає довіру швидше, ніж той, хто чесно каже «не знаю, давайте розберемося разом».
YouTube
Як не залишитися сам на сам із новою роллю
Найскладніше в цьому переході те, що на попередніх етапах кар’єри тобі допомагали. У джуна був ментор, у мідла старші колеги. А новий тімлід часто опиняється сам: команда дивиться на нього як на керівника, а він уперше в житті не знає, що робити з конфліктом двох розробників чи з людиною, яка перестала тягнути.
Тому найрозумніше не проходити цей шлях наосліп, набиваючи ті самі гулі, що й тисячі до тебе. Управлінські помилки коштують дорого, бо б’ють не по твоєму коду, а по живих людях і по цілому продукту. Системний розбір реальних ситуацій економить місяці болючого досвіду.
Саме під це у FoxmindEd є курс Effective Team Lead — не набір мотиваційних порад, а покрокова система з кейсами: як найняти свою людину й адаптувати її, як давати фідбек, як говорити з РМ і замовником, як приймати технічні рішення, залучаючи команду, а не перетворюючись на диктатора. Якщо ти плануєш перехід або вже зробив перші кроки й відчуваєш, що технічної експертизи раптом стало недостатньо, це той випадок, коли краще вчитися на чужих помилках, а не на власних.
