Роль CTO в software-аусорсинговій компанії [ukr]

Дуже радий вас бачити. Відверто кажучи, здивований, що тут так багато людей. Сьогодні ми будемо говорити про роль CTO в аутсорсинговій компанії. Підніміть, будь ласка, руку ті, хто працює в продуктових компаніях, а не аутсорсингових. Добре, а тепер ті, хто працює в аутсорсингових компаніях? Добре, приблизно порівняно 50 на 50. Загалом, класно. Добре, щодо адженти. Розкажу трошки історії і поясню, чому я вирішив саме цим поділитися. Також, трошки розкажу про архітектуру аутсорсингової компанії. Це може бути цікаво для тих, хто працює в продуктових компаніях. І далі за текстом. Не буду заглиблюватися у деталі адженти. Два зауваження. Коли я готував цю презентацію, мені дали зворотній зв'язок. По-перше, я буду говорити про свій досвід та досвід інших CTO в аутсорсингових компаніях. Це не стосується продуктових компаній. По-друге, мені сказали, що це може виглядати так, ніби я рекламую фінтех-сервіси своєї компанії. Я цього не роблю. Ми, в принципі, не працюємо на ринку України. Так що, якщо вам це здається так, це не так.

Отже, чому ця тема? В нас, з Львова, є таке CTO-спільнота. Вона, мабуть, виникла близько двох років тому. І я пригадую першу зустріч. Зібралися, прийшло, мабуть, близько 30 людей, які почали знайомитися, розповідати, чому вони тут, які очікування. І там було щось подібне. Наприклад, я СТО такої-то компанії і прийшов, щоб дізнатися, що робить CTO в компанії та яка його роль. Інший, я СТО такої-то компанії, також цікаво дізнатися, чим займаються інші CTO. Було класно, коли хтось із десяти сказав, що він взагалі CIO компанії і прийшов сюди, щоб зрозуміти, що має робити його CTO. Так що ця тема справді мене цікавить. Також я спілкувався з людьми з інших компаній, щоб трохи привнести освітлення та зрозуміти, чи існують загальні патерни. Оскільки, якщо порівняти з іншими ролями в компаніях, наприклад, у Sales Officer, там все просто скільки ти приніс нових продаж. Delivery Officer, теж просто, скільки revenue згенерували від існуючих клієнтів.

З технічної точки зору, як CTO, в кожній компанії це трохи різниться. Тому я поділюся своїми відкриттями і розповім трошки про свій досвід в компанії Sombra. Коротко про мене. Я почав більше 15 років тому як просто інженер. Працював я і в продуктових компаніях, і в одній аутсорсинговій. Потім я вирішив створити стартап для юристів в Україні, який працював близько півтора роки. Після цього я став співзасновником компанії Sombra. Це було 10 років тому. Так що ось коротко про мене. Щодо компанії, фактично вона була заснована 10 років тому і почала як простий аутстаф одного інженера для клієнта зі США. Зараз у нас більше 300 людей та приблизно 30 клієнтів. Ми спеціалізуємося на роботі з компаніями зі США та Канади, а розміром ми приблизно однакові. Не буду глибоко заглиблюватися у деталі.

Найважливіші стратегічні моменти для нас – це ріст. Ми постійно ростемо і хочемо продовжувати це робити. Це призводить до певних впливів на роль кожного у компанії, зокрема CTO. Ми – це переважно сервісна компанія, тобто ми не створюємо власні продукти. Є компанії, що намагаються робити і те, і те, але ми зосереджені саме на послугах. Останнім часом ми розширюємо свою діяльність і плануємо відкрити офіси у США. Недавно відкрили офіс в Колумбії. Це також впливає на роль CTO. Оскільки ми – сервісна компанія, основне, що ми робимо – це надання послуг. Починалося це як Java розробка в 2013 році, а з часом ми додавали нові сервіси. Так виглядає розвиток аутсорсингових компаній, особливо для тих, хто працює в продуктових компаніях. Так що це про нас у загальних рисах. Якщо є питання, ви можете задавати.

Це, якщо говорити про такі експертизи. Інше, ми, крім такого чистого аутсорса, почали самі розробляти клієнтам, повністю рішення. Це, як інший сервіс. Ось, це воно, з часом ускладнювалось. І останнє, що ми запустили, це, власне, консультування клієнтів в наших ключових ринках, Сполучені Штати та Канада, з питань Фінтеху. Цьому проекту вже рік. Ось, і це, власне, якби такий ще один складніший сервіс. Якщо коротко, то намалювати, як виглядає структура аутсорсеної компанії, це, от, є клієнти і є інженери. І, компанія пробує всадити на цих двох, в даному випадку, вантажівках, тому що бувають перекоси. У 2021 році, я думаю, всі знають, було дуже складно шукати інженерів, інженери сиділи з 10 пропозиціями і вибирали просто. Тобто, тоді був перекос ринку в сторону, реально, інженерів.

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

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

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

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

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

Це також стосується мого офісу. Підтримка, доставка — це конкретні проекти, які ми вже розробляємо, і в них відбуваються якісь, скажімо, нестандартні, нетрадиційні речі, і поточна команда не може з ними впоратися. Ось, підтримка HR — це кар'єрний шлях інженерів. Тобто, ми вже зараз переходимо в частину людей, тобто розробка кар'єрного шляху. Хто такі джуніори, хто такі мідли, хто такі сіньори в своїх напрямках. Рекрутинг і ресурс-менеджмент сепорт, тобто це технічний відбір кандидатів, як саме ми, фактично, взаємодіємо і тісно співпрацюємо з кар'єрним шляхом, тобто як ми визначаємо під час короткого інтерв'ю, годинного інтерв'ю чи там двогодинного інтерв'ю, якого рівня є людина. Підтримка емплойер-бренду — це власне виступи на конференціях, такі, які я зараз роблю. І інші матеріали, як ми себе презентуємо на ринку, те, що називається ринком кандидатів для компанії. Я тут власне закреслив "продакт", тобто в продуктових компаніях є продакт-менеджери, у нас же продуктів, як таких, немає, у нас є сервіси, тому я назвав це сервіс-менеджментом, тобто фактично основне, що ми продаємо, це саме сервіси, які я описував, і менеджмент цих сервісів фактично вирішує, як ми взаємодіємо з цими сервісами, приймає рішення про те, чи ми починаємо цей сервіс, чи ні, умовно, надаємо дослідження, чи є попит на ці сервіси — це є частиною моєї роботи.

Так от. І моя команда, власне, я наразі сформував її як команду з компетентних лідів для кожного з інженерних напрямків, тобто тут вони перераховані. Я не буду докладатися в деталі, але умовно це є там розробка, напрямки QA, UX, бізнес-аналіз, тобто, грубо кажучи, все, що необхідно для того, щоб сформувати команду для розробки, умовно, із DLC. І команда FinTech експертів — це новинка, що у нас почалася фактично цього року, тобто це така маленька команда, над якою ми працюємо і, умовно, розширюємо нашу експертизу в самому FinTech-домені. Ось. Якщо взяти трошки детальніше, то от команда — це всі ці люди, не всі з них, тобто деякі працюють на повний робочий день в цій ролі, а деякі поєднують її з роллю розробки на проекті, тому що не всім компетентніс-лідам завжди є достатньо роботи прямо на 100%. Ось. Тому це десь так виглядає. Для деяких напрямків у нас ще немає лідера, тобто ми просто їх починаємо. Скажімо, це такі тестові сервіси. Чи сподобається клієнтам, чи буде для цього достатньо попиту. Ось. Які є проблеми? Проблема, власне, полягає в тому, що зараз, як видно, в моїй команді досить багато людей, тобто приблизно 10, і ще буде надходити. Це зараз є найбільшим викликом для мене, оскільки, ну так, я вважаю, що всі знають, що менеджмент команди з 5-7 людей є оптимальним. Більше — це починає забирати більше часу. Також збільшується кількість контекстів. Тобто, окрім команди, у мене ще є різні контексти, умовно, наприклад, стратегічна робота і участь в стратегічних зустрічах, запуск нових сервісів, впровадження цього всього. І, власне, мені порадили дуже корисну річ. Варто також враховувати це при управлінні особистим часом, тобто не тільки кількість людей, яких ви керуєте, але і кількість контекстів, на які ви перемикаєтеся.

Ось. Тому це зростає, і це, насправді, досить складно. Сумарна кількість інженерів в компанії, хоча вона не підпорядковується мені, також зростає. І, знову ж таки, тут потрібно якось змінювати оргструктуру під це. З того, що я спілкувався з різними компаніями, власне, є винятки. І що впливає, власне, на роль CTO? Якщо коротко, це... Я би трошки зробив крок назад. Це те, що фактично ця роль дуже відрізняється від компанії до компанії. І всі кажуть, що це залежить від стратегії. Тобто, умовно, цю роль треба адаптувати. Не можна сказати, що CTO однаковий, чи всі працюють над однаковими задачами. Все залежить від стратегії. Умовно, на яких ви ринках працюєте, хто ваші клієнти. Загалом, за що ви відповідальні як CTO. Бо може бути так, що ви дуже часто, типу, будете відповідати за речі, за які відповідальний інший відділ. І там треба буде провести чітку, різницю, паралель між вашою відповідальністю і відповідальністю інших людей.

Наприклад, дуже часто... Ну, сорі, не дуже часто, але бували випадки, коли маркетинг підпорядковується CTO. Наприклад, кажуть, "Окей, ти відповідальний за сервіс, і ти відповідальний за маркетинг цих сервісів, тому найми собі маркетолога, умовно, і продавай ці сервіси." Це накладає певне ускладнення. Інколи буває, коли в вашу роль так само включають відповідальність за IT-департамент і кібербезпеку. Це ускладнює в тому сенсі, що там може вилазити багато речей, відповідно, треба взяти людину, якщо ви розтягнуті. І важливо в тому не загрузнути. Також я зустрічав в разі спілкування з іншими CTO ситуації, коли CTO були дуже занурені, скажімо, в проекти конкретних клієнтів. Ну, наприклад, є такий ключовий клієнт, він приносить 50% доходу, і CTO фактично тратить 50% свого часу, працюючи з цим клієнтом. Тобто, по суті, він виконує роль архітектора на цьому проєкті, або ще когось. І це дуже змінює, фактично, цю роль. Тому що, по суті, це парт-тайм людина на проєкті, парт-тайм CTO. Ось. Те саме з якимось гасінням пожеж. Так само ще буває, що я це стикався в більших компаніях, є одна велика компанія, знову ж таки не буду називати, де CTO, він практично так і називається, він якби Chief Architect. Тобто, він приймає основні архітектурні рішення для клієнтів. Ще дуже важливою частиною, яку я бачив, багато компаній, особливо сервісних, вони, коли, в меншому розмірі, вони починають розглядати варіанти робити свої продукти. Тобто, умовно, ми обслуговуємо клієнтів, от, в нас виникла класна ідея, давайте ще зробимо якийсь продукт, наприклад, для менеджменту, не знаю, зробимо ще одну апку, або ще щось, і почнемо продавати, подивимося, як воно йде. І це також дуже змінює фокус того, куди залучатися CTO, бо насправді в продуктовій частині там велике, величезне залучення цієї ролі. І це починає відвертати фокус від, там, сервісної частини, а не продуктової. І це треба якось манеджити, якось розділяти.

Фактично, якщо основні такі висновки, то всі KPI залежать від кількості клієнтів, саме в аутсорсинговій компанії, локації клієнтів, кількості інженерів. Дуже впливає попередній бекграунд CTO, тобто, умовно, якщо це є DevOps в минулому, то він буде фактично затягувати все в сторону DevOps, і, може бути складно. Так, як в мене була роль, я був колись Java-інженером, і я все бачив через призму інженера. І коли з'явилася потреба, умовно, будувати експертизу, з тестуванням легше, по дизайну, по бізнес-аналізу, воно трохи ускладнює. Знову ж таки, тому що, скажімо так, дивитись на все треба трохи під іншим кутом, і експертизи, скажімо, бізнес-аналізів в мене було, ну, мало. І бачення на наступні 5-10 років так само дуже впливає. Тобто, наприклад, дуже залежить від того, чи компанія залишається далі на тому самому розмірі, чи вона буде рости. Якщо буде рости, то наскільки? Тобто, це якийсь дуже різкий ріст через, наприклад, ті ж mergers and acquisitions, що буває, покупки інших компаній. І це є історія одної більшої компанії, де, активно скупляє менші аутсорсингові компанії, і там в роль CTO входить, власне, пересвідчитись в тому, що от купили якусь компанію на 50 людей в Колумбії, і треба переконатись, що інженери, колумбійські інтегрувалися в роль, умовно, інтегрувалися в процеси цієї компанії, яка купує. Чи будуть змінюватись сервіси? Тобто, не малі, є компанії, які працюють, умовно, по чистій отстав моделі. Тобто, умовно, вони просто беруть людей, продають, наберуть на себе додаткове якесь відповідальність за management scope, будь-чого. Це те, що називають прості сервіси. Є складніші сервіси, де аутсорсингові компанії кажуть, окей, ми вам готові зробити рішення, взяти на себе більше відповідальності, вкластися в дедлайни, вкластися в бюджети. Питання в тому, як це буде в вашій компанії, якщо йдеться про аутсорсингову компанію. Чи ці сервіси будуть ставати складніші, чи будуть лишатись такі, які є. Так, про march і acquire це я вже казав. І продукти. Так, продукти, вони дуже впливають. Тому, якщо ви плануєте це робити, додавати якісь продукти, майте на увазі, що це буде складно. З мого досвіду, якщо ви плануєте поєднувати аутсорсингову компанію, плануєте робити продукти свої, це складно. І я чесно, я не впевнений, чи я бачу успішні кейси цього, бо зазвичай це або просто робиться повністю окремо продуктова компанія, або повністю сервісна компанія. Тяжко всидіти на двох цих, умовно, гілках. Я насправді, дуже багато говорив, що я перелімітив, тому я вклався раніше і буду радий відповісти на ваші питання.