Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Як стати CTO: опис зони відповідальності, необхідні скіли, корисні книжки

Привіт! Мене звати Сергій Васенін, я СТО продуктової IT-компанії Brainstack_. Хочу розповісти про те, чим займається технічний директор, які скіли потрібно розвинути, щоб ним стати, кому точно не підійде ця позиція, а також що почитати, щоб бустнути soft skills та розширити свої знання у сфері.

Бути СТО — це мати технічний бекграунд, але займатися здебільшого менеджментом. Це делегувати майже всі завдання й водночас бути готовим до того, що роботи менше не стане. Це не боятися наймати людей, які сильніші за технічними навичками.

Хто такий CTO, які його задачі та обов’язки

Почнемо з теорії та коротенької історії посади. Необхідність працювати з технологіями призвела до появи нової керівної посади — CTO (Chief technology officer, головний технічний директор). Якщо подивитися на керівництво будь-якого стартапу-єдинорога, ви побачите там технічного директора серед керівників вищої ланки.

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

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

Важливо: 60–80% часу — це робота з людьми.

Технічний директор vs техлід vs тимлід: у чому відмінність

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

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

Техлід ухвалює рішення щодо вибору технології на проєкті.

У нього можуть запитати: «Час нам переходити на PHP 8?» або: «Чи варто використовувати Grid у CSS, хоча він не скрізь підтримується?» Техлід може аргументовано відповісти.

Чи, скажімо, його запитують: «Як нам організувати таку систему, щоб мікросервіси заводилися й могли масштабуватися?» — він виносить вердикт: «Рекомендую завести Kubernetes».

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

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

Які скіли потрібні на позиції CTO

Ось головні компетенції, які я б виділив. Вони характерні для найуспішніших CTO світу.

Лідерські якості

  • Вміння вибудовувати взаємини з людьми.
  • Розвинені комунікативні навички.
  • Орієнтація на результат.
  • Стратегічне мислення.
  • Розвинені problem solving навички.

Управління людьми

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

Технічне лідерство

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

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

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

Наприклад, якщо в компанії використовують backend на різних мовах програмування, CTO повинен володіти принаймні кількома з них.

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

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

І, звісно, не місце серед CTO безвідповідальним людям, адже від технічного директора залежить справді багато процесів розробки.

Чи можуть бути ефективними СТО без технічного бекграунду

За досвідом роботи в IT скажу: краще, коли в CTO виростають технічні фахівці. Проте без технічного бекграунду також можна стати головним технічним директором.

Наприклад, з Product Manager може вийти непоганий CTO, якщо він розвиватиметься за допомогою tech-фахівців у компанії та набуватиме необхідних скілів.

Проте ризики відсутності технічного бекграунду все ж є:

  • неправильно вибрана технологія;
  • gap’и в аналітиці/ аналізі продукту: відсутність можливості якісно проаналізувати потрібність деяких фіч, щоб у подальшій розробці продукту дарма не витрачати ресурси;
  • відсутність можливості апгрейдити та успішно масштабувати продукт;
  • ризики у питаннях безпеки: CTO часто відповідає за безпеку, оскільки не в усіх компаніях є security-інженери‎.

Головні челенджі в роботі CTO

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

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

Комунікація

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

Часто, наприклад, потрібно довести команді, що якусь фічу потрібно імплементувати в продукт якнайшвидше — чи, навпаки, пояснити клієнту, що так швидко це зробити не вдасться.

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

Ресурси

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

Дослідження

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

І наостанок, people management на ремоуті. Взаємодіяти та підтримувати контакт з різними командами дистанційно — важче, ніж коли є можливість обговорити нові фічі біля кавової машини чи зібратися командою в мітинг-румі. Щоб не втрачати контакт з IT-фахівцями на ремоуті, ми в компанії практикуємо регулярні мітинги з менеджерами та командами розробки.

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

З яким досвідом можна свічнутися в CTO — і куди може рости фахівець

Важливий нюанс, на якому я б хотів акцентувати: на СТО не вчаться, ним стають. Ефективний метод — це, наприклад, проходження всіх кроків кар’єрного розвитку, щоб набратись досвіду та зрозуміти, як все працює, і дійти до рівня Software Architect/ Team Lead/ Tech Lead.

Після цього можна зробити продукт з «нуля» та побути з ним щонайменше 3–6 місяців після продакшена. Це — шлях продуктового СТО. Або можна паралельно брати участь у великій кількості проєктів у ролі людини, яка «усуває технічні проблеми» — це шлях сервісного СТО.

Найрозповсюдженіший кейс — поступове зростання з позиції Software Engineer чи Developer. ‎Також часто техдирами стають колишні DevOps’и та системні адміністратори. Шлях до кар’єри CTO завжди передбачає якусь проміжну менеджерську позицію: Tech або Team Lead.

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

Куди потім може рости CTO? Кар’єрний розвиток фахівця — це горизонтальне зростання, робота з великими обсягами даних та великою аудиторією. Це відкриває доступ до нових підходів і технологій. Нетехнічне зростання — у СЕО (Chief Executive Officer). Інший варіант — консалтинг.

Бонус: топ-9 книг для майбутніх CTO від нашої команди

  • The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change, Camille Fournier. Тут детально описаний кожний етап становлення CTO: ментор → техлід → тимлід → VP of Engineering → CTO.
  • Жодних правил. Унікальна культура Netflix, Рід Хастінгс, Ерін Мейєр. Співзасновник Netflix Рід Хастінгс розповідає про підходи та правила, які допомогли сформувати культуру однієї з найінноваційніших, найбільш творчих та успішних компаній у світі.
  • Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series), Jez Humble, David Farley. Тут викладені принципи і технічні методи, які дозволяють швидко, поступово надавати користувачам високоякісні нові цінні фічі завдяки автоматизації процесу збирання, розгортання і тестування — незалежно від розміру проєкту чи складності кодової бази.
  • Refactoring. Improving the Design of Existing Code, Martin Fowler, Kent Beck. У книзі описано 60+ методів рефакторингу. Понад 20 років досвідчені програмісти у всьому світі використовували цю книгу, коли їм потрібно було покращити проєкт наявного коду, підвищити зручність супроводу програмного забезпечення або полегшити розуміння поточного коду.
  • Чистий код. Створення і рефакторинг за допомогою Agile, Роберт Сесіл Мартін. У книзі викладено чимало реальних прикладів коду. Прочитавши книгу, ви навчитеся відрізняти хороший код від поганого, дізнаєтеся, як писати хороший код і як перетворити поганий код на хороший.
  • The Goal: A Process of Ongoing Improvement, Eliyahu M. Goldratt, Jeff Cox. Захопливий роман, написаний у стилі трилера, змінює уявлення про менеджмент у всьому світі.
  • Rework. Ця книжка змінить Ваш погляд на бізнес, Джейсон Фрайд, Девід Хейнмейер Ханссон. Як започаткувати справу чи вдосконалити власний бізнес — про це і є бестселер The New York Times, The Wall Street Journal та The Sunday Times. Ця книга — № 1 у розділах бізнес-літератури на Amazon.
  • Бути лідером. Мудрість від тих, хто змінив правила гри, Девід Рубенштейн. Впродовж п’яти років автор спілкувався з провідними лідерами світу, як-от Білл Гейтс, Тім Кук, Опра Вінфрі та інші — про принципи та керівні філософії.
  • Емоційний інтелект, Деніел Ґоулман. Автор аналізує причини та запоруки успіху в бізнесі працівників окремо та компанії загалом, виокремлюючи навички, що вирізняють лідерів.
👍ПодобаєтьсяСподобалось17
До обраногоВ обраному12
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Чудова стаття, дякую 😜

Вибачте мою токсичність, але чому Team Lead перекладено як Тимлід? Це ж буквально ті самі букви транслітеровані по-різному

Я думаю, тут застосовано «правило дев’ятки»:

Дев’ять літер, після яких перед літерами, які позначають приголосний звук (окрім «Й»), у словах іншомовного походження пишемо «И».
Це літери Д, Т, З, С, Ц, Ч, Ш, Ж, Р.

Тільки не починаймо за диджиталізацію, бо це те ж саме правило :)

Цікаво, пізнавально.
Дякую за гарну статтю.

у список літератури можна ще класичну додати:
www.yakaboo.ua/...​v-dzh-genk-rejnvoter.html

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

Дуже згоден! Бо СТО — це не тільки про розробку, а й про бюджети, графіки, пріоритети і роадмапи.

Сорри, что не в тему — посоветуйте книжки для внучки 6 лет. Интересует городское фэнтези, как Гарри Потер, только для девочек. Язык — украинский или голландский.

Моїм в такому віці заходили «Ракета на чотирьох лапах», «Джуді Муді». Ну і «Повітряні рибки» Дяченків.

Тут щось можна знайти
book-ye.com.ua/catalog/dytyacha-proza
nashformat.ua/...​ta-sergij-dyachenky-books

З вашої статті виходить що СТО це на 98% менеджер, керувальник ризиками і рішатєль конфліктів.
Можливо, у мене трохи викривлене уявлення, але в моїй практиці (я бачив більше продуктових СТО) це в першу чергу людина, на плечі якої лягає вся інфраструктура, цілком і повністю. СТО це той, хто вирішує найстрашніші технічні проблеми, коли армія девопсів підняла лапки і пішла в запой. Тобто найбородатіший старожил у найпрокуренішому найстарішому светрі. І тільки потім, десь там, на 12-му місці він оце все комунікації та інший піпл-менеджмент.
Фактично з вашого опису СТО це тім- (навіть не тех-) лід на максималках.

Це не СТО, evangelist/distinguished specialist, весь С-level то про менеджмент більше. Стартап стартує з того, що ви описали, але після 100 людей його обійде на повороті чувак в піджаку, про якого написана стаття. Хлопець в світері залишиться жити біля серверної.

Только не так мрачно.
Парень в свитере останется с акциями и заработает много денег. А так верно, чем дальше тем технические скилы начинают играть меньшую роль.

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

його обійде на повороті чувак в піджаку

це CIO

Хлопець в світері залишиться жити біля серверної.

це і є CTO

— у даному випадку светр — це мем, а не реальний одяг
— цікаво, в Каліфорнії взагалі продають светри?
— до речі, на першому ж фото чувак в чомусь на кшалт светра на блискавці :-)

Will (хлопець в “светрі”, сто в гуглі) holds a bachelor’s of science degree in operations research from the United States Military Academy at West Point and a master’s of business administration from the Wharton School at the University of Pennsylvania. Гік з гіків.

— цікаво, в Каліфорнії взагалі продають светри?

В серверній холодно, тому светр актуальний і в калі.

В серверній холодно, тому светр актуальний

чергова людина, яка бачила серверну виключно в х/ф Хакери :-)

СТО це той, хто вирішує найстрашніші технічні проблеми, коли армія девопсів підняла лапки і пішла в запой

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

Навпаки. Треба набрати команду людей, розумніших і надійніших за себе, і вибудувати структуру.

А задача — щоб продукт мав технологічну перевагу на ринку.

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

Це як раз є прикладом дуже поганого CTO. Тому що усі С-level посади — це, в першу чергу, про стратегичні рішення та керування. Як генерал у збройних силах — звичайно, ніколи не завадить, якщо він спроможний першим же пострілом вразити супротивника за два кілометра, але робити це постійно особисто коли у якогось підрозділу виникли проблеми у полі — дуже дурна ідея.

1. CTO організації на 0-50 чоловік — це одні вимоги, а 400-800 — це вже зовсім інші. І якщо дивитися на приклад того ж Netflix який ви рекомендуєте, то 80% вимог того що ви згадуєте — це робота VP of engineering в організації такого масштабу.
2. Ultima Ratio CTO продуктової компанії — це технологічна складова продукту. Спільна побудова та Стратегія розвиту технічної складової для досягнення бізнес-цілей компанії. Робота з людьми і TechLead-ство там можливе десь на етапі до 50 чоловік. Дуже часто в безпосередньому підпорядкуванні CTO і компанії розміром 150+ ну чоловік 5 з R&D. І його основна робота з людьми — це спілкування з бізнес-частиною компанії, партнерами, клієнтами.
3. Дуже виглядає, що ви маскуєте під продуктову компанію черговий аутсорс. Бо я собі не уявляю продуктову компанію, що на головній сторінці буде розповідати скільки в них працівників, що в них бекенд, фронтенд, Андроїд. Мав кілька місяців розмову з дуже серйозним американським підприємцем, що підняв не одну компанію. Він звернув увагу на «особливість» маркетингу українських компаній. «Ваш продукт Андроїд розробники?», індійські компанії топ-рівня давно не мають згадок про техностек. Вони продають кінцеві рішення, а не Android-розробників. Той же Infosys.
Якщо ви сервісна компанія, то не треба соромитися і видаватися тим ким ви не є.
Це створює хибні очікування і працівників, клієнтів і ринку.
Ну і головне роль CTO в сервісній компанії дуже сильно відрізняється від продуктовї.
4. Найкраще, що я читав по роботі CTO Eben Hewitt Technology Strategy Patterns: Architecture as Strategy та на додаток книжки Gregor Hohpe.
На мою думку ті книжки про нетфлікси, і «історії успіху» жуйка для мозку, дистильовані від контексту речі, які неможливо реплікувати.

З книжок мені зайшла “What They Don’t Teach You at Harvard Business School”

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