Будучи признанным техническим директором (CTO), имея частичную занятость в качестве технического директора в пяти разных компаниях, а также являясь бывшим техническим директором, работающим уже на полную ставку в трех разных стартапах, и, наконец, как человек, который в настоящий момент руководит агентством по разработке программного обеспечения и запускает свои собственные продукты, я могу с уверенностью сказать, что в течение первых 30 дней работы в качестве CTO у вас не будет времени на шутки.

Я расскажу вам, как извлечь максимум пользы за это время…

Проявите инициативу

Вам стоит понять, что вас наняли, чтобы вы несли ответственность за выполняемую работу. Раньше я ждал поддержки от команды или CEO, чтобы меня ввели в курс дела. Теперь же я не жду, а просто беру инициативу в свои руки. Меня наняли для того, чтобы я выполнял свою работу, и именно от меня зависит в каком направлении поплывет этот корабль. Например, организуйте ланчи с командой в неформальной обстановке и без промедлений планируйте выездное развлекательное мероприятие. 

Определяйте паттерны, элементы дисфункции и ведите подробные записи. Будьте Шерлоком Холмсом и начните распознавать, что люди на самом деле подразумевают под своими словами. Прислушайтесь к тому, о чем шепчутся люди вокруг... Я знаю, что это ужасно, но вам придется играть в эту игру.

Если у членов вашей команды есть какие-либо недостатки, вам нужно знать о них СЕЙЧАС, прежде чем вы встанете у штурвала.

СОВЕТ ОТ ПРОФИ: делайте записи. Создайте систему показателей для каждого из ваших подчиненных и начните определять, какие у них цели и насколько они в этом преуспели.

Задавайте вопросы «Почему, Что, Как и Кто»

Давайте посмотрим, чем же вы будете заниматься следующие несколько недель.

Вопрос «Почему?»

Почему мы создаем именно этот продукт? Поговорите с руководителями компании. Узнайте какое у них видение. Чаще разговаривайте с продакт-менеджерами, и поймите, на каком этапе они находятся. Будьте с ними по-настоящему честны. Дайте им знать, что ваши отношения крайне важны для достижения успеха этой компании.

Ошибка очень многих компаний заключается в том, что продакт-менеджеры и руководители отдела технологий обвиняют друг друга в недочетах. В прошлом мне удавалось избегать этого хаоса благодаря объединению отдела по продукту и отдела по технологиям в один технологический отдел. Хотя многие терпеть не могут эту стратегию, она полностью оправдала себя в компаниях, с которыми я работал. В вашей компании может не быть такой гибкости и возможности объединения, поэтому вам лучше всего работать в согласии с командой по разработке продукта.

Несколько вопросов, которые вы можете задать:

  • Почему мы создаем этот продукт?

  • Почему этот продукт найдет отклик у наших клиентов?

  • Почему он важен для рынка?

  • Почему именно наша команда подходит для создания этого продукта?

  • Почему кто-то другой не создал этот продукт до нас?

  • Почему нас воспринимают всерьез?

  • Почему люди готовы работать день и ночь для реализации этой идеи?

  • Почему наши коллеги доверяют нам быть лидерами?

Советы:

  • Узнайте о каждом проекте, которые планирует реализовать ваша компания.

  • Узнайте о всех текущих проблемах, с которыми сталкивается команда по разработке продукта.

  • Распишите все цели на год, шесть и три месяца и проанализируйте стратегии на эти периоды.

  • Периодически разговаривайте с вашим CEO и просите посвящать вас в его видение почаще. Помните, согласны вы с этим ним или нет, успех будет зависеть только от ваших действий. Потому что если вы не можете воплотить это видение, у всей компании будут проблемы.

Вопрос «Что?»

После того, как вы получили ответы на вопрос “Почему”, пора переходить к следующему вопросу “Что?”. Что именно мы создаем? Узнайте о каждой составляющей вашего флагмана. Если вы начинаете с нуля, пора перейти к чертежной доске и определить, что мы пытаемся создать.

Сильно не мудрите. Цель состоит в том, чтобы НЕ переусердствовать. Достаточно будет нарисовать на доске несколько блоков, чтобы мы понимали, что мы создаем.

Часто я просто рисую блок-схему различных подсистем и их взаимоотношений друг с другом. Знать все детали о вашем флагмане критически важно. Если у вас не получается отразить все на листе бумаги, значит, вы делаете что-то неправильно.

Несколько примеров вопросов “Что?”, которые вы можете задать:

  • Что мы создаем?

  • Что из себя представляют подсистемы?

  • Что является основным направлением развития этой системы?

  • Что из себя представляет минимально жизнеспособный продукт (MVP)?

  • Что именно в нашем продукте будет вызывать удивление у клиентов на ежедневной основе?

  • Что мы предприняли для измерения соответствия продукта рынку?

  • Что не дает тебе уснуть по ночам? Что НЕ работает?

  • Что из себя представляет процесс приема на работу?

  • В чем заключается процесс утверждения нашего продукта?

  • В чем заключается процесс разработки программного обеспечения?

  • Что есть процесс управления релизами?

  • В чем заключается процесс управления изменениями?

  • Что из себя представляет общение в нашей команде?

  • Какие из процессов работают действительно хорошо?

Вопрос «Как?»

Когда вы получили ответы на вопросы “Почему?” и “Что?”, переходите к вопросу “Как?”. Здесь все вращается вокруг процессов.

  • Как мы строим наш флагманский проект?

  • Как мы будем его внедрять?

  • Как мы собираемся выходить на рынок?

  • Как мы объединяем все наши команды для реализации подсистем, которые мы определили, когда отвечали на вопрос “Что?”?

  • Как обстоят дела?

  • Как мы можем стать лучше?

  • Как мы измеряем успех/неудачу?

  • Как мы празднуем наши победы? (И ДА - если вы этого не делаете, вам нужно изменить политику)

  • Как мы автоматизируем процессы?

  • Как не изобретать велосипед заново?

  • Как мы относимся к нашим партнерам/поставщикам?

  • Как мы работаем с нашими партнерами/поставщиками?

  • Как часто мы делимся своим видением с командами?

  • Как часто мы взаимодействуем с окружающим нас техническим сообществом?

  • Как мы позиционируем наш продукт?

  • Каков уровень согласованности технического отдела с остальными?

Я мог бы продолжать и продолжать еще долго, но суть вы уловили...

Вопрос «Кто?»

Это моя любимая часть. На этом этапе обнаруживается, в чем именно есть явные недоработки в бизнесе. Но если вас это удивило, возможно, вам не стоит заниматься стартапом.

Для растущих компаний я очень рекомендую книгу “Traction” Джино Викмана (Gino Wickman). В ней говорится о том, как подобрать нужного человека на подходящую ему должность.

Для любой команды, которую я возглавляю, крайне важно, чтобы нужные люди занимали нужные места. Помните записи, которые вы делали о подчиненных? Пришло время поразмыслить над этим.

Вы уверены, что люди в вашей команде “Понимают”, “Хотят” свою работу и “Довольны ее результатом” ?

Вы уверены, что остальные отделы (по крайней мере, те, с которыми вы взаимодействуете) также “Понимают”, “Хотят” свою работу и “Довольны результатом”? Вы не можете изменить направление развития других отделов, если эти моменты не совпадают. Однако очень важно, чтобы вы постоянно расставляли плюсы и минусы в столбцы “Понимают”, “Хотят” и “Довольны результатом” для всех членов команды, с которыми вы работаете.

Даже если у кого-то есть минус по какому-то из пунктов, и вы не способны сейчас с этим ничего сделать, вы можете заранее выстроить стратегию.

СОВЕТ: Вот почему я обычно не работаю CTO на полную ставку, если только я не являюсь владельцем акций с очень высокой долей участия. Я отказываюсь работать в компаниях, где я не могу влиять на решения в других отделах или где другие отделы имеют слишком большое влияние на CEO, в то время как техническое руководство не может влиять на решения. Если вы разбираетесь в продуктах, продажах, маркетинге, технологиях и лидерстве, вам также следует серьезно задуматься над этим.

Вопросы “Кто?”, на которые у вас должны быть ответы:

  • Кто тот человек, который понимает все подсистемы?

  • Кто работает здесь дольше всех? (СОВЕТ ОТ ПРОФИ: сходите вместе с ним на ланч)

  • Кто тот человек, который поднимет трубку посреди ночи, если что-то пойдет не так?

  • Кто тот человек, к которому прислушивается CEO? Хорошо это или плохо, но с этим человеком нужно дружить.

  • Кто на самом деле главный? Сюрприз… вы поймете, что ваш CEO не всегда является главным, даже если его все заставляют думать, что это так.

  • Кто проявляет наибольший оптимизм в отношении этой компании?

  • Кто наиболее пессимистичен в своих взглядах?

  • Кто управляет DevOps?

  • Кто является ведущим/главным архитектором?

  • Кто отвечает за прием на работу?

  • Кто отвечает за утверждение бюджета? СОВЕТ ОТ ПРОФИ: подружитесь с ними. Вам это пригодится.

Повторюсь, я мог бы продолжать и дальше… но вы меня поняли.

Теперь, когда вы разобрались в положении дел, пора сделать следующее.

Переварите все

Не торопитесь. Вы только начали свою работу. Ваши первые 30 дней работы не изменят направление развития компании, и от вас этого не ждут.

С другой стороны, теперь у вас есть записи, полные заметок, наблюдений, показателей и стратегий, на которые вы можете положиться в течение следующих 30 дней.

Увидимся через 30 дней.


Материал подготовлен в рамках курса «Microservice Architecture».

Всех желающих приглашаем на бесплатное demo-занятие «Паттерны декомпозиции сервисов». На открытом уроке мы разберем разные подходы к декомпозиции микросервисов: Monolith first, разбиение по агрегатам, по бизнес-возможностям, функциональную модель и разбиение по транзакциям. Немного поговорим про Event storming, BDD/User story, а также рассмотрим подходы к описанию сервисов.
>> РЕГИСТРАЦИЯ

Комментарии (5)


  1. vakhramov
    03.12.2021 16:26

    Надо уточнить - статья больше про нанятого с улицы CTO в софтверных компаниях, вероятно - с типовыми решениями (раз работая в 5 местах не приходится капитально переключать контекст).

    В моей практике производственного предприятия роли CEO и CPO распределялись между CTO, CSO и CCO.

    Ключевые люди в компании - директор по продажам, техдир и безопасник. Кто из них имеет право подписи - формальный вопрос (когда человек не "с улицы").

    Другой вопрос - сейчас компании, работавшие ранее без CTO, по мере обрастания технологиями получения, обработки и преобразования данных, могут их нанимать "с улицы". СТО в таких компаниях имеет не очень большое влияние, к сожалению. И даже деньги на нормальную полную ставку они просто жмут, потому что "обходились же они до этого без таких трат", а обязанности вменяют по полной :)

    Если у кого-то другой опыт, делитесь в каментах, господа и дамы.


    1. victor_1212
      03.12.2021 17:11

      > статья больше про нанятого с улицы CTO в софтверных компаниях, вероятно - с типовыми решениями

      автор оригинала Anup Marwadi, его резюме в большой степени опыт разработки SaaS


  1. excoder
    03.12.2021 16:32
    +3

    Сейчас под CTO кого только не подразумевают. От старших разработчиков до лидеров маркетинга.


    1. Rzip
      03.12.2021 21:19
      +1

      100%


  1. NeverIn
    04.12.2021 10:39

    Никто не станет отвечать на такое количество таких вопросов. Подумают что юниор на стажировке. К такому человеку приходят за ответами.