Із Senior Software Engineer в Chief Software Engineer II. Досвід Андрія Кучеренка

Я прийшов у EPAM у 2010 році на позицію Senior Software Engineer. Зараз я маю понад 20 років досвіду в IT і свідомо вибираю поглиблюватись в інжиніринг замість того, щоб переходити в менеджмент. У цій статті я розкажу про свій карʼєрний шлях в EPAM, а також основні висновки, які я зробив за час свого росту в компанії. 

Коли я проходив співбесіду в компанію, то відразу сказав, що не хочу займатися менеджментом, мені був цікавий саме інжиніринг. Я вже мав досвід тімліда та технічного директора в невеликих компаніях, і мені не дуже подобались ті процеси, які там були. В EPAM були відкриті до такого вибору, і так я зайняв посаду Senior Software Engineer. 

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

Спробувавши різні активності в EPAM, зокрема роль тімліда та ресурсного менеджера, я вирішив усе-таки сфокусуватися на архітектурі та Advanced інжинірингу. Зараз я знаходжусь на позиції Chief Software Engineer другого рівня.  

У мене часто запитують, чим Advanced Engineering відрізняється від архітектури, наприклад, від позиції Solution Architect. Дійсно, Solution Architecture i Advanced Engineering — це споріднені гілки, у них є багато схожого. Проте в Advanced Engineering є більше практичної роботи. Я багато пишу коду, пробую різні технології, роблю POC, вимірюю швидкості. Solution Architecture є ближчим до клієнта, ми ж ближче до технологій і команд. Проте, звісно, чим вище рівень, тим більше стираються межі. Наприклад, мене іноді додають на проєкти як Solution-архітектора, тоді я роблю архітектуру. 

Під час роботи з інженерами завжди видно, чи людина чекає, що її будуть вести, чи вона сама розуміє, що є проблема, що її треба вирішувати та що спосіб її вирішення може бути різним. Це відрізняє інженерів з треку A від інженерів з треку B. Людина в A-треку (виконавець)  чекає, що їй пояснять, що робити, а людина у B-треку (керівник) знає, що робити, без будь-яких вказівок. На треку B інженер завжди розуміє, чому саме цю технологію вибрали чи чому в цієї технології саме така реалізація.  

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

Я спробував себе у різних ролях і в інжинірингу, і в менеджменті. Коли я працював у менеджменті, десь 40% роботи мені подобалось, а 60% — не дуже. Я спробував себе також архітектором — це дуже цікава посада, але деякі моменти мені теж не сподобались. Наприклад, необхідність працювати з технологіями через високі абстракції і лишати поза увагою деталі, які можуть бути цікаві. Так я зрозумів, що найбільше хочу розвиватися саме в інжинірингу.  

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

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

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

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