«Справжній лідер не боїться брати на себе відповідальність», — каже Чеслав Новицький, Engineering Manager в Innovecs. Три роки тому він прийшов у компанію на позицію Middle-розробника за напрямком React, а вже сьогодні завдяки активному професійному росту допомагає розвиватися іншим, управляє командами й відповідає за важливі рішення перед клієнтом.
«Справжній лідер не боїться брати на себе відповідальність», — каже Чеслав Новицький, Engineering Manager в Innovecs. Три роки тому він прийшов у компанію на позицію Middle-розробника за напрямком React, а вже сьогодні завдяки активному професійному росту допомагає розвиватися іншим, управляє командами й відповідає за важливі рішення перед клієнтом.
Працювати в ІТ планував ще зі шкільних років, навчався в університеті за спеціальністю Computer Science. Довчився до 4-го курсу, а далі розвивався самостійно. Освіта в ІТ є важливою, але ще не гарантує успіху в професії, зауважив Чеслав: «У моїй команді працюють як інженери з вищою освітою в ІТ, так і з дипломами спеціалізованих курсів, а також ті, які навчалися самостійно. Хороших фахівців об’єднує не диплом чи сертифікат про завершення курсу, а бажання працювати й брати на себе більше відповідальності».
Ось його поради про те, як зробити успішну кар’єру в IT.
Професійний і особистісний ріст — це постійний процес, а не одноразове досягнення за короткий проміжок часу. Тому я досі продовжую змінюватися, здобуваю досвід і нові знання, особливо у сфері менеджменту. People Management — це перш за все вміння скеровувати людей, задавати напрям, розвивати й мотивувати, тримати у постійному енергетичному тонусі. Допомагаю також і на рівні експертизи з порадами щодо вибору найкращої технології для продукту, важливих етапів розробки та можливих нюансів.
Зростав поступово на різних позиціях — від розробника до Tech Lead, а згодом до Engineering Manager. Ще до Innovecs впродовж 5-ти років працював програмістом у різних ІТ-компаніях. Починав із місцевого аутсорсу, далі була місцева продуктова компанія, а пізніше набирався досвіду переважно в стартапах. У компанію прийшов вже з визначеним бажанням стабільності.
Саме тут і розвився спочатку як Tech Lead, а потім як Engineering Manager. Різниця між цими двома управлінськими позиціями у рівні відповідальності.
Якщо Tech Lead відповідає за окрему галузь у межах технічного напрямку проєкту, то Engineering Manager стежить за розвитком і технічних, і бізнесових факторів. Tech Lead разом працює з маленькою частиною продукту, а Engineering Manager — відповідальний за весь продукт і за всю команду проєкту.
З найбільш помітних змін — збільшилась кількість дзвінків і комунікацій з командою. Як менеджеру мені важливо розуміти настрій своїх колег, бо це безпосередньо впливає на продуктивність нашої спільної роботи. З навичок, які посилив, — вміння вести переговори з клієнтом, відстоювати свою позицію і пропонувати розумне альтернативне рішення. А ще я навчився більше відпускати, делегуючи окремі завдання іншим. На рівні Engineering Manager команда розширюється, і важливо виділяти нових Tech Lead, яким можна довірити частину відповідальності, адже самому стає складно за всім стежити. Також треба уважно ставитися до тайм-менеджементу, інакше нічого не встигнеш. З нового на цій позиції — це участь у процесах хайрингу, підбору людей у команду. Якщо Tech Lead проводить тільки технічну частину інтерв’ю, то Manager оцінює soft skills. Це основні навички, які здобув на нових позиціях.
Досвід приходить завдяки практиці, а не теорії. Я всім раджу багато працювати, й тоді все вдасться. Зрештою, усе зводиться до амбіцій. Той, хто хоче вирости, обов’язково це зробить. Немає легких шляхів і заздалегідь протоптаної стежини. Особисто я багато працював як на роботі, так і в позаробочий час. З друзями розвивав стартапи, брався за різні авантюри, і це неабияк нас розвивало. Я міг присвячувати цьому весь позаробочий час впродовж тижня. Пробував себе у різних напрямках проєкту, покривав і сфери менеджменту. У процесі вивчав багато нового.
На роботі я не боявся відповідальності. Доволі часто доводилося працювати з Junior i Middle-розробниками, які просили порад і підтримки, у тому числі допомогти домовитися з клієнтом. Розв’язувати проблеми — якраз завдання менеджера.
Мені вдавалося, і я радо допомагав. Пізніше, коли з’явилася потреба розширювати команду і призначати лідерів напрямків і менеджерів, мене вже офіційно закріпили на цій позиції.
Менторство також важливе. Можна роками працювати одним-єдиним розробником на проєкті, розвиватися, але без супердосвідченого ментора ці знання бувають дуже хаотичними. Десь приблизно так було зі мною. Коли я прийшов у компанію, Team Lead допоміг мені систематизувати усі набуті знання, менторив мене і допоміг у кар’єрному зростанні. Ну, звичайно, є ще один важливий фактор росту — це крута команда. У драйвовому робочому середовищі, яке має амбіції й цілі, ти ростеш швидше.
У моїй команді є як випускники ІТ-спеціальностей, так і розробники без університетського диплому. Є ті, які завершили курси з програмування, й ті, які вчилися самостійно по відеоуроках на YouTube. Усі вони професіонали завдяки своєму бажанню працювати, а не завдяки диплому чи сертифікату. У мене немає завершеної освіти чи спеціалізованих курсів, лише багато практики.
Водночас в ІТ важливий саморозвиток — постійне читання технічних статей, ознайомлення з трендами, заглиблення у документацію. Без цього буде стагнація.
Якщо є можливість, буде корисним отримати сертифікацію, але для мене це, скоріше, стимул вивчати нове, аніж фактор значних зрушень у кар’єрі.
З моїх спостережень найважче було навчитися делегувати й позбутися надмірної відповідальності. Обсяги роботи зростають, а якість виконання завдань має лишатися на високому рівні. У такому випадку вміння делегувати — перше, що треба розвивати менеджеру. Паралельно з умінням делегувати треба також бути майстерним у тайм-менеджменті. Я налаштував отримання сповіщень у зручний для себе час і вимикаю, коли це може мене відволікати. Заздалегідь призначаю зустрічі в календарі й навіть виділяю окремий час на обідню перерву, адже вільний слот менеджера обов’язково хтось захоче використати :) Календар — найкращий інструмент у моїй роботі.
З того, що мені важко давалося — відпускати й не хвилюватися надмірно. Якщо ти маєш підвищене відчуття відповідальності, бентежишся настільки, що це впливає на твій сон, то можеш дуже швидко вигоріти. Тоді все точно піде не за планом. Відпускати й делегувати я досі вчуся, іноді хочеться бути всюди та встигнути все.
Думаю, що такі інженери насправді не хочуть рости, хоча й з першого погляду виглядає інакше. Річ у тім, що часто люди плутають внутрішнє бажання збільшити зарплату із прагненням професійного росту. Деякі хотіли б лишатися на тій же позиції, з тими ж обов’язками, але заробляти більше. Тут і виникає конфлікт інтересів між працівником і роботодавцем. Тому варто у першу чергу відповісти на питання, а чого насправді я хочу та як я можу цього досягнути.
Трапляються випадки, коли Senior-розробник вже впродовж п’яти років працює в одній компанії й нічого не змінює, бо йому так комфортно. Можливо, для певних змін йому і варто було б йти далі, але він свідомо не хоче залишати зону комфорту.
Загалом я не вважаю, що для розвитку у сфері Engineering Leadership обов’язково йти саме у менеджмент. Є інші перспективні напрямки розвитку для розробника, наприклад, стати архітектором і поглиблювати свою експертизу.
Насправді усе залежить від компанії й команди. Особисто я проти такого перестрибування етапів. Не всі Middle-розробники можуть стати хорошими лідерами команд. По-перше, їм буде складно завоювати увагу більш досвідчених співробітників, а, по-друге, чи достатньо у них технічної експертизи й управлінського досвіду, щоб брати на себе відповідальність за прийняття певних рішень? Теоретично з рівня Middle можна перейти у менеджмент, але вряд чи вдасться стати Team/Tech Lead чи Engineering Manager, якщо йдеться саме про технічну сферу. Тут важлива технічна експертиза і горизонтальний розвиток. Не вийде напівдорозі кинути програмування і стати ефективним менеджером. Це мій особистий досвід. Хоча так, у деяких компаніях найбільш комунікабельний і драйвовий може стати лідером, менеджером і керівником.
Як і в кар’єрному рості до рівня менеджера, так і в професійному від Middle до Senior, я завжди раджу брати на себе більше відповідальності. Як правило, Senior самостійно працює із завданнями, не потребує менторства і перевірки виконаних задач, може сам справлятися із викликами й готовий відповідати за ухвалені рішення. Якість виконаної роботи цілком на його совісті. Сеньйор відчуває відповідальність, має глибоку технічну експертизу й усвідомлення того, як можна масштабувати технічне рішення.
Щодо різниці між Middle і Senior, то першим маркером є глибока орієнтація в технологіях. Зазвичай Middle-розробник знає розв’язання конкретної задачі, а Senior може запропонувати альтернативи й аргументувати доцільність використання певної технології. Ще один маркер — це досвід роботи з технологіями й різними командами. Senior-розробники можуть передбачити розвиток подій, бо стикалися у роботі як з правильними рішеннями, так і з фейлами. Вони ніколи не пожертвують якістю заради швидкості, аби лише вкластися у дедлайни.
Один із моїх маркерів: чи знає розробник, що таке Open Closed Principle. Як правило, Senior знає, а Middle — ще ні.
Неприйнятно, коли твої колеги з команди приходять до тебе за порадою, а ти замість того, щоб допомогти, кажеш: «Та тут же все просто!».
Від Team Lead очікують підтримки, підказки й спрямування. Будь-яке висміювання чи приниження навичок членів команди прямопропорційно впливає на ваш спільний результат. Тому важлива риса Team/Tech Lead і менеджера будь-якого рівня — це бажання допомогти команді, підсилити її й спостерігати за ростом кожного.
Engineering Manager має чітке розуміння того, наскільки злагоджена робота команди впливає на бізнес, адже він бачить ситуацію цілком, а не на рівні окремих пазлів. Team/Tech Lead також поступово починає це усвідомлювати і транслює його на свою частину команди.
Один з найгірших можливих недоліків Team/Tech Lead чи Engineering Manager — мікроменеджемент. Це підриває командний дух і мотивацію. За таких умов команда розбігається, буде постійна плинність кадрів. А якщо немає стабільної команди — рішення затягуються. Попри те, що мікроменеджери виправдовують свої дії бажанням пришвидшити процес, усе відбувається діаметрально протилежно. Ніколи не вдається завершити вчасно. Думаю, що усі мікроменеджери — це така собі корпоративна школа минулого, яка зовсім скоро піде на пенсію, і на світі стане легше жити.
Перш за все, це вміння аргументовано доносити свою точку зору, при цьому не переходити на особистості й не допускати деструктивну критику. Ще важливе вміння залишатися спокійним й врівноваженим під час переговорів зі складним замовником, тримати свої емоції у балансі і спрямовувати всю енергію у конструктивне русло.
Менеджерам час від часу доводиться розв’язувати конфлікти та не допускати їх виникнення між членами команди. Тут важливе вміння вислухати кожного та, нікого не образивши, владнати проблему.
Загалом soft skills розвиваєш лише завдяки постійній комунікації з людьми. Бути серед людей і спілкуватися з ними — найважливіша умова. Я вчився як на своїх, так і чужих помилках. Неправильно проведені переговори мають наслідки.
Замовник може помилятися з вибором рішення, але схиляти на свою сторону, і якщо ти погоджуєшся, це виливається у проблему. Команда незадоволена. Є розрив між продуктивністю й ефективністю. Кілька таких випадків, і починаєш розуміти, що поступливість не є вигідною ні для замовників, ні для команди. Потім ти не скажеш, що попереджав, а тебе не послухали. Значить, недостатньо говорив і не переконав. Якщо коротко, то у всіх менеджерів є спільне правило — не прогинатися.
Мабуть, варто розібратися, чи їм взагалі це треба і якою мірою. Усі потреби витікають з наших цілей. Як на мене, базові soft skills будь-якого розробника — це здатність розмовляти з колегами хоча б годину на день під час щоденних дзвінків. Це вже буде добре, а якщо більше — взагалі чудово. Інші soft skills, які важко даються, варто розвивати під конкретні цілі. А ще спільним для всіх є вміння не бути токсичним і не поширювати свої негативні настрої на інших. Екологічність робочого середовища дуже важлива.
