Став сеньйором за три роки, а потім — керівником: три важливі поради для тих, хто будує кар’єру

Привіт! У цій статті я розкажу про те, як можна пройти шлях від програміста до директора, який координує операційну діяльність локації на 300+ працівників. Радо ділюся своїм досвідом та сподіваюся, що він стане вам у нагоді.

Як все починалось

Я родом із Кривого Рогу. Так сталося, що першим місцем роботи відразу стало IT. В 2010-му після закінчення ВНЗ в Дніпрі і проходження практики я пішов на роботу в якості Junior-спеціаліста у компанію, в якій виконували проєкт для «Приватбанку».

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

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

Почав самостійно опановувати наявні технічні матеріали, готуватись до проходження співбесід і, що важливо — ходити на інтерв’ю. Цей досвід був неуспішним і дещо несподіваним.

Я усвідомив, що глибина технічних знань (hard skills) не завжди гарантує успіх, якщо не підкріплена комунікативними навичками, вмінням вести себе у стресовій ситуації інтерв’ю (soft skills).

На той час я переоцінив себе. В мене було п’ять невдалих співбесід, але я не зупинявся. Під час співбесід іноді траплялись дивні питання, які не мали відношення до навичок девелопера рівня junior+/middle-.  Наприклад, досить відоме про «продай мені цю ручку» або недоречні питання про сімейний стан.

Порада №1: виправляйте помилки

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

1. самого кандидата і швидкості, з якою він здатний навчатись та виправляти помилки, аналізуючи зворотній зв’язок;
2. якість інтерв’юерів з приймаючої сторони, адже далеко не завжди співбесіди проводять адекватні на 100% люди;
3. терміновість вакансії і готовність пожертвувати деякими недоліками кандидата.

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

Через деякий час пошуків у мене з’явилась пропозиція від однієї з найбільших на той час ІТ-компаній в Україні попрацювати на іноземного замовника. Після декількох етапів співбесід я отримав свій перший формальний офер, однією з умов була обов’язкова релокація до Києва, адже тоді про віддалену роботу ще не йшлося. Тоді я почав працювати як junior ETL (extract, transform and load) Developer також для банку, але іноземного.

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

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

Коли я приєднався до проєкту, в ньому сумарно працювало 30 людей, але за три роки там було вже 200+ фахівців. Коли компанія інтенсивне росте, з’являється можливість прискореного підвищення професійного рівня: почавши з junior dev і дійшовши до senior за три роки, в мене з’явились можливості спробувати себе на leadership-ролях — спочатку в якості лідера команди, а дещо пізніше — як проєктного координатора.

Підвищення збіглося з народженням першої дитини, і в мене вже не було можливості доробляти роботу за колегами вечорами. Довелося навчитися делегувати.

Порада №2: прокачуйте відповідальність

На таких посадах team lead починаєш усвідомлювати не тільки свою особисту відповідальність за певні задачі, але і за результати роботи команди:

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

Саме так відбувається прокачування менеджерських навичок. 

Для успішного руху має збігтися комбінація факторів:

1. наявність можливостей для зростання: нові проєкти, готовність керівництва дати більше обов’язків, адекватна і прозора система рівнів, компетенцій, компенсаційного пакету, які стимулюють і заохочують людину;
2. активність і бажання самого співробітника: навіть найбільш привабливі можливості можуть так і залишитись нереалізованими;
3. підтримка з боку компанії: тренінги, ментори, корпоративні системи та обмін досвідом.

Для мене всі вищезгадані фактори співпали, що й дозволило дорости до позиції Senior Project Manager / Head of Delivery за сім років.

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

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

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

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

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

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

Зміни — це добре

На початку 2019 року настав час подумати про зміну компанії ще раз. Врешті-решт я приєднався до EPAM як Project Manager цікавого внутрішнього стартапу, до реалізації якого були залучені фахівці з України та Швейцарії. Згодом перейшов працювати на проєкт технічної міграції з on-premise в сloud для одного із зовнішніх клієнтів.

Перспективи розвитку виглядали непогано, проте були дещо скориговані пандемією COVID-19. Саме в цей час EPAM запустив програму Anywhere — модель співпраці для розробників з будь-якої точки земної кулі, яка дозволяє працювати погодинно.

Концепція програми дозволила заздалегідь підготуватись до впровадження більш гнучких умов співпраці (наприклад, part-time), які були навіть ближче до класичного freelance і, відповідно, допомогли зацікавити людей, яких не влаштовувала стандартна модель офісної роботи. 

Вже в 2020-му в EPAM з’явились плани по розширенню присутності у нових регіонах, одним з яких став південь (Одеська, Миколаївська, Херсонська області). Я став частиною старту бізнесу у нових містах «з нуля». Така  активності демонструє, як виглядає матрична структура організації компанії: з одного боку я працював з командами над проєктами в Києві та Вінниці, а з іншого — брав участь у становленні південного регіону. 

Таким чином до звичної роботи в Delivery як Project Manager, додалось багато нових обов’язків в якості Operational Manager: спочатку розподіл був 80% часу на проєкт і 20% на новий регіон, проте десь за півроку співвідношення змінилось в іншу сторону.

Робота з регіоном передбачає:

• взаємодію з командою Talent Acquisition, аби координувати процеси найму нових людей, їхню подальшу інтеграцію в компанії та розподілення між проєктами;
• роботу з існуючими і новими клієнтами з метою їхнього входження в регіон;
• побудову організаційної структури, яка б забезпечувала ефективне управління та розвиток таких напрямків як Java, JavaScript, Business Analysis, .NET, Manual QA, QA Automation, Big Data, DevOps;
• участь у заходах для залучення нових талантів, враховуючи студентів.

Фокус на локацію

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

За півтора роки роботи ми залучили понад 300 нових талантів з півдня України, створивши одну з найбільш динамічно розвинутих локацій всередині компанії у довоєнний період. Паралельно з цим вдавалося розвивати Delivery-напрямок і збільшити розмір проєктної команди майже втричі завдяки налаштованим процесам формування нових команд.

Завдяки результатам у Delivery, хорошим темпам зростання компанії у новій локації, мене рекомендували на посаду Director, Software Engineering.

В EPAM всі процеси переходів між рівнями давно стандартизовані. Для підтвердження набуття наступного рівня необхідно пройти процедуру оцінювання (assessment), де заздалегідь сформований комітет експертів з різних країн уважно аналізує всі досягнення і ухвалює рішення щодо подальших кроків.

Стандартизація процесів, посад і рівнів забезпечує додаткову прозорість з точки зору послідовності кроків для подальшого зростання, альтернативних варіантів розвитку — скажімо, коли людина хоче перейти від Project Management до Solution Architecture.

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

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

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

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

Порада №3: працюйте над собою

Універсальними факторами успіху, які допомагають, я б назвав:

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

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