В прошлый раз мы обсуждали PDCA — про оценку того, как рук-ль работает с командой. Теперь — о командах, на уровнях которых работает CTO (будем для общности называть его руководителем технического домена). CTO работает не только с разработкой. Его зона ответственности охватывает множество бизнес-доменов — от аналитики до маркетинга. Разберём, как это устроено на разных уровнях компании, определив, с кем он взаимодействует и из чего складывается оценка его деятельности.
[1 и 2] Операционно-тактический уровень - технари и тимлиды
Это, конечно, технарские команды, которых может быть несколько. Такой вот уровень работы «на земле» — операционный. Там и «бекенды», и «фронты», и мобильщики, и тестировщики, и технические писатели и т. д. и т. п. В общем, все те, кто работают руками.
Далее тимлиды, которые рулят теми самыми командами. Их команда — это уже не операционный, а тактический уровень. Все вместе и на операционном, и на тактическом уровне они занимаются развитием продуктов компании, генерируя постоянно их улучшения.
Здесь рождаются первые кросс-доменные задачи — например, взаимодействие с продуктовыми командами или аналитиками. На этом уровне CTO чаще всего проявляется как руководитель домена разработки: архитектура, темпы реализации, качество, технический долг.
Оценка CTO складывается из успешности работы по управленческой (тимлидской) и технарской (техника) частям.
[3] Уровень эксплуатации (operations) - инфра, кадры, бухгалтерия и пр.
Улучшения продуктов поднимаются на следующий уровень — уровень эксплуатации (operations). Ради него и пишется документация техническими писателями, настраиваются CI/CD девопсами — в общем, делается всё, чтобы уровень развития, как первые ступени ракеты, в любой момент бизнес мог отбросить как выполнившие свою функцию. Уровень эксплуатации — это уже третий уровень.
Здесь находятся техподдержка, те специалисты из DevOps-команд, которые занимаются эксплуатацией (мониторинг, алерты, инциденты и т. д.). Здесь идёт постоянно активное взаимодействие с эксплуатацией других доменов — например, HR, юридической поддержкой, Отделом Кадров, АХО, бухгалтерией и т. п.
На этом уровне от CTO требуется действовать по принципу минимального вмешательства, так как именно здесь находятся механизмы компании, обеспечивающие работу всей бизнес-модели. Для CTO крайне важна здесь стабильность работы его улучшений продуктов, а также скорость выката в эксплуатацию — для проверки гипотез, позволяющих тестировать на живом рынке новые предлагаемые ценности.
Здесь CTO взаимодействует с доменами DevOps, технической поддержки, внутренней безопасности, IT-инфраструктуры, а также доменами административных и кадровых служб, от которых зависит стабильность.
Оценка CTO складывается из того, насколько он грамотно обеспечивает эксплуатацию.
[4] Стратегический уровень - бизнес
Следующий уровень — бизнес-команда или C-level. Это уровень стратегии с долгосрочными перспективами. Это команда руководителей других доменов, с которыми идёт активное взаимодействие для координации общей стратегии по улучшению бизнес-модели. Если на уровне эксплуатации CTO ещё мог не взаимодействовать с продажами или маркетингом, то здесь у него идёт активнейшее взаимодействие с ними.
CTO на этом уровне включается во взаимодействие с доменами продаж, маркетинга, клиентского успеха, даже если они ему не подчиняются. Его задача — донести ограничения и возможности технологий до тех, кто строит бизнес-модель.
Оценка CTO здесь уже сложная, так как планировать, работать, контролировать и развивать ему приходится в зависимости от договорённостей с ключевыми внутренними группами.
[5] Внешний контур - рынок
И последний уровень — внешний контур, рынок. То, ради чего всё.
На самом деле вся компания со всеми доменами и уровнями — это его (рынка) гипотеза. Рынок, по сути, проверяет гипотезу (в виде инвестиций), экспертизой (в виде сотрудников и консультантов). Рынок может даже проводить валидацию. Это может быть due diligence от инвесторов, ревью со стороны партнёров или требования аудиторов в регуляторной среде. Если гипотеза оказывается верной — он меняет инвестиции финансов и внимания кастомеров на ценность, предоставляемую продуктами компании.
Оценка CTO здесь складывается из способности активно взаимодействовать с рынком по всем направлениям: от привлечения экспертизы до прохождения аудитов.
Итог
В каждом из этих уровней CTO взаимодействует с разными доменами компании. Получается сетка из уровней и функций, по которой можно диагностировать слабые места и что именно надо прокачивать или делегировать. Этот подход можно применять к любому домену. Вот как может выглядеть эта конфигурация на примере домена разработки: оперативно-тактический уровень, уровень эксплуатации, бизнес-уровень и уровень рынка.
Такую конфигурацию можно использовать для выявления пробелов в ответственности, фасилитации стратегических сессий и настройки фокуса роли CTO. Эта не оценка, как я уже в прошлый раз говорил, не дамоклов меч, а конфигурация конкретного CTO — в зависимости от того, что представляет собой компания: стартап, бигтех или вообще перекуп. Понимание своей конфигурации помогает CTO оценить зрелость своей роли, адаптировать систему управления и выстроить архитектуру под задачи компании.
Домашнее задание для закрепления
Возьмите любой уровень, начиная с эксплуатации, и выделите все ключевые внутренние группы и их представителей - стейкхолдеров, с которыми вы взаимодействуете. Попробуйте оценить каждое взаимодействие в формате дроби:
– в знаменателе — их реальные ожидания от вас,
– в числителе — то, как вы презентуете свою работу по этим ожиданиям перед стейкхолдерами;
Такая простая модель быстро покажет, где возникает разрыв — и что стоит развивать или делегировать.
