Коли молодій SaaS-компанії потрібен CTO?

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

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

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

Почніть із рішень, за які хтось має відповідати

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

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

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

Шукайте сукупність ознак, а не черговий раунд фінансування

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

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

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

Оберіть найменший формат керівництва, достатній для поставлених завдань

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

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

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

Надайте керівникові повноваження, факти та зрозумілий порядок роботи

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

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

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

Уникайте поширених помилок під час найму CTO

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

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

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

Переглядайте формат технічного керівництва разом зі змінами компанії

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

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

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

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