Як стати тимлідом: навички, обовʼязки та виклики. Особисті історії айтівців

Які навички потрібно мати, щоб стати лідом команди? Про це ми поспілкувалися з розробниками, дизайнером, девопсом і тестувальником, які пройшли шлях до тимлідів. Вони розповіли, як проходили співбесіди, які скіли потрібні ліду, з якими проблемами стикалися на шляху та чи всім підходить ця роль.

«Головне — любити людей і сприймати їх такими, якими вони є»

Сергій Журавель, Lead Software Engineer в Absio

У мене завжди були лідерські якості/здібності. Але за понад 12 років, що я працюю в IT, також траплялося багато злетів та падінь. Я ставав лідом, потім знову розробником і знову лідом. Мабуть, тому, що я ніколи плекав амбіцій бути саме лідом — звичайна розробка мені також подобається :) Та мій «рецепт» ставання лідом приблизно завжди однаковий: коли було потрібно, брав на себе ініціативу та організовував людей, щоб виконати певне завдання швидше й ефективніше.

Я отримував цю посаду двічі — й обидва рази подавався саме на вакансію ліда. Першого разу — в іноземну компанію, де пропрацював майже 5 років (до речі, це був мій перший повноцінний досвід ремоуту, ще коли це не було мейнстримом). А вдруге — в українську компанію з іноземним замовником.

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

Щоб стати лідом, насамперед потрібно вміти брати на себе відповідальність за проєкт і за команду. Це, звісно, і робота з людьми, вміння налаштувати процеси та бути лідером (мені особисто подобаються ліди, що виступають як Scrum Master’и — ті, хто допомагають, а не командують). Також треба бути професіоналом в IT. Важливо, щоб команда довіряла ліду. Не означає, що потрібно знати все (це практично неможливо), але хоча б в одному технічному напрямку слід бути спеціалістом. Хоча всього цього можна навчитися, тож, мабуть, головне — любити людей і сприймати їх такими, якими вони є.

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

«Проблеми команди — це твої проблеми, а твої проблеми — це не проблеми команди»

Костянтин Мрачко, Frontend Principal у N-iX

Якось мій лід пішов на інший проєкт, де я залишився основним розробником і єдиним сеньйором, тому мені запропонували спробувати свої сили в ролі ліда. Це було цікаво, тож я погодився.

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

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

Спершу було складно переходити від відповідальності лише за свою роботу до відповідальності за роботу інших. Важко бути «центральним вузлом» системи й постійно перемикати контексти, допомогаючи іншим, відповідаючи на запитання, оцінюючи майбутні завдання тощо. Стає простіше, коли «відпускаєш» себе і команду, починаєш їм більше довіряти, делегувати та бачиш позитивні результати. Головне — памʼятати, що проблеми команди — це твої проблеми, а твої проблеми — це не проблеми команди.

«Лід — це радше покликання, ніж кар’єра»

Дмитро Мирошник, Quality Assurance Automation Lead у Ciklum

Це було в далекому 2007-му, на другому за рахунком проєкті. Мій досвід у QA на той момент становив трохи більше як рік. Спершу я був єдиним тестувальником на проєкті, через декілька місяців стало очевидно, що роботи надто багато, і додали ще двох. Ну й оскільки у мене досвіду на проєкті було найбільше, я став головним. Думаю, багато хто з нас має таку історію :)

Стати лідом — це була пропозиція зверху; по суті, умова, за якої до команди додавали людей. Тому я погодився.

Жодної співбесіди не було і близько. Тоді ці процеси ще мало де в українському IT були формалізовані (якщо взагалі десь були). Як, до речі, не було і матеріалів чи курсів з менеджменту в широкому доступі. Так що — welcome «розгрібати граблі лобом» :)

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

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

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

Зарплата зросла десь на $100 чи $200, втім, тоді це було приблизно плюс 10–20%.

Насамперед ліду потрібні такі софт-скіли, як комунікація та емпатія. Потім — пройти курси з управління або прочитати кілька хороших книг на цю тему. Ну і головне: бажання брати на себе відповідальність за роботу команди. Лід — це радше покликання, ніж кар’єра. Іти в ліди за +$500 — безглуздо, тямущий архітект отримує аж ніяк не менше.

«Почати виконувати роботу ліда варто ще до офера»

Дмитро Бондар, Game Designer Team Lead у GrandMa Studios

Лідом я став у продуктовій Gamedev-кампанії. Підвищення було за ініціативи роботодавця. Додаткових співбесід чи підтвердження навичок не проводили.

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

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

«Потрібне вміння делегувати завдання і старатися не затіняти інших членів команди»

Олександр Лисий, Software Engineer

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

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

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

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

«Не чекайте, поки спустять завдання зверху, беріть більше відповідальності»

Павло Сайкевич, Lead DevOps Engineer у SoftServe

Я працював сеньйором в Intellias. Там завершувався проєкт, тож почав шукати варіанти роботи. Отримав кілька оферів: половину на ліда і половину на сеньйора — вибрав позицію ліда в SoftServe.

Співбесіда була схожою як і на сеньйора, але ще додатково спілкувалися з менеджером про софт-скіли й керування командою. Команда девопсів невелика — 4 людини. Додалося більше відповідальності. Якщо інші девопси чогось не знають або щось поламалося, то я з’ясовую, що сталося, часто ініціюю великі зміни, визначаю напрям, куди рухатиметься продукт.

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

Тим, хто хоче стати лідом, я порадив би:

• Не чекати, поки спустять завдання зверху, брати більше відповідальності (теоретично це має робити і сеньйор).
• Менторити інших людей, проводити інтерв’ю, стати експертом для трейні.
• Розуміти, як працює бізнес-складова проєкту, і не гнатися за «наймоднішими» технологіями, а вчитися впроваджувати те, що принесе прибуток проєкту/бізнесу або завадить утратам.

Останній пункт важливий для зростання не лише до ліда, але й до будь-якого рівня, зокрема СТО.

«Складно усвідомити, що в деяких питаннях члени команди можуть бути компетентнішими»

Андрій Шумада, Team Lead у WalkMe

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

Важливими є софт-скіли, а саме вміння виявляти, розуміти і вирішувати проблеми членів команди. Дзеркально «наверх» потрібно навчитися розуміти потреби й очікування бізнесу та адаптовувати їх до реальних можливостей команди.

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

«Кожна людина потребує індивідуального підходу. Особливо у ІТ, де кожен може грюкнути дверима і змінити роботу»

Микола Махін, Team Leader/Solution Architect в EPAM

До тимліда мене підвищували двічі — у 2008-му у Componence та у 2016-му у Symphony Solutions. В обох випадках ґрунтом до підвищення були технічні знання + сумлінний підхід до роботи.

В обов’язки тимліда входила допомога членам команди, яка дещо нагадувала менторинг, але з сильним технічним ухилом — допомога зі складними задачами (підказати шляхи вирішення, допомогти із кодом, якщо потрібно — сісти писати код разом, тобто фактично парне програмування, в багатьох випадках дуже допомагає, хоча і займає багато часу), розбір нечітких requirements, допомога з оцінкою задач (estimations), інколи розподілення задач згідно зі знаннями членів команди (якщо робота не зі Scrum/Kanban). Всі ці речі потребують сильного технічного бекграунду.

По суті тимлід — це техлід та деякі організаційні задачі, які часто теж спираються на технічні знання.

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

Щоб стати лідом, важливі технічні та організаційні навички. Але технічні — більш глибокі, а організаційні — досить прості.

Робота із людьми завжди вимагає певної делікатності. Кожна людина — індивідуум і потребує індивідуального підходу. Особливо у ІТ, де кожен може завжди грюкнути дверима і змінити роботу без особливих проблем. В такій ситуації інколи буває складно працювати із людьми, які не витягують технічно, мають проблеми із мотивацією або софт-скілами. Хоча в цих питаннях може допомогти HR.

Основна ж складність полягає в більшій кількості обов’язків — треба і свої завдання розвʼязувати, і членам команди допомогти (як з технічними, так і з мотивацією, персональним розвитком тощо), і організаційні моменти виконувати (планування, естімації, створення і розподілення завдань, оцінка перформенсу членів команді, допомога при складанні personal development planʼів). Тобто треба багато всього встигати. При цьому бажано не почати відставати в технічному плані, бо тимлід, який технічно не особливо випереджає членів команди, може втратити серед них авторитет і отримати проблеми із субординацією і мотивацією членів команди. Lead by example вимагає бути кращим.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU