«Перші шість місяців я за все платив зі своєї банківської картки». Євген Ковалевський з KOLO розповідає, як це — бути CTO в благодійному фонді

Євген Ковалевський — IT-менеджер, якому вдається поєднувати дві топові технічні посади: CTO і співзасновника благодійного фонду KOLO та VP of Engineering у LetyShops.

У новому випуску YouTube-рубрики «Що потім?», в якій ми намагаємося розбиратись, куди податися ІТ-спеціалісту після рівня Senior, він розповів про те, як це — бути C-level у благодійному фонді, чому не кожному айтівцю підходить шлях бізнесмена, що є найголовнішим у фінансовій незалежності, а також поділився думками про саморозвиток.

👉🏼 Підписуйтесь на YouTube, щоб не пропустити нові інтерв’ю

Нижче ми публікуємо скорочену текстову версію розмови.

Чим займається CTO в благодійному фонді

Це доволі схоже на роботу в бізнесі: обираю стек, команду, які технічні завдання виконуємо й коли, які платіжні системи інтегруємо. А інколи навіть пишу код: нещодавно захищалися від першої DDoS-атаки, вона пробила AWS WAF, мені написали про це — я пішов і пофіксив. Тож я точно був би DevOps, якби не подався в менеджмент, і мій бекграунд з Python мені в цьому дуже допоміг би. До речі, за Grafana в KOLO відповідаю я :) Метрики в режимі реального часу, сетапи на два монітори, магія blue-green deployment — я обожнюю це.

Наша команда — це Product Owner (на деяких проєктах це різні люди), Front-end Developer, він же верстальник, Back-end Developer, а також тестувальник і я. Це неоплачувана, повністю волонтерська робота. Ледь не всі перелічені мною фахівці працюють у KOLO зі старту.

Першу ітерацію сайту на Readymag ми зробили за шість годин. Зрозуміли, що чогось бракує, і зібрали його на Webflow. Стек обрали свій найулюбленіший: Python + Django. На фронті — HTML, трохи JavaScript і темплейтів Django. Це дуже швидко і SEO-орієнтовано. Перші шість місяців роботи за всі сервіси та інфраструктуру я платив зі своєї банківської картки.

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

Наше головне завдання на сьогодні — наблизити перемогу. Але ми вже достатньо довго думаємо над тим, що робити фонду після цієї перемоги. Один з варіантів — перемкнутись на відновлення України.

У чому полягає робота VP of Engineering і CTO

У комерційному секторі я працюю VP of Engineering — для мене це насамперед роль, а не посада. Я відповідаю за команду, people management інженерів, ефективність їхніх робочих процесів. Якщо ви будуєте легендарну команду, в якій хочеться працювати, — це відповідальність VP of Engineering. Це не обовʼязково окрема позиція в компанії, зазвичай цю роль на старті виконує CTO.

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

А що ж тоді характеризує роботу CTO? Chief Technology Officer відповідає за стратегічно-технічний менеджмент. Йдеться про керування технологіями: який стек використовуєте, коли робите міграцію IT-інфраструктури, за допомогою яких технічних рішень досягаєте бізнес-цілей. Типові «CTOшні» рішення: викидаємо Webflow і беремо Django, переїжджаємо з Amazon на Ajure або ж взагалі переходимо на hardware, бо AWS — це дорого. VP of Engineering відповідає за імплементацію цих рішень.

Як виглядає взаємодія між CTO та VP of Engineering? Chief Technology Officer відповідальний за вибір кінцевої технології — перед тим, як ухвалити це рішення, він має звіритись з бізнес-стратегією компанії, оцінити ризики впровадження нової технології, узгодити це з ресурсами на ринку. Наприклад, CTO хоче обрати Elixir як основний стек, — тоді до нього може прийти VP of Engineering і сказати: «Ми так швидко не масштабуємо наші технічні спроможності, адже ринок має обмеження, а ми — власну політику найму, через це наша команда втратить ефективність. Звісно, ми можемо це зробити, але яку користь з цього отримаємо? Пропоную порівняти кілька сценаріїв і підібрати найкращий».

Чому роль VP of Engineering обовʼязково має посідати технічно підкована людина? Щоб розуміти коріння проблем твоєї команди і сигналізувати про них технічному менеджменту компанії.

Про гроші в IT

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

Про гроші та власний комфорт в IT: я хочу не боятися забути скасувати автопоновлення кредитів на AWS, після чого Amazon зніме з моєї картки $500 за інфраструктуру. І я хочу знати, що якщо мені або близьким людям доведеться йти на фронт, то я зможу забезпечити нас спорядженням.

У мене є принципова позиція щодо лояльності компаніям. Якщо ми домовились спробувати зробити щось класне в межах співпраці, то ми обовʼязково це спробуємо. І жодні зовнішні фактори, крім вкрай радикальних, не змінять це.

Про навчання і технічну експертизу

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

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

Що, на мою думку, відрізняє гарних лідерів від поганих? Вони вже за 15–20 хвилин співбесіди можуть ухвалити рішення щодо найму і переходять до обговорення плану розвитку кандидата.

Перший найм у моєму житті відбувся так: кандидат подався на позицію Junior Python Developer, наш техлід з понад 10 роками досвіду на «плюсах» ставить йому глибокі запитання з матчастини, а я запитую про те, які проблеми цей фахівець розвʼязував під час навчання, який досвід з цього виніс тощо. Ми провели співбесіду і виходимо з техлідом переговорити в іншу кімнату. «Треба брати», — кажу йому я. А він відповідає: «Ти що, дурень? Повір мені, я наймав людей — цю людину не треба брати на роботу». Ми довго сперечалися, але врешті найняли цього розробника. Врешті він доріс до Lead DevOps, нині служить в ЗСУ, а друг, якого він привів у компанію невдовзі після тієї співбесіди, нині обіймає посаду CTO.

Чому так вийшло? Це повʼязано з моїм стилем менеджменту: я готовий віддаватись роботі з іншими спеціалістами, їхньому навчанню, якщо вони готові натомість навчати мене або хоча б навчатись самі. Якщо я бачу, що я тільки віддаю, а вони беруть, то в мене швидко зникає інтерес. Важливіше з правильними людьми побудувати «ларьочок» з шаурмою, ніж з неправильними — Google Stadia [ігровий сервіс через низьку залученість користувачів вирішили закрити у вересні 2022 року — ред.].

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

Чи варто відкривати бізнес після менеджерської роботи в IT

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

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

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному1
LinkedIn



1 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Позиция СТО как и ВП это чисто вопрос глубины бизнеса и сложности задач. Это как могут быть полностью манагерские должности так и жестко технические. Проще говоря чем больше бизнес про технологии тем больше эти роли технические. Ибо не инженер не может адекватно управлять технологической компанией, он должен разбираться в вопросе.

WAF же не про ддос, а про попытки взлома, переборы и такое. ДДОС забивает канал, WAF же стоит далеко за тем местом на которое собсно ддос падает. если у вас сервис на авс и вас ддосят, то ддосят не вас а авс. и в первую очередь это будут решать админы и сре авс.

Підписатись на коментарі