Май 31

Чи потрібно на позиції СТО писати код. Досвід NVIDIA, Preply, Kasta та Atola Technology

Чи потрібно CTO програмувати? Здавалося б, головне в бізнесі — добре керувати людьми та вміти продати свій продукт. Та чимало розробників, які доросли до посади технічного директора, продовжують програмувати. Навіщо вони це роблять, що це дає особисто їм і команді, чи не заважає написання коду добре виконувати адміністративні функції та в яких ситуаціях краще припинити цим займатися ми запитали у СТО та директора локального офісу IT-компанії.

Олександр Соловйов, СTO в Kasta

«Коли не пишу код, то не відчуваю припливу дофаміну, немає розуміння, що я сьогодні чогось досягнув»

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

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

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

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

Щоб бути лідером, у вас мають бути credentials. Чуваки в команді мають вірити у вас, знати, що ви справді «роздупляєтесь», а не просто отримали крісло як знайомий директора чи племінник його дружбана. Буває, що директор приходить з іншої компанії і забирає за собою СTO. Якщо там був зовсім інший напрям, то програмісти ставитимуться до нього як до «начальника». «Та що він там розуміє?» До мене так не ставляться, і це супер.

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

Точно не скажу, чи те, що я програмую, негативно впливає на виконання інших обов’язків. Я ж не можу зробити A/B-тест, щоб це визначити. Знаю одне: команді було складніше в той час, коли я не програмував. Якось я вирішив, що писати код на моїй позиції — це недоцільне використання часу. Все закінчилося ледь не депресією. В такій ситуації страждає все: decision making, комунікація, бо ніхто з команди не підійде до тебе зайвий раз, щоб не нарватися. Якщо ж для підтримки свого емоційного стану мені треба разок на тиждень покодити, то чому б ні? Вчора я пофіксив баг, це зайняло хвилин 10.

Про написання коду у вільний час і вдома. Маю проблему — хочу зробити вдома сайд-проєкт і не можу, тому що втратив скіл нормально концентруватися. Я можу написати код на 200–1000 рядків, а далі мені бракує посидючості. В мене є два мотиватори щось робити: 1) реакція на зовнішній подразник — коли мене хтось підштовхує щось виконати, наприклад, відділ маркетингу; 2) — цікавість. Я зрозумів, що на одній силі волі далеко не заїдеш. Вона вичерпується. Власне, тому раніше я часто змінював роботу, а в Кasta продовжую працювати, бо мені цікаво.

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

Наразі рідко програмую для себе — вільний час скоріш присвячую дітям. Окрім роботи та родини, маю хобі — веду ютуб-канал. Торік, власне у квітні, написав TwinSpark — бібліотеку на JS, яку ми тепер в Кasta використовуємо для додавання інтерактивності до інтерфейсу.

У лютому ще підготував малесенький проєкт, щоб з мобілки з Bear публікувати статті прямо у блог, а то сідати за Emacs не дуже комфортно. Годин 7–8 на те пішло, тепер набагато зручніше нічого не писати в блог :)

Дмитро Волошин, Co-founder та CTO у Preply

«Для мене важливо робити все можливе, щоб компанія стала успішною, і для цього написання коду не обов’язкове»

Про роль СTO в стартапі та великій компанії. На мою думку, роль СTO відрізняється залежно від розміру компанії. Я був СТО, коли в компанії ще не було інших розробників, крім мене. Зрозуміло, що на той час я писав код. Доки команда складалася з 5–10 розробників, я продовжував це робити. Коли ж їх стало більше, я зосередився на більш стратегічних напрямах — people-менеджменті, архітектурних питаннях. На мою думку, якщо у підпорядкуванні СТО 20 людей і він ще має час писати код, то це означає, що він фокусується не на стратегічних речах, а займається операційними. Це не найефективніший спосіб використовувати час.

Якщо говорити про ту межу розвитку компанії, коли СТО має припинити писати код, то для мене є два основні показники. Перший — коли організація розбивається на команди. Зазвичай у стартапі на перших етапах розвитку є одна команда, лідером якої є СТО. Коли ж нас стало 20, ми розбилися на 3–4 продуктові команди, в кожній з яких з’явився техлід. Це важливий етап, коли СТО потрібно відділитися, делегувати технічну частину техліду. Другий показник — команда досягла такого рівня, що їй вже можна довіряти самостійно відповідати за продукт. Тут треба мати кому делегувати свої функції. В ідеалі це має бути людина, яка розбирається в технічній частині краще, ніж ти сам. Їй не страшно довірити продукт. В нашій команді це відбувалося органічно: я мав усе менше часу на кодинг і поступово відійшов від цього. Потім код потрібно писати час від часу, щоб побути з командою, відчути, який є «біль» у процесах, але це точно не щоденна і навіть не щотижнева активність. Для СТО набагато важливіше інколи читати код, щоб тримати руку на пульсі організації.

Про факапи на позиції CTO, коли ще поєднував адміністративну роботу з кодингом. Коли я ще кодив сам, то мав чимало фейлів, один з яких обійшовся компанії особливо дорого. При цьому варто розуміти, що в нашій компанії діє культура blameless postmortems, коли кожну помилку, що призводить до інциденту в продакшені, ми аналізуємо і робимо з цього висновки на майбутнє. При цьому нікого не звинувачуємо. Я був автором десятків постмортемсів, тобто припускався десятків критичних помилок, які потім впливали на результат роботи компанії. Але це невіддільна частина розвитку. Поки в компанії немає достатньо налагоджених процесів з моніторингу, алертингу, тестування, то помилок та інцидентів буде багато. Не варто цього соромитися.

Я б розбив свої факапи на два типи: архітектурні та практичні. Приклад неправильного архітектурного рішення — на початку проєкту в нас не було лінтерів, тож перші три роки ми писали код не в консистентному кодстайлі. Інший приклад — неправильно задизайнена база даних, від чого ми страждаємо досі. Розуміємо, що якби я 8 років тому постарався краще, ми б зекономили десятки, якщо не сотні годин робочого часу розробників.

Мої практичні фейли полягали ось у чому. Я самостійно дизайнив перші пеймент-інтеграції, і якось ми виловили так звані race conditions (помилка програмування багатопотокової системи, при якій робота системи залежить від того, в якому порядку виконуються частини коду — ред.). На практиці це проявлялося в тому, що один платіж міг двічі знятися з гаманця користувача. Виявивши це, ми почали зариватися глибше в те, як працюють транзакції, локи й усе, що з цим пов’язано. Це були локальні баги, досить болючі для компанії. Інший приклад пов’язаний з міграцією, якою я керував. В одній з перших баз даних ми не передбачили, як оновиться версія для репліки, і через це отримали 15—30-хвилинний даунтайм. Було дуже прикро. Але всі ці помилки — частина learning corp. Я, як лідер інжинірингової організації, розумію, що вони допомогли мені зрозуміти, як краще побудувати процеси для того, щоб цих же помилок не припускалися мої колеги сьогодні.

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

Про клієнтоорієнтованість програмістів. У роботі важливо не забувати про бізнес-частину — користувача. Завдання не лише СTO, а й будь-якого розробника в нашій компанії, розуміти, що код і мова програмування — це інструменти, за допомогою яких ми розв’язуємо проблеми користувачів і намагаємося принести їм якомога більше користі. Код часто неідеальний, в ньому є помилки. Тож для мене найкращий розробник — це той, який може вирішити проблему користувача, не написавши жодного рядка або мінімальну кількість коду.

Ми прагнемо, щоб не лише в менеджменту, а й в усіх розробників був фокус на клієнта. Одна з цінностей компанії — це customer obsession, і будь-хто перед тим, як почати писати код, має поставити собі запитання: «А як це вплине на наших користувачів? Чи стануть вони щасливіші? Що нам скажуть дані A/B-тестів нового функціоналу?». Це продуктова культура, якої бракує українським компаніям. У нас є з чим порівнювати — маємо розробників в Барселоні та Бостоні — і дуже відчутно, що на локальному рівні цю культуру ще треба розвивати.

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

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

Василь Пастернак, директор київського офісу NVIDIA

«Я не зміг би добре керувати людьми, якби не орієнтувався в складнощах систем, які вони розробляють»

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

Водночас я більш-менш регулярно приділяю час програмуванню. На це й розраховували, коли мене брали на роботу. На співбесіді на позицію директора я вирішував задачки на C. Фактично я є одним з лідерів команд розробки, тімлідом. Власне програмую я рідко. Займаюся більше code review, архітектурою, плануванням, допомагаю команді розв’язувати проблеми. Все ж таки менеджерських обов’язків більше — я стежу за тим, щоб чітко і правильно працювала інфраструктура, щоб були виконані всі задачі. А ще на мені операційна діяльність, керую офісом. Сюди входить робота з фінансами, юристами, контрагентами, адміністративні обов’язки. Якщо ж розділити адміністративну роботу як лідера офісу і роботу, яка є всередині команди, то стараюся, щоб це було 30% на 70%.

Коли Mellanox об’єднувалася з NVIDIA, був значний перегин, доводилося багато часу витрачати на зовнішню роботу — знайомства, перебудову процесів. Я був єднальною ланкою між Facilities, Security, HR, Legal, Finances. Коли все стало на колеса, юристи та фінансисти взяли на себе основні функції, а моїм основним завданням стало забезпечення роботи українського офісу. Тут уже працює понад 50 людей, і якщо я займатимуся суто програмуванням, то він не зможе нормально функціонувати.

Чому менеджер має бути технічно підкованим. Мені завжди подобалося програмувати, не думаю, що зміг би займатися суто адміністративними функціями. Так склалися зірки: невеликий офіс, сфокусований на R&D, всі, хто в нас працює, добре підковані технічно.

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

Я не очікував, що сфера Data-центрів настільки динамічна в плані розвитку технологій. У нас немає поняття сапорту. Приблизно 80% роботи — це розробка чогось нового.

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

Про технічні знання топменеджмент. Дуже гарно про те, чи потрібно менеджеру бути «технарем» чи краще бізнесменом-маркетологом, сказав Слава Панкратов. Усе просто: якщо менеджери в компанії технарі, то вони й найматимуть технарів на менеджерські посади; якщо ж вони самі маркетологи-бізнесмени, то, найімовірніше, набиратимуть менш технічних людей.

Я не думаю, що наші топи заглядають у код, але точно орієнтуються у сфері, в якій працюють. Коли основна цінність продукту не в гарній рекламі, як-от у Coca-Cola, а в революційних унікальних технологіях, то топменеджмент має не лише знатися на тому, що відбувається зараз, а й мати гарне технічне бачення, що буде з цим ринком у найближчі 5–10 років. NVIDIA народилася як компанія, що робила хорошу графіку, а тепер вона займається штучним інтелектом, системами ухвалення рішень, робототехнікою та іншим.

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

Про мультизадачність CTO. Деякі мої колеги вважають, що СТО не повинен програмувати, бо бачили схожий досвід в аутсорсі. Та чи не в кожного розробника бувало таке, що перед ним стоїть завдання, він добре розуміє, що треба зробити, і починає працювати. Раптом прибігає СТО і намагається запхати туди щось своє, так званий чайка-менеджмент. Це всіх злить. Ліпше б він взагалі не чіплявся, і тоді робота була б виконана швидше. Водночас я багато разів ще в часи фрилансу та аутсорсу ставав свідком, коли CTO розрулював такі ситуації, в яких розробники лише розводили руками. Особливо цінно це тоді, коли один девелопер знає, як програмка працює на iOS, другий — на Android, третій — сервер-сайд, а четвертий — фронтенд. При цьому СТО розуміє одразу все, може простежити весь ланцюжок і швидко знаходить, де саме проблема — в конфігурації, сервері чи в іншому місці.

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

Віталій Мокосій, CTO в Atola Technology

«На власне програмування я витрачаю не більше як 15% робочого часу»

Чи повинен СТО програмувати. Я вважаю, що програмувати для СTO, як часто пишуть в оголошеннях з найму, буде плюсом. Далеко не всі технічні директори зростають з програмістів. Це можуть бути колишні продакт-менеджери, QA, навіть спеціалісти з техпідтримки. Сисадміни теж можуть стати CTO за умови, що вони цікавляться роботою не лише з комп’ютерами, а й з людьми. В будь-якому разі програмування буде плюсом. Та на цій позиції варто вміти не так писати код, як читати й аналізувати його.

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

Про важливість емпатії на менеджерській посаді. Зараз у команді 25 людей, з яких 10 програмісти. І вже на цьому етапі я часто задумуюся про те, щоб зовсім відійти від програмування. Насправді я уже міг би остаточно припинити писати код, та роблю це, бо мені подобається. На власне програмування я витрачаю не більше як 15% робочого часу, бо вважаю, що першочергове завдання СТО — організовувати роботу так, щоб, з одного боку, на виході з’являвся продукт, а з іншого — співробітники почувалися добре. Левову частку роботи займає саме комунікація з людьми. Я не можу собі уявити CTO компанії чи навіть стартапу, більшого за двох людей (СТО і СЕО), який є повноцінною частиною команди розробки.

На етапі розвитку компанії, де вже з’явилися інвестори і продажі, потрібно багато часу приділяти комунікації: з клієнтами зовні — знімати їхні «болі», а ще не можна ігнорувати те, що відбувається всередині команди. Один з основних обов’язків топменеджменту — знаходити і вирішувати проблеми підлеглих. Наприклад, одне з запитань, які я люблю ставити на one-to-one: «А чим би ти хотів припинити займатися?». Зазвичай, якщо в людини є якась проблема, то вона одразу розповість про неї і ми разом знайдемо рішення, щоб її це більше не дратувало.

Водночас важливо ще й вибудовувати процеси найму таким чином, щоб в команду приходили програмісти, сильніші за тебе. На це треба дати собі внутрішній дозвіл і прийняти. Зазвичай у невеликих командах СТО стає найсильніший розробник у команді. Тобто певний час ти почуваєшся експертом, всі з тобою радяться, і це приємно. І от згодом приходить зовні або зростає всередині команди фахівець, сильніший за тебе. Це може викликати різні почуття, аж до синдрому самозванця. Можуть виникати думки на зразок: «Я вже не той» «Йду в утіль», «Генерація Z напирає» тощо. Їх краще трансформувати в позитивні емоції та думки на кшталт: «Класно, що в моїй команді є такі експерти», «Це програмісти, на яких я можу покластися», «Чудово! Мені завжди буде чого повчитися».

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

Про кодинг поза роботою. В індустрії я ще з 2003-го. В перші роки я мав власні проєкти: писав утиліти, створював блоги. Усе це працювало і навіть приносило кошти. Мені було цікаво, крім основної роботи, готувати щось своє. Та орієнтовно 6 років тому я ухвалив рішення, що мені потрібен жорсткий фокус — з того часу я зосередився на одній роботі й не створюю нічого вдома. Я можу також зробити щось для загального розвитку. Так кілька років тому у фронтенд вийшов Svelte. Я подивився про це відео, зайшов на сайт і вирішив щось написати, щоб промацати технологію. Авжеж, не цілий сайт, а якісь hello world’и. Мені потрібно було зрозуміти, чому цю технологію назвали next gen порівняно з React. Поза робочим часом я радше почитаю книжки, послухаю подкасти. Так недавно слухав подкаст DOU зі СTO Parimatch Григорієм Бакуновим. Він працює в компанії із сотнями інженерів, але все одно програмує просто тому, що йому це подобається.

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

На мою думку, буде CTO програмувати чи ні, більше залежить від самої людини, а не компанії, де вона працює. Якщо хочеться програмувати, то обов’язково треба це робити, але в чітких межах. Я думаю, в невеликих компаніях СТО може приділяти програмуванню до 30% часу. Якщо ж це компанія розміром з Uber, MacPaw, то не більше як 15%. Часто це перетворюється не в чисте програмування, а в code review, командні рішення з архітектури чи менторство.

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